This repo contains a collection of cloud-agnostic deployment scenarios that use various open source and Azure capabilities.
🚧DISCLAIMER: Although We aim to provide relevant source code and artifacts for each scenario, some examples may be partial or not actively maintained due to limited resources. Our primary goal is to illustrate and summarize architectural patterns. Community contributions are warmly welcomed.
This sample uses Azure Deployment Environmnets (ADE) to manage a test bench running on on-premises Windows machines. It uses a custom container image that uses a self-hosted Eclipse Symphony to deploy a Windows-based benchmarking program to an on-premises Windows machine. Symphony uses a MQTT broker to reach the Symphony agent running on the Windows box to perform the actual deployment.
This sample uses OpenTofu to define a cloud-agnostic data processing pipeline. When deployed to Azure, the pipeline is mapped to Azure IoT Operations (AIO) artifacts. When the SAME piepline is deployed locally (such as in a disconnected environment), it's mapped to use Eclipse Symphony to deploy a local pipeline.
This sample demonstrates how to use Radius to define a cloud-agnostic application and deploy it to an edge environment powered by Eclipse Symphony. Eclipse Symphony extends Radius' capabilities to support deployment of edge components across heterogeneous edge environments—environments composed of diverse device categories, including devices running different operating systems.
This sample demonstrates how to use Eclipse Symphony to add a region selection process to the deployment process of a cloud-agnostic application described using Radius. It enables a region-less deployment workflow that guides users in deploying applications to the most appropriate regions. This architecture also integrates seamlessly with native region-less deployments, as those can be defined as additional environments within Radius.
This sample demonstrates how Eclipse Symphony can be used to automate the deployment of Dapr infrastructure (as a Symphony Target definition), as well as the deployment and configuration of Dapr sidecars using native Symphony Solution sidecar support.
This scenario summarizes four typical ways to achive application portability (across different clouds and edge environments).
-
Portability via platform parity
When multiple platforms provide a shared capability portfolio, it becomes feasible to deploy an application across those platforms without modification. For example, Azure Arc aims to provide parity for selected Azure services so that applications written against Azure APIs can be deployed to Azure Arc environments.
✅Pros:
- Deploy to different environments without modification
- Similar service quality guarantees (often provided by the same vendor)
❌Cons:
- True platform parity is difficult to achieve, so options are often limited
- Vendor lock-in to platform vendor
-
Portability via platform abstraction
In this pattern, platform capabilities—such as messaging or state stores—are abstracted behind common interfaces. This allows implementations for different platforms to be plugged in without impacting the rest of the system. For example, Eclipse Symphony follows this principle to ensure platform agnosticism.
✅Pros:
- Great flexibility and tight control over abstraction
- Platform parity is supported but not required; platform differences are hidden behind abstract interfaces
❌Cons:
- More complex code and operational management
- Leverage the lowest common denominator of platform capabilities
-
Portability via capability sidecars
This pattern pushes platform-specific implementations into a separate service or sidecar. The application uses a capability proxy to communicate with the sidecar and acquire required capabilities. Dapr is a popular example of this model.
✅Pros:
- Leverages existing platform implementation ecosystems
- Simplifies application management since only sidecars need reconfiguration
❌Cons:
- Vendor lock-in to the sidecar technology
- Must conform to sidecar-defined interfaces
-
Portability via application servers
If an application is built on top of certain application servers, such as J2EE, WebLogic, or Kubernetes, the application becomes portable wherever the application server is supported.
✅Pros:
- Application servers offer additional abstractions that simplify building certain app types
- Popular application servers benefit from strong community and tooling support
❌Cons:
- Deep vendor lock-in to the application server
- Portability is constrained by the adoption and ecosystem of the application server
