“You build it, you run it.” These were the words famously spoken by Amazon CTO Werner Vogels in 2006 — words that inspired a new generation of application development. “The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it,” he said. “Not at Amazon.”
Since then, organizations have sought out ways of bringing development and operations closer together. DevOps is the most obvious expression of this. But we can also see elements of an integrated approach in site reliability engineering, and more recently, platform engineering.
But what exactly is platform engineering, and how is it different from the trends that came before it? Why should you care? We’re breaking down all the need-to-know fundamentals in this quick guide to platform engineering. Let’s start!
What is platform engineering?
Platform engineering is an emerging field that seeks to improve the speed of software delivery. To do so, platform engineers create and maintain tools, mainly internal developer platforms, that allow developers to self-serve. This means that developers always get the operational support they need — without having to deal with complex infrastructure. Ultimately, platform engineering is about improving developer experience, which in turn boosts productivity.
Why does platform engineering matter?
So far, we’ve touched on platform engineering bridging Devs and Ops, improving developer experience (DX), and facilitating faster software delivery. But why now? Why is platform engineering especially pertinent in today’s day and age? To answer this question, we need to take a closer look at the advent of serverless, cloud-native technology.
When Vogels coined You Build It You Run It in 2006, AWS had just launched. That’s also when the term ‘cloud-native’ came onto the scene. Here’s how AWS defines cloud-native:
“Cloud native is the software approach of building, deploying, and managing modern applications in cloud computing environments. Modern companies want to build highly scalable, flexible, and resilient applications that they can update quickly to meet customer demands. To do so, they use modern tools and techniques that inherently support application development on cloud infrastructure. These cloud-native technologies support fast and frequent changes to applications without impacting service delivery, providing adopters with an innovative, competitive advantage.”
To sum it all up, cloud-native brings many benefits, not the least of which is scalability. But at the same time, it adds complexity. As this blog by Humanitec points out, “The explosion of cloud native tooling and infrastructure, combined with the shift left and ‘you build it, you run it’ trend, are overwhelming engineers and decreasing both their productivity and overall quality of experience.”
Platform engineering helps to alleviate the growing pains of engineering organizations. As new technologies emerge, such as microservices and cloud-native, platform engineering provides developers with the tools they need to remain productive and agile.
How does platform engineering work?
As we mentioned above, platform engineering involves creating and maintaining an internal developer platform, or IDP for short. Luca Galante describes the IDP as a “layer on top of the tech and tooling an engineering team has in place already.” The purpose of the IDP is to allow developers to self-serve operational support, streamlining the overall software development lifecycle.
So, who does all of this? Many organizations have a dedicated platform engineering team, led by a product manager. You can think of platform engineering teams as product teams whose customers are their internal developers. And their product is the internal developer platform.
Like other product teams, they’re tasked with building a product that fits the unique needs of their customers. That’s why an IDP will be different from company to company. As pointed out in the 2021 State of DevOps Report by Puppet, building an IDP isn’t just about implementing a cloud platform and calling it a day:
“Some organizations have taken to calling their cloud usage (public or private) an internal platform. However, for best results on an internal platform, you need to move beyond Infrastructure as a Service. We see this across the spectrum of organizations in their DevOps evolution; however, if you’re only building infrastructure as the self-serviceable items, you’re much less likely to advance to higher echelons of evolution. The major unlock happens when you start to make application components available via self-service.”
To sum it up, high performers build an IDP for more than infrastructure self-service. They also consider developer and application functionality, such as observability.
5 reasons to embrace platform engineering
Here’s a quick rundown of why you should embrace platform engineering.
Reason #1: It enhances developer experience.
As we just mentioned, platform engineering and developer experience go hand in hand. Developer experience, or DX for short, is all about optimizing the developers’ workflows, processes, work environment, and more, so that they can have a more meaningful and delightful experience. If DX is an idea, platform engineering is the material it’s made of.
Platform engineering inherently improves developer experience, and that’s because of the next point.
Reason #2: It allows developers to self-serve.
One of the reasons developers love platform engineering is because it enables self-service capabilities. The platform engineering team is responsible for creating an internal developer platform (or IDP), which is basically a collection of tools, capabilities, and processes. This IDP gives developers everything they need to build, test, and run their own software. This level of self-sufficiency reduces the friction that would otherwise exist during the process.
Reason #3: It increases speed.
In traditional settings, software engineers would be responsible for the product that the company’s selling (i.e. an app), as well as the infrastructure that would allow them to develop that product. Understandably, this type of model would have a negative impact on the business. Since software engineers had to divide their attention between the product and the infrastructure, it took them longer to deliver a product to the customer.
Metrics, such as time to value (TTV), are more likely to improve when companies introduce platform engineering. Platform engineering takes care of the infrastructure, so that software engineers can focus on delivering value to the customer (and in turn, the business).
Reason #4: It reduces the cognitive load of software engineers.
As you may already know, cognitive load is the amount of information that an engineer has to process to complete a task. Other disciplines, such as DevOps and site reliability engineering (more on this below), can sometimes lead to a greater cognitive load — while platform engineering helps to resolve that.
Aeris Stewart says it best in this article for The New Stack: “Good platforms mitigate the problems that arise from poorly adopted DevOps and SRE. Where DevOps create too much cognitive load for developers, platform engineering seeks to alleviate it by finding the right level of abstraction and paving golden paths. Where fake SRE tend to create bottlenecks for developers, platform engineering prioritizes developer self-service and freedom.”
Reason #5: It’s the natural evolution of DevOps.
By now, you might be wondering what makes platform engineering different from DevOps. After all, DevOps bridges the gap between software development and IT operations. Doesn’t platform engineering seek to do the same? Yes and no.
Like DevOps, platform engineering is concerned with facilitating the overall software development lifecycle. Unlike DevOps, platform engineering achieves its goal by creating an end-to-end self-service environment. DevOps, on the other hand, uses continuous integration to help the development teams and operations teams work together more efficiently. In platform engineering, continuous integration does play a role, but development teams don’t need to coordinate their efforts with an operations team.
For an in-depth look at DevOps (including how it relates to Agile), check out our blog post here.
Frequently asked questions
What’s the difference between platform engineering and site reliability engineering?
This article by Ambassador Labs explains it clearly: “Platform engineering teams apply software engineering principles to accelerate software delivery. Platform engineers ensure application development teams are productive in all aspects of the software delivery lifecycle. Site reliability engineering teams apply software engineering principles to improve reliability. Site reliability engineers minimize the frequency and impact of failures that can impact the overall reliability of a cloud application.”
That said, some engineering organizations do choose to combine both disciplines. Platform engineering and SRE share enough commonalities for that to make sense. For instance, both types of teams treat the platform as a product and their users as internal customers. Both rely on self-service capabilities to improve the productivity of developers. And lastly, both are focused on reducing or eliminating toil, which Google defines as manual, repetitive, automatable, and tactical work. Toil has no enduring value and often detracts from a team’s ability to innovate.
What’s the difference between platform engineering and DevOps?
Platform engineering and DevOps are closely related. Some even say that platform engineering is the progression of DevOps. Let’s first take a look at DevOps. DevOps is short for development operations. The overarching goal for DevOps is to integrate the development side and the operations side of a given software project — mainly through automation of the CI/CD pipelines. This is why a DevOps team typically consists of both developers and IT operations. The result is that projects flow from Devs to Ops more easily and consistently, and neither side is waiting on the other for feedback.
Now, let’s consider platform engineering. High-performing organizations have a dedicated platform engineering team that’s responsible for building an internal developer platform (IDP). Thanks to the IDP, developers can choose their preferred level of abstraction which reduces cognitive load. Automated CI/CD pipelines and alerting are also often included in the IDP. This process creates less dependencies.
What are some tools that can help with platform engineering?
Check out these providers to get you started in your platform engineering journey:
- Kubernetes: Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes also powers GitOps, a framework that
- Humanitec: With Humanitec’s Platform Orchestrator, you can create a dynamic internal developer platform (IDP) that enables developer self-service.
- Terraform: Terraform is an Infrastructure as Code (IAC) tool that lets you build, change, and version cloud and on-prem resources safely and efficiently.
Keeping up with software delivery, especially in the cloud-native era, can be challenging — even for the most skilled teams. But it doesn’t have to be impossible. Platform engineering can provide developers with an ecosystem that supports their speed during the software development lifecycle. And let’s not forget the ripple effect that has on developer experience and employee happiness.
While platform engineering can help to boost developer experience and productivity, it’s also important to keep in mind the importance of Focus Time. A time orchestration platform like Clockwise can help developers automatically schedule their meetings for optimal Focus Time. Plus, Clockwise syncs with Slack and Google Calendar. Try Clockwise for free today!