A Platform Orchestrator sits at the core of an Internal Developer Platform (IDP) and enhances self-service capabilities, by giving developers the ability to deploy workloads with all dependencies to all environments, with a single workload specification. The primary function of a Platform Orchestrator is to enable Dynamic Configuration Management (DCM).
How does a Platform Orchestrator relate to Dynamic Configuration Management?
A Platform Orchestrator enables workload-centric development; in other words, your developers only need to write a single workload specification. A workload specification defines the resources and configuration required without needing to supply environment-specific values, and the Platform Orchestrator ensures it provides everything needed for the workload to run.
The Platform Orchestrator delivers workload-centric development by interpreting the workload specification based on a specific context at deployment time. It uses context to determine where to deploy the workload and how to resolve its dependent resources. The context could be as simple as the name of the environment (e.g. "development" or "production") or include other attributes such as Application Name, Region, or Organization Name. Environment-specific workload configuration can be generated from resource outputs, eliminating the need to define it in the workload specification.
For example, deploying a workload into a context:
"Environment = Development"
"Application Name = Payroll"
"Organization Name = Finance"
This would allow the Platform Orchestrator to determine that the workload should be deployed into the "finance cluster" within the "Development" AWS account and use the "Payroll" RDS instance.
Defining the context and how to resolve the dependent resources within it depends on the particular Platform Orchestrator. The overarching goal is to generate the configuration and provision resources for the workload to run successfully, using a workload specification and a context.
How is a Platform Orchestrator integrated into the existing toolchain or platform?
Platform Orchestrators vary by implementation because some take over CD functionality, while others solely focus on creating configuration files and provisioning infrastructure resources. They always sit post-CI, and receive the deployment context primarily by interpreting tags passed on by the CI system. Depending on the implementation, a Platform Orchestrator can integrate with image registries, secrets management systems, and your cloud or on-prem setup. Platform Orchestrators mostly rely on drivers or Infrastructure as Code tooling to create new resources.
How does a Platform Orchestrator operate?
A Platform Orchestrator is relatively consistent with how it follows a “RMCD” execution pattern:
- Read: Interpret workload specification and context
- Match: Identify the correct configuration templates to create application configurations, and select resources to resolve or create based on context matching.
- Create: Create application configurations; if necessary create (infrastructure) resources, fetch credentials and inject credentials as secrets
- Deploy: Deploy the workload into the target environment wired up to its dependencies. If the Platform Orchestrator just creates the files, at this point it hands over to a dedicated CD provider.
What are the advantages of a Platform Orchestrator?
A Platform Orchestrator enables asynchronous cooperation between the development and the platform team and drives separation of concerns. The resulting increase in productivity can be easily measured by the uptake in deployment frequency.
For developers
For developers, a Platform Orchestrator enables workload-centric development, offering the following advantages:
- Developers need only use a simple workload specification to deploy workloads and everything they need to run.
- The workload specification is tightly scoped and has a simple syntax that’;s easy to learn and read, which significantly mitigates cognitive load.
- Configuration drift is eliminated since only one spec needs to change, regardless of the number of environments.
- The number of config files is dramatically reduced because the workload specification alone is sufficient to declare everything the workload needs.
- Developers can self-serve with no waiting times due to TicketOps, or the need to learn complex infrastructure.
For platform engineers
Platform Orchestrators help platform engineers supercharge the self-service capabilities of their IDPs by making them dynamic, and offer the following benefits:
- Greater compliance and consistency across environments and infrastructure.
- More time for platform engineers to focus on improving the platform rather than firefighting or changes, thanks to a self-service model that offers golden paths and sensible defaults.
- Standardization by design with the ability to define exactly how resources are provisioned, and generate configs based on specific contexts.
- Strengthened security for your IDP and deployments, with dynamic generation and allocation of secret outputs from resources, and an integration with your current secret store.
Summary
Platform Orchestrators are experiencing rapid adoption in recent years. While implementations vary slightly, the general patterns are mostly the same. Because of the level of automation and standardization, using Platform Orchestrators to build dynamic IDPs and implement DCM your setup usually makes sense from 30-50 developers/services upwards. From this size onwards, they can have a significant impact on the productivity of development, platform, and operations teams through continuous standardization and self-service. You can build Platform Orchestrators yourself or use managed services.
