Coté

Lessons learned from Cloud Foundry for the platform engineering community

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.

Midjourney: a mountain castle under attack from medieval soldiers and knights with siege equipment, detailed, wide angle, painting in the style of Bruegel the Elder.

Relative to your interests

Midjourney: a mountain castle under attack from medieval soldiers and knights with siege equipment, detailed, wide angle, painting in the style of Bruegel the Elder.

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.

How's DevOps been going?

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

Spot the Coté.

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.

Hold for laughter.

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

Ops-ROI-jesserobbins.png
Ye Olde Secret Sauce, 2007. (I think this sauce was more intended for tech startups more than century old banks.)

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:

About the Data: Forrester’s Developer Survey, 2022, was fielded in between February 2022 and May 2022. This online survey included 2,452 respondents in Canada, France, Germany, Italy, the UK, and the US.

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:

About the data: Forrester’s Modern Technology Operations Survey, 2022, was fielded in between April and June 2022. This online survey included 767 respondents in Australia, Canada, China, France, Germany, the UK, and the US from companies with six or more employees.

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.

If you read this far and either liked it or didn’t like it, you’ll probably enjoy subscribing to my newsletter. Its deploy frequency is “several times a week,” on average. There’s plenty of DevOps-y, cloud, Kubernetes, and other computer stuff. But there’s also IRL things, and plenty of links to all of the above. And, if you’re already subscribed, why not recommend the newsletter to your friends and enemies alike?

Midjourney: a large group of people and cute mythical creatures talking, very detailed with many objects, cartoon speaking bubbles, primary colors, in the style of Robert Crumb

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.

Link catsup

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.

    Q: What are the primary advantages of using open-source software in your organization? Please select all that apply. Base: All respondents. © 2023 S&P Global.

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!

possibly, love birds

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.

Catching up on the HOT links

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

Platform Engineering is just CI/CD infused with enterprise goop (jk...I think?)

Midjourney: a datacenter filled with clouds in the style of Pieter Bruegel the Elder.

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.

Midjourney: Room of computers that are made of pizza and beer. In the style of a Robert Crumb comic.

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.

Midjourney: a ball of tentacles flying in clouds, many tentacles wave about chaotically from all sides of the ball, HP Lovecraft vibe, in the style of Bruegel the Elder, dramatic

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):

pasted-image-0-2023-04-30T182736.471.png

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.)

If you’re into this kind of stuff (i.e., you’ve read this far), you’ll like my newsletter. It comes out a few times a week and usually has links on tech crap, IRL stuff, and my original content, be that stuff I’ve done elsewhere, or write-ups like the above.

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.

2023-06-13 day note

  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.

DevOps vs. Platform Engineering

Midjourney: a Soviet style poster with a software developer standing triumpantly on-top of a pile of software developers robots.

Names are magic

I don’t really know what I think about the idea and movement of “platform engineering.” It definitely has the feel of a market and category now. I reference it all the time, as do “us all” in the cloud native world. I suspect over the next year it’s the phrase everyone will be using for whatever it is exactly.

On the one hand, platform engineering an obvious, kind of goofy-rude hijacking of DevOps. In a sort of ideal world, it would all just be called “DevOps,” and we’d all be debating if a “DevOps engineer” includes managing the developer platform.

On the other hand, the overall community feels like it’s up to a lot of good. It’s certainly rallied a lot of new content, stories, concepts, and all the thought-leaders. The notion of pulling in IDPs and other developer tools is, I think, an addition to DevOps. But again: shouldn’t that just be an addition to, an evolution of, DevOps?

We have a good discussion of what exactly a “DevOps platform” is on this week’s Software Defined Talk, related to discussing the recent Gartner 2023 Magic Quadrant for DevOps platforms.

The names you give things are powerful, and accumulate a lot of meaning. Re-naming something is often required to evolve it, to sort of reboot everyone’s collective mindset to try again.

“We have three DevOps teams.”

“Cool, cool. How do developers get a development environment to start coding.”

“They open a ticket, of course. Wait. Was that a trick question?”

I’m beginning to think that platform engineering is a new take on DevOps where the community reverses the old DevOps principle that culture matters far more than tools.

