Today’s survey: “State of the Developer Experience 2024,” Harness/Wakefield Research.

Most enterprises need to automate their build and deployment pipelines. This is more than just building code and automating tests (which 71% of people are not doing), but also automating governance and security checks (which 41% of developers are not doing).

In my mind, this is the number one thing development organizations should be working on in 2024, and probably next year. Any ambitions to migrate to cloud, put Kubernetes in place, help software eat the world, etc. are going to go poorly if you don’t have an automated build.

Just automating your build will have large, positive benefits and ROI. Automating your build will give you a massive boost in productivity, meeting deadlines, meeting compliance and securing your apps, and raising employee morale.

A cynical(?) take on this is to say that the real magic of any “platform” or “cloud native” technology is that it requires you to automate your build pipeline1 and that automating the build pipeline is where the majority of improvements come from. Whether you’re running your apps on VMs, Kubernetes, Cloud Foundry, a shell-script platform, or a bunch of raspberry pies duct-taped together, as long as the build pipeline is automated, you’re going to improve.

Let’s look at a recent developer experience survey that gives us more numbers to pile on that fire, the Harness “State of the Developer Experience 2024” survey.

Slow onboarding, slow releases, slow governance & security

• There’s very little demographics-wise, just that it was “500 engineering leaders and practitioners.” It was done with Wakefield Research.

• Developer onboarding time is a major focus, see below for longer discussion.

• “62% of executive buyers would prefer a platform versus siloed tools.” // I assume this means a centralized/standardized platform versus a bunch of platforms in silos, and then just tools that are not even integrated into a platform.

• “60% of organizations are still releasing code on a monthly or quarterly basis.” // In the 2024 CD Foundation survey, 40% of respondents said “less frequently than a month,” 31% said “once per a week to once per month.” Let’s take 10% from that 31% as “once a month,” and throw it together with that 40%, to get a delicious kapsalon of 50%. So, while the CD Foundation doesn’t capture “a month or more,” in the realm of sponsored surveys, the numbers are similar enough to be in the same ballpark.

• “67% of developers have attested to waiting over a week to complete code reviews.” And: “59% say that their AppSec requirements limit their ability to release code frequently.” // These isn’t the best proxy for bad bureaucracy, but they’re probably representative of governance bottlenecks. Now, if you got sloppy with code and security reviews, and something went bad in production, you’d probably be all for bottlenecking. And, in fact, that probably happened several times and it’s why you have those code review and security bottlenecks.

• But: “40% of developers admitted that their organizations don’t enforce good security and governance policies across the lifecycle.” // Optimistic case: that’s because they need to automate and standardize how security is done, which is now done manually, driving 59% of developers to say that security requirements slow down their release frequency. And, indeed: “41% of developers don’t have automated security and governance policies”…I assume that means “in place.”2

• These code and security review bottleneck figures are a good pairing with paired programming which has an implicit code review built in, more or less.

• Human stuff: “52% of developers cited burnout as a reason their developer peers leave their job.” And: “As evidence, 45% of developers surveyed say they don’t have enough time for learning and development. And executives seem to agree.”

• Global developer population estimate: “developers, estimated at around 30 million globally.” // This number is a lot harder to pin down than you’d think, so it’s always nice to see someone take a go.

Onboarding

“It would take a new developer 100 days to onboard, considering the multitude of tools involved.” Meanwhile, the executive perception is that it’s 40% faster: “71% of of executive buyers said that onboarding new developers takes at least 2 months [60 days].” It’s always fun to find differing perceptions between management and workers. Most of the mismatches are like this, with the management thinking things are better.

Solving this onboarding problem was the reason Spotify made Backstage, I think. That’s lingered in the platform engineering community ever since, though I see it a lot less now-a-days.

Relative to other problems, I’m not sure enterprises care that much about developer onboarding. It’s sort of a one time problem per developer. In tech companies, there’s high churn for developers, so you want to onboard people quickly to replace developers who’ve left, but also scale-up your efforts by hiring new developers as you write new code to add new features to grow revenue (or, eyeballs - whatever) and to get into new markets with new apps.

But I suspect that in not-tech enterprises, the churn is less. And, post-ZIRP/whatever, with the miasma of industry layoffs still lingering, I’d wager most buyers are less concerned with that. “What? Are they going to be able to find a new job? Back into the coal mines!”

STILL! It’s still a good tracer for software hygiene. One thing that’s overlooked in onboarding bottlenecks is the effect slow onboarding has on maintenance and bug fixing. When you go to fix a bug in production, you have to set aside the yet-to-be-released version of the app you’re working on, and go back and setup the old version of the code.

This means, basically, onboarding to the project again (OK, not all of it, but probably the majority of it), which is time consuming. So much so that many developers will keep those old versions all pre-installed and ready to debug and patch sitting around somewhere.

The business case for the elusive platform buyer

Marketing wise, they’re doing the “show ROI by increasing developer productivity” thing. This is a fine sales tool. Some clever sales engineer will create a spreadsheet of it, and you’re off to the races! Give it to an inside sales rep, and you’ve got some great email threads goin'. There’s always the dream of doing a self-service workflow where people fill this out themselves, see some cool bouncing charts, and then get asked if they want to talk with an ISR. (Does that actually ever work, though?)

That sells the idea of the problem you’re solving. What you have to marry that kind of ROI model with is showing that cheaper-to-free alternatives (“the developers say they can get Backstage up and running on their own…”) will not get you the same result. In that way, an ROI pitch like this is great for introducing a new idea and market category (here, platforms/IDPs) because you’re just trying to convince people that it’s a problem they have with a known solution.

You can also see who these ROI pitches appeal to because they’re using a base of 1,000 developers in the calculations. That’s a pretty big company, which is fine. They’re the ones you want to sell centralized developer tools to. A larger company has bigger budgets and it’s a lot cheaper to sell to one group than a bunch of dev teams.

Nowadays, finding the platform customer that also has budget is tough. The VP of AppDev has little budget, but they have the need. And, of course, they have tons of app developers who are like “oh, I could do that in a weekend.” The VP of Infrastructure has tons of budget, but they don’t care about apps (usually by design and comp)…and the app people don’t want them to care. You can go to Line of Business people (“The Business”), but that’s not easy either, pretty much impossible.

That misalignment is one of the reasons there’s so much platform sprawl, and why you need to do this kind of ROI’ing. You’re trying to go against the very structure of the IT organization. You know, change the “culture.”

Selling a centralized platform is tough!3

Work smarter but keep working harder

Here, let me find my Marx hat to put on.

