Why Platform Engineering
Platform engineering has been a big buzzword recently in operations circles. When you look at platform engineering it’s composed of a few things:
- Improving developer productivity through creating standardized tools (“golden paths”)
- Creating reusable components and services
- Providing a clear view around the mess of vendor tools
This is one of the more exciting areas of operations because of how complicated dealing with the stack of tools that makes up a modern application. The idea of shifting left on who runs applications is a good one but it causes too much cognitive load for developers. Creating a platform with “golden paths” for deploying reduces that cognitive load while still allowing devs to own production.
All this means that when you are working at scale you want to have a developer platform. Successful developer platforms should also allow for the development of better APIs. This empowers developers by giving them tools to access every part of the organization.
What do I mean by platform engineering
Platform engineering differs from normal DevOps because the customer is other development teams. The other major difference is focusing on glue code. Much of this glue focuses on external tools and turning those tools into an opinionated stack.
The critical measure of a platform team’s effectiveness is developer productivity. Since this needs customer orientation it makes sense to have a product manager on the team. This is because platform engineering is operations with a product mindset.
This mindset shift is significant for most operations groups. It means that there really needs to be very cross functional teams. Another critical component of a successful platform is good education. Making it so that other developers know how to use the tools is critical. A common mistake is to assume that the product engineers will learn to use the platform. This doesn’t take into account the amount of other stuff they are dealing with.
For platform teams to improve developer effectiveness they need to lower cognitive load for product developers. This means creating easy to use paths for common patterns and workloads. Along with making it easy to get started on the cloud and with other tools that are widely used at the company.
Improved tools along with advocacy and education should drive adoption. Mandates aren’t the path to a successful platform, instead the goal is to get people using the platform voluntarily. Teams refusing to use the platform are opportunities for growth. When teams refuse to adopt the platform you can see gaps and areas where the platform is weak.
How platform engineering helps manage complexity
Platform engineering is critical to managing the explosion of tools that exist today. Each tool adds to the complexity of deploying applications. This is caused by each tool adding solving part of the space. At the same time each of those tools has their own APIs and quirks that need to be learned.
Despite these issues most of these tools are needed to allow for modern production practices. When they are used well it causes people to be able to go faster and build more. The key thing is that the tools need to be easy to use. By default they can be but combining them is tough. If there is an opinionated way to use those tools people are much more likely to pick it up.
This job can’t just be handled by the individual teams that are building because they have so much domain knowledge they need to learn already. Having a specialized team that figures out which tools are right for the organization, packages them up in a usable way and makes it easy to get started means people are more likely to do the correct thing. Good practices don’t happen by accident but instead because of the concentrated effort of multiple people.
Why gluing together components is critical
A good chunk of platform engineering is gluing other tools together. It’s easy to dismiss this as not super interesting; it’s actually one of the most important things in modern software systems. If you are building on a cloud platform there are a ton of tools that are being used. There are also the SDKs for other systems that have to be contended with. Understanding all of these is a big problem especially when it’s just left in the hands of product teams
Product teams need to be able to use their tools easily. You want the product team to understand how to build products, not how to use the cloud. This doesn’t mean that you don’t need any expertise around this, it just is going to live elsewhere. Platform teams can provide the expertise around tools while making a clean abstraction that others can leverage.
To build a clean abstraction layer a unified view of the tools is needed. This is where the platform needs to be opinionated. Being opinionated doesn’t just mean doing what somebody argues for the loudest but listening to customers and giving them what they need. The idea is to make something that is easier and simpler so that teams will agree to the guardrails that are being proposed.
Wrapping Up
So today we covered:
- Platform engineering is a product driven approach to Operations focused on developer productivity
- How internal developer platforms can help manage complexity
- Why there will be more glue code in the future and that’s ok
That brings up the question should you start building an internal platform. If you are in a large organization it’s worth doing. If it’s a small org or an early stage startup it’s going to be a distraction from shipping for the first time. The more interesting question is for organizations in the middle. I think once you have four or 5 engineering teams in place it’s worth thinking about how those teams can be made more productive. In the beginning that can be pretty low tech but that work would be the seeds of an internal developer platform.