In platform engineering (so far), tools matter a great deal. Practices are important (the community is close to subsuming the platform as a product notion). Culture is either assumed or not really in scope: there’s almost this feel of “oh, that’s DevOps' job…”

That’s kind of how DevOps played out at first. Automation, monitoring, then several years of surveys, PDFs, and conferences, and all the slowly-sudden: it’s all about the culture, tools don’t matter.

Agile software development was always about practices and, eventually, culture. The only tools required were unit testing frameworks and, if you were luxurious, backlog/project management tools like Pivotal Tracker and Rally for the SAFe-set.

Agile’s utter rejection of tools probably came as a reaction to the Rational era where tools were king. Rational tools embodied the process and practices. It was sort of impossible to do RUP without tools, especially the UML generators.

As with DevOps, platform engineering will learn soon enough that the people and processes are part of the platform as well: they’re as much a technology as the actual tools. Everyone knows this, of course, because of DevOps. But giving your tools and “culture” equal footing has proven hard to do over the decades. You tend to go way too far on one or the other.

Anyhow! You should check out my talk at PlatformCon! It’s posted now. I try to cover the evergreen practices and mindsets of doing platforms, whatever you want to call it.

These practices are based on years of experiences of platform teams in large, normal organizations like Mercedes, BT, The Home Depot, UBS, JP Morgan Chase, etc. And, the talk is a compact 15 minutes, which was a rewarding challenge.

There’s two other talks I recommend:

My content

Pan fried tofu recipe from Kenji’s wok book.

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.

Relevant to your interests

Logoff

See y’all next time!

You can't avoid lock-in

I have a new video, opining on multi-cloud and how Kubernetes might could help with fears of lock-in (a concept that I think is kind…basic?), check it out below:

Relevant to your interests

  • The Care and Feeding of Internal Developer Platforms - Five benefits of monitoring and managing internal developer platforms are noted: improved system performance, cost reduction, scalability, enhanced security, and improved feedback loops. Achieving these benefits entails securing deployment environments, establishing system baselines, setting up alerting rules, monitoring application performance, and automating processes.

  • Setting time on fire and the temptation of The Button - If you value writing by the time put into it (“thoughtfulness”), the AI stuff is going to mess with your judgements. // “Now consider all the other tasks where the final written output is important because it is a signal of the time spent on the task, and the thoughtfulness that went into it. Performance reviews. Strategic memos. College essays. Grant applications. Speeches. Comments on papers. And so much more.”

Wastebook

  • “months seem to fly by while hours and days can feel endless” Here.

  • “It feels like, just beneath the surface of our normal base reality, there is another layer of American culture. I’ll call it Barstool reality. It’s a place where niche Instagram personalities, OnlyFans models, college athletes, and that guy Hasbulla all intersect. Everyone has the sort of bad tan you get from spending too much time on a lake boat or the golf course or at a midwestern college football tailgate. The only food you ever see is fast food or big salads. Everything is written in a font that I can only describe as Mobile Game Sans. And no one ever blinks. This reality is always trying to figure out what the new drink of the summer is — it was White Claw, then it was ranch water, now it’s those big jugs of vodka and flavor packets, I think. That’s where this video is from. And every time a piece of content like this breaks containment everyone on Twitter loses their minds. But, honestly, all of the weirdly shiny and orange guys with zoomer middle parts wearing soft, over-sized T-shirts in these videos seem very at peace mindlessly jabbering about going to see Diplo at Red Rocks and I’m starting to think I would like to live in this world, as well.” Here.

Upcoming

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

June 9th PlatformCon, online. 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

Not much in the newsletter of late, huh? I’ve been doing a lot of other content. You can see some minor notes in the day notes posts on my blog.

Today I managed to get two videos out, which was rewarding. I have one queued up for tomorrow that’s testing a new format: just taking one figure, idea, or tiny thing and commenting on it. We’ll see if (1) I actually do, like, three, and, (2) if they’re interesting.

Are you a backpack only, or a carry on bag with wheels traveler?

Mostly links today. I’ve been traveling this week and preparing and bunch of stuff to publish in the future. Tragic for the desire to publish now, now, now…

How I Travel

