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

Just when you thought (perhaps, hoped) we finally had an understanding of what “platform engineering” is, Gartner and Forrester came out with a Magic Quadrant and a Wave that re-confuses the category.  Or, if you like, helps bring more clarity to the category! Perhaps just a sub-set of it. Let’s find out.

The PDFs reduce it down to CI/CD…mostly…with some optional metrics and IDP seasoning thrown in to varying degrees by each firm.

Or maybe they’re just describing a subset of platform engineering. Or nothing about platform engineering. You see: re-confusination.

I’m projecting the a framing onto these two PDFs that kind of aren’t totally there. I don’t think they actually care too much about staking out a position on defining platform engineering. I think each analyst shop has other PDFs that do that.

Let’s, then, look at my pleasent confusion and use it as a sort of critique of the whole, you know, deal with platform engineering as of  [checks calendar] June 15th, 2023, [checks watch] 9:52am Amsterdam time.

(Oh, and before we start: I work at VMware. We work a lot in this space and some of our products are included in each report. So, like - I don’t know -: figure out if you care about that bias. Moving on.)

PDFs define markets

Both reports are defining a newish category that’s related to most everything about custom software except for the actual programming, but also not about the infrastructure that apps run on or how the apps are managed in production (except for one, weird part, that we’ll get to). The Gartner one is more about defining a new category, the Forrester category already exists in their neck of the woods.

A Magic Quadrant and to a lesser, but still import extent, Forrester Wave feed into both (1) how vendors (and when I say “vendor,” I mean public cloud providers too - I can’t go around using a phrase like “vendor and public cloud providers” all the time - I need space for all these parentheticals) build their products, and, (2) how buyers (“enterprises”) think about their strategies, architectures, and building/buying decisions.

That is: these PDFs are important.

The next 12 months of “cloud native” strategy planning, enterprise sales, PoCs, etc. will include these two PDFs  (and many others! Along with endless blog posts and videos - maybe even screenshots of thought leaders in Twitter and Mastodon [maybe Bluesky - I think that community I much less interested in the enterprise app stack world than, say, well…you know]) as people try to figure out making Kubernetes more usable by app developers, or just hidden from them. That’s why Red Hat and GitLab licensed the PDFs!

The Stacks

These reports describe a stack that comprises a huge part of what most notions of “platform engineering” seem to be. Let’s look at them.

The Names

Gartner calls this the “DevOps Platform” (queue the grey beards who threw a shit-fit about “bi-modal IT” seven years ago to see a fun show! But will it be in Mastodon or Bluesky this time? I mean, no one reads blogs anymore, right?).

Forrester calls it an “Integrated Software Delivery Platforms” (does an “ISDP” include an IDP? idk - but, imho, idt).

What’s in the stacks

Each describes a stack of what DevOps tooling has come to mean in practice: the CI/CD pipeline and all the associated goop. (Please, don’t bimodal-IT me - I know, I know: CALMS [I still maintain it should have been CLAMS, why so serious and all that], DORA, “do the DevOps,” burn out, cool hair colors, systems thinking, sociotechnical systems, blameless postmortems, occasionally observability, jokes about pagers, culture…and all that.).

Said goop in enterprises mostly means compliance and security controls. That’s right: “CIS, NIST, FedRAMP, PCI-DSS, HIPAA, CSA, etc., etc. and so forth”.

Gartner treats platform engineer as a subset of its DevOps Platform category, listing platform engineering as one of the “multiple use cases” for the DevOps Platform category. They define platform engineering as “provid[ing] self-service, internal developer platforms [IDPs] to scale DevOps and software engineering practices.”

Let’s look at the definitions of the stacks.

Gartner’s DevOps Platform

Gartner defines it’s DevOps Platform category as:

Gartner defines DevOps platforms as those that provide fully integrated capabilities to enable continuous delivery of software using Agile and DevOps practices. These capabilities run the gamut of the software development life cycle (SDLC) and include product planning, version control, continuous integration, test automation, continuous deployment, release orchestration, automating security and compliance policies, monitoring, and observability. DevOps platforms support team collaboration, secure software development and measurement of software delivery metrics.

CI/CD, developer/project websites (you know, Backstage), and metrics.

Things get a little crazy in Gartner’s definition when they throw in monitoring and observability. So, like, Datadog, Aria, and Honeycomb and them? No, them’s not in there. However, those two phrases aren’t actually mentioned much in the PDF: monitoring just three times outside of the initial definition, and observability just twice. So, I’d sort of cast the whole monitoring and observability off as fun flourish.

Here’s a good overview of the why/what from a outcomes perspective:

DevOps platforms support multiple use cases, including, but not limited to:

• Agile software delivery — operationalize Agile development practices

• Mobile app delivery — build/test/deliver native mobile and mobile web applications

• Edge computing scenarios — support for secure delivery/update for IoT/edge devices

• Regulatory requirements — support for compliance, auditing, traceability and governance

• Cloud-native application delivery — build and deliver cloud-native applications across hybrid and multicloud environments

• Platform engineering — provide self-service, internal developer platforms to scale DevOps and software engineering practices

Gartner’s write-up of GitLab gives you a good taste of what they mean by DevOps Platform as well:

GitLab is a Leader in this Magic Quadrant. Its DevOps platform is a single product that includes capabilities for planning, source code management, continuous integration, deployment automation, observability, application security testing, software supply chain security, compliance reporting, value stream analytics and incident management.

That’s actually pretty good, except for the inclusion of “observability” (see above).

Forrester’s Integrated Software Delivery Platform

Forrester’s ISDP definition from 2022:

Integrated software delivery platforms enable an automated software delivery process from code build to code release, linking together discrete automation capabilities into a unified and open platform that provides APIs and other integration options. They enable users to customize the platform to suit their unique needs by combining capabilities of the platform with custom or third-party tools.

These platforms differ from standalone, best-of-breed tools in that they provide an out-of-the-box integration across a core segment of the software delivery process. They differ from legacy, end-to-end software development lifecycle (SDLC) tools by offering open platforms that anticipate their users augmenting the solution with third-party tools such as security scanning or impact analytics, enabling users to create a modern tool chain where new capabilities can more easily be added or replace existing capabilities as needed.

Forrester’s ISDP rating criteria is helpful too. In addition to the soft criteria (“vision,” “strategy,” “pricing flexibility and transparency” and the like), the tech capabilities criteria are:

1. Platform capabilities (but, not, like managing Kubernetes…I think?).

2. CI/CD capabilities (this is the most important criteria for them, with an evaluation weighting of 25% versus either 5% or 10% for all the others, aside from “platform capabilities,” which is 20%)

3. Development, security, and operations (mmm…getting a little broad).

4. Extensibility (can mix and match, modify how it works, etc.)

5. Governance and compliance (“enterprise goop”).

6. Infrastructure management (see “platform capabilities parenthetical above).

7. Product support (i.e., not just some project on GitHub that your developers found and are now running in production).

8. Support for test automation.

Metrics Sidebar

Both of these PDFs are interested in metrics, but Gartner much more so. These are primarily the DORA Four-a, maybe some golden SRE ones here and there, and whatever else.

This is understandable given that the four metrics are the benchmark for DevOps goodness, ROI business cases, and, generally, showing that you’ve done a good job on your digital transformation imperatives, pillars, strategy, OKRs, MBOs and KPIs when it comes time for annual reviews and budgeting. Plus, you know, actually running the business.

But, I don’t know.

Metrics are important, but they’re extremely difficult to collect. For one, even five apps, sure. You can kind of just get those word-of-mouth. But once you get to the low hundreds, and especially few thousands of apps across an enterprise, collecting the metrics is difficult and making the metrics consistent enough to compare them apples-to-apples is downright impossible. (Maybe Planview/Tasktop would beg to differ - they’ve heavily invested in enterprise metrics goop for 16 years.)

