Just wastebook and links this episode.

Wastebook

• If you’re a writing type suffering from imposter’s syndrome, spend some time as an editor. You’ll soon discover that writing is incredibly hard, so if you can pull it off, you’re the real deal.

• “Preview The Magnitude Of Our 2024 Agenda” - subject line of a Forrester email.

• Alex: “So you want training data for my replacement?” Son: “Well, at least until they unfreeze your brain.” Here.

• “‘Culture’ is a kind of catch-all in social affairs that can be deployed to explain almost everything everywhere, and so it usually explains nothing at all. If the advice your theory yields is “change the culture”, then you have no meaningful advice.” Here.

• “A Man Was Ordered to Build a Fence to Hide His Boat. He Asked an Artist to Paint the Boat on the Fence” Here.

• “business websites with personality” Here.

• “While developer led motions are awesome, all roads eventually lead to steak 🥩 dinnahs and hard-core enterprise sales to pay the bills!” Here.

• “Then he gets up from the table and shrimp fall out of his pockets and he walks out of the boardroom trailing shrimp everywhere, this is what corporate finance is all about.” $11m on shrimp.

• “the classic difficult-childhood-because-his-parents-made-it-too-easy” Here.

• ‘Yet again, I kinda sort of understand what he’s saying, but I have no idea what any of that means in concrete reality beyond, “we will collect lots of data on inhabitants, and make adjustments based on patterns.” And again, I’m not sure you need a cyberpunk city to do that.’ Here, from 21,000 words on Saudi Arabia.

• “Who the fuck wanted to spend 44 billion dollars on a toilet?” Burn Book.

• We need more life advice books by people who don’t have time to write one.

• “manufactured serendipity” Here.

• "Be an active bystander."

Relative to your interests

• What Factors Explain the Nature of Software - “The only way to know exactly what software we want to build is to fully specify it: without doing so, there will be gaps between our vague ideas and harsh reality. However, a complete, abstract specification is, in general, at least as much work as creating the software itself – in many cases, it is substantially more work.”

• Vercel Momentum - “Vercel was started in November of 2015 so it has taken over 9 years to cross $100M ARR - one has to be patient in dev tools and it doesn’t always work out!!! Harness started in 2017 so it too took 7 years to cross $100M ARR, but it also had a more focused model to sell to larger enterprises as a devops infra provider from the very beginning.”

• BP AI use for developer productivity - “A passing mention in BP’s latest quarter: 'Due to GenAI and in-house built developer productivity tools, we have increased the output of our software developers by around 70% year-over-year” and cut external developers by 60%.'"

• The Forgotten War on Beepers - Back when pagers were ruining the youth.

• Enterprises struggle to show the value of AI projects - “’Organizations who are struggling to derive business value from AI can learn from mature AI organizations,' Leinar Ramos, senior director analyst at Gartner, said in a statement. But it’s a small group: only 9% of respondents in Gartner’s survey are characterized as AI-mature.”

• Gartner Forecasts Worldwide Public Cloud End-User Spending to Surpass $675 Billion in 2024 - Cloud: lots of money.

• Crocodilia: How Crocs became a clog-selling profit machine - I need a pair!

• As clicks dry up for news sites, could Apple News be a lifeline? - Wow! // “the Beast on track to make between $3–4 million in revenue this year from Apple News alone — more than its own standalone subscription program, and without much additional cost.”

• The #1 Platform Engineering Problem You’ve Never Heard Of: Platform Decay (Webinar Recap) - Avoiding the accidental platform and platform sprawl. Gartner Identifies the Top Five Strategic Technology Trends in Software Engineering for 2024 - (1) Software Engineering Intelligence, (2) AI-Augmented Development, (3) Green Software Engineering, (4) Platform Engineering, (5) Cloud Development Environments. “Gartner predicts that by 2026, 80% of large software engineering organizations will establish platform engineering teams, up from 45% in 2022.” // What’s weird about this prediction is the question: “uh so what have the PaaS, DevOps, and SRE people been doing this whole time?”

• Using AI to generate web forms from PDFs - With Enterprise AI, the app is still the hard part: “What took longer was the other stuff: identifying the problem, designing and building the UI, setting up the templating, routes and data architecture. It reminded me that, in order to capitalise on the potential of AI technologies, we need to really invest in the other stuff too, especially data infrastructure.” And: “What really slows transformation is bureaucracy. It’s getting permission to use a tool like this, and to make improvements to the underlying service.”

