Eric Laan - Sr. Specialist Azure App Innovation & Development - Microsoft

While the DevOps approach has been around for quite a while, many times it is mistaken for what it is. The last few years we see the term Platform Engineering entering discussions, at times making conversations even more complex. Sometimes it is misunderstood or seen as a replacement of DevOps. This short article aims to explain the place Platform Engineering takes in (complex) modern software engineering systems and what problems it can solve.

Traditional

In the "traditional" software engineering approach the development team responsibility focus is limited for both process and stack. Teams focus on development of new functionality and the majority of the infrastructure/platform resources and their configuration is provisioned on behalf of the application team with a strong dependency on teams who provide these services.

The result is that development teams have limited freedom of choice and software delivery typically sees long lead-times due to dependencies and lack of flow, leading to low business agility.

DevOps

Using a DevOps approach, teams take end-to-end ownership, ideally covering the entire value stream. Teams now no longer just develop new features but also have the responsibility for operational activities, manage cloud spend, and provision the required infrastructure resources and their configuration themselves, where the "landing zones" are provided by a platform team.

Owning both end-to-end process and stack means development teams have freedom to choose and have reduced dependencies resulting in shorter lead-times. However, they need many more skills (security, infra, networking, operations) while team sizes remain unchanged which means that the cognitive load heavily increases and can result in a "cognitive overload". In addition, with a DevOps (Scrum, Agile) approach the number of delivery cycles a team goes through heavily increases which means that certain activities (e.g., security testing) have to happen more often and require a "shift-left" approach.

The result is that on team level we see these teams struggling with all these (overhead) activities which do not directly add business value (e.g., no new functionality is created when you are implementing observability for your Kubernetes cluster) but are very much needed to run applications effectively. With the pressure to deliver new features, teams have to balance speed and quality, potentially impacting reliability.

On company scale, we see that innovation and (cloud)platform adoption is stalling, making it harder for organizations to deliver on their strategic priorities.

Platform Engineering

Platform Engineering is an evolution to DevOps in which, on team level, the operational model remains the same. This means that the ownership and accountability do not change for an application team. What is introduced are centrally provided reusable components and services. These components and services are part of the platform delivered with a product-mindset, offered on a self-service basis, effectively providing paved-paths for application teams to leverage.

Application teams “pull” in these centrally provided components, increasing the time spend on activities which provide business value. Result is that by practicing this:

• cognitive load for applications teams is reduced,
• more time is spend on value adding activities (which increases flow and thus business agility),
• and team autonomy is maintained.

In addition, by providing components centrally we have the ability to standardize usage and optimize resources (on e.g., reliability, cost optimization, operational excellence, performance efficiency, and security & compliance).

Effectively, Platform Engineering enables organizations to scale efficiently and increase the ability to innovate using platform features.

Is Platform Engineering really something new?

The Platform Engineering concept and thinking has matured over the last couple of years. To a certain extent, many organizations are already doing it but there is room for improvement. Often, offered services are not scalable or are not fit-for-purpose and can't be extended on by application teams. Over the last couple of years the thinking around Platform Engineering has matured with two goals that have surfaced and have proven to be essential in the successful implementation of Platform Engineering:

• Shift in culture for the platform to be a "product" which aims to enable their consumers (developers).
• Provide self-service with guardrails enabling consumers to "go fast" with guardrails.

So, not completely new, but when done right, Platform Engineering has the potential to improve the way we deliver software to our users. Take a data-driven approach to measure impact and you’ll see the positive effect it brings.