Edge Infrastructure Platform
A practical foundation for operating distributed physical systems without sacrificing local autonomy.
Edge infrastructure is more than hardware deployed away from a data centre. It is the operating foundation that connects local compute, devices, storage, messaging, monitoring, and remote administration into a repeatable system. The platform must let each site continue useful work locally while giving operators a disciplined way to see, change, and support the estate.
What an edge infrastructure platform actually provides
An edge infrastructure platform is the operational substrate for distributed workloads that interact with the physical world. It establishes a local execution environment beside equipment, connects the required protocols and devices, retains data where it is produced, and provides controlled visibility beyond the site. Its purpose is to make a fleet of local systems operable as an estate without turning every data path into a cloud dependency.
This is distinct from a generic virtualisation layer or a cloud container service. Those tools solve important compute-management problems, but they do not by themselves establish the acquisition path, device state, local retention, event model, or operator workflow required by cameras, sensors, controllers, and specialist processing modules. The infrastructure layer must own the boundary where software meets an unreliable network and a changing physical environment.
In Banalytics, the local Agent is that execution point. It runs on operator-controlled hardware close to devices, while the browser portal is used for configuration and remote access. The architecture is local-first: recordings, measurement streams, processing tasks, and local rules do not require a permanent cloud data plane to function.
Separate the local data plane from the management plane
A useful edge design separates the work that must remain local from the services that help people operate it. The local data plane acquires, processes, records, and reacts near equipment. The management plane presents configuration and operational state to authorised users. Enterprise systems consume selected events or data packages through explicit integration boundaries rather than becoming a hidden prerequisite for every local decision.
| Layer | Primary responsibility | Banalytics pattern |
|---|---|---|
| Local edge node | Connect to equipment, execute tasks, evaluate local events, and retain the data that must stay at the site. | Agent, components and tasks, local file storage, Event Manager, cameras, industrial devices, and custom processes. |
| Site data plane | Move raw and structured data between local services with predictable latency and failure behaviour. | In-process, shared-memory, ZeroMQ IPC/TCP, MQTT, and protocol-specific device connections. |
| Management plane | Expose configuration, dashboards, status, and support access without relocating the primary workload. | Portal signalling, browser-to-agent P2P/WebRTC sessions, agent-owned UI resources, and System Monitor. |
| External integration | Deliver only the events, metadata, control messages, or data packages another system requires. | MQTT, APIs, ZeroMQ, databases, files, and controlled custom actions. |
This division is not an argument against cloud services. It is a placement decision. Fleet reporting, long-term aggregation, and enterprise workflows can sit upstream; acquisition, time-sensitive processing, and a site’s essential response path should remain viable when that upstream connection is degraded.
Autonomous sites, shared operational visibility
Distributed edge infrastructure fails when central visibility is achieved by centralising every workload. A production cell, warehouse, building, or remote collection point needs an independently functioning node: its devices must continue to be read, its recordings must continue to be written, and its local rules must continue to execute even if remote access is unavailable.
Banalytics follows this model: each Agent operates locally and independently, and a browser user can work with more than one participating agent. The portal uses WebSocket signalling to establish a browser-to-agent P2P/WebRTC channel, so remote access does not depend on exposing inbound ports or placing the Agent behind a traditional VPN. The connection model is described in Portal Integration; the multi-site operating pattern is detailed in How Banalytics Works for Multi-Site Operations.
Four capabilities turn deployed nodes into infrastructure
1. Connectivity that is close to the equipment
Infrastructure begins at the interface to real devices. A node needs to acquire camera streams, poll a register, receive a message, or exchange data with a specialised process without first routing that work through a distant service. Banalytics provides connectors for cameras and local media, Modbus devices, MQTT, ZeroMQ, and other extension points. The MQTT Server and Modbus Line documentation show the local protocol patterns in detail.
2. A deliberate local execution model
Connected data needs an owner. Components represent resources; tasks perform work; events carry state changes; and actions express the response. This makes an edge node reviewable as a system, rather than as a collection of background services whose dependencies only become visible during an incident. The module and task model is explained in Banalytics Modules.
3. Local data gravity with explicit export
Raw video, high-frequency sensor data, and operational evidence can be expensive or inappropriate to transmit continuously. The node should retain what must remain on site and publish the derived signal that other systems need. That can be a status transition, a quality result, a measurement, an event with context, or a carefully selected recording. Local storage and event history make this boundary visible to operators instead of leaving it implicit in application code.
4. Observability and controlled access
A distributed system is only infrastructure when it can be operated. The System Monitor exposes CPU, memory, disk, thread, media, and WebRTC-related runtime signals as events. Those signals can be viewed, retained, or fed into rules. Agent-owned dashboards and remote sessions then put the relevant context in front of a support engineer without changing where the workload runs.
Infrastructure needs a lifecycle, not just an installer
Edge sites diverge naturally. One location gains a new device type, another adopts a revised processing module, and a third needs a different dashboard or retention policy. A viable platform must make that evolution inspectable and recoverable. Otherwise, every operational improvement becomes an untraceable site-specific change.
Banalytics distributes capability as independently versioned modules. The operator can inspect installed versions and select an update or rollback path without treating the entire edge runtime as one opaque image. Module-owned web resources also allow specialised interfaces to remain close to the capability they describe while the portal provides the common management shell. See Version and Module Management and Architecture 2.0 for the implementation model.
The practical result is a clearer division of responsibility: the platform team maintains the common runtime and operational conventions; domain teams own their processing modules and rules; site teams own local equipment and rollout constraints. No single group needs to absorb all of those roles in an unstructured deployment.
What this platform is designed to be-and what it is not
Banalytics is well suited to an edge estate in which local physical systems need device connectivity, processing, recording, event automation, monitoring, and remote operator access. Typical examples include distributed camera installations, instrumented production areas, warehouses, buildings, and remote sensing sites. It is particularly valuable where data locality and site autonomy are operational requirements rather than optimisations.
It is not a replacement for every infrastructure product. It is not a general-purpose Kubernetes fleet manager, a full enterprise CMDB, or a substitute for a PLC safety system. Nor should it be used to imply that every device protocol or enterprise workflow is available without integration work. The correct design starts by naming the local workload, the data-retention boundary, the expected failure modes, and the external consumers of the resulting information.
Build the platform from one repeatable site pattern
- Classify the node. Define its equipment, protocols, compute envelope, storage requirement, local users, and upstream dependencies.
- Draw the local critical path. Identify what must continue during an upstream outage: acquisition, recording, event detection, control, or a combination of these.
- Define the export contract. Specify which events, measurements, recordings, and health signals leave the site; avoid moving raw data by default.
- Make health actionable. Set the resource and workload signals that indicate degradation, then decide whether they create an operator task, an event, or an automated protective action.
- Prove update and recovery. Validate version changes, local task restart behaviour, constrained storage, and remote-support access before copying the pattern to further sites.
Scale-out should reproduce a proven operating contract, not duplicate a one-off appliance. That is the central contribution of an edge infrastructure platform: it gives distributed local systems a common, supportable operating model while preserving the reasons they were placed at the edge in the first place.