I listen to a lot of podcasts, and have for, I don’t know, over 20 years. I’ve made and make a lot of podcasts. You might call me both a podcast listening and podcast creating expert. In the classic sense: a critic. I should review podcasts more frequently!

If Books Could Kill - Worth the Resulting Shitting-On Vibes

A few times I year I try to eliminate all the bad vibes media from my life. You know what I’m talking about: there’s all sorts of things out there whose whole deal is to have a negative take. CringePub.

That’s what happened to If Books Could Kill after I listened to the initial episodes. The whole point of the podcast is to take down airport books. Their analysis of books like Freakonomics and Men Are From Mars, Women Are From Venus were pretty perfect. With a lot of these airport books (you know, super popular advice books and what can only be described as the “turn out,” Malcom Gladwell genre), you’re often left thinking two things (1) but now what I am I supposed to do differently, (2) I don't know, that all sounds a little too clever and kind of fishy?

Each episode delivers on that intuition perfectly. And the two hosts are meticulous in their research and structuring the take down. If you’re familiar Michael Hobbes’ years on You’re Wrong About, you’ll know exactly what to expect.

They actually read the book Well, often just one of them does. But this creates a good narrative tools:

1. The co-host who read the book has to give a good overview of it. The other one who didn’t read it acts as a sort of narrative straight man.

2. The co-host who did not read the book is a proxy for us, the audience who may not have read the book.

3. Hearing the real-time reaction and thinking that the co-host who did not read the book adds another dimension of analysis (and content).

Also, they do extra research to look up claims. For example, in the Atomic Habits one, they do a lot of double turns out’ing on the cutesy anecdotes and “studies” that are used to prove out the habits theories.

Finally, they’re good at spotting simple writing and structural nonsense. And, as they read more and more of these books, they’ve started to find the common tropes, structures, and, therefore, warning signs. In the Atomic Habits one, they come up with a grand theory of the structure for these turns out, airport books.

What makes them credible (in addition to reading the book and being able to summarize it, and the research) is that they point out the parts they agree with. And, in one of their first episodes, talking about Bobos in Paradise, they get really close to concluding something in the spirit of you’re not (completely) wrong, David Brooks, you’re just an asshole.

There’s also some great moments when they’re discussing the absurdly taken for granted things in some the premise of some books. For example, one one episode they shit-on The Game, a book about pick-up artist techniques. The whole premise of this book is that it’s hard for men to have casual sex with women. At one point in the discussion, Hobbes, who’s a gay man, says something like: wow, I never realized sex was such a fraught, stressful thing in the straight world. The implication being: this book only exists because those weird morals in the straight world.

But, like I said, it got to be too much negative vibes pouring into my overfilling, cracked bucket of a mind. At a certain point, especially when Hobbes is the straight-man (hah! pun!), they go overboard with just adding more and more shit-layering on the book. The shitting-on can make your brain-teeth start like too much frosting on a cake. And I was doing the spreading! So I stopped.

This week, Brandon reminded me of it, so I went back to it, listening to them do their shit-on show with Atomic Habits (hence all my references to it above). It suffered from the too much shit-frosting problem, but overall it was great.

If you read this newsletter, you’d probably like it!

(Sidenote: what is wrong with Wikipedia that the page for the podcast doesn’t seem to contain a link to the actual podcast? At least one that’s easy to find.)

Socialmedia, circa CY2023H2

My Content

Speaking of podcasts, this week Software Defined Talk is back to our usual format of the three of us going over tech stuff: This week we discuss RHEL licensing changes, check the vibe of DevOps and some thoughts on programing language. Plus, has ChatGPT already become boring? Listen in!

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 11th How Cloud Native Improves & Ensures Security, Governance, and Trust in Finance, online talk. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking

Logoff

It’s the weekend, so here is your suggested outro song to listen to as a cold beverage melts in your hand and you watch the golden hour horizon:

When a good teacher seems like cheating

All of the worrying about cheating with ChatGPT is hiding its biggest potential: being a teacher. As an “expert” (or, at least, well read) in digital transformation, DevOps, cloud native, blah blah, when I ask ChatGPT to do things for me, it’s mostly smell-free garbage, kindergarten stuff. But, when I ask it to tell me about something I don’t know about, it’s great.

For example, I’ve been reading Against Purity, which does the community thing of using a bunch of jargon without explaining it. One word was “syncretism,” which ChatCPT did a good job explaining it to me. What was especially magical about this little moment was that I used the text grabbing feature on my iPhone’s camera app to just copy and paste the text from an actual book into ChatGPT. Magic!

ChatGPT also great at simplifying dense text and ideas I don’t understand. It can be brutal in making a concept overly simplistic, removing all the artful phrasing that experts will use to describe something. Experts tend to either over explain an idea or over explain it.

When the CFO Says No

For example, I talk a lot about legacy software, and the need to modernize it. Here’s the slide I used to give a definition of it:

The longer definition is pretty good for people who are vaguely familiar with software. In focusing on the outcome (what it means), it doesn’t really tell you why legacy software causes these negative problems, nor wha to do about. But, someone knowledgable with software already knows why and what to do about it. Anne is just giving a good definition we can all agree on. Which is very important: just imagine if we all agreed on one defining characteristic/metric for “DevOps” or “platform engineering” (I’d suggest app deploy frequency) and we could move on with our lives.

The Michael Feathers one is an example of stripping away everything but the essence of a definition and make it into a tool. A developer who reads that will say “yes, I get it now. Legacy software is risky to change because you can’t verify that your changes don’t break things.” And then, those seven words also tell you what to do to escape the legacy trap: write tests.

And then my definition - the title of the slide - is just me being cute.

But to an outsider, I’d imagine these definitions aren’t very good. Here’s a definition from ChatGPT. I asked it to reduce a longer answer into a paragraph:

Legacy software refers to outdated or obsolete systems that are critical to an organization's operations but haven't been updated due to high costs or potential disruptions. Despite their antiquated nature, they are often maintained because they fulfill essential business functions. However, these systems pose increasing risks over time, such as system failure, security vulnerabilities, and integration issues, while their maintenance becomes more challenging due to the dwindling expertise in the old languages or hardware they use.

After a little bit of priming, I then asked ChatGPT to explain the Michael Feather’s definition to a CFO who is making decisions about budgets and doesn’t understand legacy software:

This definition highlights an important aspect of legacy software from a technical perspective. In modern software development, "unit tests" are like mini exams we give to bits of code to make sure they're doing their job correctly. If a piece of software doesn't have these tests, it means its functionality hasn't been assured in a systematic, automated way. This could be a risk as it makes the software more prone to undetected errors. So when we say "legacy code is code without unit tests," we're saying it's older software that hasn't been built with these modern safety nets, making it more challenging and risky to maintain or update. For a CFO, it means these systems could lead to unexpected costs and disruptions if they fail or need to be changed.

Coming at from another direction, you a developer could ask ChatGPT to explain things to CFO is an expert at! With a little bit of going back and forth, I had it come up with an explanation a CFO might give for putting off legacy modernization:

As the CFO, I see the value in upgrading our legacy software, but we must prioritize the most impactful investments to meet Wall Street's expectations this year.

Our existing vehicle fleet, which is progressively more expensive to maintain, is a point of concern for both us and financial analysts. Investing in an updated, efficient fleet reduces these costs, satisfies eco-conscious customers, and offers a more immediate return on investment.

Now, when I mention increased amortization, I'm referring to the process of spreading the cost of this fleet upgrade over the useful life of the vehicles. While this means we'll see an increase in our expenses in the short-term due to the costs associated with the new vehicles, this is far outweighed by the long-term benefits.

This immediate capital investment boosts our operational efficiency by reducing the ongoing expenditure related to fleet maintenance. Moreover, newer vehicles would lead to an uptick in customer satisfaction and usage, directly contributing to our net earnings.

These factors should collectively improve our stock value, addressing Wall Street's expectations for prudent management of our capital resources and strong earnings performance.

Regarding the software modernization, it remains an important long-term project. But given the higher and more immediate returns from updating our fleet, I recommend postponing major software upgrades to the next fiscal year. We'll continue necessary maintenance to keep our systems running smoothly and securely until we're ready to invest in a full upgrade. I hope this offers a clearer picture of our financial strategy for this year.

I bolded the most important thing that the developer might not be considering: yes, but my job is to increase the share price as a function of being a responsible steward of our investors money.

An expert in one field forgets they need to be taught in other fields

The CFO’s explanation is much longer than the corresponding legacy modernization pitch to the CFO. I tried shortening it (scroll down to the CFO part of the chat I’ve been doing here), but then I realized a fun point: my need to have it longer is because I’m not an expert on this stuff and I need that extra simplification and expanding it out. That’s the whole point I’m making here! If I tried to piece that together from wikipedia, Investopedia. reading some CFO Weekly trade publications, or even people commenting on a TwitterMastodonBlueskyThreads question…I don’t think I’d get as good an explanation.