ROI is a way of showing buyers that your software is worth paying for. It makes your developers work faster, and therefore they can hit deadlines better, software eats the world, number go up, BUSINESS, BUSINESS, BUSINESS!

Abd then, you can have the workers do more work for the same pay! More work with the same. Buy low, sell high.

This is why “productivity” can be a let-down for workers. Better productivity should mean that you can go home early, work less. But, nope: you keep working.

A worker might be motivated to increase productivity to prevent (1) overtime (in the survey 23% of developers said they work overtime at least 10 days a month), and/or, (2) boredom and tedium.

These are great things for a worker to strive for! However, management has to make sure to actually keep those benefits in place. As you get more productive, management tends to want to do more and tackle on more complex things. The Share Price isn’t content with flat, reliable EBITA.

If the workers suddenly have free time, get them to do more work! Eventually, you’re back to working more overtime and introducing back in the tedium. “Now we need to figure out how to leverage AI! Oh, and what’s your sandwich order for tonight?”

Progress! The cycle continues.

For workers, the productivity metrics to track are (1) going home on time (2) eventually, going home early, (3) reducing bullshit work that could be automated or just eliminated entirely (“toil”), (4) more pay and benefits.

We should make a Backstage plugin for those.

Definitions

Finally, the survey has some good, concise definitions of common terms:

• Toil: “Developer toil can be characterized by repetitive, manual, and low- value tasks that consume significant time and effort.”

• Goals of DevOps: “The overarching goal of DevOps is to foster collaboration, automation, and a continuous delivery pipeline that enables organizations to rapidly and reliably release high-quality software products and services.”

Reader letters

Jay Cuthrell sends the following re: yesterday’s ketchup taboos talk:

Two spouts - way to increase productivty, eh?

Check out his newsletter, if you like this one, you’ll probably like that one.

Relative to your interests

• Before Platform Engineering Killed DevOps, SRE Killed DevOps.

• That time when Microsoft bought and killed Nokia phone unit - Good write-up of (probably mostly) forgotten time. // “Barely two years after it was announced, the whole thing fell apart and Microsoft wrote the whole thing off as a tax loss.” And: “Elop was right, but his solution wasn’t.” // “Disruption” is an easy word to say, but a very difficult one to solve. // And a D&D reference! “The Nokia board rolled the dice again on hiring another non-Suomi manager, Rajeev Suri, and this time hit a double D20 in D&D terms.” (Though, I’ve never heard of a “double d20,” but, sure, probably.)

• If you didn’t find it in the links above, this documentary on waste and burnout in corporate work is great. You’t thinking “that’s an hour, WTF?” But, really, just watch it, it’s good.

Wastebook

• "A certain amount of uncertainty." Here.

• “Today, a fathom equals six feet–quite an inconvenient number to use in your head, when trying to go back and forth between feet and fathoms.” // For some of us, all numbers are “quite and in convent number to use in your head.” Here.

• “refusenik” bruces.

• “pluralistic ignorance.” Yup.

• And: “I really felt that part when the lawyer said she wanted to get hit by a car just so that she wouldn’t go to work. Feel that most days, if not all.” Comment on Ibid.

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Atlanta Executive Dinner on Enterprise Software Dev, etc., May 22nd. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th. SpringOne/VMware Explore US, August 26–29, 2024. SREday London 2024, September 19th to 20th.

Discounts. Cloud Foundry Day (May 15th): 20% off with the code CFNA24VMW20. SREDay London (Sep 19th to 20th) when you 20% off with the code SRE20DAY.

🪵 Logoff

I saw an early summary of a platform survey we just did. It has some good figures in there. I’m interested in sharing the platform sprawl related ones.

Business models are fascinating. Most business models come down to a type of arbitrage, at least as I understand it. You find something you have that you can sell to someone else, crucially, at a price above what it cost you to make that thing.1 In, let’s call it, The Capatalist Upbrining, there is a major intellectual jump where you understand that the price for a think is not determined by what it cost to make it, the costs of goods sold. No, no - not at all. How much it cost to make a thing has little to do with what price the thing sells for. And there’s the arbitrage: a business model is all about making the difference between the cost of goods sold and the price paid for goods as big, large, and mysterious as possible. Buy low, sell high.

It is because I am so familiar with the business of software that I think of it as The Beautiful Game of business. There is only one product more ephemeral as software, and that’s selling identity, life-style, existential, I don’t know, “affirmation”: Coke, Nike, Patagonia. The margins on selling identity are extremely high and durable over decades. But, software is up there.

Anyhow, this is why connoisseurs of software strategy are annoyingly obsessed with open source startups and business models. It’s like my imagination of studying particle physics: you just load up some stuff into a big torus, wham that stuff together at high-speed to make them explore real good, and look at sparks and charts that follow.

Anyhow, that’s the subject of this week’s Software Defined Talk episode. The theory I put further is that open source is a commoditize your condiments business model. Which is to say, it’s ketchup. You can’t have a business that just giving away ketchup.

You would never eat ketchup on its own: this is widely considered disgusting. Put in your mind the image of someone walking up to a ketchup pump, bending down, putting their open mouth under the spigot, and giving one, swift pump.

Buuuuut: if you put ketchup on something, it is considered delicious. American French fries are not very good on their own: you pay for them as an excuse to eat ketchup.

An open source business without the fries performs poorly.2

There is no free-as-in-catsup in Europe

When it comes to the business of condiments, the Europeans are the clever ones. Usually it’s the Americans who are clever at the business of software, pardon, I mean, of condiments. First, the Europeans eat mayonnaise not catsup. I think they view catsup as something like children’s food, but I’ve never really asked.3 Back to my point: the Europeans never made mayonnaise free. You pay for mayonnaise and catsup. You pay an insulting amount: something 50, sometimes even 80 cents. It is insulting because it is such a small amount.4 Well, insulting to Americans.

In America, pricing obfuscation is politeness. A business should not reveal that it uses “loss leaders” as a net to pull in fish; a business should never let you look behind the curtains and see that they’re selling sugar(free) water at a massive mark-up. The ketchup you get from pumps and packets at an American restaurant isn’t free, the price is included in everything else.

But in Europe, no.

They make you know the price everything you’re buying. Europeans are very open, clear, straight forward, explicit. Transparent.5 They want you to know exactly what is happening, exactly the truth. Everything is catalogued, everything is logged. Do you want catsup with your burger, then, here, I am putting that on the receipt, what you paid for it. Are you behaving in a strange way? Then, here, I am going to tell you. Surely you must know this, and if you don’t surely you will be delighted that I am telling you

