Harmonising Orchestration in Heterogenous Environments with Eclipse Symphony

The ecosystem of software and hardware components is becoming more heterogenous in every industry. The pace of innovation is accelerating, increasing the pressure for organisations to monetise new capabilities like software-defined infrastructure and cloud-native stacks, while ensuring that investments in existing toolchains are well integrated. The task of ensuring that all these toolchains, which each have their own lifecycle, can coordinate and co-exist effectively is becoming more and more complicated. 

There are different ways of addressing this problem. In theory, you could build in point-to-point integrations. This would necessitate building a system where all the components are highly aware of each other and would require redesign and change to allow these components to interact with each other. That’s a tough sell, and very costly in a heterogenous environment. 

This points to a clear need to decouple components from each other and introduce a central control capability that takes on coordination responsibilities using state management capabilities across the different components. Traditionally, this would be done using a workflow-based deployment. Workflow engines would deploy different components in a predetermined way in a continuous integration and continuous development (CICD) pipeline. 

But in the growing complexity of modern development environments, workflow-managed deployments are not enough. There is a need to define clear dependencies across loosely coupled components and their states without requiring any modification to the different components. 

Orchestrators address this need. They can manage multiple components as a system-of-systems to optimise the performance of the whole system. But as more modern systems like Kubernetes and other cloud-native stacks adopt orchestration-based resource management patterns and capabilities, a new challenge is introduced: how do you manage multiple orchestrators that have to work together in concert? 

In these highly heterogenous environments, with multiple orchestrators working at once on their own suite of components, there is a deeper need to ensure every orchestrator is coordinated with every other orchestrator. In other words, the ecosystem needs an orchestration engine that can organise multiple edge services into one coherent whole. This is where Eclipse Symphony comes in.

Eclipse Symphony is a technology-agnostic abstraction for any orchestration task. It provides consistency across any software stack and orchestrator. Combined with full support for the entire lifecycle of edge computing initiatives, Symphony is designed to seamlessly integrate with existing technology stacks.

A Stable and Standardised Infrastructure for Diverse Device Landscapes

Unification of orchestrators is the goal. But there are different ways of getting there. One way is to do it via regulation: creating standards and specifications. This is a slow process and is difficult to achieve even across one industry, let alone multiple. Another way to do this is the full stack/monolith way. In this case, you take control of the full stack and essentially force your customer to use just one vendor, or one set of certified or approved systems. But this is not an open source or community-enabled way of working. 

This is why Eclipse Symphony decided to adopt a “good enough” standardisation and abstraction approach. Things that are common for any orchestration task, like the models and core APIs, are standardised. But every vendor is given a lot of freedom to operate within that standardised concept. 

Four different abstractions make up the core of this concept. 

The first is that Symphony is a declarative system. It allows developers to define target states for each of their different components, as well as how that target state is related to the other components in the system. 

This then allows the system to take on the role of managing how each component transitions to its target state while managing its dependencies on other components using orchestration models, which model these orchestration problems as code. This is the second abstraction. 

As these tasks can become quite complex, the orchestration models also include information graphs as abstractions, allowing developers to build indexes of the different artifacts involved in state seeking. The orchestration model can then access them as needed across all systems, from local machines to central databases or GitHub repositories. 

The final level of abstraction is workflow management. This is what enables Symphony to support complex deployment and orchestration patterns (like A/B testing, Ring Deployments, etc.) across environments and toolchains, while enabling the other abstractions and capabilities to behave in a coordinated manner in a central workflow. 

A Mature Project Making Inroads

The Eclipse Symphony project is currently in incubation, having joined the Eclipse Foundation relatively recently. It started life as a Microsoft-led initiative that, after four years of development on various adjacent initiatives, was donated to the Eclipse Foundation in early 2024. Microsoft has been deeply involved in solving the technical challenges that have plagued orchestration for many years now, and Symphony is an open-source solution that aims to bring unification across the industry. 

Although it operates under the banner of the Eclipse Software Defined Working Group, the project is not limited to addressing automotive challenges. The orchestration challenges that Project Symphony addresses are not confined to SDV alone but span multiple industries facing similar complexities. 

But the reality is that few environments are more complex or demanding for this kind of application than SDV. As such, it made sense for the project to live here. If it could meet the extremely strict operational and safety requirements for software defined vehicles, not to mention accommodate the sometimes radically heterogeneous software and hardware environments even between different models of the same car, it could likely do so anywhere. 

As Eclipse Symphony has an ambition to drive unification for the orchestration challenges for any software stack, we decided that this is not something any company or organisation can achieve by itself. This is why we decided to make it an open source project and release it under the MIT license, a very permissive licence that allows anyone to take the core of Symphony and build their own product. 

Built for Flexibility and Simplicity

An important principle of Symphony is that it was designed to be as simple to use and as flexible as possible. Several elements of its design support this. It can be run as a standalone agent on Windows or Linux, as a Kubernetes application in a Kubernetes cluster, or by using remote orchestration via RPC over MQTT and a REST API to interact with devices without needing to be installed on them. The footprint of Symphony can range from 4 to 87 megabytes, covering every use case from a system-of-systems approach to supporting real-time systems. 

Project Symphony is intended to simplify life for both developers working on applications, and infrastructure or IT operations teams working on infrastructure, by enabling the application model and the infrastructure (host environment) model as two separate concerns. Developers can focus on the application model without needing to focus too much on infrastructure. But because infrastructure and IT teams work on the same abstraction, they can in turn focus on defining host environments and optimise resource utilisation for solutions.

Standardised Abstractions Rely on Extensions 

Eclipse Symphony deliberately doesn’t have a strong dependency on any specific technology, and the models and APIs are all technology agnostic. The standardised abstractions, in theory, maximise its accessibility into any toolchain. Symphony is easy to integrate with any toolchain, as the specific logic is encapsulated within in extensions, which are easy to develop and only required to support two interfaces. 

This is why we’re looking for contributors to extend the reach of Symphony to any toolchain. Eclipse Symphony has a lot to offer as an orchestration abstraction within the SDV space or any heterogenous environment, with potential applications in anything from retail security systems to IoT device coordination for manufacturers. 

We welcome anyone or any organisation with complex orchestration challenges to try out Symphony, and we look forward to partnering with you to drive unification and a common experience for any orchestration need. Your contribution and feedback will make sure Symphony becomes the best orchestration experience for any ecosystem.