The framework has modular structure and uses industry standard protocols as interfaces between subsystems (e.g. Git for SVMs, Kubernetes API/CLI etc.). This is to make sure that alternative tooling and vendor-specific managed services can be used.


The diagram above outlines high-level architecture of provisioned OpeNgine instance. Entire instance is hosted inside single Public Cloud (environments spread across multiple clouds are in development). There are multiple Kubernetes clusters. The clusters are sharing single VPC or use dedicated VPCs with communication and routing enabled between them. One of the clusters plays special role - it hosts management and orchestration tools. The rest of clusters are application environments (Development Environment, Test Environment, Production Environment, etc.). That’s why usually overall size of the OpeNgine instance = N + 1 where N is the number of environments adopted in your development process. Although it is recommended to install OpeNgine management cluster in a separate Kubernetes cluster, this requirement is not mandatory, and it is technically possible for management and orchestration tools to co-exist in the same cluster. This approach is reasonable for Development environments.