(All y’all DevOps-heads out there can fancy this up by name checking the Dunning–Kruger effect. As a side note, if you look at the part of my chat session [towards the end] where I try to get ChatGPT to use all of this an example of Dunning-Kruger, you can see another fun teaching moment: an explanation that is totally unexpected [by me] due to different framing that I’ve been taught to have when it comes to Dunning-Kruger. That is, in the DevOps world, you often invoke behavioral economics and cool psychology tricks when you want to point out problems, be sarcastic, and otherwise be negative.)

Students are rarely good at being a student

Teachers are in short supply, and it’s impossible to search for answers like this, let alone ask for a new explanation, ask for clarification, etc. And yet, there’s so much worrying about ChatGPT ruining education. As with so many tools that can automate “the basics,” the initial freak-out reaction misses the benefits of doing away with bullshit work. When comes to education, there’s another benefit: scaling teaching, trying break the constraint of the supply of human teachers.

One of the most eye opening things I learned as a student was that to be a good student you have to learn how school works…how to do the actions of student-ing. There are deadlines for turning in work. You will be told what needs to be in your history paper (the KPIs/MBOs/OKRs!). You must write your citations in this one format. You need to show your work in math. You can read a 400 page novel easily if you just read a little bit of each day. You should be taking notes as you read that book, and in class…especially if the teacher has told you what needs to be in your essay at the end. When you take a test, go through any answer all the questions you know the answer to first and skip over the ones you don’t know; that is, don’t get blocked on question three out of ten, when you know the answers to questions 4 to ten.

I don’t think we exactly know how to integrate something like ChatGPT into that “student-ing.” I mean, it’s only been in the mainstream discussion for, let’s say, five months. There hasn’t been enough time to learn what works and doesn’t work.

Socrates famously thought writing was a terrible technology that was going to destroy society. Like so many things, he was being an arrogant dumb-ass. Never mind video games, I think calculators were going to destroy society, and people think that having a computer in your pocket and access to the Internet is going to destroy society. I’m pretty sure people thought type writers were going to destroy society, and for a couple centuries, printing a book always ran the risk of being burned at the stake.

Instead of worrying about students using ChatGPT to cheat, and, thus, destroy society, maybe we should all focus on how to use it as a new tool. That’s what the history of everyday technology would teach us.

You can now buy enterprise support for those millions of Spring apps that are running the world

We’ve soft launched a new business selling enterprise support for Spring. If you’re involved in software and IT in a large organization, I guarantee you you’ll be interested in this. If you know what Spring is, you know why: it probably runs huge chunks of your business.

If you work in IT, even if you have no idea what I’m talking about, you should be interested. Pretty much every large organization builds and runs Java app, as RedMonk shows every year. This means most of them use Spring. Spring is everywhere and runs a large portion of the world as we know it.

As with anything that helps run there world, as versions of Spring (and especially the wildly poplar Spring Boot) come and go, you’ll want to get bug and security patches, including for very old versions that aren’t exactly supported well for free by the open source community. Plus, you’d like someone to call when you have questions, and it’s always cool to have training and certifications.

Anyhow!

You can buy Spring support now, just on its own, very straight forward and easy. It also includes tcServer, Tomcat, OpenJDK support. Don’t hold me all of this: I haven’t, like, taken the training to know the official menu. I’m just going off the web page.

And, yeah, this is enterprise software so you can’t just put your credit card into gumroad or something: you have to contact us to talk with an enterprise sales rep. I mean, you’re probably going to need to deal with your EA compliance cabal, and, then, procurement department, so, like, we’re already in the enterprise sales game zone. Also, make sure to ask them for a fancy steak dinner (unless you work for the government, I guess). And don’t miss out: ask before and after you close the deal.

Check it out!

I’m writing about this at length because I’m excited about it, both on its own, but as a strategy experiment. Pivotal and, now, VMware1 haven’t really directly monetizing the Spring Framework as much as they (rather, “we,” since I work here) could - as much I thought they should.

This is largely on purpose: the Spring open source community there has done well to remain, like, “pure.” Things have been fin! I work there, so I’ve seen plenty of second-order monetization over the years, both by us and others. Spring runs fantastically in the Tanzu Application Service (previously called Pivotal Cloud Foundry) and is first in line for support in our Kubernetes platform toolkit, the Tanzu Application Platform. And, you pay for Spring directly when you use the Microsoft Azure Spring Apps service. (With all my “hold on, this Kubernetes thing might be going too far?” waffling, I’m starting to think that some of the people I talk with who want want to make Kubernetes easier to use for developers just use that and get on with their lives.)

However, all the time, every year, we encounter the basic question “can I pay for Spring support?” Strategically, it’s also a fun experiment: it’s selling directly to developer groups, a very simple value-proposition (versus the very valuable, but very big and complex platform products we have), and, you know, kind of obvious. It’ll be fun to see how to turns out.

I don’t really understand all of this, but there’s also a lot of stuff going on in the Java world in at the moment (and through the next year) that creates a market window. That’s the seller-side way of putting it. On the buy side: there are some decisions to be made about how you use and get support for enterprise Java applications coming. Some of these are pure business, and some of them are just standard upgrade cycle events.

You should check it out!

Making the “DevOps Engineer” title acceptable

DevOps Thought Leader: if you have a group called "DevOps Engineering," you have no idea what DevOps is. You should at least feel bad if it’s your title. [Crowd laughs.]

Platform Engineering Thought Leader: Got it. Here, hold my beer. [Squints and grins]What if we called the group "Platform Engineering."

DevOps: Wait, hold on, that's not what I meant...

Platform Engineering: Hey, sorry, I was busy. Just launched a Slack and conference. posted 20 sponsored articles on The New Stack, and my O'Reilly book is coming out next week. Gotta go finish that post on Backstage sprawl now.

DevOps: …

Platform Engineering: oh, also: could you retweet my thread on “ten things you’ll got wrong about platform engineering”?

Wastebook

• Has business travel decreased, or it just me (and the tech world)? Ask perplexity: “Overall, it seems that while corporate travel budgets are recovering to pre-COVID levels, the number of trips taken is still lagging behind. Spending on international business trips is expected to pick up in 2023, but the frequency of work trips is unlikely to fully recover.”

• Culture is impossible, tools are easy.

• Threads: finally, an app for centrists.

• “I would dearly love a world full of these things. It takes me back to the days of a more creative time on the early internet, and makes me wish for a future that has more of this in it.” Here.

• What’s the 2023 take on the ethics of being annoyed? Not like, offended and hurt, just, like, annoyed in the way a kid if upset when you serve the Brussels sprouts.

• “I need a respite for my mind.” Dear John Letters #23

• I’ve been using HEY! again for email. I almost am there in liking it. I can’t wrap my mind around the idea of no archiving, and I don’t really like the way it lists The Feed. I want my newsletter subscribers to show up as one line and hide the ones I’ve already read. But, as I said to Dave Briggs when he asked me about it: “I have this ongoing theory in my digital life, though, that I should stop using tools that are too perfect, and instead use tools that seem to embody (or limit you to) a certain world view or life-style that looks good. Hey certainly seems like that. It's a kind of attitude about email that's a little less perfectionist/completionist. It doesn't value email as much? I don't know.” This is a twist on the #DefaultsLifeStyle.

• Also, he started a newsletter. You should try it out!

Relative to your interests

• Amazon Prime Video’s Microservices Move Doesn’t Lead to a Monolith after All - The New Stack - At this point, who knows anymore? I think the secret to being a grey beard in tech is to never say “oh, that’s just like SOA!” but instead to just nod and say “wow, that’s a great idea!”

• Facebook’s Threads is so depressing - Fantastic writing!

• Five Nos - “‘yeses’ matter more than ‘nos,’ and taking more chances generates more of each. While there’s a near equal chance of getting told ‘no’ in our endeavors, in virtually all cases, there is no penalty for that rejection beyond some brief discomfort or embarrassment. On the other hand, when you get a ‘yes,’ there is likely a positive outcome on many fronts.”

• How legacy tech can kill recruiting efforts, increase attrition and ruin the employee experience, Conner Forrest - “451 Research’s Voice of the Enterprise: Workforce Productivity & Collaboration, Employee Lifecycle & HR 2023 survey listed ‘candidates expect software or tools we haven’t adopted’ as the top recruitment challenge (52%) they face. To put that into context, the next-highest response was expectation of flexible work (42%) and then compensation expectations being too high (40%).”

• Rocky Linux project details how it will live on - “Nobody chooses RHEL because it’s state of the art. It isn’t. In fact, it’s about as far away from state of the art as it’s possible to be, and in the rapidly changing world of open source, that’s a very desirable attribute for a certain type of purchaser. They choose it because one specific version will be supported for a decade plus, and that in turn is why vendors support RHEL, and often nothing but RHEL.” // Also, the tricky way one of the clones plans to get the RHEL source code to make their clone distro.

• Gartner Survey Finds 79% of Corporate Strategists See AI and Analytics as Critical to Their Success Over the Next Two Years - This seems very true: “Strategists said that, on average, 50% of strategic planning and execution activities could be partially or fully automated; currently only 15% are.” And if you established a stranded memo format, even more so. And you could have it generate presentations for you. Key will be, as always, getting access to the market and internal data needed.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 11th How Cloud Native Improves & Ensures Security, Governance, and Trust in Finance, online talk. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking

Logoff

Of course I have a Threads account now. Having seen the meager uptake of other social networks over the years, I’m overly pessimistic, but I give this one a 70% chance of being wildly successful. If they actually do good stuff with whatever open standard, it’ll be like a new type of RSS. If they let me merge my Mastodon account, that’d be amazing. (Is that a thing you do with Mastodon? I know you can move to a new account, but you can merge your old account into your existing new account?)

Tomorrow I have the first installment (hey, it could always be the last installment if I get bored with the idea or just forget I was going to do it) of The Podcast Review. Here is the premise I was talking about (also) with Brandon this week:

I listen to a lot of podcasts, and have for, I don’t know, over 20 years. I’ve made and make a lot of podcasts. You might call me both a podcast listening and podcast creating expert. In the classic sense: a critic. I should review podcasts more frequently!

Make sure you’re subscribed so that you’ll get it!

LEGACY SOFTWARE AT BANKS! That's the topic of the talk my colleague and I are giving tomorrow. You can watch it for free, check it out. In addition to the talk, you’ll get a free copy of my book on managing legacy software, Escaping the Legacy Trap Here’s the slides we have so far, a preview:

The eternal first inning of cloud

According to the chart below, the movement of apps to the public cloud has stalled out at about 25% since getting to around 20% in 2017. You can see that people have been planning to get around 40% of their apps into the public cloud in the short term for awhile as well.

This is from a recent Benedict Evans post on AI in the workplace.

Of course, things can change quickly, as Horace shows every few years when/if he updates this chart (which shows market share of various “PCs” over the years):

One of the most important take aways from this chart is to pay attention to when the definition of your market changes. Then, in addition to just old apples to old apples comparisons, you can do old apples to new apples comparisons.

More on the RHEL Drama

Last episode I tried to figure out what Red Hat moving all “upstream” development to CentOS meant. I understand the effects of it: you not need to be a customer or in Red Hat’s developer program to (easily?) get access to RHEL source code.

I still don’t have a strong handle on how the whole thing functions, the mechanics of how the source code is managed that makes those effects happen. All the details are the kinds of things that the people freaking out must think are just obvious, and no one needs to point them out. After talking with a lot people, and reading more, I think it’s something like this:

1. Previous to the drama, anyone could get RHEL source code. I’m not sure exactly how (as it in CentOS, but that was canceled, sort of - so, maybe there’s just a RHEL repository or big download).

2. Cloners could build their own RHEL. It was all compatible and enterprise reliable.

3. Now, you can’t do #1. You have to be a customer or in their developer program to get the source code. (“Anyone” can still get the source code, but presumably Red Hat could deny them either being customer or in the developer program. Thus, Red Hat can control who has access.)

4. But, CentOS Stream is now the “upstream” version of RHEL.

5. And, yet, even though CentOS Stream is the source code for the future version of RHEL…this somehow means that you can’t get the RHEL source code.

6. Here is what’s new in my mind: “upstream” does not mean what I think it means at all, despite the diagrams. To me “upstream” means that, for example: first, the current version of RHEL is n. Red Hat wants to release version n+1 (the next version). You grab all the code from the “upstream” and compile it. Now you have RHEL n+1 and can release the new version of RHEL. Cloners could do the same thing. End of story.

7. It turns out “upstream” is more, like, code you base RHEL n+1 on, plus some security patches, etc. It’s not an exact copy of the future version of RHEL. So…it is not actually the future version of RHEL, it’s some code that is used to make the future version of RHEL, plus some other code that is…kept where?

8. That’s not what “upstream” means to me, but whatever.

9. This is still very weird to me, and my head hurts thinking about, so I’m just going with the consequences that was clear from the beginning: if you want to clone RHEL for free, you can’t do that except through some artful work. It’s harder now. If you want the RHEL source code, the intention is that you should either get a developer license (and be limited to running 16 simultaneous RHEL servers) or become a paid customer for Red Hat. In both cases, you’re not supposed to take that source code and make your own clones of RHEL.

¯\_(ツ)_/¯

There’s also a pretty good page where Red Hat tells you why you wouldn’t want to use CentOS for, like, enterprise grade uses.

Relevant to your interests

• Food sellers fear extra costs & hygiene risks as plastic takeaway scheme starts today - (1) the point of the whole thing is great, and, (2) this is a great example of all the hidden complexities, scenarios, and thinking that has to go into what otherwise seems like a really simple change in an existing system.

• The Homework Apocalypse - How to incorporate ChatGPT (etc.) in school and lessons…in a good way.

• Patterns vs Platforms - It’s all hard stuff. Instead of centralized platforms, perhaps consider public cloud instead, mixed with conventions. Variation: don’t build your own platform, outsource it to a vendor/cloud.

• Tony Hsieh and the Emptiness of the Tech-Mogul Myth - ’Hsieh, in the end, was a rich guy who, early in his career, used his Harvard connections and some seed money to buy a series of lotto tickets in the tech boom, and then used his expanding wealth and influence to spread a bunch of marketing, in the form of pseudo-psychology, into the world. He slept with his employees and terrorized his closest friends. His descent into addiction and his untimely death were certainly tragic, but I couldn’t find much to admire about Hsieh in “Wonder Boy,” nor did I understand why I was reading dozens of meticulously reported, almost snuff-film-like pages about his journey into ketamine addiction and mania. None of this means that “Wonder Boy” is a bad or dull book—on the contrary, it should be mandatory reading for anyone who is interested in big tech. But it did not give much of an answer to the question of how and why so much of the press and the public got suckered in by Hsieh’s generation of tech evangelists.’

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 4th, July 11th Cloud Native for Financial Services talk series. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 18th to 19th SHIFT in Zadar. Oct 3rd Enterprise DevOps Techron, Utrecht.

Logoff

I saw the new Spiderman multiverse movie yesterday with my son. It was pretty good.

I don’t make the time to go do “normal” things like seeing a movie enough.

Source Code

I’ve almost figured out the drama around Red Hat redoing how they distribute the source code for RHEL.

Is this it?

Here is my understanding of it:

1. Before the changes, anyone could get the source code (and I assume configuration, build methods, etc.) so that they could create an exact copy of RHEL (“bug for bug,” as people like to say).

2. This means that “clones” of RHEL (or distros) could be relied on to act exactly like RHEL.

3. So, if you did not want to pay RHEL for access to RHEL and the support they’d give if things went wrong, you could get RHEL for free, or some discount from the clones (including Oracle).

4. The drama was: RHEL no longer provides that source code.

5. What this means, exactly, is incredibly confusing. Red Hat still develops future versions of RHEL all in the open in a project called CentOS.

6. HOWEVER - and this is key to everything, so if it’s not accurate, I am still super confused -, as Jonathan Bennett wrote here: “CentOS Stream just isn’t quite the same as RHEL, and there are bugfix patches that land in RHEL and not in CentOS Stream.”

7. That is, whatever is in CentOS is not exactly the same as what’s in RHEL.

8. Now, you can actually get access to the source code for RHEL, and thus the ability to build it on your own and get the exact copy as in #1 above.

9. BUT! There are new restrictions on that: you have to be a customer (I don’t think it matters if you pay or not) or be in their developer program (which is free).

10. There’s some open source licensing (GPL) “license interpretation innovation” going on here.

11. The thing about being a customer or in the developer program, is that Red Hat could decide to terminate you as a customer or your membership in the developer program at any point.

12. Thus, a cloner could sign up as either, get the current (and presumably past) RHEL source code. They could then build the exact copy in #1, and go about their business (literally and figuratively).

13. However, if Red Hat doesn’t like this, they could terminate that cloner, cutting off all future access to the source code.

Control

And that’s the drama: effectively, Red Hat now can control who gets ongoing access to RHEL source code.

It’s very hard for me to figure out if these details are correct. It all hinges on point #6 above. There’s another version of point #6 that is less “bad”:

It could be that CentOS is actually “bug for bug” compatible with RHEL. However, I think Red Hat said they will only sync up RHEL to CentOS for every major release of RHEL. That seems to happen every six months. This means that whatever happens in between every major release - in particular bug and security patches, the most important things you’d want! - is held back by Red Hat. So, if you went with a clone of RHEL, you’d have to wait that six months to get your bug and security patches. I don’t know though: that seems like some real tin-foil hat shit, and what does it even mean to “sync” code: is Red Hat maintain a private repo of all the patches and then they just do a pull request to the CentOS git repos every May and November. I mean…that’s not technically impossible.

To simplify it a lot, if I understand this correctly, first, even though RHEL development is done in the open, it’s only mostly done in the open. Some of the code is held back, particularly when it comes to bug fixes and security patches.

Second, Red Hat can control who gets access to the real RHEL source code.

This means that you can’t clone RHEL reliably, which means that if you’re running your organization on software that is only supported and verified to run on RHEL, you now have to run on RHEL and, thus, pay Red Hat.