• Internet use statistically associated with higher wellbeing, finds new global Oxford study - “The study analysed data from two million individuals aged 15 to 99 in 168 countries, including Latin America, Asia, and Africa and found internet access and use was consistently associated with positive wellbeing.” // At this point, who knows? Like everything else in life, it’s probably how you use it that matters.

• Why We Hate Working for Big Companies - Capitalism knows the central planning committee is bad, so, logically, Capitalism runs on corporations that are central planning committees.

• Everyone hates Workday - “Workday reveals what’s important to the people who run Fortune 500 companies: easily and conveniently distributing busy work across large workforces. This is done with the arbitrary and perfunctory performance of work tasks (like excessive reviews) and with the throttling of momentum by making finance and HR tasks difficult. If your expenses and reimbursements are difficult to file, that’s OK, because the people above you don’t actually care if you get reimbursed. If it takes applicants 128% longer to apply, the people who implemented Workday don’t really care. Throttling applicants is perhaps not intentional, but it’s good for the company.” // This gets close to something, but doesn’t have enough empathy (understanding?) of executive life to sound right. More like: the purpose of a large organization is to perpetuate itself as is. It only changes if there is a crisis or a huge improvement to be had (10x? 20x?). Workday is good enough: all the effort you would put into fixing it would just result in the same general outcomes. You would take on the risk of it failing, and get little improvement of things went well.

Conferences, Events, etc.

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

Atlanta Executive Dinner on Enterprise Software Dev, etc., May 22nd. SpringOne Tour London, June 5th. 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. SREDay London (Sep 19th to 20th) when you 20% off with the code SRE20DAY. And, if you register for SpringOne/VMware Explore before June 11th, you’ll get $400 off.

Logoff

I’m in Atlanta this week for two events (see the dinner one above). I’m in a Residence Inn this week - which has a kitchen (no oven, though). Usually I’d go to Whole Foods to eat from the hot bar for at least one meal, but this morning it wasn’t open yet. I realized I could just buy some eggs and salsa, and an avocado. I always buy avocados in the States: they are not good in Europe. I also realized I could buy a steak! (Hard to get American style steaks in Europe). Amazing!

//

I had a long conversation today about a gap in the enterprise software journalism and analysis world. There doesn’t seem to be enough reporting there - the focus is on crushing iPads more, AI now-a-days, sure. The problem with the space is, how do you make money publishing about it? A lot of companies end up getting sponsored by vendors, which is totally fine.

//

I also recorded an interview with JT Perry about Enterprise AI in healthcare. It was great! It should be out later this week.

//

On the way over here, some Americans complained about how hot it is. First, in Schiphol, then in the Atlanta airport SkyTram. What they meant was the AC wasn’t cool enough. Long ago, when I was traveling for RedMonk with James, he and the other Europeans would always complain about how cold it was in American conference rooms. They seemed insane. Who wouldn’t want cold AC? But now, living five years in Europe, I get it. I didn’t even feel like it was warm. And when I walked into my hotel room, it was freezing! I turned it up from 60 degrees to 70, and that seemed right. I still like cold AC, regardless of tempature. The crispness is impossible to get otherwise.

//

That Gartner prediction about platform engineering above (“Gartner predicts that by 2026, 80% of large software engineering organizations will establish platform engineering teams, up from 45% in 2022.”) has really “chipped my chops” as one of my friends like to say. There’s something weird with the current conversation around platform engineering. I get all the newsletters on the topic, read all the stuff. As I mentioned above, what have we been doing this whole time with “platforms”? Did they not exist?

Here, we have Paula and Colin talking about platform as a product in 2019. The book Team Topologies was out in 2019. A year before that, 2018, you had the Bottcher/Thoughtworks definition of platform. Cloud Foundry was released around 2011, and was at the beginning of its stride in 2015. There’s Heroku, of course, the late 2000s. And then DevOps, SRE, and centralized tools groups of Netflix and Google fame spread through-out there. I guess that’s five years since 2019. Of course, those ideas were germinating for 2 or three years ahead of that (just proposing a book, getting a book accepted, writing a book, and then waiting for it to come out probably took a couple years, 18 months at least?).

