Here’s One Golden Path to Build an MVP Enterprise IDP

If you’ve been at any tech conferences recently you’ve almost certainly seen a seemingly ubiquitous slide of the Cloud Native Computing Foundation landscape to illustrate how complex modern software development has become; so much so, it has become something of a cliché.

Of course, the CNCF landscape also shows how successful Kubernetes is, and how much innovation has been happening in the cloud native space, but the cliché has a grain of truth to it; tool sprawl is a genuine issue, and it doesn’t only affect application development teams.

“I think it is just as hard for platform teams to figure out what their toolset should be as it is for application teams,” Paula Kennedy, co-founder and COO of Syntasso, a platform engineering company, told The New Stack. “Only I think there is greater confusion because platform engineering is maybe less well defined as a practice, and so what constitutes platform tooling is also less clear.”

On top of this, at least in my personal experience, platforms often start to grow organically. An individual developer builds a tool for herself and then shares it with others in her team because it proves useful. This works well for a while. But as the number of developers grows, the approach hits problems since, as Kennedy put it, “there’s not that intentional architecture or systemized thinking; it is just organic growth.”

At a certain point, an organization may find that this just no longer works for them, and may then look to spin up a centralized platform team to try to gain the benefits of faster developer onboarding and quicker software delivery in a more considered manner. But where should a newly spun-up platform team start?

Obviously, you need to talk to your application developers and understand what their needs and pain points actually are, and then build a solution that solves those problems, but you still face the issue of trying to choose the right combination of tools and components.

With the CNCF landscape, “one of the things that makes it easier is the ubiquitous Kubernetes construct; everything on the CNCF is built with cloud native patterns in mind,” Kennedy said. “Whereas if you are in a platform team that is dealing with some old legacy mainframe, plus some cloud native and some other stuff, your toolset could be anything and have a whole bunch of different principles as its core.”

To try to ameliorate this, Humanitec has released a series of white papers and open source implementations of a reference architecture for an internal developer platform (IDP). Combined, these provide a means for an enterprise platform team to get up and running quickly with a minimum viable product (MVP) version of a new platform. The reference architecture itself is based on work from McKinsey.

A Pattern for Internal Developer Platforms

At June’s PlatformCon, Stephan Schneider, a digital expert associate partner at McKinsey, and Mike Gatto, a senior DevOps engineer at the company, gave a talk describing how they had identified a set of common patterns for internal developer platforms based on their analysis of multiple organizations.

As you would expect from McKinsey, the focus is on enterprises rather than smaller organizations, which makes sense in the context of platforms, because one way to think about a platform is that it is an attempt to make DevOps practices work at an enterprise scale.

As can be seen in the diagram below, McKinsey’s suggested architecture makes use of a number of off-the-shelf components including developer portal builder Backstage, GitHub, Terraform and Humanitec’s Platform Orchestrator, along with components from the cloud provider (Amazon Web Services, in this case).

👁 infographic showing the architcutre of an internal developer platform for AWS.

McKinsey’s blueprint divides the developer platform into five planes, each with a set of related capabilities, such as observability and networking, shown in the white boxes above.

• The developer control plane is where the developers publish their code and access the platform via the interface of their choice. It comprises version control, the integrated developer environment, Infrastructure as Code, and a developer portal such as Backstage. Along with the code, the developer also provides a Score workload specification file. This is a YAML configuration file specifying the resources needed to run the application in an environment-agnostic way.
• The integration and delivery plane takes the application code, packages it into one or more containers, and then publishes it to a registry, such as Amazon ECR. Once this is done the CI pipeline notifies the platform orchestrator of the new artifacts in the registry (McKinsey uses Humanitec for this), and kicks off a build. The orchestrator generates fresh application and infrastructure config files and manifests before deployment.
• The resource plane comprises the resources necessary to run the application. This will likely include compute (for example Amazon EKS); building a Kubernetes cluster if one isn’t already available; data (for example Amazon RDS, MySQL etc.); networking (for example, Amazon Route 53); and services (such as Amazon SQS).
• Monitoring and logging are handed off to the cloud provider, with Amazon Cloud Watch being used in our AWS example.
• Finally, security manages secrets and identity to protect sensitive information (HashiCorp Vault is used for this in the reference architecture).

