6 Patterns for Platform Engineering Success
There’s no doubt the IT tooling choice is overwhelming — just scroll through the Cloud Native Computing Foundation Landscape as it stretches across several screens filled with tiny icons.
Alex Williams, The New Stack’s publisher, kicked off a PlatformCon 2023 panel with the observation that, in the platform engineering community especially, “there’s a high demand for guidance and how to build these robust internal developer platforms, how to architect them, and which tools to use.”
With such a plethora of choices, there are more questions than clear answers:
- Build versus buy — versus buy and customize?
- Select an open source platform or a proprietary one?
- How do you integrate existing tools and workflows?
- Deploy on single cloud, multicloud or hybrid cloud with some workloads on-premise?
- How do you build a modern internal development platform [IDP] out of existing setups?
- Who is in charge of the platform — DevOps, operations, sysadmins or a platform team?
- How can you tighten the feedback loop with developers?
And most importantly, what do your internal developers actually need?
Today we unlock several emerging patterns — and highlight some antipatterns — as the young socio-technical discipline of platform engineering reaches toddlerhood. Here are highlights from the PlatformCon panel on modern blueprints for platform engineering, so you and your team can hopefully find your unique way of walking and then running with a platform that developers actually want to use.
1. Recognize That Your Platform Will Be Unique.
What is an internal development platform (IDP) for modern organizations? That’s the key question without clear answers.
“That’s quite specific to the company you’re talking about,” said Anastasija Efremovska, platform engineer for Dutch e-commerce shop Bol.com on the panel. “Smaller companies’ UI templates or blueprints are working very well, but the moment you go into an enterprise, you do need a bit more diversified approach.”
Because as you scale, you have very different skills and types of engineers to cater to — and likely must meet more compliance and security needs. This all translates into an IDP that can be anything and everything, from a blueprint to CLI.
“The first thing we think about IDPs is there is a user interface and we’re scaffolding a new service or resource,” said Kaspar von Grünberg, CEO of Humanitec. But, he added, “that’s only a small bit of the whole thing and it’s a little bit of a narrow focus.”
An IDP blueprint must consider the entire life cycle of the application, von Grünberg said.
“I also really don’t think you can boil this down to tools because the reality in the enterprise is multi-CI, multi-registry, multi-everything. So there is not that toolset for platform engineering,” he said. “It’s how you combine them.”
Von Grünberg thinks about modern reference architecture as built into five planes:
- Developer control plane: version-control systems with Infrastructure as Code, with perhaps a workload specification or a developer portal, like Backstage, where the different personal groups interact with the whole platform.
- Integration and delivery plane: takes developer requests and syncs them with the baseline configuration of the platform. It includes CI/CD pipelines, image registries and platform orchestrators.
- Resource planes: the cloud or clouds, databases, clusters.
- Monitoring, logging and observability plane.
- Security plane: for instance, policy layers and secrets management.
To von Grünberg, a combination of these is what is behind an internal developer portal. Then, which tools you choose to deliver this platform stack will depend on the team and the complexity of the organization.
2. Figure out Who’s the Boss.
What is a platform engineer? It’s a frequently googled turn of phrase, because frankly a lot of organizations are rushing to adopt platform engineering in name only. Sometimes, the human resources department just updates job titles from sysadmin, DevOps engineer or site reliability engineer (SRE) to “platform engineer.”
Part of the problem is, when no one in your organization specifically designates a platform architecture team, different roles can get saddled with the job. Those colleagues could come from any of these teams:
- Systems administration.
- DevOps and CI/CD.
- Operations.
- Security or site reliability engineering (SRE).
- Developer experience or DevEx teams.
- Application development teams.
All of these teams should be involved in some way in creating your organization’s platform. It should delineate a more secure, frictionless pathway to production. And it should eventually integrate within your DevOps or CI/CD pipeline. Always remember that the point of the platform is to ease the burden on application teams, which means they should be able to give ample feedback — but they likely shouldn’t be building the whole thing.
“A lot of companies are figuring out there’s a need to curate the experience of using this platform because there are so many different systems,” said Taras Mankovski, CEO of Frontside Software, a developer experience consultancy and a Backstage organization member.
They’re asking questions like, should developers be using Terraform? Said Mankovski, “What the [DevEx] teams are engaged in is the process of asking: What difficulties do developers have and how can we remove that friction?”
That makes two key questions for building modern developer platforms:
- What is our developers’ toil?
- How can we remove it?
It all comes back to identifying what Abigail Bangser, a principal engineer at Syntasso, calls the “not differential but not unimportant work” that teams share across the organization. You know, the cross-organizational priorities like security and deployment speed, which are often taken care of the same way across an org. These things are priorities, but individual app teams don’t bring differential value to end users by fussing around with them.
Different companies start out with different phases or goals in their platform journey. Actually, most don’t start out with a platform mindset at all. There might be a DevOps team already in charge of some of the platforms like the CI/CD pipeline. Maybe am SRE team doing some chaos engineering, monitoring and observability. And then, of course, individual app teams are building their own stuff or using third-party tools — often to engineer around anything from those other teams that are in their way.
At several companies we’ve talked to, the idea of a platform — or, according to Puppet’s “State of Platform Engineering Report,” in reality, three to six platforms — kind of comes up organically. A cloud engineer or a DevOps engineer might not even realize they’ve become a platform engineer — or what that even means.
As scattered platforms evolve into more of a tangible, cross-organizational platform strategy, you need to clarify who is in charge — that one point of contact and source of backlog.
Oh and one more thing. The platform team may be in charge but don’t forget the old adage that the customer is always right. If you don’t listen to your internal developer clients and build what the majority of them want, then they will again engineer their way around whatever you’re foisting upon them.
3. Establish a Culture First.
A platform is hardly a novel concept. It’s just that, these days, it’s built through collaboration, while previously it was more command and control.
“Before the advent of platform engineering, we just built stuff and expected our engineers and our end users to use it,” said Quiran Storey, software engineer at Bol.com. Now it’s about thinking about what your internal users actually want.
While tool choice is important, platform engineering is an inherently socio-technical endeavor. That means nurturing a developer-first culture is a crucial part of any success.
“When we start to talk about [whether] to build or buy a platform, we need to first ask ourselves and ask the company about our mindset, about our culture, and how does a platform fit in this company?” said Juliano Marcos Martins, senior technical manager of cloud and platform at Mercado Libre Latin American e-commerce platform.
After all, cross-organization communication is both a benefit of a platform strategy and the secret to its success. The company culture supports the platform, but platform engineering should also have a positive effect on the culture. A platform should act as a translator or transparency enabler that allows IT to stay better connected to the business value, and business to gain better insight into what the large cost center of IT is up to.
Friction can occur, Martins observed, when platform teams are taking away responsibilities from DevOps, which is why he says an IDP shouldn’t just factor in the developer perspective, but also the company perspective, improving, among other things, governance, security, efficiency, cost, and time to market.
4. Maintain One API Access Point.
“Suddenly the shift is, we have customers as platform engineers,” Efremovska said. “You need to make them happy, while keeping stability, security, audit-ability.”
In her five years as a platform engineer for Bol.com, she has learned that you shouldn’t abstract things too much — because that adds to an engineer’s cognitive load when they try to work out how to do things or what’s happening under the hood.
One of the things app teams want out of their platform is a uniform way to access what they want. That’s via an API.
A platform API should be akin to the Kubernetes resource model, Efremovska advised, where you can use the Kubernetes API as a single, consistent way to access a lot of different cloud providers and third-party offerings.
So, once you get out your first platform prototype or thinnest viable platform, she recommended, you should create a single access point via a single internal API. Then you create templates on top of it.
5. Focus on the Goal of Self-Service.
The platform team does not want to turn into another barrier to app teams. An API-first design is essential to fulfilling the demand that a platform and its automation are first and foremost self-service. Your app teams want to be able to pick, choose and use the pieces of the platform they need.
“Good architecture designs allow for the system to grow de-centrally,” von Grünberg said. “The user can say, this golden path works for me, but, if it doesn’t work for me, I know how to extend this and grow the system.”
Any extension could be later adopted by the platform team to create a new golden path.
Another must-have for the self-service platform is searchable documentation, so your developers can find the answers, how-tos, code samples and error-code definitions themselves.
6. Let Your Developers Drive Your Decisions.
Storey’s advice for kicking off your platform journey: Ask your developers what they need to do 80% of the time.
For each piece of the platform that you release, you need to provide and uphold a service-level agreement, golden paths, documentation, compliance and support. It’s better, Mankovski reminds us, to work on the release and adoption of smaller wins than having to sell monolithic-style internal updates. That also keeps a much tighter developer feedback loop.
“Be wise in what you offer because then it becomes operational burden for you as a platform team,” which is tasked with maintaining and complexity or technical debt you create. Storey echoed the thinnest viable platform way of reducing complexity: “If you offer one thing and you do it well, rather do that, than offer a bunch of things that are just sort of mediocre.”
Want to learn more about platform engineering? Pre-register to receive the forthcoming ebook, “Platform Engineering: What You Need to Know Now,” sponsored by VMware Tanzu.
