Platform Engineering. Platform Engineering everywhere… and anywhere. Because most of the posts about Platform Engineering I found in the internet is either a detailed dig into one area of SDLC automation, like comparison of tooling for observability or review of platform orchestrators – or a detailed, purely technical topics for DevOps Engineers, like courses on writing Kubernetes operators, gitops approach to infrastructure provisioning or specifics of Backstage portals implementation. Both types of articles / blogs / courses are super important and brings a necessary details ti implement robust Platforms, but still this is only 20% of what Platform Engineering is really about. So let us finally cover the whole area! Or at least try… This article will guide you from the very concept, through organisational – and then, architecture change Platform Engineering brings to DevOps approach.
Concept
Let’s begin by understanding what Platform Engineering is all about. It’s a relatively new IT field that evolved from DevOps, aimed at boosting developer team productivity by incorporating security, compliance, costs, runtime observability, and other elements.
Platform Engineering is a practice built up from DevOps principles that seeks to improve each development team’s security, compliance, costs, and time-to-business value through improved developer experiences and self-service within a secure, governed framework.
Microsoft, link
A dedicated product team creates and maintains the engineering platform, which is designed to support the needs of software developers and others by providing common, reusable tools and capabilities, and interfacing to complex infrastructure.
Gartner, link
The idea is to abstract these elements so developers can, for example, launch new working environments within seconds without worrying about technology integration or application integration with observability tools.
My definition of Platform Engineering is, in simple words, if you treat your Developers as you normally treat your Customers – and think about how to serve the developers, how to simplify the process of building & maintaining applications, so Developers & Ops Guys can better do their job – you will became a Platform Engineer.
80%
Organisational Change
boundaries of responsibility, operating model, service approach, product mentality, dedicated platform team, defined services, SLAs and goals…
20%
Technology Change
organised DevSecOps & AI tools, permissions model, abstraction: automation, orchestration, portal & self-service…
Platform Engineering isn’t merely about technology; it’s fundamentally an organizational change. It’s about how various IT teams collaborate with developer teams and business application teams. Why is it mainly an organizational change? Because to establish a platform in an organization, several conditions must be met.
- Firstly, clear responsibilities must be defined for the platform team and other teams.
- Secondly, the platform team needs the authority to define and implement these responsibilities across DevOps tools, ensuring that responsibilities aren’t duplicated across multiple teams.
The service-oriented approach and product mindset are crucial. Platform should give a space for Developers to communicate their needs, and the platform provides in an organized way. This shift is also technological since it requires a structured approach to DevOps tools, automation, and orchestration to avoid chaos and enforce clear responsibilities.
You can think about Platforms as building a System to build & maintain other systems. And in order to build such a system, a Platform Team needs to have certain organizational and technological power in hands.
Continuous Platforming
So, how do you approach Platform Engineering? It’s treated like any product development – you start by analyzing user needs, in this case, the developers, and tailor the platform to fit the organization rather than the other way around. This includes planning the platform architecture, defining services, migrating tools, and deciding on user interfaces, like whether a JIRA or a developer portal is used for interactions. Ultimately, the delivery phase involves changing team structures, setting business metrics to measure benefits, and defining service level agreements (SLAs). Operations then focuses on delivering services to developers and ensuring the platform adds business value, assessed through SLAs and feedback.
In summary, while the technological aspects are essential, the analysis phase is critical as it defines how the platform team integrates and operates within the organization, ensuring the platform’s effectiveness and alignment with business goals.
Looks complicated? Yes, it is, if you do it for the first time with no previous experience. Luckily, today you can catch this up with just a few hours!
I’ve spent 4 years building Internal Developer Platforms – as manager of several and advisor to the people, who did it first time. Recently I’ve released an online Efficient Platform Manager, which essentially Platform Engineering Handbook for Managers.
In this course I provide you with end-to-end guidance how to approach Internal Developer Platform – starting with cognitive load analysis, through Platform Services & Architecture design, ending up with success measures, case studies & selling points you can use to convince your organization that Platform should be built. All of the topics from a picture above are there.
Author
Organisational Shift & Results
As organizational result, first – and the most important – Stream-Aligned Teams can finally be focused fully on delivering business value. They do not wait for resources necessary for SDLC process, they are provisioned with the tools in minutes. Developers also don’t need to configure those tools or understand how they work in details – they simply use them, without fighting the high entry barrier or being forced to manage those tools.
We also know exactly who is responsible for what in SDLC – we have a communication channels planned and defined services privisioned by Platform Team, addressing the very cognitive load the stream-aligned teams may have, both organisational and technical.
Practical Example: Provisioning Service – if above sounds too theoretical
Practical Example: Provisioning Service
If this sounds too theoretical – you are right, time for an example, how the things may look like if we have a nicely-done Platform.
Imagine you have a new Stream-aligned Team in a company – or existing Team wants to deliver a new application. Having a Platform, they can simply express their need through a dedicated channel.
“Hey, we are going to build a new software. This new software will be created in Java, there will be a data storage needed & exposition to open network for users. We are going to integrate our app with core-banking & regulatory systems, and we will be handling 1000 transactions daily, mostly from Poland”.
Stream-aligned Team is expressing the need through a dedicated space in Portal – filling a form, creating a YAML file, talking to LLM Chat, you name it. Important is that we have a structured request for Platform Service.
Based on such request through dedicated channel – it can be a portal for example – time for Platform Team to provision this Stream-aligned Team with all necessary resources & capabilities to create, release and maintain a new application.
So, Platform Team is responsible for ensuring, that:
- All the New Team members have access to a repository for their new application.
- In this repository, they find a demo services with the languages.
- This demo services have a ready-to-use CI/CD pipelines, which are deploying this demo application to their environments in Kubernetes – up to production.
- This demo services are integrated with Logging, Monitoring, Tracing Toolset; on which team members can log into and define their own dashboards, alerts & filters.
- This demo services are using databases the Team requested.
- And finally – team members receive instructions from a usage perspective for everything.
What is crucial that all this is done in a matter of minutes – through orchestrators. Mature platforms have all this automated and triggered by a request in the Portal, so the Platform Engineers are not even present in this service. Having everything provisioned at once gives the Stream-aligned Team space to create their applications from the very first day, reducing the number of teams they need to contact, reducing any technical configurations to be played or specifying requirements to technical teams – on which they may not be experts, like network configurations.
Platform Architecture
Ok, a quick look on technology perspective now. This is my way of how I explain Platforms – CNCF recently published their own version, which is probably more detailed than mine – but I believe my example still holds up if you want to understand the principles behind Platform Engineering.
First, the botton-layer, DevSecOps. Here we have an order – no duplicating technologies and capabilities coverage of each step in software delivery lifecycle. This is what most of the big companies already have – maybe not always in an organized, automated way.
What Platform Engineering introduces is orchestration & interface layer. In orchestration you will find a definition of Platform Services & scripts which makes changes in each tool in DevSecOps Layer to provide a managed-service to Stream-Aligned Teams. If we take the previous example, for provisioning those will be a script making changes in Kubernetes namespaces, creating databases, creating indexes in observability et cetera.
At top level, we have an Interface Layer – where you can find either a Portal – or a channel on which developers can state what is their need, in a structured way. It does not always need to be a backstage, sometimes simple APIs or even Jira Tickets are enough. Probably very soon we are going to have chatbots here.
Benefits
Time to summarize the benefits of the Platform.
- First, most important – is time-to-market for business features & bug fixes. Its due to the fact of automation and responsibility boundaries between Platform and Stream-aligned Teams. You simply pay developers for what they are good at – creating and maintaining business features, not fighting, or playing with…
- … technology, which is standardised and limited to what is really necessary in the company. Also, it has an abstraction layer, so the developers can use it without a headache.
- Service approach in Platform Engineering is also organising and standardizing the communication patterns. You won’t have millions of meetings and chats, because with Platform everyone will know what is expected from the Team they belong.
- All three benefits together will give you a slight reduction of core-IT Operations costs – not only because of automation, but also because of standardization and known responsibility boundaries.
- And having abstractions to the tools allows you to hire less experienced developers to create business software – or developers more oriented on the business domain rather than technical solutions.
What is important is that you remember, how to start the initiative – not with purchasing or installing the DevOps tools, not even with the automation – but with a definition of Platform Services and Operating Model, based on deep understanding what is a Cognitive Load in your organization. Techniques to do that you’ll find in Module three of my Platform Engineering Handbook for Managers. Always remember – think about your developers as Customers of a Platform.