I mean, that organization could run on not exactly RHEL clones and will probably be fine. The clones will have to figure out and distribute bug fixes and security patches, presumably. But no one wants say “yeah, the software that runs our factory, makes sure shipments get from Rotterdam to LA, makes sure the missiles don’t accidentally land in the suburbs will…probably work…there’s probably not a problem or incompatibility in the operating system.” Instead, those organizations will want the assurance (and, like, finger-pointing and support) that it’s all certified on RHEL and that they’re running actual RHEL.

Of course, you could come up with a scheme to get access to RHEL source code. The cloners could hire anyone off the street to sign up for an account and download the source code again and again, burning a developer account each time. Once that person had the source code, as I understand it due to the open source licensing, that person could give the code the cloners. Or just put in online for anyone to download it. Once you get a copy of the source code, you can then give it someone else if you don’t mind your developer account being canceled.

I assume you have to be 18 to get a legal developer account with Red Hat. There’s something like 2.6 billion people in the world over the age of 20. So, I don’t think the clones will run out of people to hire to fill out a form and click a button: the clones could automate the process as well.

You could even see people crowd funding this: you just pool together something like $5,000 a month to to hire someone for, like, $500 to fill out the developer program forum and then run a script to download the RHEL code. So whenever a patch comes out, you do that, and you can get an exact copy of RHEL, per #1 above. Someone like Oracle would probably be like, “here, how about $15 million?” Then you could even setup a foundation and get a fancy executive director!

This is a high degree of shenanigans, however. I can see the clone sales rep trying to explain it all to a CISO at, like, Citibank or the German Air Force and that CISO going like “hmmm…how about I just spend $20 million more every three years and totally eliminate a weird bucket of risks? I mean, I’m the CISO, all I have to do is sneak up behind the CEO and CFO and go ‘SECURITY! BOO!”, pick up the spare change that falls out of their pockets when they jump-scare, and then my budget is pretty much unlimited.

“I’ll get my Red Hat (or, even better, IBM!) rep to buy me some steak dinners a few times every year, fly me out to Vegas for the annual conference, be on a panel at RSA for them, and we’ll call it a day. (Also, we’re supposed to be running all our shit in THE CLOUD by 2028, where we won’t be using much, if any, RHEL, so…whatever?)”

So…?

Did I get that all correct?

Consequences

More than just control, all this means that more people would likely become paid RHEL customers. This is because the clones would no longer be reliable enough (see the “probably” scenarios above). There’s probably not too many enterprise customers that have reduced their bills by paying clones or just running without paid support. (I’ll let someone else look up the marketshare). I could see that a lot of telcos would be doing this, though. Some managed service providers, maybe even the big cloud providers. Still: how much extra revenue are we talking about: is it $15 million, or more like $2 billion?

The whole social contract, norms, feels and vibes thing is a completely “orthogonal” thing as the people involved might say. I just want to make sure I get the understand the new constraints in the system.

Developers

Also, in the developer program, you can only run 16 simultaneous instances of RHEL, which would put a damper on some companies, who, for example, would want to certify that storage arrays are compatible with RHEL. For example, if you’re a hardware manufacturer and you want to run 100 tests (I don’t know, for stats or some shit) for the new version of RHEL to make sure it works on your hard drives and computers, you’ll have to do that in chunks of 16.

Let’s assume that testing takes three hours. You need one hour of setup time, one hour to run the rest, and one hour to analyze the results. If you could run then all at once, then it’s just three or four hours to run those tests (plus the time to rig up the hardware and stuff, but let’s assume you’re really good at that by now, so it takes, like, two hours at most to do all of it).

If you have to do that in batches of 16 [is this the right math: ( (100 * 3)/16 ) * 3?] then it will take 56.25 hours instead. That’s 2.3 full days (24 hours), and seven working days (8 hour days).

So, you could say that your costs became 2x to 8x (mostly in labor), depending if you already were running on three shifts (day, evening, midnight) or just one (day). This would also mean that to fully certify a patch, you’d need seven days. This means that, if a security problem came out on any other day than a Monday, and in the morning, you’d need people to work on the weekends, or have them work overtime.

And then, if had to patch previous versions of RHEL, you need to multiple that by however many versions back you go that needs the patch. Obviously, all of these numbers are made up, but you can see where there’s a model here for figuring out how only being able to run 16 simultaneous RHEL instances (for free) would change things a lot.

Now, I would imagine that a lot of the people, rather, organizations that are doing this testing already have an extensive, long-term customer/partner relationship with Red Hat. These would be from the likes of Dell, EMC, Intel, AMD, SAP, Microsoft, likely the public cloud providers, etc., etc. So, they probably don’t care. It’d be the smaller, even down to just one individual who’d suffer from the above.

And, I guess, if you were working a system or software that was intended to run more than 16 instances of RHEL - like most parts of Kubernetes, OpenStack, scaled out databases, etc. - you’d be kind of screwed too if you wanted to do it all for free.

Wastebook

• Goofball training - leaving my wallet behind is good practice for relaxing more, moving to a carefree lifestyle where I don’t worry shout all that.

• “There is so much to worry about, that we forget to worry about ourselves and then it’s too late.” Here.

• I don’t know what to do with Bluesky. I’m not really into the nature of truly keeping up with what people are thinking and doing - that’s Facebook, right? And I’m not big fan of that activity in Facebook already. So, I’ve just been posting a pictures a day there. But, really, until I can just automate it, I don’t think I will anymore. Thus far, I haven’t really found a point in the post-Twitter Twitters. This is due to the huge follower-ship I’ve built up in Twitter since, whatever, 2006/7 - that’s a big asset of mine, professionally. In comparison, the use of Mastodon and Bluesky as a publishing channel is not good. Plus, I’m increasingly tired of, like, trying. After all, my bigger project of is commiting selective infosuicide.

Relevant to your interests

• A modern-era lift and shift: Danske Bank seeks massive cost-to-income ratio improvement with the help of Infosys - As ever with outsourcing: hire cheaper labor under less restrictive labor laws…?

• 28 Questions to Ask Your Boss in Your One-on-Ones - Good things to talk about in your meetings if you can’t think of anything else.

• ‘Zero trust’ was supposed to revolutionize cybersecurity. Here’s why that hasn’t happened yet. - ’John Watts, a Gartner analyst, wrote in the firm’s annual predictions memo from last December that “moving from theory to practice with zero trust is challenging,” and that fewer than 1% of large enterprises are actually using it today…. Moreover, Watts predicted that “over 60% of organizations will embrace zero trust as a starting place for security by 2025 but more than half will fail to realize the benefits.” A report from Nathan Parde of MIT’s Lincoln Lab last May, meantime, estimated the typical zero-trust deployment will take anywhere from three to five years. That is a depressing thought, to be sure.’

• Midjourney and Adobe Stock - Using AI to make stock photography, etc.

• Mobile Industry Eyes Five Billion ‘Dormant’ Phones Sitting In Desk Drawers For Reuse Or Recycling - 5 billion phones sitting in desk drawers.

• The real story of how Facebook almost acquired Waze, but we ended up with Google - “Acquisitions are the first moment when founders and investors have diverging interests. This is the one time when you should be wary of feedback from your investors. And, of course, like any negotiation, whoever is willing to walk away will get the better deal – always have a red line and hold firm to it.”

• Beyond belt-tightening: How marketing can drive resiliency during uncertain times - What’s a little crazy is: shouldn’t this all just be the way marketing always works?

• Red Hat ends the RHEL clones’ free lunch - I still don’t understand exactly what source code is unavailable and when. If CentOS is the “upstream” code…then getting an older version of the CentOS code will get you the current version of RHEL code, righ? Is it just annoying to do…or is it actually not at all possible to build a “bug for bug” copy of RHEL now without paying or having the dev license…because the actual RHEL code is actually not in CentOS? Or the magic is all in the extra stuff Red Hat adds to the RHEL build (like drivers, config, etc.), which used to be no strings attached available, but is now not?

• How Google Reader died — and why the web misses it more than ever - “At its peak, Reader had just north of 30 million users, many of them using it every day. That’s a big number — by almost any scale other than Google’s. Google scale projects are about hundreds of millions and billions of users, and executives always seemed to regard Reader as a rounding error.”

• Fuel for Thought: The Transformation of Auto Retail – Bricks, Clicks, and People

Upcoming

Talks I’ll be giving, things I’ll be doing, places I’ll be going.

July 4th, July 11th Cloud Native for Financial Services talk series. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 18th to 19th SHIFT in Zadar. Oct 3rd Enterprise DevOps Techron, Utrecht.

Logoff

Hey, I really just am curious to figure out the stuff above. I do not have schadenfreude tingle-dreams here, or whatever. I just like to pull apart and understand puzzles like this.

See y’all next time!

I really liked how this first talk in out three part series came out. I wanted to talk as much as possible about actually strategy, business-think, so to speak, when it comes to how financial enterprises do software. All of us cloud native people spend a lot of time talking about the general benefits of cloud native stuff: better developer productivity and getting closer to the agile, deliver once a week (or daily!) dream; resilience/uptime; security blah blah; and etc.