It seems weird. Lots of people don’t even automate their build. One surveys says that only 35% of respondents apps are are using DevOps for management. So maybe it is actually something new? Rather, maybe actually doing it is something new.

I look at these years of conversation about the platform topic and I get a little queasy: are we just going to keep talking about this over and over, giving it new names here and there? Are enterprises giving themselves the chance to see their “transformations” through to fruition? It feels like introducing a platform into a large organization, in a big way, takes three years, maybe even five.

I’m not sure: but there’s a good conference talk in there! Maybe I can work it out for my upcoming “Developer Productivity Is Waste” talk (NDC Oslo and then DevOpsDays Amsterdam). The premise would be something like “developer productivity is a symptom, a signal of actual problems. It’s just how you measure something, not an ends to itself.” I mean, I guess that’s the problem with any metric: when you think improving it is the point. The point is actually “why aren’t we doing better, and how would we fix it.”

In the case of all this platform stuff, based on how “new” platform engineering is, and the other surveys I’ve looked at recently (low CI/CD usage, low DevOps usage), the answer seems like: because you’re not doing much to improve it.

Really up-lifting stuff!

Just links and waste book today.

Wastebook

• “If it ain’t broke, don’t cloud it,” me, 2011.

• Follow and mute.

• “Dell’s employees, whom I believe are mostly adults and not small children, will be given colour-coded ratings to shame those who don’t come into the office enough.” Justin Warren’s newsletter, “The Crux #93.”

• “Largest companies most likely to deploy via YAML” - slide title from cloud native platform survey.

• “A Lot of Spain Looks Like Arizona… Except for the Parts of Spain that Look Like Massachusetts.” Here.

• And: “Not only is there a €1 coin, but a €2 coin too, in addition to 1, 2, 5, 10, 20, and 50 cent coins. So if you pay for a €2.65 bottle of wine with a €10 euro note, you had better prepare yourself for the hail of loose change coming your way.” Ibid.

• Her job was a “velvet coffin.” Here.

• At the splash-pad in the park. There was a couple here that had a rice cooker with them. I imagined this conversation as they were finally getting out the door: "The rice is done, give me a few minutes to put it in a container.” “No! It’s go time, the kids finally have their shoes on and are not upset that the color blue exists. Just grab it and let’s get the fuck out of here!”

• “The sale was merely the exclamation mark at the end of the sentence.” Here.

Relevant to your interests

• I asked my co-worker Whitney what “Kubernetes security” means, and she sent me this presentation of hers. It’s fantastic! Exactly! At some point, it becomes a crazy board of stuff. There’s no way an application developer, or even an ops person should have to keep up with all of that. Things get super-bonkers if you’re building your own, custom platform. At some point, you assemble all the components from the CNCF hot-pot bar, and you’ve got a unique platform that you now own security wise. GOOD LUCK!

• Aligning with User Needs with Rod Johnson - “Spring Source ended up not monetizing Spring at all — but rather worked on monetizing with products that were complementary to Spring. ‘We monetized Spring by not monetizing Spring, by using it to open the door.’” // Great interview if you’re into the whole open source business model thing.

• AWS CISO: In AI gold rush, folks forget application security - “the places where we’re seeing the security gaps first are actually at the application layer”

• The Presentation Mistake You Don’t Know You’re Making - “If your very expensive luxury hotel rooms offer ocean views, silk sheets, and a Jacuzzi, don’t mention the ironing board in the closet or the coffeepot.” // Seems a little too turns out… // This replication study show that it sort of works. Furthermore that if you include an expensive item for free on the bundle, people see the bundle as good. // I generally think this kind of BOGO stuff is a scam and pricing tricks. So when I see it, I get suspicious that I’m being tricked.

• Notes on Spain - “Not only is there a €1 coin, but a €2 coin too, in addition to 1, 2, 5, 10, 20, and 50 cent coins. So if you pay for a €2.65 bottle of wine with a €10 euro note, you had better prepare yourself for the hail of loose change coming your way.”

• Dan Vega - Spring Developer Advocate, YouTuber and Lifelong Learner - Dan and DaShaun are great devrel people, and they’ve built a great corner of the Spring community, in just a year!

• Boomi Dismembers TIBCO Through Acquisitions - “TIBCO’s mistake was cobbling together a bunch of unrelated products and not investing in a cohesive user experience. I’ve called it the ‘TIBCO Frankenstein’ to my clients. TIBCO needed to build a unified user experience across its integration products. But with the sale of Mashery, it appears that ship has sailed.”

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. SREDay London (Sep 19th to 20th) when you 20% off with the code SRE20DAY. And, if you register for SpringOne/VMware Explore before June 11th, you’ll get $400 off.