Americans have a phrase, “not my circus, not my monkey.” The European equivalent would be something like “our monkey, our circus.”6

Hmmm. I seem to have doorway’ed myself here.

So.

Anyhow! Check out this week’s episode, The Big Blue Burger Buffet.

📼 Lead Time to Schwag

The first thing that’s funny about this talk is that the people who posted it didn’t realize I completely changed the talk. They posted it with the original title. I mean, obviously they weren’t going to watch it, but it’s such a strange editorial non-decision decision.

The second funny thing is, you know, my actual talk. How do you apply developer productivity metrics philosophy (you know, “developer productivity”) to getting free shit at a conference? Also, who doesn’t like a good ITILv3 joke? I didn’t watch it until the end, but who does that in YouTube?

🪵 Logoff

Back to work tomorrow!

On that random person in Nebraska

1. Open source is important for the entire industry, sell side (especially in the cloud era) and buy side. Things would go very bad if it did not exist as method of software production and innovation. (Source: see the QED from that one xkcd.)

2. Open source is a bad business model, it’s very difficult to grow and it conflicts with the VC need for a big pay off. (Sources: The pro-business license changes at open source companies in recent years [too many to cite]; many more; most recently well put by Brian Gracely in his Cloud Sunday Sermon.)

3. VC funding of open source companies is not a great area for returns (versus other opportunities). VCs should fund closed source (at best, open core) software (and cloud) companies. (Source: while Aneel never says this in words, in the room, it felt like he was saying it with sighs.)

4. Open source is only sustainable when part of a big company that makes money because open source if a commodified compliment of their closed source/cloud product. (Source: Kubernetes; us in this week’s Software Defined Talk episode.)

5. Open source is a generational (young boomers and Gen-X) variance that got its last gasp from ZIRP. With cloud and SaaS, there’s little reason to do open source as a business, plus, see #2 above. I like this observation because it shows the bias my generation has to open source as a good business model (and, thus, many of the major thought-leaders, just by age and aggregation of attention over the years, e.g, still being alive). (Sources: Red Hat was always held as the proof of this view, but even they are no longer independent; The Oxide podcast episode on FUD; Pete Cheslock’s DevOps hangover talk.)

6. Open source is a great business model. (Source[s]: I’m looking for some references; awaiting the sogrady missive).

These are collected from my fellow grumpy old tech men RSS feeds. I need to gather views from other RSS feeds too. I reckon there’s probably some good stuff from the recent Open Source Summit.

Sustainability

What comes out in many of the views above, and what I conclude, is that our focus should no longer be on open source business models, but on open source sustainability models.

“Sustainability” means that you can rely on the software existing, being supported (at least patching bugs and, especially, security problems), and preferably evolved and innovated.

Also, I suspect that a kind of unspoken part of sustainability is “free,” but that gets the goat of many of my generation of open source people. In my experience, when you talk with the buy side, they want “free, as in don’t give me a lecture.”

Open Source Foundations: More Important Than Ever

No matter which view(s) is useful (accuracy is always cool, too), I think it shows the importance of open source foundations. They’re even more important now because they (more or less) are not at the whims of either VCsPE needing a 100x cash-out and mucking with the business models once founders [lose|give up] control and slow growth, nor PE companies doing their [MUCH_LESS]x synergizing and optimizing.

The foundations need to be there as long-term stewards, protectors, and community/marketing management for the products. For example, when that xkcd situation happens, the foundations should be hiring that random person in Nebraska: tracking them as an important, strategic asset for the overall ecosystem that needs to be supported, if not by a mega-company, then by the foundation. I don’t know, you could, like, ask The AI to go look at GitHub and LinkedIn to figure that out, right?

The foundations should also be a common ground and (I can’t think of the positive version of this) bureaucracy1 for maintaining the governance in the community. You know: using transparency to enable potential shame to prevent shenanigans.2

Relative to your interests

• Is there a business model in “hey guys” videos for enterprise IT buyers? I replied with some two-coffees-in thinking.

• Supercharged Developer Portals - Spotify Engineering : Spotify Engineering - Spotify is really going for the enterprise product thing! Most importantly, check out the legacy of the Drunk & Retired podcast with The Frontside mention.

• Generated images for non-generated text and video - ‘It’s only a matter of time until “generative art = spammy bullshit” will be the majority position because that’s how the economics of it are playing out. Using extruded synthetic art will not do your writing or video any favours in the long run.’ // I mean, yes, and…the idea is that in the future, the AI generated images will be so good that you won’t be able to tell. But, that is just an ideas.

• A Letter from Paul Auster - When the rejection is more comforting than the confirmation.

• Volo’s Culinary Guide to Icewind Dale - We talk a lot about the downside of the Internet, the web, whatever. But the existence of this as a widely available thing is an example of why the Internet is great. I mean: when would this ever exist otherwise except as some obscure zine on a magazine rack at rundown university coffee shop?

• Java 17 is now the favorite brew of developers, along with - “About a tenth (9 percent) of applications were using Java 17 in production in 2023, and now 35 percent of applications are using Java 17, representing a nearly 300 percent growth rate in one year. It took years for Java 11 to reach anywhere near that level.” And: “While Oracle retained the top spot in 2022 (34 percent), it slipped to 29 percent in 2023, and it’s now at 21 percent – which represents a 28 percent decrease in one year.” // Sure, but what matters more is: is Oracle making more money off Java or less?

• Related: The Java migration imperative: Why your business should upgrade now.

• AWS hits $100 billion revenue run rate, expands margins - (Covered more extensively in this week’s Software Defined Talk.) “The CEO also noted that 85 percent of current IT spend is for on-prem tech. So AWS has plenty of room for growth even as it approaches $100 billion annual revenue.” (1) we’re out of the first inning of cloud, and now into the second inning, the “15% inning of cloud.” (2) selling investors on TAM is dicey. What you’re saying is that the buyers are going to be spending the same (inflation adjusted, I guess), so there will be no price discounts. Counter-argument to (2): the spend will be the same, but buyers will do more/get more: “more with the same.” But, their overall IT budget will remain. I guess that’s macroeconomic “productivity”?

• Generational Shift - When I was growing up, we watched cartoons from our grandparents, parents, and ours times. We had Groucho Marx references in Bugs Bunny. We watched Scooby Doo and Power Rangers. AND WE LOVED IT. I don’t know of if this is good or bad, it just is. It reminds me of what you see on Europe: kids and old people both know the beer garden drinking songs.

Wastebook

• “Someone who knows English never would have thought of that name!” Here.