These are good business outcomes/value, but I like getting deeper into what the actual apps are doing and how they’re helping create new types of business, products, and so forth. So, here, it was fun working with Darran (who’s actually worked on all this stuff at banks, most recently UBS) to talk about all that. Plus, I got to learn a couple new case studies from out customer base.

Anyhow, you should check it out. Sure, it’s a webinar, so you have to sign up for it, but: come on, no problem, right? You’ll enjoy it. Tell me what you think.

Watch the Talk

There’s two more in the series as well, next Tuesday and then Tuesday the week after that.

Changes in the streams

This week’s Tanzu Talk podcast: Ben and Ed try to help Coté understand what the changes in RHEL open source development mean. We don't figure it out completely, but get close enough. Also, Ed tells us what Crossplane is. Finally, we briefly discuss two new reports from Gartner and Forrester that seek to define the cloud native application stack.

Listen to the episode

Lost Videos

I found two videos I made that I’d forgotten about:

1. Thinking about governance in enterprise software.

2. Making a stronger connection between making money and all that money you spend on IT.

Depending on how you count them (are live streams of podcast recordings included?) I’ve made around 200 videos for work in the past three years. I started with some little goofy ones I made during paternity leave, then a lot more during COVID, and now it’s just a normal thing.

It’s not easy to make videos all on your own - it’s a multi-tool skill. Plus, you have to act, figure out the content, and promote them. The secret is that I was thrown into video making back in 2007 when I was at RedMonk. Or maybe it was 2008. Who knows. CIRCA &co.

We had a totally ridiculous (in a good way) contract with some early internet video startup whose name I forget. I think most of those videos are lost. Our boss was Steve Gillmor! His early podcast, The Gillmor Gang, was a huge inspiration for my own podcasting, general tech world thought leadership craft, along with Jon Udell, both who had shows on IT Conversations.

That didn’t last long (it was, after all, ridiculous). But, it lead to RedMonk starting up a video business, which I ran soup to nuts (except for sales, that was shared among the three of us). You can see those videos still in YouTube. As you’d expect 12 years later, their videos are insanely better now-a-days, not just a dork with a tripod in an poorly Las Vegas conference room and hallways.

Anyhow. I like making videos.

I’ve more or less come to accept that I both can’t and don’t want to put in the effort to get “famous” in the video world, which has sort of lessened me making videos more frequently. When you see that you only get, like, 150 views with only about 5 people watching all of the video, you start to think: why am I doing this? That’s in YouTube: the numbers in LinkedIn and Twitter are higher…but the people who drop off early on seem the same. I envy people who code in their videos: they at least are doing something instructional and there seems to be no end of content for them. I have to just talk in mine, and I’ve kind of said all I know to say.

Of course, there’s all the non-tech videos I make too, which are definitely worth it just for the fun:

I was thinking of all of this when I noticed I almost have 200 subscribers on my YouTube channel. Things are gonna start changing once I get over that hump!!

Upcoming

Talks I’ll be giving, things I’ll be doing, places I’ll be going.

July 4th, July 11th Cloud Native for Financial Services talk series. August 21st to 24thSpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 18th to 19th SHIFT in Zadar. Oct 3rdEnterprise DevOps Techron, Utrecht.

Logoff

It’s almost July! My mother is coming for the summer which is always great. The kids, of course, love seeing her; she loves seeing the kids; Kim and I like seeing here; and, I won’t be coy: we finally get some free time from the kids!

I’ll probably roll up the links next episode.

Here’s my talk from Cloud Foundry Day, last week:

The Cloud Foundry community has been around for a long time and the PaaSes built on it have been in use for awhile as well (many for at least five year, some for well over 7 years). In this talk, I first wanted to go over some advice on growing and sustaining a community build around a platform. And, second, I wanted an excuse to point out that Cloud Foundry works well for people and, you know, it’s kind of weird that we’re, once again, table flipping it all and starting over. But, you know: seems like what the overall cloud native community wants to do - good luck storming the castle meme, and all that.

Check out my co-worker Nick’s talk for proof of Cloud Foundry’s coolness, which he gave right before mind.

Wastebook

• “I’m about to do a purge and burn on my RSS reader’s feeds, because it’s boring the shit out of me.” Here.

• Real Kafka experience checking in at the hotel tonight(Frankfurt Airport Sheraton). Except the guests checking in were the maze and the clerks were the bewildered protagonists.

• “While you study the cloud, he studied the blade.” Here.

Relative to your interests

• Apple’s Vision Pro Is A Pricey Cabled Halo XR Headset For Developers And Prosumers Coming Next Year - Thorough industry analyst style review: “The target market for such an expensive device is developers, prosumers and enterprises that aren’t bothered by the external battery and wire. I genuinely believe that Apple’s customer base will be within the enterprise productivity space, many of whom are likely also prosumers.” And: “I wouldn’t bet against Apple, but I also think that the company hasn’t quite nailed down the new use cases for it yet, and that’s why I think this device is mainly trying to capture the mindshare of developers.”

• It’s time for the Kubernetes value line - “There’s a reason the saying ‘culture eats tech for breakfast’ has become a favorite in today’s IT lexicon. What this pithy saying doesn’t get into is that technology can change behavior over time.”

• Inside the Fantastic Smoked-Meats World of Lockhart’s New Vibrant Barbecue Restaurant Barbs B Q - “The menu is full of South Texas influences from Charnichart and Tovías’s Brownsville upbringings: the brisket is coated in Mexican spices, the ribs are tangy with lime zest, and in addition to the charro bean sides and concha pudding dessert, they’ve also added a twist on the usual mac and cheese by offering green spaghetti, a creamy poblano-based pasta.”

• not for me - The anti-take take: “the value of responding to a book (or a movie, or TV show, or whatever) simply by saying: It wasn’t for me”

• The Harried Leisure Class - This seems like a good way of thinking, but I can’t figure it out.

• ‘It’s every woman, it’s us’: Rotterdam falls for British statue of ordinary black woman - "It doesn’t stand on a plinth and isn’t an exalted representation of someone exotic. It’s just yourself, how you are, not a ‘super’ version. And how many images of black women are there?” And: “It’s every woman, it’s us – and it’s just standing on the floor like you and me.”

• Backstage Disneyland - Amazing!

• Smilemakers: McDonald’s approved vendor for branded merchandise - Imagine being so proud to be associated with a brand that you bought throw-back t-shirts and hoodies to wear on the weekends. It sounds like a good mindset to be in:

• Lotte Hotel Little Secret - “Those three little stickers represent a beautiful universal guarantee: if you build a weird funky little hidey space, kids will find it.”

• I don’t enjoy these 7 software development activities. Thanks to generative AI, I might not have to do them anymore - The blog title is accurate.

• Working Remotely with Belkin’s BoostCharge Pro - Looks real nice.

• 10,000 microwave enthusiasts to attend annual microwave conference in Las Vegas - “Despite all this potential, my naive guess is that this conference doesn’t exist because nobody cares about what big microwave builds next. As useful as the appliance is, there isn’t much else for it to do.” // The joke here makes a good point about how technology strategy changes as it the technology becomes wide-spread and normal.

Upcoming

Talks I’ll be giving, things I’ll be doing, places I’ll be going.

July 4th, July 11th Cloud Native for Financial Services talk series. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 18th to 19th SHIFT in Zadar. Oct 3rd Enterprise DevOps Techron, Utrecht.

Logoff

We did our first talk in a three part financial services series today, this one on the topic of integrating software into your strategy. It was fun! I wanted to try out the “big pictures, no words” approach to slides.

Normally, I loath that kind of talk (both watching it and giving it). It worked out fine. Part of the motivation was that I wanted to have more back and forth, be more like a podcast. So, as I learned from Bridget a long time ago: if you have slides with big pictures, you can change what you talk about to whatever you want. Check it out: it also has some good content linking together business strategy and agile/design-drive software thinking. There’s two more talks, you should register for them and attend.

Also, I keep liking are.na. It’s fun to post there and fun to browse. Most of what I see there is clearly from designers and “creatives” rather than, like, fandom and collectors as seen at Tumblr. Which is fine: there’s already a Tumblr.

Has DevOps reached its goals from way back in the late 2000’s: deploying multiple times a day and having developers work closely with operations people? Adam Jacob brought up this question in two interviews recently, on my podcast, interviewed on my podcast by Matt Ray this week (which I [cough] haven’t, well actually listened to yet - maybe on the dog walk after I finish up here], and the Cloudcast, interviewed by Brian Gracely (I listened to that one real-good-like!).

Conclusions

After looking at it, my answer and analysis is:

1. Deployment frequencies (if I remember how they were in the 2000s) got much better, but have long stalled out at, I’d estimate, 50% deploying monthly or less. Not much progress has been made there for several years. But, if we readjust the goal from “multiple” times a day to “a month or less,” things have gone pretty good.

2. Application developers working closely with operations is not clear. Perhaps it wasn’t exactly the idea in the first place, and has been replaced by having a good platform in place for application developers. (We just need to finally focus on building that platform instead of re-starting it every five or so years.)