🪵 Logoff

I wrote up a preview of our new State of Cloud Native Platforms survey today, probably published on The New Stack. We used to call it the State of Kubernetes Survey, which I’ve covered each year.

Anyhow, I’ll stick a link here when it my weblog post comes out.

Today it’s just a links and wastebook clean out.

Two Recent Garbage Chairs on Amsterdam

I’ve found a few Garbage Chairs of Amsterdam recently. Truth be told, I stopped looking. When I moved here, the locals were bemused about all my photos “I never really thought about that,” they’d say, “but; yeah, there are a lot of garbage chairs!” I’ve got to get that sense of wonder back.

(I seem to have deleted wherever I kept the archive of all these. I should set one up again. In the meantime, here are some video commentaries on some Garbage Chairs of Amsterdam.)

From Google Gemini on the above (who knows if it’s true?):

The image you sent me is titled “CAFÉ HAVELAAR” and it was created by Dutch artist Anton Pieck (1895-1987). It is a pen and ink drawing of a man standing outside of a cafe. The man in the image is likely a customer or employee of the cafe.

Pieck is known for his illustrations of fantasy worlds and fairy tales. His work was also inspired by the Art Deco movement and Expressionism. This particular drawing is a realistic depiction of a scene from everyday life.

The CAFÉ HAVELAAR drawing is not one of Pieck’s most famous works, but it is a good example of his skill as a draftsman. The drawing is detailed and atmospheric, and it captures the feeling of a quiet moment on a city street.

I like the phrasing of “not one of his most famous works.”

That feels comforting, like:

“What did you do today?” the man in the well fitting suit standing at the end of my desk asks.

“Oh, you know,” I say raising my eyebrows, smiling lazily, standing as I wipe my hands on my pants, “just finished up not one of my famous works.”

“Ah, very good,” the well-fitted suit man says, “shall we go get a beer?”

wfh, artist edition

From “About my studio”…

(1) No commute saves time and means booting up into work is faster and frequent:

there is also an advantage to not having a separate studio outside your home. When I did rent a studio in the past it meant that all my artwork in progress was elsewhere, and that required overcoming inertia to make myself go to my studio. When the artwork is right next to me then it’s simple to do a few minutes extra work on it – correcting a mistake or enhancing a part of the image – without needing to trek to the studio.

(2) You think about work more frequently, a good version of living rent free in your mind…work lives rent free in your house? But, it’s your work, living in your head, not The Man’s work.

And having my work-in-progress continuously visible out of the corner of my eye while I’m decompressing from my day job – streaming a film, reading a book, browsing the web – means that I unconsciously reflect on it during my downtime, allowing flashes of lateral insight to spark in my head while I’m actually concentrating on something else.

These more apply to solitary synchronized, creative endeavors. When it comes to synchronized collaborative management (“meetings”), maybe not so much?

Relevant to your interests

• Au petit Cordon Bleu - Fun, 1930’s cookbook.

• The Ultimate Guide to building Developer Tool Websites - PLG for developers. Get them home pages set-up for the funnel!

• Automation and the Jevons paradox - Always good to bring in Jevon’s Paradox.

• UHF in UHD: Weird Al’s cult classic movie will get its first 4K release - “Nothing says ‘I love you’ like a spatula.'” // this movie, and the VHS of Pee Wee Herman’s stage show are probably the basis of my humor. Many summers watching stand-up and Doctor Katz on the Comedy Channel came later, but were probably equally defining. And, of course, the Phil Hartman era of SNL, and the occasional Letterman when I stayed up that late.

Wastebook

• “Just realized French Onion Soup without enough broth is a soggy onion sandwich.” Galaxy brain level shit from Matt Ray.

• “It’s really a celebration of personal freedom and surplus wealth.” Here.

• And: “huffing the fumes of Timothy Leery’s corpse, or whatever.” Ibid.

• “Yeah, in France they don’t have refillable drinks but you can buy cigarettes instead of fries.” Here.

• “The result often reveals the unconscious clichés of the users.” Here.

• “Coffee badging” Here.