• And: “Ivy is not a momentary trend that you follow, but a tradition to be honored, passed down from your fathers and grandfathers. It’s not just clothing but a way of life.” Ibid.

• “Welcome to the dematerialization age.” Here (Notice the .do URL - Struts!).

• I know I’m all like “welcome the party” status on this, but Adam Savage! He’s got something special and interesting going on. How does someone end up like that? (Also, notice that he rarely uses filler words like “uh” or “like.” Instead, I think, he pauses to think…and the editors [is it him?] leave the dead air in! Revolutionary!)

• Related: If most people are not experts, most people don’t know how an expert will do something and will be interested. Furthermore, experts are generally older and know “everything.” They are interested in learning more esoteric, unique things. The market for experts is very small compared to the market for everyone else. Therefore, for a broadcast medium like YouTube, you probably want to appeal to beginners who are learning, intermediate level people less, and experts the least. (This likely creates a un-virtuous cycle: in a medium like YouTube, there is less content for experts, so experts start thinking “I don’t ever find anything useful there,” so they stop looking there…at least for things in their area of expertise.)

• The point is not to get there quickly, it’s to get home late.

• “The shape of the conflict with no details.” Matt Ray.

• There should be a version of D&D where the “lite” monsters are removed, and it’s just the big ones. E.g., no more Spectator, just Beholders.

🪵 Logoff

Still on stay-cation; which is to say, I’m sure I have typos and copy-regerts in the above, apologies.

See you next week.

Kubernetes is popular. If you’re in my business, you know that it’s widely considered to be how enterprises run and will their applications. So, it must be a huge market right? Lots of money flowing around.

Well…not really! Let’s look at some numbers:

1. "The container management market has seen accelerated growth of 28.6% over the past year with a market value of $1.6 billion in 2022. The market is forecast to exceed $3.6 billion in constant currency by 2027, with an 18% CAGR." // Includes both private and public cloud. (2023 Gartner Container Management MQ)

2. $1.46bn in 2023, growing to $2.85bn in 2028. (451 Research)

3. $5.56bn in 2027. (IDC)

What this means is that there “isn’t any money” in the Kubernetes market. Imagine having to share that pie with the three public cloud vendors, IBM/RedHat, VMware (hi!), SUSE/Rancher, and all the others. Those are small pie-slices.

Or, those forecasts could be weird! With TAMs, knowing the market-definition is incredibly important. The Gartner one has a pretty good overview of the market definition.

But, the size of the market just tells you that there’s not a business in it. Which, I think, is the point. Google didn’t want there to be a business, they wanted AWS to have less of a business and less of a hold on public cloud: shake the snow globe. It worked! And, people are really into Kubernetes, so it’s like win/win for vendors and users. Kubernetes is probably the current, best example of using open source to commoditize complements - as a strategy to mess with your competitors’(s) competitive advantages and change the market to your favor.

There is probably tons of money in all of the stuff built around Kubernetes. After all, the core is pretty small and designed (I think?) to need all that extra stuff. When people talk about Kubernetes, they’re usually talking about building a platform - a “cloud” even! - around a core, but small engine for running apps in containers.

Which is to say, assessing Kubernetes based on its market size (how much people are buying) is the wrong question. First, it’s better to track how much it’s used, how many apps/workloads are running in Kubernetes. Second, the money number you want to track is the spend on that bigger platform.

What’s different about that number than, say, in the 2000s or even 2010’s is that public cloud vendors are part of that TAM. This makes things weird to track. In the old days, you would track license sales for platforms. But now, what you pay for a platform includes actually running that platform: servers, networking, storage. You can slice out just what you pay for any layer…but that feels weird to me.

(And, to apply some Adam-kindness Wisdom: don’t get distracted by money talk, look at all they’ve done to change and improve things, that community is doing a great job.)

Platforms

Speaking of platforms, here’s a sort of virtual EBC about my work. If you care about the above, here’s our take at Tanzu:

Relative to your interests

• IBM Is Buying HashiCorp. What Comes Next? - Good analysis of the possible business strategy, the synergies to activate. // “Customers in specific industries, often highly regulated and conservative in outlook, have often chosen IBM and continue to do so. For them, the value of cloud is complementary at the margins, not a wholesale change to the core. They are pragmatic, serious guardians of the established order, not revolutionaries hell-bent on destroying and replacing the Ancien Régime.”

• OK Cloud, On-Prem is Alright - A case for private cloud, or, if you prefer the “a nicely automated VM or container environment” view: on-premises. I’d summarize it to: there isn’t enough ROI to motivate everyone to change, even spend the time to decide to change.

Wastebook

• “He is surely the friendliest little goblin you have ever met.” Caught In A Wizard’s Web.

• “exploring the latent space of visual styles” Midjourney release notes.

• “I used to get frustrated by people who I saw as uncurious.” Lauren Pope

• “Well, I had all kinds of plans for this morning, and then one of the chickens died in their sleep” 26apr24

• “Sorry, I was ranting and I forgot what the original question was.” A. Savage.

Have you had a chance to check out my series of videos full of my advice for working in a large company? WHAT?! If you have access to O’Reilly’s stuff, you can watch these. If you work at a large company, there’s a good chance you have access. Anyhow, check them out. There’s four four star reviews, including these accolades:

That’s right. Watch em!

🪵 Logoff

I’m supposed to be on vacation, so I hot-wired this one to send out automatically in the future. Well, what is now my future, but is - I mean - to you, in your now…ahem…what is now your now! And, then, actually, I unscheduled it so I could write more on Monday. Which future am I in now?

Container, DevOps, and Generative AI for Testing Usage

My work sponsored an IDC paper going over ways to use generative AI (and ML) at various stages of software development (the “Application Development and Product Life-Cycle Management”). There’s some interesting ideas in there, you should check them out.

As always, I like to collect the numbers from surveys and estimates. There’s some good ones in there! Here they are:

• “26% of organizations are using GenAI to support application development, testing, and management and 25% are utilizing machine learning with the greatest focus on leveraging AI to support DevOps analytics and process, governance, and security testing”

• “32% of application portfolios are built on containers and microservices today and, in five years [2028?], enterprises estimate that 39% of their portfolios will be built on containers and microservices” // I’m always after how many apps/workloads are running in Kubernetes. This is a new one! IDC’s numbers here don’t tell you which are running in production versus just in dev/test, but, whatever. Also, it’s “containers and microservices,” not just containers. // These are different estimates than a recent Gartner one: “By 2027, 25% of all enterprise applications will run in containers, an increase from fewer than 10% in 2021.”1 But, given that IDC’s is containers and microservices, maybe if you throw out microservices that are not running in containers, the IDC and Gartner numbers would be closer. I think the beers after work estimate, then, is something like: I don’t know, I’d guess companies are running something like 10% to 20% of their apps in Kubernetes? 20% seems, high - I mean, I just read the other day that 71% of developers don’t automate their builds and testing, right? So, who knows what’s going in enterprises. Anyway…want another beer?”

