What is platform engineering?

#devops #programming #cloud #tooling

What is Platform Engineering? It is one of those terms that suddenly start to pop up in every tech article and job offer, and you can’t help but look at it suspiciously. Is it a new trend that will be forgotten in two weeks? Is it a new name for the same old DevOps you already know and love? Let’s dive deeper into the Platform approach, and unveil this mystery once and for all.

What is platform engineering: Terminology

To clarify what a platform is and what it is not, let’s use Evan Bottcher’s definition:

“A digital platform is a foundation of self-service APIs, tools, services, knowledge, and support which are arranged as a compelling internal product.”

What does he mean by that?

The platform must be self-service. The dev team needs to respond quickly to customer needs. They can’t depend on creating requests for another team and depend on their availability so they can keep on with their job.
The platform must provide support. The platform team (the team dedicated to making the Internal Development Platform a reality) needs to make it useful, effective, and easy to understand.
The platform must be a compelling internal product. The platform team must advocate for their platform product and “market” it to internal teams, so they find it attractive and want to use it.
Using it must be voluntary, not compulsory. The only way the platform is going to be successful is if the users want to.
It must simplify something for the user. The platform should give dev teams a path of least resistance, making the right thing the easiest thing to do.
It must be carefully designed and curated. Platform teams need to focus on the users of the platform (the dev teams) and their needs, designing the platform with them in mind and putting the focus on UX and DevEx).
It must evolve to take advantage of technology changes, improving the capabilities it offers with a clear roadmap.
It needs modern product management and service management.

Internal Development Platforms, or rather, the whole Platform as a Product approach, provide your company with the answer to a lot of the problems that you once thought insolvable, like:

Developers constantly wait on Ops for simple tasks or face complex structures composed of different new technologies if they don’t want to wait.
Poor developer experience and difficulty to change from one product to another.
Ops becoming a bottleneck in the development process, while also being tied to repetitive work and hard-to-maintain setups.
A lack of standardization across the organization: each team does its thing with wildly different results.

In short, people spend more time having to interact with relatively low-level services and thus spend their time on relatively low-value decisions.

This approach helps change the story. With an Internal Development Platform, many of the pain points in the development lifecycle improve or are completely solved. A Platform:

Is designed with standardization in mind.
Reduces maintenance overhead
Reduces the cognitive load for the developer
Gives more autonomy to the developer, without more responsibility.
Evolves and adapts to new features demanded by the environment.

Platform Engineering vs. DevOps

The DevOps’ main goal is the unification and automatization of processes. They balance the needs throughout the software development cycle, from coding to maintenance and updates, and aim to streamline the communication and collaboration between Operations and development teams.

Platform engineering and DevOps teams are responsible for deployments, infrastructure, and service accounts. DevOps teams, on the other hand, aren’t creating platforms with explicit APIs and abstractions that provide flexibility to app developers; platform teams are.

Platform teams are complementary to DevOps, and they can work together to meet the increasing demand for faster development cycles. The typical scenario shows the DevOps team managing many operational responsibilities (resource management, scaling, security…), all of which are not a big deal on their own, but pile up really quickly and take time off for more meaningful work. With Platform Engineering, they would set the baseline configurations, templates, roles, and permissions of the organization’s infrastructure. The Platform Team would then develop a platform with the dev team in mind, where they can configure, deploy and spin up app infrastructure on their own, without DevOps intervention.

IDPs also help the DevOps team in achieving its goal of automating the software delivery process, and help the company deliver software faster: developers don’t have to wait for a DevOps engineer to provide the infrastructure for their code.

Platform Engineering vs. SRE

Site reliability engineering primarily focuses on IT systems’ reliability and performance. SRE teams work with developers throughout the software development life cycle to ensure the software is reliable and meets non-functional requirements and SLAs. It not only follows the project until it’s live, but also keeps it updated and working after that.

Platform Engineering allows developers to easily comply with the requirements imposed by SRE. By creating an environment with golden paths (where, as we said before, the right thing is the easiest thing to do), the workflow improves.

Meeting in the middle

Platform Engineering focuses on developing an ecosystem that can be efficiently used from the Dev, Ops, and SRE standpoints. It provides developers with more autonomy over their own code in the whole development cycle, it allows DevOps to automate as much of the development and deployment process as possible (and it also liberates them from mechanical tasks so they can improve their DORA metrics innovating and experimenting with new products), and finally, it gives SRE a way to centralize and manage the reliability of the projects.

This article was originally published at Napptive Blog