As the Platform Orchestrator has a central role in the blueprint, it is worth looking at it in a little more detail. The following diagram describes the core functionality:

👁 An infographic that shows the core functionality of the Humanitec Platform Orchestrator

With every git-push, the Orchestrator interprets what resources and configurations are required for a workload to run, creates app- and infrastructure configs based on rules defined by the platform team, and executes them. To do this, the Platform Orchestrator follows what Humanitec call a Read, Match, Create, Deploy execution pattern:

1. Read: Interpret workload specification/Score file and context.
2. Match: Identify the correct configuration baselines to create the application configuration and identify what resources to resolve or create based on the matching context.
3. Create: Create application configuration; if necessary create (infrastructure) resources, and fetch credentials injecting them as secrets.
4. Deploy: Deploy the workload into the target environment wired up to its dependencies.

An Open Source Blueprint for IDPs

McKinsey’s reference architecture resonated well at PlatformCon so, inspired by the talk, Humanitec has created several white papers that offer reference architecture blueprints for building an internal developer platform, not only for AWS, but also Google Cloud Platform and Microsoft Azure.

Continuing to build on this, the vendor has now released the first in a series of open source implementations of the reference architecture, made up of a set of Terraform configurations that can be used to deploy an example of the blueprint on both AWS and GCP. The AWS version includes Backstage as shown in the diagram above, and there are plans to add examples for Azure and multi-cloud implementations over time.

This provides a way for a platform team to quickly spin up something perhaps best thought of as an enterprise-style, minimum viable product (MVP) for an internal developer platform, which also happens to provide a convenient way to take Humanitec’s Platform Orchestrator out for a test drive.

“The community response to the reference architectures has been incredible,” Luca Galante, Humanitec product manager, told The New Stack. “We’ve had 10k downloads in the first few weeks which speaks volumes to the need for clear blueprints and design patterns the industry has.”

Of course, you can also swap components in and out, including Humanitec itself should you wish to. Thinking back to the diagram with its planes and capabilities, “the planes are important because they provide orientation and lay the groundwork, and the capabilities are also important.,” Clemens Jütte, platform architect at Humanitec, told The New Stack.

“You absolutely want to have every capability you see in the diagram—we’ve never seen a platform without those. But the logos inside of the boxes are not important. You can pick and choose, start iterating and build the IDP you want.”

‘Golden Paths, Not Golden Cages’

This flexibility matters, because another challenge for enterprises is they likely already have some processes and tools in place that they are reluctant to give up, and different teams have different needs.

By the same token, you don’t want to end up forcing developers to use a specific platform — there are often legitimate reasons why one particular team or group may need to do things outside of the paved route, and also shadow IT practices will emerge if mandatory tooling prevents developers from doing their jobs. It is much better to focus on making the platform as attractive to your application developers as you possibly can, so that they choose it by preference in every situation where it fits.

Mathieu Frenette, director of DevOps at the Canadian financial company Nesto, “talks about golden paths, not golden cages,” Kennedy said. “Which I really like, because it helps me think about the fact that developers need to have an easy path; they need to have a template that helps them to get going quickly, but they need to be able to break it open.

“And platform teams need to be able to offer simplicity through abstraction, but also flexibility when it’s needed.”

Until now, according to Galante, “there hasn’t really been such a blueprint out there, one where I can keep my Terraform setup, keep my infrastructure and CI pipeline, but I can glue this together in a more robust way to get all the benefits that an internal developer platform promises.”

Whilst the implementation of an IDP varies significantly from one organization to another, this reference architecture can provide a useful starting point.