3. Without finding a bunch of charts to back this up, the job and culture of operations seems to be a lot better.

Now, let’s take a look at some charts to see how I got there!

(Oh, but first…)

OO Config & Release Management

First, how about the new idea Adam is showing up for?

I saw Adam reveal his new company back at cfgmgmtcamp. Their approach to configuration management looks nice: it’s like going whole-hog on object oriented programming for configuration and release management.

I mean, any configuration and release management ultimately rests on the actual code that updates the configuration: from fancy Kubernetes reconciliation, calling APIs on infrastructure, down to brute forcing it with automating SSH calls to modify weird Linux files. It is very gritty, tedious, and grueling that’s hidden behind clean abstraction layers (blah, blah) at the top. We’ll see how that work goes!

This new approach looks like fun, so hopefully we’ll see more of it.

Back to the idea that DevOps hasn’t met it’s goals.

Spock and Scotty Working Together

How would you rate the spread of DevOps? There’s a few metric-able things: Adam talks about developers and operations people working closely together on a release. I’m not even going to pour through my decade plus of saved PDFs to find a year/year survey question about that. It’s have to be something like “are operations people embedded on application development teams?” I’ll just add my anecdotes from talking with regular enterprises (read: not tech companies, large 5,000 to 10,000+ employee organizations) over the past ten years: no. (There’s a bonus chart below that sort of backs this up.)

Further, when you look at the talk around “platforms” for the past seven or so years (currently going under the phrase “platform engineering”), the whole space is pretty clear about keeping operations people separate from developers. The point of a platform, after all, is to automate as much of operations (esp. configuration and release management, but also just figuring out how to integrate everything together) as possible so that developers can focus on their applications - “moving pixels on the screen” as I like to say. I mean: this is great! YES, more of that.

Over the years, and once again, Andrew Shafer and friends have been reminding us that Warner Vogels mid 2000s decree that “you [application developers] build it, you run it” does not mean application developers run all of it down to the metal. It means that there’s a platform in place doing all of the hard work.

Deployment frequency, CI/CD

Deployment frequency is one of the major focuses of DevOps: how often can you deploy new code to production? Before culture emerged as - I don’t know, I’d say - the primary focus of DevOps, deployment frequency was a primary metric. This is the metric I’ve tracked over the years.

Deployment frequency the one I use to rate how well things are going when it comes to doing better at software. The more frequently you can deploy your applications, the more frequently you can learn what your users are doing, experiment with ways to do them better (by introducing new features in the apps and modifying existing ones), and get feedback about improvements. This is known.

The goal of DevOps early on was getting to daily deployments. Hmmm…“goal”: I don’t know, at the very least the aspiration and what seemed cool. However, over the years, and knowing the rates that large, not tech companies deploy, I think weekly to monthly is a fantastic goal.

I like to focus on “large, not tech companies” because tech companies are outliers to me. I care about what governments, banks, not-Amazon retailers, logistics companies, pharma…you know, the companies that fill our everyday lives when we’re not doom scrolling.

DORA - 81% deploy monthly or less, but the charts are weird & tech companies are over-represented

First, let’s look at the holy PDF, the DORA report. (Side-note: did we ever get the story of why the DORA reports forked from Puppet? It’s been long enough now that surely the tale can be revealed!)

There isn’t a chart that explicitly shows the percentage breakout of deploy frequencies, but you can make one if use the four clusters they have, which are created by various levels of the DORA metrics, including deployment frequency.

Here’s the chart of the percent of respondents in the four categories over the past four years:

I rebuilt the chart to a 100% stacked bar chart focused on deployment frequency (yes, one of them adds up to 107%: ¯\_(ツ)_/¯):

First, the span of “weekly to month” is kind of annoying. I’d want to see multiple times a day, daily, weekly, monthly, six months, an annually.

Second, things are weird in 2022 because they threw out the elite category (green above) because:

we don’t consider any cluster to be elite this year. This year’s high cluster is a blend of last year’s high and elite clusters. We decided to omit an elite cluster because the highest performing cluster simply isn’t indicating enough of the characteristics of last year’s elite cluster.

These numbers go back and forth so much over these four years that I’m not sure what to make of them.

The 2022 results are pretty bonkers: the report authors say the pandemic might have caused the huge shift to weekly to monthly Going from 28% to 69% is super-bonkers. You could look at just 2018 to 2021, but then 2019 is the whacky year too. Or you could look at changes in “elite” (deploying multiple times a day), but then since there weren’t enough elite performers in 2022, that 26% of respondents who deployed multiple times a day evaporated…?

I could look at shifts in demographics each year: were there big shifts each year? Like, were there more people reporting from large, not tech companies? From lagging geographies? From more conservative roles in the organization that might not have visibility into deployment frequencies (or the opposite)? But, I didn't!

So, let’s say that in 2022 11% of respondents can deploy daily or multiple times a day. By the goal of deploying multiple times a day, then, DevOps hasn’t had much success. However, again, getting large, not tech companies to deploy “weekly to monthly” things have been pretty fantastic.

But! By the goal of monthly or less, you’ve got 81%, which is clearly great.

However, since over 50% of DORA respondents are consistently from the tech world, I’m not sure. I’d want to throw out tech companies and just look at what’s left before concluding much.

(I looked at the 2017 to 2015 reports for these breakouts but couldn’t find them.)

State of Agile Reports - ~50% lack CI/CD capabilities

I’ve used the State of Agile reports over the years to track even the possibility of deploying frequently. These reports asked survey respondents if they used CI and CD tools. My theory is that if you don’t have CI and CD, you’re going to have a tough time deploying frequently. It’s certainly possible! …but not likely. We’ve all heard tales of people sftp’ing code changes to production, after all.

They stopped reporting on these metric in 2022. What I see in this chart is a steady growth in continuous delivery (the empty bars), but stalling out for continuous integration (the filled in bars).

Another way of reading this is that over the years, about 50% of people do not automate their builds (or maybe “pipelines”) because they don’t even have continuous integration.

I didn’t lookup the company demographics since I’d already made this chart sometime ago, and I’ve already spent a lot of time typing all this up. I’ve got webinars I’m supposed to be making slides for, friends.

By this metric, DevOps doesn’t seem to have done well at deployment frequency. At the very least, you’d want to automate the pipelines. I think?

CD Foundation - ~65% deploy monthly or less

Thankfully, the CD Foundation surveys have an easy to find, multi-year charts of deployment frequency:

So, here, we’re at about 30% for daily or multiple times a day. 35% for monthly or more, an equal amount for between a week and a month. So, let’s say, 65% can deploy monthly or less. That’s good.

What’s striking here is that it’s stabilized since late 2020, for the past 2 and half years (or whatever that calendar math is).

Without seeing the company size and industry break out, I can’t comment on large, not tech organizations. But, they throw in some commentary on large organization’s lead time (time from committing code to deploying, so a little different that deployment frequency [rolls eyes]):

Among developers at large enterprises (more than 1,000 employees [I’d call these medium-sized companies, but whatever -Coté]) we began to see an increase in top performers for lead time for code changes to 21% in Q1 2022, which has since decreased to 16%. However, despite the percentage of top performers decreasing, we still see that 40% of developers have lead time changes of less than one week, the second highest since we began asking developers.

So, 60% of developers at large enterprises have a lead time of a week or more. If we assume the week to month is similar to deployment frequency (like, 30%), then we have 30% doing a month or more. I don’t know, I just made that up!

Here, DevOps things are pretty great, but not getting greater.

As a bonus, here’s a chart showing the types of activities developers say they’re involved in

This is interesting when thinking of the “are the Devs working with the Ops…or at least, doing the whole ‘you build it, you run it’ thing?” Some are, but, sort of, less than 50% are doing many of the activities I’d call “DevOps.”

Forrester - 27% to 42% deploy monthly or less

Here’s two charts from Forrester:

First, it’s a little jarring when the legend and the chart are in opposite order, but, hey, maybe The Book was out of print at the time.

In this chart, 25% of people release monthly, while 50% are between a month and a quarter. 12% release weekly, and 6% release 1 to n times a day. Here, we have 42% (in 2021) of people releasing monthly or less.

In 2022 they changed the way they ask the question to: “How often does your team release through automation large or entirely new applications?” resulting in this:

So…let’s say 86% release their software a month or more: 15% average monthly, 31% average it every quarter, 26% twice a year, and 13% a year or more. And: 27% a month or less.

Forrester also asked for average/common release frequencies:

In the above chart, you get 26% of respondents saying they average a month or less to deploy.

So…27% to 42% of respondents deploy a month or less. Not too hot for DevOps.

Things are OK, but not super-fantastic

I don’t know, let’s say: “this Liberal Arts major concludes that something like 50% of organizations deploy monthly or less. [throws smoke bomb, and disappears!]”

13 years after the Spock and Scotty talk, things are probably better than they were back then. The only chart I have that goes back that far is the State of Agile one, which has shown tiny improvement since then.

I think the focus of DevOps has changed over the years and is less about deployment frequency and more about, I don’t know, making sure your software actually works in production - resilience? Also, as Adam comments on somewhere, DevOps has also made the culture of IT much better. We didn’t used to talk about, like, operations people being happy.