• “[E]nterprises are using DevOps methodologies to manage roughly 35% of their application portfolio today, with the anticipation of using DevOps to manage more than 47% of their portfolios in five years” // This seems like a better estimate than the headline one in the CD Foundation survey I looked at yesterday, which was (I don’t know the surveying name for this) synthetic conclusion based on the tools and practices people use, not the saying “we do the DevOps.” // Also, they’ll be spreading to 10% more of there portfolio over five years, to just under 50% of their portfolio under management. Change takes a long time! If we put the invention of DevOps as “[a]round 2007 and 2008,” we’re 16 to 17 years into DevOps and creeping towards 40% adoption. Probably fine, actually. It also shows you why we’re still talking about DevOps all these years later, and why there’s big windows for DevOps remixes like platform engineering.

• “[O]rganizations estimate that nearly 40% of their testing activities are automated, with ambitions to make almost 50% of testing activities automated in three years.” Now, this one feels bonkers. Who doesn’t automate their tests? Who doesn’t see the value in automating their tests? Well, could be that the someone in their team (or their org.) is automating tests and not the person answering “no” to this question. In my CD Foundation survey overview yesterday, I didn’t highlight the practices people said they used. “Test automation/management” use in the last 12 months was at 22%! So…I guess we’re to conclude that universal test automation is not universal. Bit of a WTF? there.

Above from “Applying Artificial Intelligence to Strengthen Application Development and Product Life-Cycle Management,” Pete Marston, IDC, November 2023.

If you enjoyed the above, check out my newsletter for more analysis like that, and plenty of other goofy things.

Relative to your interests

• Spring Now Offers Free Access for the Spring Academy Pro Content - Free Spring training for all: “The Spring team has announced that the Pro Content from their Spring Academy will no longer require a paid subscription, effective April 5th 2024, to improve the learning experience for the Spring community. The Spring Academy will continue to provide new content in the future.”

• A Shift in LLM Marketing : The Rise of the B2B Model - Enterprise AI requirements are different than consumer AI requirements: “For a data-focused customer base, SQL generation, code completion for Python, & following instructions matter more than encyclopedic knowledge of Napoleon’s doomed march to Moscow.”

• IBM to acquire Hashi for $6.4 billion, seeks software boost - Enterprise AI businesses case are difficult: “But he also said buyers’ initial enthusiasm for generative AI has eased as they ponder whether it can generate return on investment. Users are finding that applying generative AI to a single business process could cost as much as $300 million, a figure Krishna said is unlikely to produce positive ROI.”

• Inside TSMC’s Phoenix, Arizona expansion struggles - Sounds like a shitty place to work! Long hours, sometimes filled with low value work. The TSMC people must think Europeans are insane. In contrast, for the American work-culture, this feels like a “thank the unions” story.

• The Chilling of TikTok - “the bigger concern will simply be the distraction of it all. Product decisions will take longer. Timelines will slip. Executives will be absent. Employees will leave.” // Yeah, never good for a tech company to feel under attack. They’re just not used to it.

Wastebook

• “The characters shouldn’t be able to end the entire endless night by killing a big bird.” Sly.

• “The Coddling of the American Parent.” Here.

• “You don’t need to raise a cow to have the milk. You just have to make sure that the milk can be delivered to your doorstep.” Prof. Hsu.

• “In LLMs as in humans, context is that which is scarce.” Here.

• Kubernetes Kopacetic.

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Atlanta Executive Dinner, May 22nd. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th. SpringOne, August 26–29, 2024.

This year, I won’t be at Cloud Foundry Day (May 15th in NYC), but if you’re going you can get 20% off with the code CFNA24VMW20.

🪵 Logoff

I’m starting to think I could put together a whole presentation based on these surveys. I wouldn’t want it to be negative, maybe something more like “hey, slow down, in the real world, everything is fine.” I need to come up with a talk to pitch for DevOpsDays Ghent - maybe that’d be good! A sort of “DevOps isn’t dead, it’s just super-chill”…?

The CD Foundation Survey, 2024

Today’s survey: “State of CI/CD Report 2024: The Evolution of Software Delivery Performance,” CD Foundation and SlashData, April, 2024.

Are people getting better at frequently releasing software and fixing problems in production? The most recent CD Foundation survey says…no:

• On average, 29% of respondents say they release software once a week or even more frequently; 40% take a more than month. The numbers here have been pretty stable over the past 4 years. This suggests that (a) improvement has stalled, and/or, (b) this is the normal baseline.

• 59% of respondents can fix production in a week or less, 40% in a day or less. This has gotten worse over the past 4 years. In 2020, 65% of respondents could fix production in a week or less.

Looking at the past 4 years of these surveys I also get the sense that we haven’t progressed very far with two of the goals of DevOps: more frequent app releases and fixing problems in production faster. This matches older surveys that show a very slow increase in release frequency, so slow that it might as well have stopped changing.

Does every organization need to release software frequently (weekly to daily)? Probably not, but in general what this survey tells us is not great. Does this means DevOps is a failure? Not at all: if you think these release cycles are long, you should have seen them in the 2000s and the 2010s!

My quick, hunch-made (read: “unscientific”) conclusion is that these numbers are “the new normal.” That means if asked how often enterprises release their apps, I’d say something like “about 50% of release their apps once a month or even daily (maybe 13% to 15% do daily or less?), and the other 50% take longer than a month, I’d guess most of those are quarterly.”

How frequently do most organizations really need to deploy, especially if you don’t count at-will bug and security fixes and patches? Does my pharmacy need to add new features every day, every week? My bank? The maintenance scheduling app my power company uses to send out trucks? Probably not. Maybe deploying once a month or more is actually perfect for most enterprises. What you’d like to see are survey questions that ask “and are you happy with this?” or “what are you plans, if any, to speed these up?” You’d want to divide these up by individual contributor and management/executives. I’d suspect the first would be like “meh,” and the second would like “fuck yeah!”1

To summarize: “You’re improving only getting slightly worse. Let’s put it like that.”

Deployment to production frequency

• The main question for app release frequency is: “On average, how often do you or your team deploy code to production?”

• In 2020Q3, 35% were at a month or more. In 2024Q1, it went up to 40% (this is bad, the wrong direction).

