What is Platform Orchestration?
Platform orchestration lets developers provision infrastructure and environments for application development, testing and QA. In this context, environments mean the applications, infrastructure, configuration, policies, pipelines, databases and more.
Platform orchestration automates and unifies these processes, eliminating errors, reducing cognitive load and ensuring standards compliance. This is done automatically, using blueprints that ensure governance with IaC and policy as code. This frees developers to work as they need, without waiting for provisioning, and also ensures that environments are secure and compliant.
Some vendors offering platform orchestrators are Syntasso (Kratix is the open source project), Humanitec and Qovery.
Despite the name, the category does not “orchestrate” the internal developer platform. To understand why, let’s define what an internal developer platform is. An internal developer platform creates the golden paths for developer self-service, so that everything is reusable and not done in patchwork or doing TicketOps. What does the internal developer platform consist of? It is made of all the elements that are part of your SDLC, as well as your infrastructure, cloud and everything in between. This will include: your IaC, Git provider, CICD, feature flagging, Kubernetes, microservices architecture, observability, AppSec tools and more. So what really “orchestrates” the platform is within the tools and APIs that make the platform itself.
This explains why Gartner, in its latest Hype Cycle for Platform Engineering used a different name for the category. It chose “Self-Service Environment Management”, which seems to be a more apt name if you take into account what “platform orchestration” actually does, which is set up environments in the internal developer platform..
In fact, platform orchestration happens every time you create self-service actions in your internal developer platform, through GitHub Actions, your CI or other tools, or even using automations in the internal developer portal.
Why is platform orchestration needed
Without platform orchestration, every organization lets developers or devops set up environments independently.
Not only are different engineering organizations “snowflakes” in the way they set up environments, when many different environments are separately set up by different policies, they also can be snowflakes, creating lack of uniformity and potential standards compliance issues.
Regardless, the result is that environments aren’t uniform and that standards aren’t met, risking security issues and excess costs. In addition, this results in poor developer experiences, since they either wait for the non-repeatable creation of the environment, or need to deal with it on their own, causing excess cognitive load.
Platform orchestration therefore:
- Creates a better developer experience, since some of the steps and data for the creation of environments is abstracted and made easier, creating golden paths
- Ensures standards are met and that all environments are uniform and comply with policies
In sum, platform orchestration allows the creation of environments as a service provides for simpler governance and a better experience for developers that are spared the underlying complexity.
Benefits of platform orchestration
Using platform orchestrators or self-service environment management provide several benefits:
- Platform engineering teams create a one-time as code blueprint, covering configuration and policies, and this is reused by developers
- Eliminating wasted time spent on waiting for tickets to set up environments for developers
- Ensure policies and standards are complied with when environments are created, ensuring that there are no production readiness, appsec or cost issues
- Making it easier to set up environments for testing results in better software development.
In essence, platform orchestrators create “paved roads” enabling developer self-service and ensuring the resulting environments are secure and built in accordance with policies. This is to counter the complexity of containerized, cloud native applications.
In many cases, the platform orchestrator is more than just a self-service for environment creation, as in cases where it takes information about the environment needed (e.g. a larger database is required) and deploys the environment accordingly.
It is important to note that just like environments are created they should also be torn down. The classic example is a temporary environment for testing, with a time-to-live (TTL). In this case, platform orchestration would set it up, but won’t necessarily be able to do the tear-down. In this case, you can use automations in an internal developer portal to do just that.
Platform orchestration alternatives
Any interface that supports self-service environment creation, such as a CI tool, can be considered an alternative to platform orchestrators, and can also be built to include policy as code and infrastructure as code.
Another alternative to platform orchestrators is an internal developer portal. Internal developer portals are a user-friendly interface to the internal developer platform – abstracting the complexity of the software development environment by providing a single user interface that’s built to answer any questions developers have about the SDLC or standards, and to provide a simple, abstracted interface for developer self-service. In short, it is where the work of platform engineers - including setting up self-service environments - is made available to developers.
In the content of a portal, “orchestration” is made of two parts:
- It’s a unified interface which effectively creates business processes that take the developer through the SDLC, step by step. This workflow is“orchestrated” in the portal.
- It is also triggering the desired backend actions in the internal developer platform.
In this respect, whenever you build your internal developer platform with developer self-service, and make this available in the portal, you are creating orchestration between the platform and the portal. You can do this for environment setup, preserving uniformity and standards, offer simple self-service in the portal - and… you’ve used an internal developer portal as a platform orchestrator.