So much so, that you start to wonder how the respondents to the DevOps surveys figured out what to say. (I was not trained to science the shit out of anything [feel free to ask me about the flaws in most philosophy, minus that eye-rolling period between, say, 300 AD up until Nietzsche finally rescued philosophy from absolutely boring-ass proofs of why God exists] so I don’t know what I’m talking about here with respect to surveys.)

Don’t get me wrong: metrics are important, but it’s asking a lot of this category to support them. “DevOps Metrics” deserves to be its own category (holy shit, the bi-modal shit-fitters would just 🤯 over that one, right?). In theory, if you had everyone in your BigCo actually using the same build pipeline, following the same enterprise architecture and governance, put in place something like Planview/TaskTop, and got apples-to-apples-ized prod data…yeah? An that might be just the aspiration here.

Kubernetes Korner

There’s an interesting feels about Kubernetes in each. Forrester only mentions Kubernetes three times (support is in the roadmap for one vendor, and one vendor [disclaimer: my work] is dinged because “platform support seemed limited to Kubernetes workloads”). Gartner, however, is all over the Kubes.

I think both would agree that their platform do not include managing Kubernetes. Even though the platform they evaluate may do exactly that, those capabilities are another part of those stacks.

This is the most important thing when contemplating how these PDFs fit into platform engineering. Sometime soon the platform engineering community needs to decide if managing Kubernetes is part of their scope, or not. I think the answer should be: no, we don’t want nuthin’ to do with that.

Single-source versus Best of Breed

Forrester hits on what’s the, like, existential dilemma of these two categories, I think: build versus buy. Both reports discuss this, but Forrester is much more interested in this idea (rightly so). Based on their conversations with IT leaders:

while these ISDP tools hold great potential for a complete end-to-end toolchain, many individual capabilities fell short of enterprise needs, forcing these leaders to source those capabilities from separate best-of-breed vendors.

Our reference customer survey backs this up by indicating that enterprises are using (on average) only 53% of the capabilities they are paying for, with the remaining capabilities either being delivered by a separate vendor or simply not used. This means that ISDP vendors are not only competing with each other but also competing with the best-of-breeds. ISDP vendors recognize these challenges and are responding with a number of innovative solutions that will make them more attractive than a traditional DIY toolchain but open and extensible enough that end users can add the tools they want without sacrificing capability. The challenge is striking the right balance to create overall value.

This is what’s going on with all of this: do you buy one, integrated stack from a vendor, or assemble it yourself from parts?

There’s probably (I’d hope!) a companion piece from another part of Gartner, the former Burton Group, uh…group (apologies, I forget what they’re called just now: GTP?) that goes over how you’d build your own platforms and how to figure out if that’s a good idea or not. The parts of Forrester and Gartner that make the PDFs we’re looking at are interested in rating things you can buy, not things you can build.

Now, I mostly hate to believe this, but I think you have to go with the idea that people are going to build their own stacks. And by “people,” I mean application developers. They’re going to first assemble stuff from free (read: open source) components or already paid for (read: they don’t need to open a ticket to get access, let alone figure out how procurement works) cloud services. The app developers will get bored after a year (less, even), and frustrated when they have to deal with the above mentioned enterprise goop. Then they’ll hand it off to an infrastructure group (the one who stood up Kubernetes and figured out reining in YOLO public cloud usage across the enterprise). To which the infrastructure people will be like, and I quote, “whaaaaaaat da fuck?…,” let out a big sigh, mutter something like “FML,” and then call up all us vendors (maybe some outsourcers if there’s an existing, multi-year contract in place), and be like “got a mop for this?” And us vendors reply “Golly-Wow! That’s a new one!” and tag that account as “highly qualified.” The infrastructure people get good lunches for the next three months. (Pro-tip: look-up when your vendors quarters end, especially Q4.)