Putting the charts away and going back into the land of anecdotes, there’s a lot of work to be done when it comes to improving deployment frequency and over all improving how software is done. Again, things have improved, but not, like, for 100% of organizations, developers, and so forth. Or probably even 50% or 60%.

Also, it’s worth noting that we often forget how much has improved. I forget what bias it is, but a few years after a system improves, people reset their baseline for bad. You know: airline travel sucks, but we forget that traveling by horse is incalculably worse.

Reverting to yaml mean

As you probably recall, dear readers, my other theory is that we can’t help ourselves when it comes to maintaining focus on the application layer, “developers.”

Every five or so years we have to dive down the stack and mess with the infrastructure layer, halting our work on making things better for developers. That work is not only halted, it’s usually tossed aside. Most recently, we did this with Kubernetes. That layer itself is totally fine…great, even for what it does, standardizing infrastructure over cloud (native) stacks: an API and data structure; configuration, release, and operational models; and even application architecture.

But the overall ecosystem (vendors and end-users) got too obsessed with Kubernetes, despite plenty of pleading not to by the the Kubernetes sages. The dog that caught the bus, etc. And we’re still too obsessed. Hopefully, it’s lessoning as it dawns on everyone that getting better at software means paying attention to the application layer and developer productivity.

Something like 50% of surveyed organizations can deploy their apps monthly or less. That number is probably less for large, not tech companies. Even if that’s 40%, even 30%, that number is great compared to what it probably was back in 2009. Let’s keep up the work to get the rest of them fixed up.

Upcoming

Talks I’ll be giving, things I’ll be doing, places I’ll be going.

June 28th, July 4th, July 11th Cloud Native for Financial Services talk series.August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 18th to 19th SHIFT in Zadar.

Logoff

This DevOps question is a little unfair in that it can seem like it’s precise. I mean, it’s just some charts and trying to make sense of them. If we had all of the years of DORA charts with the deployment frequency and other characteristics over time, I think that’d be the best. Perhaps that exists! But I didn’t look long enough to find them. Tell me what you think, and see y’all next time.

I’m at Cloud Foundry Day today - travel, conference, etc. I realized I’m giving the last talk, which is kind of a good slot to have. I’ll have to do some kind of “end of the conference” commentary on life. It’s Germany, and it’s hot. People leave the doors open for a breeze, so there’s the light smell of cigarettes here and there. (The Texan in me is a bit mystified, even stressed out at seeing open doors when there’s air conditioning.)

Before there’s too many, it’s just a links catch-up today. People over in Mastodon really liked the first two links, a different set of people the Cloud Foundry community round-up from Nick.

Relative to your interests

• Why did the #TwitterMigration fail? - Difficulty crossing the chasm. But, come on: it’s been less than a year.

• Bluesky Has Problems - Me: there aren’t enough people and, thus, communities yet. Also: federation isn’t really anything people care about, and, thus, not a feature worth spending time on. And, the same as above applies: it’s been much less than a year, way to early to make condensing judgements.

• All those naked Greeks… - I think the conclusion is status, power, beauty, and sex.

• Rest for the restless - “Maybe it’s my low tolerance for boredom. I can’t help but do something, anything. If only I could embrace boredom, and just let myself be. I can do a seated meditation for 10 minutes with no big issue of fidgeting, just focusing on my breath. But that’s still doing something? Reigning in the monkey mind, trying to keep a straight spine. Not quite what I imagine a relaxed state to be.”

• Hacking through flashing LEDs on network cards - “The author’s show that these LEDs can bleed information about power consumption that can be used to deduce when and for how long a computer is computing cryptographic keys and that can be used to deduce the keys. For example, using a “hijacked” security camera the author’s were able to film the power LED on a smart card reader from 16 meters away and from that able to deduce the keys.” It has a link to the paper.

• Google: Reports of My Death Are Greatly Exaggerated - “Startups can move faster and be more innovative because they aren’t afraid to break things and disrupt existing business models. Large incumbents are historically slower to innovate and they resist disrupting their business model because they risk hurting their established profitability margins. They become addicted to their high profit margins and fear investor’s wrath for the perceived misallocation of capital, so innovation with large companies is typically much slower…. However…the innovation shift with AI will unfold a bit differently because the power of AI is universally accepted.”

• Open Source Platform Engineering: A Decade of Cloud Foundry - “I managed and maintained over 1,000 applications, which ran over 22,000 application instances across 26 deployments of Cloud Foundry. The platform served more than 1,000 developers, who deployed applications ranging from e-commerce, health care, logistical and highly compliant workloads.” And: “Our average customer PE efficiency ratio is one platform engineer supporting 190 developers, with an overall platform team average of six platform engineers supporting 1,200 developers. In some cases, we have seen an average of one PE supporting up to 500 developers within an organization. The platform engineering efficiency metric is a critical differentiating factor, as our user base sees a drastic decline in PE efficiency when evaluating alternative technologies.”

• Your mother taught you not to trust yourself when it’s exactly what you need the most. - ‘A mother can be a person who, as you grow older, shifts from telling you what to do next (wash your face, brush your teeth) to asking you to experiment and see for yourself what you like and don’t like. A mother can go from quieting your tantrums when you’re tiny to listening closely and asking good questions when you say “I feel negative” or “I feel lost.” A mother can encourage you to notice and pay close attention when you feel confused or uncertain without immediately trying to squelch those emotions because they make her feel anxious. When you’re upset, a mother can say, “These feelings aren’t ‘bad,’ they’re informative and worthwhile, because they’re telling you what you want from your life, letting you know which things bring you joy and satisfaction, what feels incomplete or unacceptable to you.”’

• Gartner Forecasts Worldwide Banking and Investment Services IT Spending to Reach $652 Billion in 2023 - Banks spending more money on IT. They’re planning to spend on: “cybersecurity, data and analytics, integration technologies and cloud.” // And, keep moving to (public?) cloud: “More than half plan to increase investments in cloud, while reducing IT spending in their own data centers. This is reflected by slower growth in data center systems spending from 13.2% in 2022 to 5.7% in 2023.” // ‘Worldwide banking and investment services IT spending is forecast to total $652.1 billion in 2023, an increase of 8.1% from 2022, according to Gartner, Inc. Spending on software will see the largest growth with an increase of 13.5% in 2023…. “Current economic headwinds have changed the context for technology investments in banking and investment services this year,” said Debbie Buckland, Director Analyst at Gartner. “Rather than cutting IT budgets, organizations are spending more on the types of technologies that generate significantly higher business outcomes. Spending on software, for example, is shifting away from building it in-house, in favor of buying solutions that generate value from investments more rapidly.”’

• Guillermo Del Toro on His Future: “I Only Want to do Animation. That’s the Plan” - “[Why] does everything act as if they’re in a sitcom? I think is emotional pornography. All the families are happy and sassy and quick, everyone has a one-liner. Well, my dad was boring. I was boring. Everybody in my family was boring. We had no one-liners. We’re all fucked up.”

• The EU Digitalisation Strategy for the Financial Services Sector is put to the test - It’ll take awhile, but I think the multi-factor nature of a smart phone ads a lot of identity verification, governance (tracking and transparency), and other capabilities that’ll drive all sorts of yet to be known new features in banking. Just having a super reliable form of identity verification(way above, you know, what a piece of paper or little card with your picture on it can do) seems huge.

• Kubernetes flexes open-source muscle as it transforms enterprise IT - in the chart below, “beyond cost savings, the chief motivations for using open source in EMEA are the ability to customize software (50%) and avoidance of vendor lock-in (48%)” // Most of the piece is a lot of commentary on the kubes community, circa 2023.

  

Wastebook

• “The elephant in my room.” RotL #502.

• The past is not what's normal, the present is.

Upcoming

Talks I’ll be giving, things I’ll be doing, places I’ll be going.

June 21st Making digital transformation stick in government agencies, online. June 22nd to 23rd DevOpsDays Amsterdam June 28th, July 4th, July 11th Cloud Native for Financial Services talk series.August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 18th to 19th SHIFT in Zadar.

Logoff

As much as I love traveling for work, in the past few months I’ve grown to dislike it. This is weird! I mean, I’ve done it since 2006, so it’s been part of my life for 17 years. I enjoy being home and with family, of course, but that’s not the issue: over those 17 years I’ve figured out how to make that all work out. It’s more that I don’t seem to be getting enough out of it for both work goals and my own, compared to those outcomes if I just stay at home.

Somewhat related to this is a sort of writer’s block when it comes to conference presentations and something else odd for me: a sort if disinterest in the same old shit over and over. I need some new talks! New ideas!I’ve been looking at the talks accepted at conferences by my peers (and, sure, others). None of them seem too inspiring. They’re either the usual DevOps-y things, or those 200 slide performances with one word on each foul…that often amount to simply saying “try harder, this time.”

