Platform Engineering

by Camille Fournier

This is where platform engineering plays a vital role, providing a crucial foundation for boosting agility, speeding up time to market, and enhancing overall product quality and user experience. By standardizing tools, infrastructure, and workflows, platform engineering streamlines development, fosters collaboration, and amps up efficiency among teams. It’s the backbone that ensures scalability, reliability, and security, empowering organizations to keep pace with evolving needs while maintaining top-notch performance.

A platform is a foundation of self-service APIs, tools, services, knowledge, and support that are arranged as a compelling internal product. Autonomous application teams1 can make use of the platform to deliver product features at a higher pace, with reduced coordination.

Platform engineering is the discipline of developing and operating platforms. The goal of this discipline is to manage overall system complexity in order to deliver leverage to the business.

The key to avoiding this situation is to constrain how much glue there is, which aligns with the old architectural principle of “more boxes, fewer lines.” Platforms allow us to do this, and thus to extract ourselves from the swamp. By abstracting over a limited set of OSS and vendor choices in an opinionated manner, specific to your organizational needs, they enable separation of concerns.

Inevitably, these experts will struggle to understand the business needs well enough to make optimal choices, and application teams will suffer. Standardization via authority isn’t enough.

Platform engineering recognizes that modern engineering teams should have systems that they enjoy using, provided by teams that are responsive to them as customers and not just focused on cost reduction or their own support burden. Instead of prescribing a set of standards based on appeals to authority, platform engineering takes a customer-focused product approach that curates a small set of primitives able to meet a broad range of requirements.

Platform engineering is the discipline of developing and operating platforms. The goal of this discipline is to manage overall system complexity in order to deliver leverage to the business. It does this by taking a curated product approach to developing platforms as software-based abstractions that serve a broad base of application developers, operating them as foundations of the business.

From this definition, we can identify the four pillars of platform engineering practice: Product Taking a curated product approach Development Developing software-based abstractions Breadth Serving a broad base of application developers Operations Operating as foundations for the business

“One of the goals we ask our platform teams to aim for is that a user of the platform should be able to tell whether they’re doing something wrong or the platform is doing something wrong. Obviously that’s an ideal you can never entirely reach, but it’s a good mindset.”

When you build products with business-facing surface area, business-facing product managers come with the territory. So, in these cases we advise hiring a PM much earlier—maybe as soon as the team is formed. However, you need to avoid the mistake of thinking every successful business-focused PM can successfully transition to internal platforms. They’ll be accustomed to being evaluated based on whether they can deliver the company revenue and profits, so they’ll be focused on business and customer needs. This likely means that not only will they want to leave platform aspects like “reliability” and “developer productivity” to their engineering manager counterparts to scope and prioritize, but they will also demand that such concerns take secondary priority unless they have visible customer impact, at which point it’s usually far too late to solve them with cheap or easy fixes.

You should reinforce this culture of customer empathy through goal setting. Platform teams without a captive audience may complain about adoption as a goal, rightly pointing out that they can’t force users to adopt their products; meanwhile, teams with a captive audience may blame their users for slow growth in adoption, citing lack of engagement or other priorities. Both of these reactions lead to the question: Are you building things that people want? How do you know? How are you making it as easy as possible for people to adopt your offerings? Do you know what the potential customer base looks like, and are you being realistic about who needs and wants this offering? Asking your engineers to measure their success through the eyes of their customers shakes them out of a purely technical mindset and refocuses them on the experience, use cases, and purpose of their systems. Some basic questions to start with include: If your system is supposed to make people more productive, how much time do you think this change will save your users? It’s surprising how many teams claim to improve productivity but neglect to measure what they are planning to improve! How many hours a year do your customers have to spend to keep using this platform (through reacting to upgrades, migrations, etc.)? This can help you spot unattended pain points and friction. Are your support requests about common repeated issues or unusual situations? The easier the system is to use, and the better your docu...