…I mean: right?

Related to that: there’s an implied notion as well in the vendor selection and discussion: if you choose one of the public clouds (AWS, Azure, Google), does their big ol’ portfolio of cloud stuff include these capabilities, and integrate together enough to be good?

A welcome addition to to definitional stew - it’s tasty!

Much like those bespoke platforms application developers build, I think of the platform engineering category as a ball of tentacles that’s flailing about, slowly collating into a solid core.

And, I haven’t even started to look through this year’s PlatformCon videos to smell out the new tentacles yet!

Listen, I like these PDFs.  If you asked me if I like analyst PDFs I’d be like, “I used to be an analyst and do M&A. I like PDFs. That’s what I do. That’s what I live for.”

They define a good grouping of tools that most every shop doing custom software will be doing, or already does - aside from that observablity and monitoring part: ¯_(ツ)_/. The ideas in the reports are valuable to contemplate when trying to sort out what platform engineering is. I’m pretty sure those ideas are part of DevOps too - one of the reports is even called the DevOps Platform. I’d say they’re defining a subset of “platform engineering.”

Here’s how the CNCF defines a (cloud native) platform, which I think is pretty damn good, the best we have so far (that pastel palette is questionable…but that’s just, like, my opinion, man):

You can see that what’s in these PDFs fits mostly on the right side, of the middle part, of the burger. Gartner is more into container registries than Forrester is - I suspect any platform definition will need to include image/container registries going forward.

It’s clear that there’s a lot of definitional work ahead of “platform engineering,” probably for the next year or two. I think it’s inescapably tied to Kubernetes. We used to know what a platform was and we have great, proven ones. Now that we’ve emerging out of the Container Wars with Kubernetes as the agreed on winner, it’s time to climb back up the stack and help application developers.

These two PDFs loosen that tie to Kubernetes which is important to pay attention to when it comes to defining platform engineering. And, I agree with them! Platform engineering probably needs to have little care about Kubernetes, just like the culture-faction of DevOps has little care about Kubernetes as it has with whatever other infrastructure has been in the rotating cloud door since ~2007.

My prediction is that “platform engineering” is going to come to mean “DevOps tools and culture/practices + IDPs + being able to deploy to Kubernetes.” Managing and care and feeding of Kubernetes will rest with either the public cloud providers or Infrastructure groups. Let’s hope at least. We’ll see!

(And, if you can’t get enough of this, we discussed the Gartner MQ more last week in our Software Defined Talk episode.)

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

I’ve been neglecting the newsletter of late, but here we are! I’ve got many links stored up, and some little notes. In the meantime, and while it’s also getting some neglect, you can follow my blog for links, pictures, and day notes. As noted in the Upcoming section, I’ll be at Cloud Foundry Day next week. It’ll be fun to see that group. I’ll re-highlight this in a newsletter tomorrow - or whenever the next one is - but check out this interview with Cloud Foundry Ram.

1. What is the deal with Disney live action kid shows? Do they have a team that makes sure they all have the same…vibe? It’s so weird. (This Jessie show is ok. Not sure about the handsy ten year old: Jessie: “Do you have an off switch?” Handy ten year old: “yup. Do you wanna try and find it?!")
2. I asked Ram about Cloud Foundry a lot today. I’m still not sure what I think about Kubernetes being “the future” when there’s so much work to do to make it easy to use.
3. Related: “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.”
4. Amazing.
5. I’ve been using ChatGPT for recipes. It’s great for asking questions like “what kind of sauce for fried tofu can I make out of sesame oil, mirin, and soy sauce.” The pointing being: I know those ingredients make a simple sauce, but I have no idea what the ratios are. Lentils are another one.
6. Nerds look down on marketing, but it’s a complex skill and craft that depends on as much structure, engineering, luck, and banging your head against a wall as programming.