When I look at recent platform engineering surveys, the results are positive: people see the value in platforms and platform groups. I’d say this is because platforms are helping speed up the app release cycle by automating a lot of the infrastructure work app developers would otherwise need to do, baking in/automating security and compliance, and, to a lesser extent, standardizing how apps are built, run, managed, and optimized.

Here’s my notes on one of those surveys, the one from Perforce/Puppet. (I’ll look at the one from Port in my next newsletter episode.)

The Perforce Puppet survey“The State of DevOps Report: The Evolution of Platform Engineering,” Puppet, survey conducted August 24th to September 30th, 2023, published March, 2024

• Demographics: 474 people, 90% some kind of “management”; 44% in tech industry, 24% in ops and 19% in app dev; min. company size 500, 13% 50k or more; 89% from orgs with $50m+ revenue (16% with $2bn+); 38% NorthAm, 27% EMEA, 22% APAC.
• I usually toss out “tech industry” respondents - I don’t think how tech companies operate is “normal”: they use newer tech, pay IT much higher, typically already have good app and ops cultures, and defy most laws of enterprise CFOs and valuation. Outside of that, you have a pretty good mix of medium to larger organizations, and with 13% coming from, like, “Fortune 500” companies. Oddly, 67% said “I am on the platform team” - since 90% are some kind of manager…I guess this means that many of the respondents are platform engineering manager? I don’t know - anyhow - just something to keep around in the back of your head. It’s best not to over-think demographics in these surveys.
• Developer productivity is the top key benefit, followed by quality, and then faster releases (“reduced lead time for deployment”).
• There isn’t a common home in the organizations for platform teams. It’s spread across engineering, operations, and product. However, development seems to own the platform the most, with only 35% of saying that ops owns the platform.
• People believe the platform team is valuable: 65% say that “The platform team is important and is receiving continued investment”
• Platform product management is important: 91% of respondents agree that a platform product management is good (“important” or better) to have, 52% say they’re critical for success.
• “[M]ost organizations have had a platform team for at least three years.”
• “[W]e were surprised to learn that for a popular tool like Kubernetes, only 22% of organizations indicated that it was used in production, with a much greater 46% saying they had no intention to use the tool.” I’ll have to check the latest CNCF penetration numbers - but that seems…expected?
• Security - every vendor’s favorite topic! 60% say that platforms help speed up app releases because the platform has built-in security and compliance. “83% of respondents acknowledged that their platform team played a crucial role in enhancing their company’s compliance.” And most of the respondents agreed that the platforms help with security and compliance.
• Platform security helps lower risk (59% say), removed bottlenecks to growing the business (50%), and freed developers up (“48% reducing time for devs needing to learn security & compliance baselines” and “42% reduced manual work related to auditing”).
• Centralization is loose: 56% of respondents said their organization had 3 or more platforms. Last year (2023), 44% had 3 more or more platforms. This seems bad. The more platforms, the more things to worry about, and the less benefits of scale and centralization you get. Given the history of IT buying and app stacks over the years, it might be unavoidable. The answer here is to embrace this multiplicity and make sure you have standards and practices in place to make it work. Relying on open source tools - especially the shared architecture and config formatting - is a good start. Use Spring if you do Java development, use an open way of describing infrastructure (e.g., Kubernetes) and how to package and deploy apps (e.g., cloud native buildpacks). Still, it seems like a waste to me…

From Lawrence E Hecht and Heather Joslyn who redid the chart on this for their The New Stack article on the survey.Who owns the platform? 👉 Who owns the budget?It looks like (app) developers own the platform. For now.

The survey asks where the platform team resides in organizations. That is, who owns it. This usually means who owns the budget, who decides which platforms to use, and how much to pay for them.

Possible answers were in “engineering,” “operations,” and 'product." I’m not sure what the difference between “engineering” and “product” is.

If we assume “engineering” is “developers” (and probably application developers?), the platform team is in the developers’ organization for 44% of respondents, and ops for 34% of respondents. A 10% gap would be big enough to say something like “development probably owns the platform.”

Further, if we assumed “product” is part of development, we get 64% in development versus 34% in operations.

At the very least, you could say that ops is not the dominate buyer as only 35% of respondents said ops owns the platform.

This makes sense for en early developer-tools market. Developers are often the ones who bring in the new tools and they end up being accidental operations people. This happen[s|ed] with Kubernetes, with cloud, DevOps v1 automation tools, LAMP/rails, Java, etc., etc.

Eventually keeping the platform up-to-date, adding in new features, trouble-shooting (“carrying a pager”), dealing with security and compliance people starts to get tedious and boring for developers. As the chart above shows, the skills needed for running the platform are not application developer skills. App developers don’t want to own production. And if they do, they’re insane: they’re missing out on one of the primary life-style benefits of being a developer.

Operations will end up owning and running the all those accidental platforms, muttering “not fault, but now my problem” as they walk out of the hand-over meeting. This also means the budget shifts over to operations. That’s good, in a way, because operations typically has (1) a way bigger budget than app developers, and, (2) many more cost controls in place (you know, “FinOps”).

But, for now (and the next ~2 years?), it’s developers that drive most all of it.1

Selling platforms For marketing, this means targeting developers, for product this means making it quick, easy, and cheap-to-free to use. For enterprise sales it means “ugh.” Developers usually both believe (1) they can do it all themselves (they’re developers, building software is what they do!), and, (2) they have small budgets (most of their budget is spent on people, see previous item). Those are both not fun for enterprise sales people who want to do six to seven figure deals. You want to sell to operations: they have the money and they don’t like building stuff on their own, they like running it.

An “enlightened” executive buyer would get ahead of this and buy into a centralized platform early (this is the case with many Pivotal/Tanzu customers), but most of the market ends up as an archipelago of misfit platforms. Because ops doesn’t product manage it well (it’s not in their skill set or traditional culture), the platform’s features get old and stale (but, it’s rock-solid!). The app developers get disenchanted and bored with the platform that ops is running…and they start tinkering with and building their own. The cycle repeats itself! So, you know, try to make better mistakes next time.

---

😎 Get a Proven Enterprise Platform in PlaceHey - speaking of, are you interested in a platform? We have several pre-shaved yaks you should use.

The first is based on the open source Cloud Foundry platform and has been used to run all sorts of enterprise apps by many enterprises for something like the past decade: the Tanzu Application Service (previously Pivotal Cloud Foundry, PCF). The second is a toolkit of components to build a platform on-top of Kubernetes, if you need that kind of thing: the Tanzu Application Platform. Both will run where-ever you like, public cloud, private cloud, etc.

If you want to get the bigger vision, check out the recording of this Tanzu overview I hosted:

I think it’s pretty ridiculous to build your own platform, but: I get it, my work sells those platforms, so I must be biased… ¯\_(ツ)_/¯

---

🪵 LogoffNo links or waste book today. But, here’s a quick idea to make solo roleplaying D&D even more fun.

1This could be bad analysis on part, though. If “most organizations have had a platform team for at least three years,” with 35% at 6 or more years, the whole platform thing might be fully baked and done at this point. It doesn’t feel like that, though - platform engineering still seems new, barely at the chasm, maybe just over it? Perhaps I should get out more.