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.