• Home
• /
• News
• /
• An Open Source Approach For Decentralized Edge Operations with IBM Open Horizon and EdgeLake

An Open Source Approach For Decentralized Edge Operations with IBM Open Horizon and EdgeLake

Enterprises are increasingly evaluating edge deployments that reduce reliance on centralized cloud services. A common driver is that operational data is often generated outside the data center—at substations, factories, water facilities, retail locations, vehicles, and city infrastructure. Traditional approaches frequently move that data to a centralized platform (such as a cloud data lake or historian) before running analytics. In environments with intermittent connectivity, privacy and data-sovereignty requirements, or latency-sensitive workflows, centralizing data can increase privacy and operational risk and create substantial, ongoing, and often unpredictable costs, including cloud-hosted data services, BI tooling, and network ingress/egress.

This article describes how two complementary open source technologies can be used together in edge architectures to offer cloud data services at the edge:Used together, the edge supports

enterprise-grade, cloud-like data services: Open Horizon deploys and manages EdgeLake services across a fleet of edge nodes at any scale, while EdgeLake supports decentralized data ingestion into databases running at the edge and enables applications to query data in place across nodes as if it were hosted in a centralized cloud database.

Why orchestration and decentralized data often need to be addressed together Edge initiatives commonly encounter two recurring challenges: Together, Open Horizon and EdgeLake inherently solve these problems:

How Deployments Work in Practice

Open Horizon deployments are typically defined in container terms and managed through a hub-and-agent model. In a representative setup, services are published and edge nodes run agents that evaluate policies and deploy the workloads they match.A common approach for deploying EdgeLake with Open Horizon looks like this:Open Horizon service definitions specify the configuration agents run EdgeLake on target nodes. Configuration includes:Rather than installing software manually at each location, Open Horizon policies can target nodes by attributes such as CPU architecture, operating system, location tags, or environment classification. This enables a consistent rollout approach across heterogeneous edge nodes.Open Horizon is designed to handle deployment and update workflows across distributed nodes, which can reduce the amount of site-by-site operational work when managing containerized services.

Example Real-World Smart City Use Case

The City of Sabetha, Kansas provides a practical example of why this architecture can matter. In an LF Edge case study, Sabetha sought improved monitoring and alerting to reduce operational risk across water, wastewater, and power facilities. Documented needs included monitoring generator feeders, supporting real-time operations, and maintaining historical data for trending and analysis. The deployment used EdgeLake in a way that integrated with existing systems and produced real-time dashboards and alerts derived exclusively from edge data and operations. Notably, after two weeks in production, the city cancelled their AWS contract and continues to operate entirely without cloud dependency.

The case also illustrates an operational model where analytics and reporting run locally, eliminating dependence on cloud services for monitoring and management of city infrastructure. In this pattern, EdgeLake functions as the data layer that keeps data local while still making it queryable for real-time insight. Standardized interfaces (including MCP-style interfaces) make that data accessible to downstream automation or AI systems without requiring a separate, custom integration for each source. For failure prevention scenarios—such as generator incidents—reducing reliance on centralized pipelines can improve responsiveness when minutes matter.

Takeaways

For organizations seeking to simplify edge operation, it can be useful to separate (and then intentionally recombine) two concerns:Open Horizon addresses the first by providing mechanisms to manage containerized services across fleets. EdgeLake addresses the second by enabling decentralized data storage with federated query access across nodes. Combined, they form a new edge architecture where software distribution is automated and data can remain local while still being accessible for real-time monitoring, AI-enabled analysis, and automated operations.