Edge Architecture: Infrastructure Management
Design an edge estate so that local systems remain autonomous, observable, and changeable at scale.
Edge infrastructure management is the discipline of operating many local systems without pretending they are one central server. A sound architecture makes each node accountable for its local workload, data, and recovery, then provides explicit management paths for visibility, change, and integration. This avoids the two familiar failures of distributed systems: isolated appliances that cannot be supported, and a central control plane that becomes a dependency for local work.
Managing the edge means managing boundaries
An edge node occupies several boundaries at once. It is close to physical equipment, often connected through an imperfect local network, operated by people who may not be on site, and expected to exchange selected information with other systems. Its architecture must therefore define more than software modules. It must define where data is processed, which actions continue during isolation, how users reach the node, who can alter its configuration, and how a change can be verified or reversed.
Management is not synonymous with centralisation. The management plane should make the system visible and supportable; it should not be on the critical path for acquisition, recording, detection, or local automation. In Banalytics, the Agent performs local work on operator-controlled hardware. The portal provides signalling and browser access to that Agent, while the principal workload and its data remain at the site.
The practical architectural question is simple: if the upstream connection disappears for an hour, which outcomes must still be delivered locally? The answer determines the local data plane, storage, rule placement, and recovery design. Everything else can then be managed through a controlled remote path.
Use three planes with clear responsibilities
| Plane | What it owns | How it should behave during an upstream outage |
|---|---|---|
| Local operational plane | Device connections, acquisition, processing tasks, recordings, local events, and time-sensitive actions. | Continues independently according to the local configuration and available resources. |
| Management and support plane | Configuration access, component UI, dashboards, diagnostics, upgrade requests, and operator collaboration. | Remote functions may be unavailable, but loss of access must not stop the local workload. |
| Enterprise integration plane | Selected events, measurements, reports, commands, and data packages consumed by upstream systems. | Uses explicit queues, protocols, or retry behaviour appropriate to the integration; it is not the source of local truth. |
This model makes design reviews more concrete. Instead of asking whether a system is “cloud-connected,” a team can ask whether a specific workflow belongs in a local task, a browser-facing management function, or an external integration. The answer can differ for a critical alarm, a dashboard refresh, a model update, and an enterprise report.
Give every node a declared operational role
An unmanaged edge estate is usually a collection of machines whose purpose is remembered informally. A manageable estate starts with a node contract: which devices it owns, the local data it retains, the tasks it executes, the events it can produce, the storage headroom it needs, and the users or systems permitted to interact with it.
Banalytics makes the runtime model explicit. Components represent connected resources and services; tasks do the work; events carry changes in state; and actions define the response. This is more than terminology. It lets a support engineer identify the smallest affected scope when a connection, model, stream, or rule needs attention. The component and module model is documented in Banalytics Modules.
- Equipment boundary: device types, protocols, physical location, ownership, and expected availability.
- Data boundary: raw data, retained evidence, derived events, retention period, and approved export routes.
- Workload boundary: processes, model workers, tasks, rules, and the local recovery behaviour of each.
- Operations boundary: required health indicators, permitted users, remote access requirements, and escalation path.
Architect the path according to latency and ownership
Not all data needs the same transport. A camera frame delivered to a local model, an in-process measurement, a value shared between local processes, and an event sent to an external consumer have different latency, reliability, and operational requirements. Treating every exchange as a remote API call creates unnecessary dependencies; treating every exchange as an internal shortcut makes integration and diagnosis difficult.
Banalytics supports transport tiers that range from in-process and shared-memory exchange to ZeroMQ IPC/TCP, MQTT, and external integration paths. The important management principle is to document each boundary: which producer owns it, whether it is local or remote, what happens during a disconnection, and what evidence is retained when delivery fails. The industrial sensing reference architecture describes this pattern in How Banalytics Works for Industrial Sensing.
Use remote access for operation, not to relocate execution
Remote access is necessary in a distributed estate, but its design matters. Banalytics Portal Integration registers the local environment through a WebSocket signalling channel. A browser then establishes an authenticated peer-to-peer WebRTC connection to the Agent for data, media, files, and shared access. The pattern allows an authorised user to work with a local system without configuring inbound port forwarding or a traditional VPN for that session.
The remote path is also the path through which agent-provided UI resources are synchronised. In the 2.0 architecture, modules package their matching browser resources; the portal is the common management shell, rather than a static catalogue that must know every component in advance. This keeps a specialised component interface close to the capability that owns it. See Portal Integration and Architecture 2.0 for the implementation details.
Remote management still needs a local fallback mindset. A site should have documented local access, a clear restart and recovery procedure, and enough retained evidence to investigate an issue after the remote channel returns. The remote portal improves reach and consistency; it does not remove the need to design the node as an independently operating system.
Changes are infrastructure operations
Configuration changes, new model versions, device additions, and module upgrades all alter the behaviour of an edge node. They should be treated as operations with a target state, maintenance window, validation criteria, and recovery plan. A fleet becomes difficult to support when its actual software and configuration differ from the intended state without a visible record of why.
Banalytics capabilities are delivered as independently versioned modules. The operator can inspect installed versions and select updates or rollbacks; the Portal Software Upgrade Center stages packages locally and applies the new module set during restart. That sequence makes a change observable and keeps previous module sets available for recovery. The relevant procedures are documented in Version and Module Management and Portal Software Upgrade Center.
| Change type | Minimum control | Post-change evidence |
|---|---|---|
| Device or protocol configuration | Validate the local connection and an expected data sample before enabling automation. | Component state, a sample event or measurement, and a documented rollback setting. |
| Task, rule, or action change | Prove the narrow workflow in a controlled window before broadening its scope. | Input, resulting event, action outcome, and absence of unintended repeat activity. |
| Module or model update | Stage the version, plan a restart, and keep a recovery path. | Installed version, health after restart, and a representative end-to-end workload result. |
| Remote-access change | Verify the intended user scope and connection behaviour from outside the local network. | Successful authorised session and confirmation that local work remains independent of it. |
Manage node health as part of the architecture
Health is not a dashboard afterthought. It tells the management plane whether the local contract is still being met. A node might remain reachable while its disk is nearly full, its native memory is exhausted, a media stream is backing up, or browser sessions are creating transport pressure. These conditions need a defined signal and a proportionate response.
The System Monitor publishes CPU, memory, disk, thread, WebRTC, media, and user-activity metrics as System state events. These can be displayed, retained, and used by Event Manager rules. For architecture reviews, define which measurements represent a capacity warning, which require a local corrective action, and which need an operator decision. Avoid turning every metric into an alert: signal quality is part of operational reliability.
Seven questions before you replicate a site design
- What remains local? Name the acquisition, processing, storage, and response functions that cannot depend on upstream connectivity.
- What leaves the node? Define the event, measurement, file, or control contract for every external consumer.
- Who owns each integration? Assign a responsible component, protocol, retry or recovery behaviour, and diagnostic record.
- How is the node reached and supported? Specify authorised remote access, local fallback access, and the evidence needed for troubleshooting.
- How does it report degradation? Set the resource, workload, and connection signals that indicate the node is outside its operating envelope.
- How does it change safely? Document validation, maintenance windows, version control, and rollback for configuration and software changes.
- Can the pattern be repeated? Confirm that a second site can be deployed from the same node contract without importing undocumented assumptions from the first.
Edge infrastructure management succeeds when local autonomy and central operability reinforce one another. The architecture should make every node trustworthy on its own, while giving the wider organisation enough control to operate the whole estate deliberately.