I’m trying to give this whole “platform engineering” thing open mind, but my brain is starting to fray like a person who’s been staring at Azathoth too long and can’t get those pipes out of my mind. We pile Confluence and, at best, CI/CD on-top of DevOps…and that’s it? Plus, here at Cloud Foundry Day I’m reminded of the trend that we’re ignoring a perfectly good, mature, proven, and useful PaaS in favor of building out a brand new stack from scratch on-top of Kubernetes is gnawing at my old man yells at cloud demons. I go back and forth on all of this a lot: it’s good because we incrementally improve and expand the original ideas, it’s bad because we incrementally forget and dispose of the past.

This seems to be what people want, what is. The rest of the industry seems to want to revisit the, meant as understandingly as possible, same old shit over and over, rebuilding from the start once again.

The effect was that of a Cyclopean city of no architecture known to man or to human imagination, with vast aggregations of night-black masonry embodying monstrous perversions of geometrical laws and attaining the most grotesque extremes of sinister bizarrerie. Here.

Perhaps the travel isn’t helping. (Or maybe there’s not enough of it!) Just like most everyone else in the tech world, we have dramatically smaller budgets for travel this year. So I’ve been traveling less which, I suppose, has forced that idea and experience on me. You don’t notice something until it changes, and all that.

And, indeed, once I get back from Cloud Foundry Day, I don’t have any work travel planned until August when I’ll be going to VMware Explore/SpringOne. There’s innumerable online things and projects, just not travel. (Of course, there’s family/vacation travel.)

We’ll see what that’s like!

Recommended theme song:

Dog walk through the park

Out on a dog walk on a recent evening, there were several things to see.

The homeless guy who lives in the parkwas sitting in his little area and there was a young guy sitting there with him. They were talking about something, smiling and laughing a lot.

On the bridge there was a girl and a guy fishing. She was sitting in a chair and the guy was leaned over the side of the bridge with a fishing pole, while the girl was tearing up something to throw in. I guess old bread to attract the fish.

Two kids, one wearing an Ajax shirt, running down the path kicking a ball.

A lady in a bikini sitting with her back to me and some little tiny tattoo at the top of her back, with what looked like an empty bottle of rosé. She also had a little bucket-hat on her picnic blanker that was black with white weed leaves on it.

A group of two old couples walking on the path, towards the bridge.

Two, possibly, teen love birds sitting on the swings in the playground, kind of gently swinging back-and-forth talking with each other.

Pockets

Upcoming

Talks I’ll be giving, things I’ll be doing, places I’ll be going.

June 21st Cloud Foundry Day, Heidelberg, speaking. June 21st Making digital transformation stick in government agencies, online. June 22nd to 23rd DevOpsDays Amsterdam June 28th, July 4th, July 11th Cloud Native for Financial Services talk series.August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 18th to 19th SHIFT in Zadar.

Logoff

See! It’s not all always computer-shit. If you get angsty while waiting for the next episode, check my blog for links, pictures, and occasional notes about what I’ve done that day.

Do you like words like: security - governance - PCI - regulation - SBOMs?! Then you should attend our talk series on cloud native app development in banks, insurance companies, and financial services. It’s online and, of course, free.

Relevant to your interests

• The Quest for Better, Faster Deals - The highest quality deals are driven by strategy and vision needs at the buyer, the lowest by regulation needs and projects done by external consultants. I don’t know what “high quality deal” means, but it must be good. The conclusion: you want to sell to the business.

• Reports Of OpenStack’s Death Greatly Exaggerated - Hmmm….I mean, I think it’s fairly exaggerated. the only market estimates (from the Flexera reports) show small share and y/y decline. But, there’s still a very active community/market in that slide of the cloud pie.

• AI And B2B Marketing — Three Opportunities And Challenges To Ponder - “Half my advertising spend is wasted; the trouble is, I don’t know which half; the trouble is I don’t know which half” is still the case after all these years: “most B2B organizations struggle to deliver basic content measurement and intelligence today — 47% of B2B organizations consider themselves beginners at tracking content impact metrics.”

• Go Faster, Break Less: DevOps Transformation at HSBC - “An interactive account of HSBC Technology’s DevSecOps transformation programme featuring David Keane, Global Head of DevSecOps Transformation. This talk will provide rich insight into transformation from concept through to operational delivery, revealing the real and ‘in the field’ impact for employees and HSBC customers.”

• 31 AI Prompts better than “Rewrite” - Prompts!

• GPT best practices - OpenAI API - more prompt writing tips.

• Mercedes-Benz’s Cloud Foundry (Tanzu Application Service) usage, from “Improving developer productivity with Platform as a Product,” June 9th, 2023 - “So what are we doing on a daily basis? We have multiple platforms running. We have platforms in our own Mercedes Data Center on-premise, and also on AWS. We have integration and production platforms on either environment. And to give you some numbers, we have around 300 application projects, 3,000 application instances, and around 1,500 platforms services, which we are providing at the moment and constantly growing. So what do we need to make all this happen? We need a great platform team. And of course, the ton of automation. So we are around eight people that’s not too much to operate all these applications and service instances.” –Roland Fetscher, Platform Architect, Mercedes-Benz AG

• What is platform engineering? - “Here are the key pillars of platform engineering, as I see it: Self-service; Platform operations; Platform as product.” And: “at CWT we created a series of DevOps services like a CI/CD pipeline, self-service performance testing, an image service for pre-approved, hardened images (consumable via source templates or the built images in a variety of formats), as well as a container service built on Kubernetes. Every time we got more than one product to adopt a service, that was proof we’d avoided duplication and created efficiency. The structure of the services also optimized for self-service, which accelerated developer velocity. With one of our DevOps services, we reduced the round-trip cycle for performance testing from 24 hours to a few minutes, as teams were based on opposite ends of the world. We also cut 30+ days off the release timeline for new applications and major releases.”

• What Is Platform Engineering, and What Does It Do? - Lori Perri at Gartner defines platform engineering (Oct 2022): “In short: Platform engineering implements reusable tools and self-service capabilities with automated infrastructure operations, improving the developer experience and productivity. This technology approach utilizes reusable configurable application components and services. The benefit to users is in standardized tools, components and automated processes.”

• Citi to cut 5K jobs citing tech initiatives - Not good for the pro-AI crowd. // ‘Citi’s technology transformation plans, which Mason said are in the execution stage, are driving efforts to reduce headcount…. Over time, “we will no longer need the same level of people that we have at this particular phase,” Mason said. “We’re reducing people even further … as we use that technology to automate a bunch of activities that we have to do manually today…. The bank is in the process of retiring legacy tech platforms. It’s also moving its wholesale credit risk platforms to a common underwriting process, and will no longer need thousands of people over time because of a standardized approach, Mason said.’

• Change Fatigue In Digital Transformation: Where Has All The Value Gone? - Ways to keep the digital transformation alive: Contextualize business outcomes; Share the effort; Share the value; Conduct holistic load management; Target smaller, more frequent wins; Have a playbook; If you can, adjust incentives.

• Change Management In Digital Transformation: There’s No Tunnel, There’s No Light - “21% of global services decision-makers supporting their organization’s digital transformation cited implementation of new processes and capabilities as one of their greatest challenges.” // …79% have more important problems, maybe even culture change totes chill.

• Singapore Bank DBS: A Blueprint For Digital Transformation In Finance - Nothing on how these changes were done, but a brief “what” of the strategy.

• Celebrity photographer Chris Floyd shares six pieces of career advice everyone can learn from - “I think that anything generic is fucked now. Anything where a client thinks: ‘We need a picture of a woman who is eating a salad’, say, or ‘laughing with a laptop’. If it’s not a specific person, it’s just a representation of an idea; they can just do that now in AI.”

• Billionaire’s Secret Buyout Formula: 110 Instructions and an Intelligence Test - Older piece, but a look at the general patern of PE firms buying tech companies to optimize and then draw out more revenue. The thing sort of glossed over is that you get a portfolo of these little companies to get cash to buy larger ones, pay off debt, and pay yourself. It’s like buying a bunch of dentists offices and bundling them together into one business.

Wastebook

With some selections from the day notes.

• Standard American expat requests for visitors from the States: Large bag of CostCo chocolate chips; Kraft brand mac and cheese (like 6 boxes?), just the regular macaroni one; CostCo bag of pecans.

• Booked my VMware Explore travel, to Las Vegas. I haven’t been there in a long time - four, five years? So many happy RedMonk memories from there. One of the best: that time James Governor lost his shit about the PDF standard at dinner with Mark Cathcart as a rando hanger-on.

• When I refer to analysts reports (Forrester, Gartner, IDC, 451 Reseach, etc., etc.) I reference the analyst shop as the author, e.g., “Gartner seems to be saying…” I feel bad each time I write this: there are actual people writing these reports. Sometimes I reference the people, especially in presentation footnotes. But, it’s a universal, industry style to just list the analyst shop name. In fact, when you get official permission from those shops to use their content (something you need to do when you’re a vendor, even if you’re quoting public material - I don’t know: it’s just the norms), they strip out the authors and just put the shop name. That tells you a lot about their business mode, style, and overall vibe.

• There’s always thing I should do, but few that I need to do.

Logoff