For the past five years, we’ve been asking people how they use cloud native platforms in our State of Kubernetes surveys, now renamed the State of Cloud Native Platforms. This allows us to get a sense of how well these platforms deliver on their promises.
The promise of platforms is to improve how your organization builds and runs its own software: getting faster releases, higher quality with more security, and freeing up developers’ time to focus on the actual apps instead of the infrastructure. As a budding discipline, platform engineering seeks to deliver a seamless, self-service, and continuous platform experience. But, setting up a platform engineering program requires a significant investment of time and effort, and it doesn’t operate on autopilot afterward so the benefits of doing it need to be substantial. Let’s explore the significant payoffs reported this year and look at some indications of how to put together a good platform engineering strategy.
Making people more efficient and productive
When it comes to productivity, this year, platforms are looking good. Seventy percent of respondents said that IT operators are more efficient, and 64% said that developers are more efficient when using an application platform. These are up from last year as you can see in the below chart:
Similarly, you can see slight growth in the actual business. Just over a quarter said that their platform initiatives are helping their business grow market share. And, the same amount said that their platform initiatives are helping create new sources of revenue. Hopefully, those will grow over time as organizations’ use of platforms matures and they add more apps to the platform.
Technical Benefits
Let’s look at the more technical benefits survey respondents reported this year. Here, we’ve been pretty consistent in asking the same questions each year, so we can see some multi-year trends. I try not to read too much into small fluctuations year over year, but you can see some interesting ones this year.
First, though improving resource utilization still tops the chart, it’s gone down and stayed flat for the past two years. Better use of infrastructure is one of the promises of containerized apps: you should be able to cram more of them on each “server” you have, but more than with traditional virtualization, you should be able to spin down apps that aren’t in use – the whole “elasticity” promise of cloud that meant you could bring up resources when needed, and shut them down when not in use.
What I’ve tracked the most over the years are the developer-centric benefits: shortened software development cycles and containerized monolithic applications. In 2021 and 2022, you can see those two took a nose-dive. At the time I attributed that to Kubernetes going mainstream. As more and more people used Kubernetes, especially outside of the tech industry, a new, multi-year learning cycle kicked in. Looking at the responses this year, you can see that they’ve been increasing for two years now. I’d speculate two things here: people are getting more practiced at platforms, and platforms are getting easier to use.
Can you have too much platform?
There are still challenges, of course. As with most years, topping the chart of challenges is “Meeting Security & Compliance Requirements” which 55% of respondents reported as a persistent problem.This year, we added a new way to look at challenges by asking people how many different platforms their organization used.
Our theory was that the more platforms you had, the more challenges you’d have. One of the most important goals of platform engineering is to introduce consistency into the app layer – how apps are architected, configured and packaged, instrumented, run, and are fixed in production. The more ways you have of doing those activities, the more your dev and ops staff are going to have to learn, use, and contend with. Their cognitive load increases, to use the platform engineering term for banging your head against the wall.
Putting a platform in place can help, but if you end up putting many platforms in place, you’re just repeating the same problem of too much variability over again. This year we were able to track this by looking at the rankings of challenges based on the number of distinct platforms organizations run.
As organizations move from one or two platforms up to four or more, you see large jumps in reported challenges. Topping the list, as ever, is security and compliance. But, when you go from organizations using one platform to four or more platforms, people saying that security and compliance is a challenge jumps from 48% to 74%. You can also see that building “golden paths” gets more difficult as well when you look at “Challenging to build repeatable, scalable paths to production.” There, respondents with one platform cited this challenge just 25% of the time, but it goes up to 47% in organizations using four or more platforms.
To me this reads as saying that you should endeavor to reduce the number of different platforms in your organization. This can mean several things.
First, you can put in place an “opinionated” platform like Cloud Foundry. Like all platforms as a service (PaaS), Cloud Foundry standardizes how applications are packaged, configured, deployed, scaled, and managed. It favors the benefits of standardizing over the ability to customize. This is the ultimate way to put in place consistency across the board. And, it works! Thousands and thousands of applications run on Cloud Foundry. There’s a good chance you might even use one today.
Second, you can introduce opinions, templates, and, thus, consistency on-top of Kubernetes with a framework like app Spaces, which our team has been working on. Here, your platform engineering team can customize and specify how developers use Kubernetes and also ease how developers configure Kubernetes runtime environments. The effect is the same as using something like Cloud Foundry.
Conveniently, we’ve evolved the Tanzu Platform for both of these scenarios!
Platforms won’t fix your broken culture, but a broken platform will break your fixed culture
There’s a trope in our world that technology is easy, but people are hard. That is, you can easily figure out and install any old tool that comes along, but changing how people work is the real challenge. I think this is half-right: as someone with first-hand experience being a person, I can vouch that people are difficult to change.
However, technology is incredibly difficult as well. Knowing what’s available, selecting it, figuring out how to budget for it, setting it up, and then figuring out the ongoing management practices of it are all difficult. If technology was easy, most of us in the IT industry would be little more than staff who knew how to unlock the mysteries of corporate procurement.
Instead, I’d look at your platform as the thing that enables your people to change how they work. You want what your platform does, how it “thinks” and wants your developers to think, to reflect the change you want. Technology might not fix your culture, but choosing a technology that’s incompatible with your culture is going to make things even more difficult.
Add to this that building and maintaining platforms year after year is difficult and costly. Over the past ten years, I’ve seen many people fail to take platform selection and gardening seriously. Most of those who suffered thought that technology was easy – they could just build it on their own, often from Kubernetes – and then get to changing those pesky humans. These teams underestimated the effort, costs, and risks of platform building. They spent much of their time on lengthy platform building projects, and less time on the higher value tasks of improving how the organization did software. Many of these DIY platform building shifted to ready-made platforms after a year or so when they found themselves still building the platform instead of running apps.