Relative to your interests

  • Maximizing value, controlling cost with cloud FinOps - “Among current users, 56% report that spending on public cloud was significantly over budget (by 30% or more) or somewhat over (by 10%-30%) in 2022, compared with 45% of respondents saying the same in 2021. Multiple factors cause organizations to overshoot their budgets for public cloud services (see Figure 2). The need to scale up resources to address unexpected demand emerges as the chief culprit for cloud budget overruns (cited by 29% of respondents, up from 22% in 2021). Other factors include overcommitting to resources (16%), lack of governance/usage guardrails (14%) and lack of pricing transparency from the cloud providers (10%).”

  • Do You Shop Online? So Do Your B2B Buyers! - “75% of B2B buyers prefer a rep-free experience, and 68% made a recent significant purchase using digital commerce”

  • Planck’s principle - “A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it…”

  • Kubernetes flexes open-source muscle as it transforms enterprise IT - There’s a great description of what a cloud native environment is like in here. It’s missing the “middleware” and frameworks app developers would use, but I think that’s fine. It’s not to much covering what an appdev platform is.

  • Identity Crisis - A Tale of DevRel

  • Seth Godin on Marketing, Meaning, and the Bibs We Wear - Seth Godin begins many answers with asking the question “What is X?” Good for reframing the question, also buying time to think! Big on stories, of course. Whole Foods answer early on had core marketing strategies in it: “Since Amazon has taken it over, I think what we’ve seen is, they’re not exactly sure what they are measuring. Are they measuring convenience? Which is what Amazon wants to stand for. Or are they measuring uniqueness? Or are they measuring creating surprise and delight? They alternate between all four of those things.” Need to look up some of his talks to see what his technique again. He describes that at about 35:00.

  • Recent quarterly PE tech M&A activity way down: “The increased stress in the US financial system has made M&A way too stressful for a lot of private equity acquirers. Unsettling bank failures, nonstop rate hikes and the still-unresolved debt ceiling brinksmanship have all heaped additional uncertainty onto an already-troubled financing market. As a result, current spending on tech transactions by buyout shops is trending to its lowest level since the Great Financial Crisis.”

Brenon Daly at 451: “Overall, spending by sponsors in both April and May has plunged to only about $1 billion per month, down from an average of about $10 billion in the first three months of the year, according to the M&A KnowledgeBase.”

My content

I’ve been busy this week with the opaque media:

  • Fireside chat with the GM of my business unit at VMware, Purnima Padmanabhan, Senior Vice President & General Manager of VMware’s Modern Apps and Management business. See my remote recording studio above.

  • Cloud Native Security & Compliance, with David Zendzian - If you’re like me, you’re always wondering what exactly “security” means when it comes to cloud native apps - or just apps in general. Everyone is always freaking out about it in surveys and people are always like, “yeah, but is it secure?” I this interview with Cora Iberkleid and me, David Zendzian explains what all that actually means in very practical terms. We discuss regulations as well and how large, global organizations have unique challenges there. David is incredibly passionate and fun to talk with. You’ll like this episode.

  • We spent a lot of time talking about Salesforce on this week’s Software Defined Talk. I think it was…entertaining?…nonetheless. Every Salesforce is a Snowflake - The week we discuss Enterprise Software hiding data, corporate status reports and a quick update on New Relic. Plus, Coté records using an ironing board from a Renaissance Hotel in Brussels. Listen in!

Upcoming

Speaking at VMUG Belgium this week.

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

June 7th State of Kubernetes overview, online. June 8th to 9th PlatformCon, online. June 21st Cloud Foundry Day, Heidelberg, speaking. June 21st Making digital transformation stick in government agencies, online. June 22nd to 23rd DevOpsDays Amsterdam 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 playing around with “day notes” on my blog. They’re like week notes. Except…you know..day notes. I (re-)noticed Dave Briggs doing them, and they’re delightful to read. I subscribe to about five or so of the week notes blogs. They’re, oddly, mostly UK people. Also, Warren Ellis does a form of it on his blog that’s relaxing to read. So, if you’re starved for true microscopic details, there’s now some more available in the world.

@cote@hachyderm.io, @cote@cote.io, @cote, https://proven.lol/a60da7, @cote@social.lol