top of page

The Missing Middle: Why Platform Orchestration is the Key to Better Developer Platforms

You can follow the supposed “best practices” in building an Internal Developer Platform (IDP) and still end up with something people avoid.

It’s not necessarily because your newly built platform has poor features; it’s because it’s disconnected.


Even with great tools, your platform could feel disconnected when developers have to jump through hoops to use “approved” unmaintained components, follow unclear instructions, or wait for others just to finish their work.


Yes, you’ve embraced automation and have a great continuous integration and continuous delivery pipeline in place, but you skipped the part that truly connects development and operations.


You skipped the orchestration layer. A successful IDP depends not just on what you build but also on how you orchestrate what you’ve built.


The current state: Top-down and bottom-up approaches

Many organisations struggle to clearly define how they're building their developer platforms. The “why” is easier to answer. Off the top of the head, they can say:


  • Boost developer productivity.

  • Improve operational efficiency.

  • Enhance developer experience.

But how will they achieve all this? With the goal of a happy platform and development team. 


In the quest to get to the “why”, many organisations have been stuck in “the current state”, which follows two opposite approaches. 


The top-down approach is a developer-focused approach that often overlooks operational complexities in favour of developer experience. It’s like creating a user-friendly interface or portal like Backstage, where developers can easily access everything they need, without having to understand the complexity behind it. 


The idea is good in practice, and it makes deployment as seamless as possible. However, these platforms often end up hiding too much complexity. Developers may love how easy it is to use the platform, but they quickly realise they don’t have enough flexibility to make custom changes to components when needed. 


In this case, at first, the platform and development team are happy. But as more applications get shipped and more issues surface that require changes to platform components, the development team becomes unhappy. With the constant requests to the platform team, they quickly become unhappy too.


The bottom-up approach, on the other hand, is an approach that focuses on giving developers and operators more control through automation and Infrastructure-as-Code (IaC).


Terraform and GitOps workflows are common in this setup. They’re powerful but can also be overwhelming. Developers need to understand HCL, Kubernetes, and some other tools, which can be a whole lot.


In this case, the development team is not happy, but the platform team is. But like mentioned earlier, the platform team's happiness will quickly disappear when “best practices” and processes are not followed.

Now, how do we find a sweet spot? What is missing? 

From what you’ve read so far, you will agree with me that it's platform orchestration. 


The missing middle: Defining platform orchestration

If top-down and bottom-up approaches don’t fully address the internal developer platform problem, and platform orchestration is the missing piece that connects the dots and bridges the gap, what is platform orchestration?


 Diagram of platform engineering (Annotations by Daniel Bryant)
 Diagram of platform engineering (Annotations by Daniel Bryant)

Platform orchestration is the process of managing, coordinating and optimising all the tools, services, and workflows developers need to build, test, and deploy software efficiently.


Unlike infrastructure orchestration, which handles lower-level resources related to compute (and storage, networking, etc.), platform orchestration is about reducing complexity and improving the lifecycle management of platform components for developers.


So, when a developer requests a new service, the orchestrator decides what needs to happen: what resources to provision, what policies to apply, what integrations to trigger, and what notifications to send, all without the developer needing to know how it works behind the scenes.


If you are using a platform orchestrator like Kratix, this enables multiple stakeholders to contribute to building and configuring the platform's components. This can provide the development teams flexibility to move beyond the predefined “paved paths” when they encounter an edge case or a new use case. 


Orchestration doesn’t replace what you’ve already built. It works by connecting the tools your team already uses, such as Crossplane, Terraform, Jenkins, etc, into one smooth, automated workflow. 


Related to this, we can explore Kratix’s “Compound Promises,” which are Promises that, in their dependencies, contain other Promises (building on the existing building blocks) that allow platform teams to deliver entire stacks on demand.


This enables you to deliver “everything as a service”.


Why platform orchestration matters

Platform orchestration is the key to making your developer platform truly effective.

Orchestration ensures that when a developer asks for a new service, everything just works, without them needing to figure out the details on their own or chase down the platform team. 


The right resources get set up, permissions are handled, and everything is connected automatically. So, instead of opening tickets and reaching out to the platform team, or even switching tools mid-task, developers interact with a single, consistent experience on the platform. 


They just make a request, and the platform knows what to do across the infrastructure layer, security, compliance, and everything in between. 


For example, when a developer pushes code to GitHub, a pipeline is triggered, infrastructure is provisioned on AWS with Terraform, IAM roles are set, monitoring is in check, and compliance is followed. 


The developer doesn’t need to request help or switch to a different tool. Everything happens in the background accurately and in the correct order, without the need to figure out how it all comes together.


The how: Building the orchestration layer

With all these in mind, how do you build a successful platform orchestration layer?


You can start by understanding the gaps in your current platform. What’s causing delays? Are developers spending too much time waiting for environments to be set up, or are they juggling multiple tools to complete a simple task? 


Identifying these gaps will help you determine where orchestration can make the biggest difference.


Once you know what needs fixing, automate the repetitive tasks. For example, if developers often request new environments, create an automated workflow that provisions resources, sets up permissions, and configures integrations.


Orchestration doesn’t mean adding another layer of complexity. Instead, it’s about abstracting away that complexity from developers. However, developers also need to have some control over the process. That’s why it’s important to allow customisation where needed. 


A well-built orchestration layer should allow developers to tweak certain configurations for a specific service without breaking the overall flow. The platform team can enable this by being deliberate with the (Promise) API design of platform components.


Finally, once your orchestration layer is in place, the work doesn’t stop there. You need to monitor how it’s performing and be ready to make changes. 


  • Are developers using the system as intended? 

  • Is it making their lives easier? 

  • Is it speeding up their workflows and simplifying complex tasks? 


Gather feedback, identify pain points, and keep iterating to improve the system.

By doing this, you ensure that the platform is more adaptable, allowing developers to focus on creating and deploying features while the platform handles the rest.


Building platforms with purpose

Too often, internal developer platforms are built with good intentions but miss the mark because they focus too much on tools and features rather than how those pieces actually work together. 


It’s not enough to give developers access or automate processes. You also need to create a smooth and reliable experience that lets people focus on building and shipping without obstacles.

Comentários


bottom of page
Scarf