• The other time periods are mostly stable, but multiple deploys a day went from 12% to 9% over that time range.

• You glass half-full this and read it as: 60% of people release their software once a month or even more frequently. That reads pretty good, actually!

• If you want to get real detailed, you could pay close attention to the “you or your team” part of the question. This is different than “your entire organizations’ average across all apps.” For my purposes, the difference doesn’t matter.

How long does it take to fix problems in production?

• Fixing problems in production is measured her by time to restore service (MTTR)

• “The proportion of developers who can restore service in less than an hour has remained at around 11% since Q3 2022, though down from 17% in Q3 2020.

• However, the proportion of the worst-performing developers – more than one week to restore service – has been steadily increasing and is now the condition for 41% of developers.”

• Same point about “you and your team” versus “your entire org” as above.

Build automation and testing are not the norm

I use deployment frequency as the quickest/best metrics for measuring how we’re doing with getting better at software. Like I said above, you may not need to deploy at will. But if you’re doing all The Best Practices and DevOps Things, you should be able to deploy at least once a day if not more.

Can you deploy daily with manual deployments? Sure, we’ve all scp’ed files to production. Is that good? No. It is very not good. You want to automate your deployments, you know: Continuous Deployment. In an enterprise, like a big bank or pharmaceutical company, this is especially important because it’s the only way you’re going to reliably speed up the audit, compliance, and security bottlenecks.

Before CD, though, you need to automate your build and testing, you know: Continuous Integration.2

This has been known and recommended for a long time, 35+ years if I did the math right:

Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI [circa 1989] and did advocate integrating more than once per day – perhaps as many as tens of times per day. Wikipedia.

I’d add that Thought Works championed this, as did many other people, and it became a one of the foundational principles of DevOps.

So. How are CI and CD usage doing? NOT GOOD.

Let’s look at people who agreed with the statement “I test my applications for security vulnerabilities” across the last four years of the survey:3

Above you can see people who answered yes/agree to the statement In 2024Q1, 71% of people said they do not “use continuous integration to automatically build and test my code changes.”

One of the people who I asked to look over this pointed out that the wording of the question is for individuals (“I use continuous integration” instead of “My team uses continuous integration”). It could be that individuals on a team don’t use CI, but that their team does. This also points out another survey nuance: you have to be careful about questions that ask “does your organization…” versus “does your app/team…” For example, for the first you could ask “does your organization use Generative AI?” And if there’s just one person in a 300,000 person company using it, the answer could be yes. That “yes,” of course, is much different than if 40,000 people are using AI, or if the top 3 products in that company rely on AI. And, indeed, dear readers, you’ll know that I am always interested in how many applications/workloads are, for example, running on Kubernetes, not how many organizations are using Kubernetes.

For more on CI and CD usage, let’s look at a different survey that goes back further, the State of Agile survey.4 They stopped asking about tools usage in 2022, but we have surveys that go back to 2007:

These numbers are (much) better, but there’s a problem with the results from both surveys: improvement is flat. Things haven’t gotten better or worse in a ~10% band.

So much ROI in your future

So, something like 47% to 71% of people don’t do CI. I’m not sure what to do with that. I hesitate to even think it’s real.

¯\_(ツ)_/¯

But, let’s say this analysis is right.

What it means is that:

1. Need something to boost your annual bonus? If you don’t have CI in place, it should be easy for enterprises to get better at software by simply automating builds and testing. If you don’t have CI in place (never mind CD!), set aside everything else you’re doing and put CI in place. Anything new you’re doing in apps (cloud native, DevOps, Kubernetes, etc.) is going to fail (or at least fail to achieve ROI) if you don’t have CI.

2. If you can get people to pay for CI/CD, you’ve got a market goin’! Selling these tools is difficult because you’re selling to a group that thinks they can do it on their own and have small budgets - you’ve got to go in with a freemium/cheap option and at some point, you add in RBAC, and you can sell big, company wide deals.

Other Details

• This report is done by Slashdata. They have huge data sets and do many of the reports for the CNCF. If you dig around on their site you can find PDFs of their general survey, Developer Nation.

• Demographics aren’t covered very well. I can’t tell what percentage is tech companies versus “normal,” company size, or the split between management and staff in respondents. But:

• “We survey 30,000+ developers annually.” And: “The report is based on a

  large-scale, online developer survey designed, produced, and carried out by

  SlashData over a period of ten weeks between November 2023 and February 2024… from 136.”

• Everyone is doing the DevOps: “As of Q1 2024, 83% of developers are involved in DevOps-related activities.” // There’s some variation by industry and org. size, but it doesn’t really matter. People think of themselves as doing DevOps, and many of the practices are likely practices. DevOps Thought Leading wins!

• BUT! If you look at how they determine this, they ask what DevOps practices people follow. There are 9 practices, some of which are just general programming practices, e.g., using CI, automating testing. This is different than asking “do you do the DevOps”? I don’t really like this method, so I wouldn't draw any conclusion about how many people are “doing the DevOps.” Maybe how many people are using DevOps practices if narrowed down from those nine.

• It’s probably better to use fewer (if not just one) CI/CD tools than more: “using multiple managed CI/CD platforms has minimal impact on improving deployment frequency, but is much more likely to lead to an increase in low performance.” More: “One possible reason for this may be that lead time for code changes is impacted not just by platform usage, but also by their CI and development processes. Multiple managed CI/CD platforms may introduce fragmentation of the CI process, leading to greater negative impacts. Similarly, development practices like code review, collaboration, and testing may be impacted by having to adapt to multiple platforms throughout the workflow, and this challenge has a larger impact on lead-time performance.” I’m all for centralizing and standardizing tools/platforms/stack, so, sure, I like that one.

• I think the PDF is saying that if you use hosted (public cloud) CI/CD tools, things are better.

• There’s an attempt (which I’m really interested in) to see if running your tool stack on public cloud versus on your own is better. The answer is that doing both (“multi-cloud”!) is the best. I don’t think this tells us enough.

//

If you liked this survey review, check out the two recent ones on platform engineering (the Perforce Puppet one and the one from Port, also, a bunch of other ones from over the years).

🪵 Logoff

I’ll put some links and waste book stuff into the next episode. In the meantime:

• Yesterday, I had the wrong link for the “Things I Like” post I mentioned: here is the correct link.

