Platform Engineering

While developer relations typically focus on external developer customers, platform engineers are building services to better serve the needs of internal application and operations developers. An evolution of business agility and DevOps, platform engineering looks to break down more cross-organizational silos, while reducing the cognitive load of application teams and duplicate work. This is usually achieved via the creation of the internal developer platform or IDP.

Read on to learn what platform engineering is, when it’s needed, and how to leverage it to increase team velocity without increasing developer burnout.

Where Did Platform Engineering Come from?

DevOps looks to create application teams that are able to build, test, release, maintain and operate a single domain. But, the further down the stack you go, you’ll find a lot of cross-company duplicate effort. Because application teams were built to more rapidly deliver value to end users — not to learn how to orchestrate Kubernetes, to spin up multicloud environments or to worry about security and compliance. As a maintainer of platform-as-a-product framework Kratix Abigail Bangser put it, these are non-differentiating activities, but not unimportant ones. And, as the tech industry moves more cloud native, they are extra burdens for release teams.

In comes the internal developer platform team to the rescue! Platform engineering is the discipline of building workflows, toolchains, platforms and documentation to support application teams in their delivery of business value. The platform engineering team sits on the horizontal, serving cross-company needs so the vertical application teams’ can serve their end users. It focuses on enabling an application team to get up and running without the cognitive overload and overlap of each team learning to be cloud native. Ideally, it enables them to do it without a human in the loop always having to approve things either.

“One of the goals of platform engineering is to promote self-service to enhance developer velocity and free them from being dependent on people and processes to do their job,” David Melamed, Chief Technology Officer of the Jit DevSecOps orchestration platform, told The New Stack.

A la Netflix’s guardrails not gates, platform engineering teams look to create “golden pathways” where teams are able to choose from a pre-approved selection of tools, resources and compute, to help them get what they need to run their applications. The platform team takes care of the cloud, so app teams don’t have to. But that doesn’t mean they’re off the hook for essentials like security — it’s just these teams now have the pathway to automate and run security tooling.

Getting Started with Platform Engineering

Platform engineering isn’t for every company. In fledgling startups, usually everyone does a bit of everything and that’s OK. But it doesn’t scale. Once you have two or more app teams, you may start to discover duplication of efforts. As you scale up more, so does this repetition. That’s when you might start thinking about hiring a platform engineer to tackle that toil.

There’s no secret recipe to “the platform.” It will vary by organization. The best way to get started on your platform engineering journey is to have a conversation with your engineers. This could kick off with a survey on bottlenecks or developer frustrations or by platform engineering embedding and pair programming within application teams. Some teams, like at CyberArk, borrow application developers to help build aspects of the platform.

You can also kick off your platform planning by looking at the tools you already have, Bangser recommends, like Slack, Trello and Jira. Where do you see the most complaints or requests? Where are your developers finding the most uninteresting repetitive, manual work? Where’s your toil? Start looking to solve those shared concerns first.

Just remember, at every step of your platform process, it’s essential to get internal developer feedback early and often, iterating as you go. Look to over-communicate. Offer your internal customers product demos over free lunch. Incentivize early adopters. And never forget to document your platform to encourage self-service and independence.

These are all tactics to make sure you are building a platform that your colleague developer audience will actually want to use.

And don’t forget to factor in other stakeholders, like making sure you are tying the platform to the overall business value delivered. Namely, make sure your C-suite understands what you are building and why as well, or your platform might not be adopted at all.

What Are the Benefits of Platform Engineering?

Platform engineering looks to, hopefully, deliver on more of the promise of DevOps. After all, developers are creative knowledge workers and are best put to use solving interesting problems and delivering value to your customers — not fixing problems outside of their domain.

Benefits delivered by platform engineering include:

• Increased velocity. It exponentially cuts down on the time it takes for developers to get up and running in the cloud.
• Scale through environment automation. App teams can create, replicate, remove, and update deployment environments — without worrying about what’s going on in the background.
• Cuts costs. Cutting down on workload duplication and reducing unnecessary app developer workload saves money across organizations. It also makes it easier to pursue FinOps and monitor cross-organization cloud costs and carbon footprint.
• Reduce complexity. Or abstract it away, so app teams focus on their apps, not the underlying infrastructure.
• Emphasize differentiators. While the platform team focuses on infrastructure, app teams can focus on delivering customer value.
• Speed up onboarding. Sometimes it can take a week for a new teammate to be able to spin up an environment and start doing what they were hired for. With an IDP, they could be committing in a matter of minutes.
• Enable developer satisfaction. Retain your team because they actually like what they are doing and feel like they are doing meaningful work. A platform team is dedicated to improving the internal developer experience.
• Be secure and compliant. Centralize the essential by automating a lot of the privacy, compliance and security requirements, and scale it across your organization. As Port describes it, platform engineering drives adaptive governance.

Again, an internal developer platform isn’t necessary for all organizations. But as your infrastructure gets more complex, platform engineering can help abstract out what’s unnecessary for your developers to get their jobs done.

What Are Some Internal Developer Platform (IDP) Tools?

While platform engineering is still an emerging discipline, there’s already a lot of different options to get started. Part of it depends on how much flexibility your application developers need and where you want the platform to sit.

You can certainly build your own platform, but that costs a lot of overhead. You could also use an out-of-the-box IDP tool but that might not include the flexibility needed to best serve your internal customers. It may be that the complexity is abstracted out by a developer portal that facilitates self-service. You can also use a plethora of open source options as well as CI/CD pipeline tools. Here’s an overview of the currently available platform engineering tool suite:

• Ambassador – cloud native developer control plane
• configure8 – developer portal for implementing standards
• Crossplane – open source framework for building cloud native control planes
• Cycloid – self-service developer portal
• Humanitec – self-service platform orchestrator
• Kratix – open source framework for platforms-as-a-service
• Port – no-code developer portal
• Upbound – an API-driven developer control plane

Also under this umbrella of platform engineering tooling, you will find a wider array of tooling dedicated to abstracting out Kubernetes complexity.

What’s DevOps versus Platform Engineering versus Site Reliability Engineering?

DevOps — the bringing together of development and operations — is the practice of breaking up monolithic architecture and teams, in order to create smaller, autonomous teams that can build, deliver and run whole applications. Platform engineering is the discipline of abstracting out any infrastructure or toil that distracts from DevOps teams delivering their domain. Site reliability engineering or SRE teams are dedicated to helping both the DevOps and internal platform teams by increasing reliability, scalability and, often, security. DevOps focuses on the development side, SRE focuses on the operations side, and platform engineering focuses on internal development enablement.

All three disciplines understand that it’s not all about technology — everything stands on the sociotechnical pillars of people, processes, and tech.

Both site reliability engineering and platform engineering benefit from the three ways of DevOps:

• Concentration on increasing flow
• Tight feedback loops
• Continuous experimentation, learning and improvement

And any successful SRE or IDP strategy hinges on cross-organizational collaboration and understanding, which DevOps’ silo-breaking enables.