(Transcript of an ignite talk delivered at DevOpsDays Berlin 2024)
You are a new "DevOps" engineer joining my team. We are a small product team in a large IT organization. You hear we need to redesign our whole CI/CD pipeline concept in order to scale. So, you start looking for some company-wide standards we can leverage on, but all you find is that every team seems to be doing its own thing. You have to start from network and firewall configurations for our case. That means, the application scaling will take longer than expected. Customers are unhappy. We have a problem!
But it shouldn’t be like that. Mankind has not achieved the technological evolution of today by reinventing the wheel each time new ideas needed it. Quite the opposite: we reuse, we build on top of existing knowledge. Technological mass adoption has historically, consistently relied on these principles. Why should it be different for DevOps?
In today’s world, it is reasonable to expect that, if IT-Organizations have “established” DevOps, they also have mechanisms in place to scale it.
Why is this a reasonable expectation? Let’s review three base facts...
Fact #1: DevOps is a mindset. You know, less of “this is my part” and “that is your part”. More collaboration, we talk about teams having end-to-end responsibility and ownership of the software, including all operational aspects of it.
Fact #2: DevOps is enabled by tooling. To achieve the famous “You build it, you run it”, a significant layer of code and tooling is necessary: delivery pipelines, runtime configurations, monitoring and observability, etc. This layer can be seen as “The Platform”.
Fact #3: There is a lack of operations experience in developers. The tooling can be quite complex and when scaling, the cognitive load for the team becomes significantly higher.
Now, the goal of introducing and establishing DevOps in IT organizations is to optimize and maximize value delivery. For this, it’s quite normal today to find structures of product teams focused on generating value for customers. Depending on the size of the IT organization, it might be just fine when product teams cover also all the platform aspects of the software.
But the larger the organization, and the amount of product teams, the more necessary it becomes to have at least one “Platform Team” to help with the flow of value delivery.
A platform team would develop, build, and maintain the platform that enables DevOps in the product teams. While a product team is focused on generating value for the customers, a platform team is focused on generating value for the product teams.
At this point I highly recommend you to read about the “Team Topologies”. You’ll find valuable insights supporting not only the platform teams’ approach, but in general how to optimize teams for fast flow.
It’s interesting also to see how the Platform Engineering approach is seen as a key technology trend in the next years. According to Gartner and international consultancies 2023 technology trends:
By 2025, 95% of enterprises will fail to scale DevOps initiatives if shared self-service platform approaches are not adopted.
By 2027, 75% of organizations will have switched from multiple point solutions to DevOps platforms to streamline application delivery.
Coming back to my story from the beginning, back then my team got stuck because there was no platform team around that we could rely on. Luckily, things are moving in the right direction in the company now.
My key message for you today is: Platform Engineering is more than a hype, it’s a necessity. It’s the only way DevOps can scale.
Comments