• On this week’s Software Defined Talk, I interview Jana Werner about some digital transformation cards she and her AWS friends have been using when they work with executives. It’ll post this Friday (April 26th at 7am Amsterdam time. It’s good stuff! You can find it in our YouTube channel or by subscribing to the podcast.

• Here’s my case for buying you cloud native platform instead of building it. I’ll probably regurgitate this in a future newsletter as well.

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.

Below are my notes one of the many, recent surveys.

The Port survey

Source: “2024 State of Internal Developer Portals,” Port, survey conducted October, 2023, published Dec 2023.

Major Take-Aways: The Internal Developer Portal (IDP) definition isn’t widely known yet, with only 54% of respondents following the survey’s definition. Backstage is the most commonly used stack, at 25%, followed by other commercial portals. The primary goal of IDPs is to increase developer productivity, reducing deployment time is a distant second. Respondents do a lot of DIY work and reporting for developer metrics.

Further Details:

1. Demographics. N: 100 full-time employees from the US and Western Europe with 150 or more developers. Geographies: 50% of respondents were from the US, and the remaining 50% from Western EuropeIndustries: 30% were from “tech,” 21% from insurance (!), 11% manufacturing, and then spread out below that. Company size: 89% of respondents were from companies of 500 or fewer developers.

2. The answers are from a management point of view: 99% of respondents were “management” or “executives.”

3. The survey was done in October, 2023. In a brand new category like developer portals, that’s a long elapsed time between then and now.

4. The definition of developer portal isn’t widely known yet: “only 53% use what we define as a portal, while 35% use spreadsheets with microservice data and 12% use a self-service platform that isn’t a portal (e.g. CI)”

5. People use developer portals to improve developer productivity, mostly (?) by removing waste and toil. In contrast, only 25% of respondents used “reduced time to deployment” as a measure of IDP success.

6. After that, there’s interest in making “ops” related stuff better: “easing DevOps fatigue,” security, compliance, and making Kubernetes easier.

7. What portals do people use? Backstage is the most common at 25%, and other commercial options at 17%.

Developer Metrics

When it comes to measuring that developer productivity, most people are DIY’ing it with surveys or custom reports: “Surveys (43%) and custom reports (31%) are the most common ways of measuring productivity, signifying a focus on either self-reported productivity or custom measures of productivity instead of frameworks such as the DevEx framework (15%), DORA metrics (5%) and SPACE (5%).”

The mix here is a little odd: DORA metrics and SPACE are actual metrics, not tools or techniques for gathering metrics. You could be measuring them in your surveys and custom reports.

Nonetheless, you can probably conclude from this that selling metrics software/services/solutions to enterprises is tough. Once DIY stacks are in place in development and ops, unseating them is difficult. They’re often “good enough,” can be customized, and cost zero.1

It continues to baffle me that anyone thinks DIY stacks are a good idea. It is a terrible idea for most organizations.

//

Also, see my notes on the 2024 Puppet platform engineering survey.

My Work: Tanzu, Tanzu, Tanzu!

This month we’ve been doing a “what’s up with Tanzu” media-blitz. You maybe recall this excellent overview I was involved in. Here are some other recent article and videos:

• "VMware’s Spring AI with Ryan Morgan and Mark Pollack," Software Engineer Daily, Lee Atchison.

• “The Evolution of Tanzu Post-Broadcom Acquisition: A look at VMware’s refined focus, ” SiliconANGLE, Victor Dabrinze.

• “Driving Software Agility with VMware Tanzu,” theCube, John Furrier.

• “Why Broadcom is Investing in VMware Tanzu,” SDxCentral, Emma Chervek.

• “Platform-Centric Cloud-Native Apps with Broadcom’s Purnima Padmanabhan,” TechStrongTV, Mike Vizard.

• “VMware says Tanzu is key to strategy after Broadcom acquisition,” SiliconANGLE, Paul Gillen.

• “VMware Tanzu Simplifies Accelerated App Delivery,” VMware News & Stories, Purnima Padmanabhan

Relative to your interests

• Most developers have adopted [D]ev[O]ps, survey says - I’ll have to look at this more, but: “29% of developers used continuous integration to automatically build and test.” This means that 71% of respondents are not automating their builds and tests. // “Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI [circa 1989] and did advocate integrating more than once per day – perhaps as many as tens of times per day.” // 35+ years later, here we are at 71%. WTF? Something is weird here, or just 🤦.

• Lessons after a half-billion GPT tokens - In nerd-space, the deflation of AI expectations has begun, finally, after a year or so of usage. This is good! We can finally just get to realistic work. Let’s get those insights on accounts receivable.

• Real-world gen AI use cases from industry leaders - Speaking of everyday enterprise AI uses…

• AI isn’t useless. But is it worth it? - “they do a poor job of much of what people try to do with them, they can’t do the things their creators claim they one day might, and many of the things they are well suited to do may not be altogether that beneficial.” // I’ve lost the links to all the Tweets-n-shit on this sentiment, but I’m more or less like this: most of the time I try house AI to create, it would have just been faster and easier to do it myself. AI is great of search and for learning (I spent an hour figuring out NPV and discount rateing as applied to non-economic thinking everyday life - ChatGPT was great at this!). AI is not good at creating…if you’re already an expert.

• Summaries of Airport Books - YES.

• The cloud is benefiting IT, but not business - “The central promise of cloud computing was to usher in a new era of agility, cost savings, and innovation for businesses. However, according to the McKinsey survey, only one-third of European companies actively monitor non-IT outcomes after migrating to the cloud, which suggests a less optimistic picture. Moreover, 71% of companies measured the impact of cloud adoption solely through the prism of IT operational improvements rather than core business benefits.” And: “Only 32% report new revenue generation despite having invested hundreds of millions of dollars in cloud computing.” N=“50 European cloud leaders.” // So, backward-looking FUD, sure <double hand-guns agreement>. But also: as opposed to what? Should we still be updating Windows NT servers with a binder full of CD-ROMs?

• Tech Time Capsule: Early 1990s Clip Art Captured an Era - Good stuff.

• Do software companies actually have good margins? - ’In other words, software development costs are COGS. Not literally; not according to the accountants. But in practice, if you can only sell SaaS software—and retain customers—by promising a steady stream of new releases, how are the expenses associated with developing those releases functionally any different than the money you spend on servers and support agents?’ // Counter-point: yeah, but their free cash flow is the best.

Wastebook

• “Management avoids firing people with paper trails.” Corporate Camouflage

• Domestic refactoring: re-arrange and clean the spice shelf. Move the pile of pills and bottles away from the bread. Stop buying so much bread. Use the wine fridge as the overflow fridge. Get rid of unused pans. Buy snacks you like. Save less leftovers: you’ll just throw away moldy goop weeks later.

• From the people who funded crypto, may I present: AI!

• Kids are less civil around their parents. They are different people w/r/t “don’t be crazy” around other people.

• Unless you’re working on the strategy, the planning, the ideation…don’t pay attention to the business sausage making. Just eat the sausage, or sell it.

• “is Santa effective?”

• One thing Noah Kalina a is doing is using his purposefully crafted awareness of being filmed as part of the “art.” He doesn’t always do it intentionally while filming, but he ends up using it as found footage in editing. This is especially, blatantly true in the ring-billed gulls on Seneca lake video.

• “If you have a barrel of water and this cantrip, you have a solution to most problems.” Here.

• “I wrote the first line in a loony bin in Massachusetts in August 2018. And the last line on Thompson Street in NYC last night.” Here.

• I did my annual thing of trying to use Obsidian. It feels so nice, but it is so much work…? Also, the syncing via iCloud is not good. I can’t get into the vibe. (See you never year!)

🪵 Logoff

I am thinking I should make a regular bit out of taking notes on surveys…?

Also, I made a list of things I like this morning. I found myself also typing up “things I no longer like,” which seems like a good follow-up.

Related: there’s not much, but I’m lazily figuring out how to use my weblog more.

Suggested Musical Outro.

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…

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 Place

Hey - 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… ¯\_(ツ)_/¯

🪵 Logoff

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

Lots of original content this week, starting with this prediction about “enterprise AI”:

I also made these since last episode:

• Another go-round at figuring out playing D&D with ChatGPT. It went pretty well! Here’s my retro/analysis of it, and here’s the actual play session with inline commentary.

• I was the guest co-host on this week’s Cloud Foundry Weekly where we discussed the new features in the Tanzu Application Service 6.0. We, of course, spent a lot of time on the generative AI beta stuff that’s included. We discuss other new features as well.

• Software Defined Talk #462 - Lifting Code - This week, we discuss Matt Asay accusing OpenTufu of "lifting code" and recap the Google Next '24. announcements. Plus, we share some thoughts on camera placement and offer listeners a chance to get free coffee beans. You can also watch the unedited video.

Relative to yours interests

• IT departments are blowing their cloud budgets - “Nearly three in four (72%) of the IT decision-makers polled reported that their company exceeded its set cloud budget in the most recent fiscal year. Among the areas experiencing an acceleration of cloud deployments are: applications/workloads in IT operations (54%); hybrid work (50%); software development platforms and tools (45%); and digital experiences (44%).” // vendor-sponsored // has ranking of causes.

• Kubernetes community capitalizes on open source and AI synergies - Among AI talk, 451’s Kubernetes TAM: $1.46bn in 2023, growing to $2.85bn in 2028.

• Substack Is Setting Writers Up For A Twitter-Style Implosion – Home With The Armadillo - Seems weird. // “New reporting from The Wrap details how Substack’s decision to implement a new “follow” feature — part of its transition from newsletter publishing platform to social media site — has tanked subscription growth for lots of newsletter writers.”

• A simple model of AI and social media - “It is better to just start by admitting that the feed is fun, and informative, for many teenagers and adults too.” // I grew up in the Satanic Panic era, clowns kidnapping kids in vans around every corner, video games scrambling kid’s heads, skulls and boobs in ice-cubes, and of course fear of hip-hop. People actually thought that, across the country, there were Satanic cults trying to convert your children to worshiping the devil, or worse. It was in the news. A lot. I mean, you know [shrugs]: the 80s. So when I see people worrying about popular culture ruining The Kids, I’m immediately suspicious. // Also, I am part of the first generation of heavy Internet users (Gen-X), so I know what the analog world was like: from nothing, to beepers and pay phones, to alpha numeric pagers, the WWW, flip phones, laptops replacing desktops as the norm, WiFi, and then finally smart phones). The analog world sucked in comparison. iPhone 3G forever!

AI Corner

• Next ‘24 - Google Cloud CEO on why an open AI platform with choice, one which allows you to differentiate, is essential - Enterprise AI as a feature.

• ‘This shit’s so expensive’: a note on generative models and software margins - “The fundamental problem with generative models is that they are 10x too expensive to work with the industry’s default business models and structure. Either these companies who are going all-in on 'AI”'need to fundamentally change everything about how they work – laying off a bunch of people won’t make ML compute 10x cheaper so they’d need to change the org to survive on razor-thin margins – or they need to discover some undefined magical way of lowering compute costs 10x. So far they’re opting for magic."

• Counter-point: Notes on how to use LLMs in your product. - “Even the most expensive LLMs are not that expensive for B2B usage. Even the cheapest LLM is not that cheap for Consumer usage – because pricing is driven by usage volume, this is a technology that’s very easy to justify for B2B businesses with smaller, paying usage. Conversely, it’s very challenging to figure out how you’re going to pay for significant LLM usage in a Consumer business without the risk of significantly shrinking your margin”

• The Art of Product Management in the Fog of AI - “before products launch, it’s critical to run the machine learning systems through a battery of tests to understand in the most likely use cases, how the LLM will respond.”

• Amazon Isn’t Killing Just Walk Out But Rather “Pushing Hard” On It - Hmm, hopefully we’ll see some nuanced corrections in all them news outlets…

From the VP of Cable’s Mood Board, then/now, 2005/2024

Wastebook

• “You can never have too many chickens.” This guy is amazing. Internet art at its finest.

• “Meanwhile, I’m headed to Milwaukee this weekend to play pinball and get drunk. Perhaps I should rethink my life choices.”

• “Keep it up.”

• Word watch, “pink slime”: “Pink slime sites mimic local news providers but are highly partisan and tend to bury their deep ties to dark money, lobbying groups, and special interests.”

• They’re like the Karens of Europe.

• Mutually assured mansplaining.

• “Nexit.” NL Politics.

• News from the AI v. Human front: “You spend a week writing the 70 page doc only have [to] it sent back to you in 10 minutes. God help us.”

• “Everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” Here.

Logoff

My old pal Andrew Shafer bought a burger place in Tucson:

I know! I bet they’re good burgers - too bad I don’t get ti Tuscon much.

I don't think we really know what "enterprise AI" is yet, what apps will be helpful. So you need to just mess around and see what works. Come on a dog walk with me in Amsterdam and I'll tell you more.

Check out the experimenting we're doing with private AI in the VMware Tanzu Platform.

Logoff

No links or anything today, just the video above which I liked making. Will people actually watch six minute and 12 second video? Boy. I’m guessing not that many people will watching it all the way through. Too bad for them.

Last week I found Noah Kalina’s new YouTube videos, and, quickly got obsessed with them. So, I farted around with a little “future Coté” in this video. It’s fun.