• “What I didn’t know about Battersea is that the lower-level floors are a mall, with Apple’s offices taking up the higher floors.” Here. // This is something I really like about London: all these hidden away nooks and crannies, sometimes whole malls! You can see how Neil Gaiman could have come up the “London Below.”

• “slop” - spam/AI generated copy and images.

• Sometimes you’re at a trade show after party, and someone with a camera and fancy mics is like, “hey, want to record a little interview?” You want to say yes, because what the fuck else are you doing at that after party? Here is an example of two masters at work, delivering the perfect pitch for that moment (clear explanation of the problem solved, clear explanation of the product/solution, check out the 2 unnamed customer references, the one named reference, name-check the VC investment, giving a tiny briefing on the state of the company [which only an analyst would care about, but which is important to drive thought leadership, buzz, and story], a notice very little filler words and stammering, mention of TAM, etc., etc.), relaxed, keeping the answers short, pedigree of the CEO (themselves). Also, the interviewer, Dave, is good too: look at all those takes and survey numbers he can weave in there. All in 9 minutes and 26 seconds. (I’ve known Aaron for a long time, so I may be a bit biased.

• The past is only in the present if you think about it. #DadTalk!

• Another day, another Euro.

• Can you imagine there being an answer that would be helpful? If not, don’t bother to ask the question. The question you’re thinking of is probably more of a statement.

• “disadvantation” Context.

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 five star reviews our of five reviews, including these accolades:

That’s right. Watch em!

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. And, if you register for SpringOne/VMware Explore before June 11th, you’ll get $400 off.

🪵 Logoff

There’s more school holiday the rest of this week, if you can believe it. I have to tell you: these Europeans might be on to something.

When it comes to cloud native application platforms, we’re at an important evolutionary point: will the best practice for platform strategies be to build or to buy? Should you choose the components you need for a platform and integrate them together, or should you buy a pre-integrated platform? Unless you’re a handful of organizations, the practical answer is that you should buy the platform.

Before I get to why, what even is a “cloud native platform”?

Defining a cloud native platform

The Platforms Working Group at the Cloud Native Computing Foundation (CNCF) has a great paper defining “platform.” They’ve got a real swell burger-diagram, above. Trying their best to boil down 13 pages into one paragraph, the authors summarize a platform as:

Platforms curate and present foundational capabilities, frameworks, and experiences to facilitate and accelerate the work of internal customers such as application developers, data scientists, and information workers… A platform for cloud-native computing is an integrated collection of capabilities defined and presented according to the needs of the platform’s users. It is a cross-cutting layer that ensures a consistent experience for acquiring and integrating typical capabilities and services for a broad set of applications and use cases. A good platform provides consistent user experiences for using and managing its capabilities and services, such as Web portals, project templates, and self-service APIs.

Platforms support the software you’ve built to run your business. A platform not only runs that software, but it manages the services your apps need. Typically, the platform also specifies how your apps are packaged, configured, and deployed to your platform. The platform usually has opinions about your app’s architecture. For example, a cloud native platform really wants your apps to follow the 12-factor best practices and use a microservices architecture. You know: containers.

Avoid accidental platforms

Platforms are the interface between your application developers and the cloud infrastructure and services their apps use. To me, that’s the key thing that makes it a platform instead of just a pile of clouds or catalogs full of “services” that developers have to find, learn, and integrate into their applications.

All apps need a platform to run. Developers will create that platform if one doesn’t exist. This leads to the spread of “accidental platforms” across the organization. All of these platforms need to be managed and cared for, and since they’re all different, staff spend a lot of time managing each platform.

In a large organization with thousands of developers and applications, teams don’t get the benefits of scale when they have a bunch of different platforms. This creates a huge amount of drag on IT: an IT manager, for example, and his staff could end up spending between 70% and 80% of their time on maintenance just keeping all the platforms running, with little time left over to improve those platforms or add new functionality developers need.

The main issue here is that it drags down the actual business because an organization’s apps are increasingly how the business functions, and even what the business is to customers. Think about how people interact with businesses, government agencies, schools, and even their hobbies and entertainment. Most of that is done through an app, through software as the primary, if not mission critical, component and “storefront.” And it’s not only that, software is how businesses get better, grow, and innovate.

Is Kubernetes a platform?

Over the past few years, there’s been a lot of confusion about where the line between a platform and infrastructure is, mostly driven by everyone’s interest in Kubernetes. Kubernetes is more focused on standardizing how infrastructure is used and managed, and how apps are configured and run.

That standardization is the goal of Kubernetes: wrapping an industry-standard API around all the different cloud infrastructures. It’s removing variability, which is always good in large IT shops. But, as said long ago, Kubernetes is a platform for building platforms. You use it to standardize your infrastructure across clouds, across on-premises, and even “edge,” so that you can then build your application-focused platform. On its own, Kubernetes just delivers a blinking cursor: an empty cloud that’s ready to be filled with useful services and apps.

But if you stop there, things go poorly. Many organizations are much too quick to hand over that blinking cursor to developer teams who have to first understand how Kubernetes works, and then, second, build the platform they need on top of Kubernetes. The result is a backslide into a mess of accidental platforms.

So, is Kubernetes a platform? Not the kind we’re talking about here, a platform for application developers. It’s the foundation for a platform. You still need to add the services, interfaces, and tools that application developers use. There are also all the usual operations, security, and compliance services you need.1

Pitfalls to building a platform

This is all to say that if you’re building a platform, you have a lot of work to do. You need to select each of the components, integrate them together, keep them updated, and improve them as you learn what works and doesn’t. In short, you now “own” a full product, including supporting it. And you need to run it and manage it. Ongoing, as new capabilities come along you’ll need to add those into your platform, for example, AI, new versions of programming languages and UI frameworks, databases, and so forth.

This is a lot of work. There used to be a quip that “all companies are software companies now.” which always seemed weird to me. No matter how good at software my favorite fried chicken restaurant is, if I order some Korean fried chicken, I want to find some fried chicken and fried cauliflower in the box, not software. But, once you start building your own platform, then you are a software company with the responsibility to build and maintain a software product. That requires a lot of corporate resources like time, money, and attention.

Whether your business is fast food, insurance, manufacturing cars, collecting taxes, or whatever else, you’d probably rather spend time being good at your business than good at platform building.

Benefits of buying a platform

For most organizations, a platform contributes very little to a business’ differentiation. You need a platform, but like electricity, email, ERP systems, and even analytics, the platform itself isn’t what makes a difference. What makes a difference is what you do with the platform and how you use the platform. The more time you spend building and maintaining your own, homegrown platform, the less time you spend focused on your actual differentiation, including your applications.

So, unless your customers buy from you because of your unique platform, you should probably buy your platform instead of building it. This frees up your resources to focus on your actual competitive advantages. '

Things like: how do they get that cauliflower so crispy and keep it so crispy as it cools off on the bike trip to my house?

You’ll also benefit from the platform being an actual, evolving product. For example, at the Tanzu, we build a platform, and we spend all of our time adding new features, improving it, and integrating it with as many types of infrastructure and services as possible.

The feature-set isn’t static like so many homemade platforms in large organizations end up being. You can see this with the AI services we’re adding to the Tanzu Platform – that’s become a priority for many organizations, so we’ve been adding it to our platform. The comprehensive integration with the Spring Framework is another example. If you have enterprise applications, you likely have many Java applications, and if you have Java applications, you’re very likely using a lot of Spring. If you use the Tanzu Platform, you can update your Spring apps quickly and easily, benefiting not only from new features in Spring and Java but also getting the performance and cost savings improvements.

What that means is that you have more time to focus on what actually matters: your own software and applications. That’s enough work, and hard enough, without having to worry about how you configure and deploy software, manage security, handle data, and otherwise do all that stuff below your apps.

To the question of whether it’s ultimately better to build or buy: buying a platform means you can focus all of your effort and resources on making your business better by perfecting how you make your software.

If you’re interested in how a platform fits into improving how your organization builds and runs software, check out the discussion below I had on that topic with Purnima Padmanabhan and James Watters. We of course talk about the VMware Tanzu platform, but you’ll also hear how large organizations are thinking through this build/buy decision.

This was originally published on CIO.com as a VMware Tanzu sponsored post (“BrandPost” they calls it). But, don’t worry, I did actually write it, all by myselves! Well, I mean, with some suggestions and copyediting from my work-pals, sure. I made some slight changes in the above.

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. And, if you register for SpringOne/VMware Explore before June 11th, you’ll get $400 off.

🪵 Logoff

That’s it for today. I’ll save up the fun links and strange things from the World Wide Web for tomorrow.

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.