What is platform engineering?

Have you heard about platform engineering? Are you wondering what it’s all about, or do you want to learn more? If so, you’re not alone — it’s ranked number 4 on New Stack readers’ top topics for 2023. Even Gartner’s now gotten into the mix, which is a big clue that platform engineering is gaining momentum and headed toward the mainstream.

However, I think Gartner’s view is missing critical aspects — too much emphasis on the engineering rather than the platform. This runs the risk of perpetuating an incomplete approach that causes platform cargo-culting instead of healthy improvements in velocity, efficiency and customer experience. (On the flipside, take a look at the blogs by Forrester’s Charlie Betz!)

If you’re wondering whether platform engineering is right for you, here’s what you should ask:

If you’re primarily a developer, are you feeling the pain of frequent roadblocks waiting on internal approvals or fulfillment? Would you like to deliver on your timeline instead of that of your IT team?

If you’re more of an operator (e.g. SRE, DevOps engineer or DBA), are you feeling the pain of repetitive request fulfillment and operational firefighting? Would you like more time to build your vision of the future instead of what feels like busywork?

If you’re an executive, would you like to create efficiency and deliver value more quickly? Wouldn’t you love to see more reuse instead of duplication across all of your products? What if you didn’t need to build underlying capabilities before shipping value to your customers?

I’ve been pushing the concept of platform engineering for many years, so I’m thrilled to see it taking off! When I led the DevOps transformation at travel-tech company CWT (formerly Carlson Wagonlit Travel) from 2017–2020, this is a huge piece of what we did. Coming straight from roles at leading-edge analyst firms like RedMonk and 451 Research to a pretty typical enterprise, I was certainly a few years ahead of the curve. Fortunately I was able to excite and convince others of the value of this approach, and it paid off.

Since then, my time seeing up-and-coming startups as Executive in Residence at Scale Venture Partners, inventing a developer-first product strategy at Docker, and now transforming our database services and great open-source software into products at Percona have continued to inform how I’m seeing the trend develop, as well as how it could help the vast majority of teams and companies.

Here are the key pillars of platform engineering, as I see it:

• Self-service

• Platform operations

• Platform as product

Let’s dig into more detail on what each of those pillars means.

Self-service

Self-service has become an expectation, but developers often still don’t get it for internal tools. They’re stuck filing tickets, and “automation” means that someone in internal IT approves + runs a script. This is a combo of long-term trends such as open source, cloud, and consumerization of IT. Shadow IT works until you want to go live in production. Then you get what I see as the only meaningful form of cloud repatriation, which is your own security & operations teams telling you that you’ve built in a totally noncompliant and nonresilient environment, and that needs to change immediately.

Platform operations

Platform operations is about applying an SRE approach to these internal platforms. Regardless of where they run, you operate them as a platform-level service (cattle vs pets), invest in reducing toil, and implement SLO-style monitoring / error budgets. You need to shift the mindset from operating a single server to operating a service as a whole. This helps to get you above water so you can think about overall health of your service offering, rather than individual instances. The SLO model also helps to get into a more preventative mindset to avoid customer impact.

Platform as product

Platform as product is about bringing a product-management (PM) approach to internal platforms. Vital: You need to talk to your internal consumers, and solve for their needs! Many traditional infrastructure teams often don’t understand the workloads running on their platforms, or their internal consumers’ needs. It’s a “push” model where vendors and products get forced upon the development teams, rather than their input being a critical factor in the decision. How can you expect to enable or accelerate what you don’t even understand? I’ve successfully applied this “platform as product” model to even non-product-like areas such as major-incident communications, and it’s worked amazingly well.

No dedicated, full-time PM is required, although it certainly helps! (By the way: Product managers are distinct from product owners, scrummasters, and project managers. You need to understand the difference. See here, here, here, here, here.) Team leads, managers, architects, or BAs can pick up enough modern PM skills to succeed. Want to get a head start? Take Alex Cowan’s PM track here on Coursera for a very reasonable price, or audit it for free!

The value of platform engineering

Bring them together, and you’ve got platform engineering. This empowers developers to deliver without roadblocks waiting on other teams, it ensures they have the needed underlying platforms to create value at speed, and it also enables operators to move away from the 100% reactive approach toward more of an engineering model.

For example, at CWT we created a series of DevOps services like a CI/CD pipeline, self-service performance testing, an image service for pre-approved, hardened images (consumable via source templates or the built images in a variety of formats), as well as a container service built on Kubernetes. Every time we got more than one product to adopt a service, that was proof we’d avoided duplication and created efficiency. The structure of the services also optimized for self-service, which accelerated developer velocity. With one of our DevOps services, we reduced the round-trip cycle for performance testing from 24 hours to a few minutes, as teams were based on opposite ends of the world. We also cut 30+ days off the release timeline for new applications and major releases.

Overall, I see platform engineering as an evolution of DevOps and SRE into their next generation. You could do DevOps and SRE without ever fully solving for self-service or platform as product, which is the key distinguishing factor.

Best of luck on your platform-engineering journey! And if you want some advice on how to apply this, let me know — we’d be happy to help.