Searching for Cheap Tricks

The amount of AI content and conversations out there is getting exhausting. It’s almost as bad as the burbling font of platform engineering content that gets rewritten and published each week. The below RAND paper and commentary got me thinking though: a lot of the AI talk is just talk about applying new technologies in general.

We are still really bad at the basic task of communicating requirements to developers, checking in on their work and seeing if they’re solving the right problems in a helpful way…and even knowing what business problems to need attention in the first place.

Here’s an email I wrote to a friend on this:

Re: my prodding to figure out cheap tricks for getting organizations to improve how they use computers, this paper has a few theories of why AI projects fail. I feel like you could do a search and replace for "AI projects" to just "IT project" and the same could be said. The core, non technical problem is two sided:

(1) getting non-technical leadership to understand what AI can do, how much effort it takes to do the work, and most importantly how to properly set the requirements: making sure you solve the right problem in the right way. This last part is the mystic "understand what you're doing, the point of it, the why's of your business." Like we were talking about last night in the backstreets of Antwerp, my theory here is that if you asked most people in a business "how does the business operate and function each day?" they would have poor answers, let alone answers that an AI could do anything with, or that programmers could do anything with.

(2) the technical people are unable to "speak the language of business" and get the people in #1 to "speak the language of IT." I'm sure this is a lack of communication, facilitation, and interpersonal skills ("managing upwards"), but it probably results in the tech people not pushing back enough and drilling down to get the non-tech people to be helpful. This is the pesky thing of consultants always saying "before we talk solutions and projects, let's take a step back and examine what you really want." People are eager to fix/improve the problems, and don't often question if they're solving the right problem, nor understand the tools available to solve it. (Including the tool of continuous learning which would say "we have to use a tight-feedback loop to learn how to solve the problem).

It all amounts to introducing an ongoing "culture" of finding and understanding the problems you're solving, and a similar process of "leadership" frequently checking in to see if the tech people are getting closer to solving a useful problem, or if they're straying away from the original requirements.

One of original goal of agile software development was to address these problems: “business IT alignment” as we sometimes called in the 2000s.” On the one end, Extreme Programming had a concise, clear cookbook to follow. I like these prescriptive, “do this” approach to corporate improvement. They’re a collection of “cheap tricks” you can start applying.

However, the “fix” is to change the mindset of the company, from management to worker, to always be curious and on the hunt for how to do things better, “continuous improvement.” There isn’t always a way to do things better, and you also have to spend most of your time actually doing things.

But, there’s at least two things that most organizations could be better at:

1. Understanding what they do, the job to to be done, and how their organization does that - I have a feeling that if you asked most people, tops to bottom, at an organization “how do things really work around here?” you’d get mixed results, most of them only part of the overall picture. Can you draw out and end-to-end flow of all the activities it takes to deliver the product or service to the customer?

2. Spotting when to experiment with changes. This is applying Toyota kata and all that. The mystic version of “continuous learning” is that you’re always on the lookout for learning and improvement. But, you also have to actually do the work. You have to check out people at the grocery store, put the Fedex letter into a person’s hands, send out a plumber at the right time to the right place to unclog a sink (and then they need to unclog it), transfer money between two accounts, etc. When is it OK to stop “doing things” and work on improving things? That’s a very hard “stop the line” call to make.

I want to find a way to combine the mystic management mind-games of most corporate improvement and transformation talk with “cheap tricks” that get people to start improving and keep improving.1 This is something like “the habit of building habits.” It’s all well and good to talk about “habit stacking” and tell people that they need to establish new habits and routines. Yes, but how do I start the habit of starting habits?

Once the people in an organization have gone through the mystic experience of asking “why” or even discovering their customer’s milkshakes, what are the daily tasks and routines they do? What tools do they use? How do they actually do the work? What are the cheap tricks they can start using to be better?

Relative to your interests

• Moonbound Revisited - “Several decades ago, the semiotician A. J. Greimas claimed that all stories are comprised of six actants, in three pairs: Subject/Object; Sender/Receiver; Helper/Opponent.”

• The Forgotten Surrealist Painter Who ‘Didn’t Have Time to Be Anyone’s Muse’ - “In contrast to the tendency of Surrealism’s male artists to depict women as thin, young, fragmented, static, and perpetually naked muses, Carrington’s women fell across a spectrum: often very old, powerful and threatening, in a state of action and transformation.”

• How Platform Engineering Enables the 10,000-Dev Workforce - Vendor survey overview.

• How the buildings you occupy might be affecting your brain - “Could bad architecture also be contributing to the development of neurodegenerative and psychiatric disorders?”

• Is AI a Silver Bullet? - “This is the trade off we have seen before: eliminating the accidental complexity of authoring code has less value than we think because code spends most of its time in maintenance, so the maintainability of the code is more important than the speed to author it.”

• The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI, RAND paper - As ever, communicating the requirements and the problem to be solved to IT is difficult and often results in solving the wrong problem, at least in the right way: “In failed projects, either the business leadership does not make them- selves available to discuss whether the choices made by the technical team align with their intent, or they do not realize that the metrics measuring the success of the AI model do not truly represent the metrics of success for its intended purpose. For example, business leaders may say that they need an ML algorithm that tells them the price to set for a product–but what they actually need is the price that gives them the greatest profit margin instead of the price that sells the most items. The data science team lacks this business context and therefore might make the wrong assumptions. These kinds of errors often become obvious only after the data science team delivers a completed AI model and attempts to integrate it into day-to-day business operations.”

• Why “AI” projects fail - “And we’ve been doing this for decades now, with every new technology we spend a lot of money to get a lot of bloody noses for way too little outcome. Because we keep not looking at actual, real problems in front of us – that the people affected by them probably can tell you at least a significant part of the solution to. No we want a magic tool to make the problem disappear. Which is a significantly different thing than solving it. Because actually solving a problem includes first fully understanding the reasons for the existence of the problem, reasons that often come back to an organizations’ structure, their – sometimes inconsistent – goals and their social structure in addition to actual technical issues.” And: “AI is so good at writing summaries of all the meetings I can then have summarized afterwards to understand what was going on” says that your organization has probably too many meetings that are not structured well and that you don’t think that understanding why people say a thing, how they present their case is important (which makes you a bad manager).”

Per Request

Wastebook

• “Progressive doomerism.” Here, but, interestingly it was my perplexity.ai summarizer that came up with that phrase which did not exist in the article.

• “I want to stay little like this. I don’t want to get bigger.” My four year old.

• “Dystopian hod-rod races.” Apple Music summary of Liquor in the Front.

• Similar to “resume-driven development”: “Given the demand for new AI projects, interviewees reported prioritizing projects that grab headlines, improve reputation, and increase institutional prestige. We refer to this as activity prestige, which is the amount of positive attention given to some projects based on the public demand for those projects' outcomes.” Here.

Logoff

I’m in Antwerp for DevOpsDays Antwerp. This is the 15th year anniversary of DevOpsDays, so I wanted to attend. I’m lucky that they accepted a five minute talk from me as well. In the talk, I’m trying to answer the question “has DevOps made things better?” I do that by looking at changes in the DORA clusters, but more importantly, changes in how those clusters are made (thanks to some help from Steve Fenton and Nathen Harvey understanding how that is all done and, thus, a more accurate y/y analysis).

And, then, of course, I give some advice on what the DevOps community should focus on now. These are just two points I talk about a lot here: (1) make sure you actually have build automation in place, because it seems like many people don’t, and, (2) stop building new platforms and just use pre-built ones. If there was a third common theme for me, it’d probably be something like “start the practice of product management” this despite how difficult, even impossible, that seems.

//

There are two Brueghels in Antwerp, at the Museum Mayer van den Bergh. First, it’s a great museum if you’re into Flemish and Dutch golden age paintings. The building itself is a nice Netherlands canal house style building. The two paintings are Mad Meg and Twelve Proverbs.2 Here is Mad Meg:

Seeing pictures like these is much different in real life than online or even in books. It’s not that much different so as to be divine or anything: you just see some new things like textures and your field of vision either gets bigger or smaller. For example, with Mad Meg, you can really get in there and study the countless micro-scenes. In contrast, with Twelve Proverbs, you can see how basic and simple the pictures are; unlike the Brueghels most everyone knows, these pictures are not chaotic and “alive.”

Anyhow.

If you like that kind of thing, you should check out on of my favorite books, Short Life in a Strange World. If that book is a good fit for you, while it’s a bit mystic, it’ll help you enjoy “art” in new ways. If you just want the cheap tricks, check out the equally good Art as Therapy.

Just links and fun finds.

Relevant to your interests

I didn’t do link round-ups this past week, so there’s a backlog. Also, I’ve been using Perplexity to summarize some articles (not listed here, usually). I think it’s pretty good, and I recommend you use it.

• Amazon’s CEO says their AI tool has saved them a crazy amount of time - This oddly specific, and a big deal if applicable to other organizations. // ‘The average time to upgrade an application to Java 17 plummeted from what’s typically 50 developer-days to just a few hours," he wrote. “We estimate this has saved us the equivalent of 4,500 developer-years of work (yes, that number is crazy but, real).” The AI is not only fast but seems pretty accurate, too, according to his post. Amazon developers shipped 79% of the AI-generated code reviews without any additional changes, Jassy wrote.’

• How Lidl accidentally took on the big guns of cloud computing - A sort of community cloud for Germany and Austria? // “Its IT unit, Schwarz Digits — which became a standalone operating division in 2023 — has signed up clients including Germany’s biggest software group SAP, the country’s most successful football club Bayern Munich and the port of Hamburg. Last year, the unit generated €1.9bn in annual sales and it employs 7,500 staff.”

• 3 ways CIOs can turn strategy into execution - “Less than half of enterprises reach the majority of the strategic goals IT leaders set out to achieve, according to Gartner research.”

• How Platform Engineering Enables the 10,000-Dev Workforce - “60% of companies in the survey said they are releasing code on only a monthly or quarterly basis”

• Does Market Share Still Matter? - "we find that the positive relationship between market share and profitability generally still holds, but that it weakens with greater digital transformation. This means that market share increases translate into lower profitability gains for highly digitalized compared to less-digitalized companies. Additionally, it implies that digital transformation benefits smaller firms in particular because it leads to greater relative profitability gains for them compared to larger firms by removing some of the limitations that traditionally hindered them from becoming more profitable.” // “This means that the more digitalized a company becomes, the less upper management should rely on and prioritize market share to grow profitability. And the smaller a company is, the more it should prioritize digital transformation to boost profitability.” // See also the original paper.

• Dell’s AI Server Business Now Bigger Than VMware Used To Be - Maybe private AI will really be a thing: ‘“We are still in the early innings, and our AI opportunity with tier 2 CSPs, enterprise, and emerging sovereign customers is immense,” Jeff Clarke, Dell’s chief operating officer, explained on the call with Wall Street analysts. “Our view is supported by an AI hardware and services TAM of $174 billion, up from $152 billion, growing at a 22 percent CAGR over the next few years. We are competing in all of the big AI deals and are winning significant deployments at scale.”’ And: more analysis of Dell’s numbers.

• analyze_interviewer_techniques - “You are a hyper-intelligent AI system with a 4,312 IQ. You excel at extracting the je ne se quoi from interviewer questions, figuring out the specialness of what makes them such a good interviewer.” And, an example of it in action with a Tyler Cowen interview. Great looking stuff!

• Broadcom has brought VMware down to earth and that’s welcome - ”I left VMware Explore feeling that Broadcom has brought VMware down to earth and that’s a good thing, and that some of the complaints about the current state of VMware are a very natural struggle to cope with sudden and significant change.” // Great example of what a column on covering a tech conference should look like.

• VMware Tanzu Platform 10: Unified cloud app development simplified - ‘"With Tanzu platform 10, we have a unified single console to manage your applications, look at your CVEs, security governance, compliance,” she stated. “There are three main messages. Keep it very simple for the developer, never expose YAML files, configuration files and lower level configs. Number two, make sure that the deployment is dynamic and it automatically adjusts to the app needs. Then the third one is you want to do continuous update, repair and continuous security.”’

• A Java Language Cumulative Feature Rollup - ‘I found myself asking myself the question, “What’s every new feature Java has introduced since the last time I really cared about new Java language features?”, and didn’t find an easy answer via Google. So, I decided to create that list.’

• Is Your Organizational Transformation Veering Off Course? - “The research highlights that shifts in emotional energy, such as increased frustration or anxiety, can signal that a transformation is off track. Addressing these emotional shifts can help prevent derailment.”

• Being quietly radicalized by being on holiday - Pretty accurate view of the European lifestyle. “Enjoying life” is part of the ROI analysis.

Wastebook

• “There’s a fox a chicken and a bag of grain and now we want an ice cream so you go first and take the fox then leave the chicken but swap them with a soft-serve in a cornet with a flake.”

• And, the title itself: “Beaches are for people who enjoy the bureaucracy of going to the beach.”

• A very elegant tourist trap.

• If a PowerPoint joke is worth doing, it’s worth doing right.

• “Tip Jar Culture” and the “Tip Jar Economy.”

• If you find yourself tsk’ing at something, that’s a good indication that it’s something you should not care about. A tsk is a second arrow.

• Interacting with AI is like slot machines: you win just enough times to make you pull the lever again.

Logoff

As mentioned above, I’ve been really liking Perplexity. I use it for summarizing articles, but it’s also really good at what we now call “search.” Either asking quick questions that I’d other wise google-hunt for, like how to do things in apps. You know “google-hunt”’ing: you search for something in Google and spend time sorting all the crap and RTFM jerk’s answers to find a simple answer. Not with Perplexity! Sure, it takes longer than that “instant” Google search, but you save time on the second part of a Google search: filtering out all the bullshit. Plus, you can narrow down and integrate Perplexity more.

The Collections functionality is a different approach on making GPTs. You setup a persistent prompt that’s used in each new chat in the collection. So, for example, I have a collection that’s called “tl;dr,” and I have a “summarize this for me…” style prompt. So, each time I start a new chat in that Collection, it uses that prompt.

I need to experiment with using it for non-search chats, like playing D&D. I’m not sure it’ll be good at that kind of inward looking, hangout with the AI thing like ChatGPT is. On the other hand, I bet it’d be a good therapy-bot because it can go and search for things to add context.

Theory: that’s something that makes Perplexity good: Context. It can use Context (somehow) to weed out all that RTFM jerk stuff (this is sort of anti-Context - the people writing that stuff are operating in a different context than you are), and because it can search the live web (right?) it can add in relevant context to whatever you’re discussing with it.

Anyhow, you should use it!

I signed up for the annual plan. Sure, ChatGPT says they have search coming out, but (1) I don’t believe them, they announce all sorts of things and then trickle them out over the next year, if at all, and, (2) Perplexity is great!

//

School starts next week, so Kim and I are on one last, just-us weekend trip thanks to my mom’s annual, summer visit.

Normally I wouldn’t disclaim this since I think you, dear readers, are wise enough to know that it always applies, but: these views are my own, not my employer, VMware Tanzu by Broadcom. Also, we covered the below on this week’s Software Defined Talk. If you prefer to listen a podcast, it’ll be out on Friday morning, 7:30am Amsterdam time: subscribe!

Private Cloud

Yesterday at my work’s big conference, Explore, there was a lot of conversation about private cloud. It’s pretty straightforward and clear: VMware is your enterprise private cloud platform. From Hock Tan, Broadcom CEO:

“Public Cloud is much more expensive, more so than you ever expected. Complexity – another platform means another extra layer for you to manage. And compliance; you have regulatory policy requirements. It’s more complex, it’s more expensive and compliance is hard,” Tan told attendees. He said many CIOs are now moving their workloads back on-premises to deal with these three Cs, which represents a huge change, but also a huge opportunity. “Here’s my view,” Hock said. “The future of the enterprise is private. Private cloud, private AI fueled by your own private data. It’s about staying on-premises and in control. Of course, you’ll continue using the public cloud for elastic demand and bursting workloads, but in this hybrid world, the private cloud is now the platform to drive your business and your innovation, and we have work to do to make that happen.”

In round-table commentary, analyst Dave Vellante adds in the “AWS of the private cloud” angle. Commenting on the analyst day discussion with Hock Tan, Dave says:

I mean, he said in the keynote today, you basically get AWS on-prem. In the analyst briefing he said, okay we’re gonna to take 30, the top 30 services in the in AWS and we’re going to replicate those. We’re not going to do 300. But we’re going to basically create a substantially equivalent on-prem experience to the public cloud. And that’s their entire strategy. And you know I think if to the extent that they do invest in that road map people are going to stay with it why would you rip and replace VMware all?

Figuring out how many workloads are in private cloud versus public cloud is one of my ongoing side-projects. It’s not as easy as you’d think! Estimates are all over the map. 50/50 is probably a good estimate based on analysts, surveys, and other estimates I’ve seen in recent years. If you like something lower, Daniel Newman of The Six Five/Futurum estimates that only about 20% to 30% of workloads ever migrated to public cloud in the first place.

It’s also hard to find numbers around how many workloads are moving back to on-premises from public cloud, “repatriation” they call it. VMware sponsored an IDC white paper that pulls from IDC cloud surveys, saying this:

Two-fifths of respondents to IDC’s recent U.S. Cloud Migration Survey indicated that they performed or initiated repatriation of workloads from public cloud to dedicated environments in 2023, and 42% said they plan to repatriate some workloads in 2024. Security, data privacy, cost management, and performance are the top reasons companies engage in repatriation activities.”

IDC ROI PDF sponsored by VMware, August, 2024.

Here’s a similar data point from Forrester in 2023:

According to Forrester’s Infrastructure Cloud Survey in 2023, 79% of roughly 1,300 enterprise cloud decision-makers surveyed said their firms are implementing internal private clouds.

Here’s a very DevOps-y idea discussed in another Explore interview: most enterprise IT departments are run very inefficiently, “culture” and organization wise. There are silos for everything, and they are “best of breed,” which actually means the downside of locally optimized: different groups use different tools, you have lots of wait between handoffs, turf wars - all of the things people don’t like about large bureaucracy. The suggestion being that if they focused on organizing better, and consolidation, they’d get the gains that public cloud gives them. After all, that bureaucracy optimization is a side-effect of using public cloud: you no longer have such a large, bespoke IT department. You just have one of the public clouds and how they do things, take it or leave it.

Tanzu Platform 10 - Cloud Foundry and Kubernetes In One Runtime

I work in the Tanzu division, so I’m interested in what’s going on there. Here’s the big wrap-up post of everything.

Here’s my take on Tanzu.

Our main thing is this: the Tanzu Platform is an enterprise-grade PaaS. The primary focus is on private PaaSes (see above!). This can mean running on-premises, or running it in the public cloud with control over your own, single-tenant PaaS in public cloud.

People don't really say "PaaS" anymore, which I think is weird. They say "platform," so I'll use that word here.

The Tanzu Platform1 is composed of two approaches to building a platform:

1. Tanzu Platform for Cloud Foundry2 - a platform with a completely pre-built, turn key PaaS. This is Cloud Foundry, used by many large enterprises, supporting thousands of applications. In this case, you don't build the platform, but you can customize it here and there and add in services (“middleware”) that you need. You trade the ability for infinite customization for stability, consistency, and saving time on building and maintaining your own platform. You get those bureaucracy-busting benefits of going to public cloud.

2. Tanzu Platform for Kubernetes - a framework for building a PaaS on-top of Kubernetes. Added to this are tools for managing the apps running on these runtimes. Also, developers and platform engineers have the consoles needed to manage those apps. In this case, we provide defaults and templates (“opinions” to use PaaS-parlance) but you focus on building the platform to match exactly what you want, and can do so. We layer more usable yaml on-top of Kubernetes yaml, and have a good GUI as well. You can get a sense of what this all is by poking around at our docs on the Tanzu Application Engine.

3. There are data services built into Tanzu Platform as well: Postgres, MySQL, Redis/Valkey, Rabbit, Greenplumb (data warehouse), GemFire (in-memory data grid

4. And, the Tanzu Platform has very tight integration with Spring. Most enterprise applications are written in Java, and many of those use Spring. This means that Tanzu Platform is a great fit for most enterprise applications.

5. And, you know, all the runtime, management, consoles, integrations with infrastructure, etc. stuff you’d expect for a cloud platform.

When you spell it out it seems like a lot, but that’s sort of it. There’s of course a lot of details with such a wide scope. But, you can really simplify it as: the Tanzu Platform is a PaaS that will run Cloud Foundry or Kubernetes. The rest is just details in the yaml.

Here’s more from an interview with the GM of Tanzu, Purnima Padmanabhan:

The first part of Tanzu 10 is: we are bringing the reinvestment and the power of Cloud Foundry back to the Tanzu Platform. And Tanzu 10 brings in a single umbrella the choice of application runtimes. So you can build your application once and deploy either to a Cloud Foundry based application infrastructure, or application platform, or a Kubernetes either one, all within a single platform.

(~0:43)

The return of the Cloud Foundry philosophy and principles:

[There are ] three main messages. [Number One] Keep it very simple for the developer. Never expose yaml files, configuration files, kubectl, and lower level configs, BOSH, none of that. Just give them simple interfaces, say build my container and deploy, that’s it.

Number two, make sure that the deployment is dynamic and it automatically adjusts to the app needs. You just say, I want HA. You don’t have to tell me which cluster, how to connect the network, how to tie it all together, we will take care of it.

And then the third one is, you want to do continuous update, repair and continue security.

All these are actually pages from the Cloud Foundry world that now we are bringing to Tanzu platform as a universal tenant that applies across everything, whether you deploy in Cloud Foundry or on Kubernetes. (~11:00)

There’s something important to notice/know about “Tanzu Kubernetes”:

The core Kubernetes runtime is now baked into VCF, which is called the Tanzu Kubernetes Grid, it is made available with VCF, just like public clouds have their runtimes: EKS, GKS, AKS. Tanzu Platform layers on-top of that TKG runtime and gives you the application platform, the ability to build your application fast, the ability to deploy it with a single command, the ability scale it, the ability to secure it.” (~1:50)

This is something that’s still not widely understood: while VMware’s Kubernetes “distort” is still called “Tanzu,” it’s actually part of VCF. The Tanzu Platform requires an existing Kubernetes “dial-tone.” That is, you have to bring the Kubernetes. Of course, per what Purnima says, if you have VCF, you have Kubernetes. This is a minor distinction in the big picture, and maybe, actually, not really important to customers. But it’s worth keeping track of if you, you know, are into these kinds of industry details.

More

• My round-up of the SpringOne content from Monday.

• Here’s a recording of the Hock Tan keynote.

• Tanzu and Spring blog posts: Spring Announcements Blog; Tanzu AI Announcement Blog; Cloud Foundry specific Announcements; Data Announcements Blog; K8s specific Announcement Blog; Tanzu Platform Roundup Summary of Announcements Blog; Tanzu Sessions at Explore.

Conferences

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

This year, SpringOne is free to attend and watch online. Check out Josh’s pitch for the event. There’s an on-site conference as well at Explore if you’re interested. But, for those who can’t, now you can watch all the fun!

SpringOne/VMware Explore US, August 26–29. DevOpsDays Antwerp, 15th anniversary, speaking, September 4th-5th. SREday London 2024, speaking, September 19th to 20th. SREday Amsterdam, Nov 21st, 2024. Coté speaking. Cloud Foundry Day EU, Karlsruhe, Oct 9th. VMware Explore Barcelona, speaking, Nov 4th to 7th.

Discounts! SREDay London and Amsterdam: 20% off with the code SRE20DAY. Cloud Foundry Day 20% off with the code CFEU24VMW20.

Logoff

That should be it for my Explore coverage. There’s a lot of better coverage out there. I’ll be back with links and fun finds next time.

SpringOne

Yesterday we put on Spring One. There’s still sessions going on, which you can watch live if you register for free. Here’s some highlights.

We went over one of the most valuable products the Tanzu team has put out this year: the Spring Application Advisor. You set this up in your pipeline and it continuously scans for Spring and Java components that need to be updated. Using OpenRewrite recipes, it then creates the code you’d need to apply to not only update those components, but also update your own code and configuration.

This is a huge amount of work to do manually - Amazon estimates that it takes about 50 days. Just generating those changes is huge, but then also having the workflow to look at them, approve them, and make them official is a big help too. After the first go at it, you can then set up your CI/CD pipeline to automatically do this checking.

In large enterprises, keeping your Java, Spring, and other libraries up to date is difficult. Well, it’s more like a vicious cycle where people don’t prioritize it and get stuck using a mash-mash of years (and years!) old frameworks and components. This means they get stuck in the legacy trap: they need to upgrade, but they have no idea if it will break things, so they just keep using the old versions.

In a similar vein, Tanzu Spring also includes the Enterprise Spring Boot Governance Starter which puts in enforces various security and policy standards, like FIPS and PCI. Check out this overview as well.

Spring AI

Of course, what you really want to know about is the AI stuff.

There was a great demo of just how easy it is to add generative AI to a Spring app. Josh Long, Cora Iberkleid, and Mark Pollack went over a demo of doing just that. They made it seem effortless, and that’s the point of using Spring AI. In addition to just wrapping APIs around common AI calls, there’s also common patterns, defaults for setting up chat and RAG…in summary, a ready to go Java stack for using AI in your apps.

There’s also, of course, deep integration between Spring AI and the AI services in the Tanzu Platform. This means that if you’re using the Tanzu Platform for Kubernetes (tPCF), you can start messing around with AI now. There’s all sorts of models that work with it if you want to do some “private cloud” AI, and you can also call out the OpenAI APIs and others as well.

I haven’t watched it yet, but my co-worker Nick did a talk demo’ing Spring AI + tPCF. He walks through a couple of demo apps. This shows the coding, of course, but also how it all integrates together in the Tanzu Platform. He goes over the a platform engineer would do to add AI services to their platform, here our Cloud Foundry PaaS. And, there’s more details on Spring AI here.

Tanzu Platform

Today’s focus at the conference is on our PaaS, the Tanzu Platform. I’ll write more about this later this week. In the meantime, here’s the big round-up, and blog posts on our Kubernetes-based PaaS, our Cloud Foundry based PaaS, and the bundle of databases, messaging systems, and other data stuff we have.

Logoff

In an effort to find any videos from Explore in YouTube, I came across this recording of the original launch of Cloud Foundry in April, 2011. It’s interesting to ponder how far - or how not far - the industry has gotten since then. I think you could change a few words around (put in “Kubernetes” where “Antiquated Middleware Stack” is in the above - not that Kubernetes is antiquated [it’s only 10!] but that it causes stack-complexity problems), update the clothes, and you’d have pretty much the same situation and general pattern of fixing it as you saw back then. We keep going back and forth with the platform build-out.

Two major items of note: I don’t think ruby ever took off enterprise-wise. You can see how much they try to legitimize ruby for enterprise use. Back then, I guess, open source was still sort of scary for enterprises, and definitely not the way a lot of infrastructure was done. There’s a lot of open source in the enterprise boosting that you just wouldn’t see now: it’d be taken as the default.

This week’s Software Defined Talk podcast

We talk about the open source “rug pull” du jour in this week’s Software Defined Podcast: “This week, we discuss CockroachDB's relicensing, the ongoing debate about remote work, and platform engineering. Plus, some thoughts on the use of speakerphones in public.” We both steer us towards a conclusion something like: yup, the open source vendor can change the license and start charging whenever they want, that’s the new reality. You can control that risk if you use foundation-hosted projects, but if you use open source projects, you now need to do some risk analysis of the price going from $0 to $0+n in the future.

Is this good? I mean, no? We all enjoy a social contract where we’re on the free end of getting a lot of value.

If anything, the open source world should figure out the problem of “we gotta make some money.” Historically, that’s been a difficult subject for that community to talk about, and it’s certainly never been resolved.

We also talk about a similar shift in norms when it comes to speaker phone use in public.

Take a listen to the episode!

SpringOne Live-streamed, free, next week!

Next week is SpringOne, our conference all about the Spring Framework, which I think is the most widely used Java framework. It’s free to register for and watch online.

I’ve seen a lot of the content, and helped work on some of it. You can watch it all for free next week, starting August 26th at 9am pacific time. It’ll run for three days.

If that’s your thing, sign-up for it and watch for free.

Wastebook

• In enterprise IT talk, instead of “seamless,” consider saying “easy,” “simple,” “quick(ly),” or just deleting the word altogether. (That said, “seamless” is a term of art in IT, so we sort of all know what it means based on the context of how it’s used.)

• Necessity is the inventor of compromise.

• “‘The Art of Pantomime in Church’ is this weird mashup of clowns and Christians and I have no idea how it even got made. The thesis is that professional clown Randall Bane can teach you how to incorporate pantomime into your church services. I have no dog in this fight, I’m not particularly anti-Christian or even anti-clown, but I literally do not understand how I struggle to get by and yet there was money to produce this thing.” Via.

• ”it’s a reminder that people of my generation, those who grew up watching the original (and best!) Star Wars trilogy, are now the people running the world and its weapons systems” Here.

• Commin' 'atcha with another Coté Footnote(tm).

• Incomprehensible spaghetti.

Relative to your interests

• IDC’s Worldwide AI and Generative AI Spending - “IDC has recently unveiled the latest release of its Worldwide AI and Generative AI Spending Guide, 2024 V2. Presently, the global Artificial Intelligence market stands at nearly $235 billion, with projections indicating a rise to over $631 billion by 2028.” // Something is weird with this estimate. There’s no way companies found an extra $235 billion to spent on new IT projects. And if they’re reallocating that money from other IT projects, like, your grocery buying app is going to stop working because there’s no budget for the computer needed to run it. // Meanwhile…

• C-suite enthusiasm over generative AI wanes, putting pressure on quick wins - “Interest in the [AI] technology fell 11 percentage points among senior executives and eight percentage points among board of directors, respectively, since Deloitte’s Q1 2024 survey.” // I think the people most enthusiastic about enterprise AI haven’t actually used even enough consumer AI to get a grasp on how little AI can actually do. And, as with new tech (like cloud computing in the early 2010’s), they underestimate how expensive it is to use, and how difficult it is the change how their organization functions. // Also, there’s a bit danger that the AI-driven company valuations jumps too quickly drop due to lowered expectations. // Speaking of…

• AI may be distracting organizations from other IT priorities - Well, things are getting better, but enterprise AI is a distraction from keeping the lights on. // “IBM reports that fewer than half of the respondents believe their IT organization is effective in delivering basic services, compared to 69 percent from a survey in 2013. Among chief execs, that figure is 36 percent today, down from 64 percent previously, while for chief financial officers, the figures are 50 percent now, down from 60 percent before…. What might be causing this? The Armonk-based biz says that 43 percent of surveyed tech CxOs indicated that concerns about their IT infrastructure have increased over the past six months due to the focus on optimizing their infrastructure for generative AI.”

• Private Cloud - What’s in a Name? - “Forrester’s ‘Private Cloud Market Insights, 2023’ reporting that 79% of surveyed cloud decision makers are implementing internal private clouds” (Source: "Private Cloud Market Insights, 2023," Forrester). Cf. my past attempt to round-up private cloud usage/market-sizing.

• How public intellectuals can extend their shelf lives - Spend a lot of time steering yourself to be optimistic, and engineer a continuous drip of new ideas and perspectives.

• Platform Engineering: The Next Step in Operations - This is a really good overview/state of thing. // Once again, I think it’s all about introducing product management to operations and continuously building the platform, the product.

• Developer Content That Ranks in 2024 - Educational content attracts the most attention (“how to”). Also content where you define things (“what is”). Converting that content into sales, or at least pipeline, is the secret magic.

• $ git push heroku betty - That sounds like fun. People keep telling me about the revitalization of Heroku. It’d be great to see that happen. If everything just want their own Heroku, what’s been holding them back? Solving that puzzle would be wonderful to see after all these years of PaaS yo-yo’ing. // I like the unstated opinion here: “Many are now facing lots of scattered homegrown production platforms and are starting to feel the pain of maintenance, technical debt, and difficulty in consistently delivering reliability, stability, and security while trying to scale. There simply aren’t enough engineers for every company to support this, nor does it make business sense.” // The opinion is: stop doing that.

• An American came to stay – and completely changed my attitude to water - As Europe gets hotter (not good, sure, but:), hopefully they’ll understand the pleasure of ice water.

Conferences, Events, etc.

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

This year, SpringOne is free to attend and watch online. Check out Josh’s pitch for the event. There’s an on-site conference as well at Explore if you’re interested. But, for those who can’t, now you can watch all the fun!

SpringOne/VMware Explore US, August 26–29. DevOpsDays Antwerp, 15th anniversary, speaking, September 4th-5th. SREday London 2024, speaking, September 19th to 20th. Cloud Foundry Day EU, Karlsruhe, Oct 9th. VMware Explore Barcelona, speaking, Nov 4th to 7th.

Discounts! SREDay London: 20% off with the code SRE20DAY. Cloud Foundry Day20% off with the code CFEU24VMW20.

Logoff

I won’t be at Explore and SpringOne next week. I’m hoping to write-up my thoughts and analysis from my Amsterdam perch. Of course, I know a lot of the content already, but actually seeing it presented and thinking about how I’d “live blog” it in the old days is another thing. We’ll see what happens!

//

I’m slowly starting a project called “things that are happy that you’re about to eat them.” I might call it “Please Eat Me” (maybe “Pleased to be Eaten”?) for short. I’m on the lookout out for food labels and ads that depict the thing you’re about to eat as jolly. You see this is a lot with BBQ places, like the old Bill Miller BBQ back in Texas:

Those are pretty tame. That pig seems super chill, though. You see it a lot in candy and hot dogs. The best is when a hot dog is putting ketchup or mustard on itself: getting all ready to be chomped on:

It’s a bit morbid when the food is an animal, but we should have some compassion for the fruit and vegetables too:

Also, there’s a highly-related category of, like, “Please Kill Me” (maybe “Pleased to be Killed”?) where the animal/fruit is happy that you’re buying a device that will help kill it:

If you see any, pass ‘em along!

Are you at a large organization doing platform engineering? Have you been building and/or using a platform? How are you introducing product management in your operations group?

I want to test a theory that’s come up in my conversations a lot this summer: introducing product management into ops and infrastructure organizations is too difficult. It won’t work. There are teams here and there that can do it, and they show up at conferences. But, when you're proposing that you're going to "change the culture" of thousands of large organizations, it's an impossible task. These detractors cite DevOps, even agile: after all these years, have we really done much, or have we just experienced the bad parts of Larman’s Laws?

That sentiment is pretty bleek!

If you're working in one of these large organizations, how do you start up the product management practices and roles for your platform? Is it working? A further filter is: how many apps are you running on your platform, following platform engineering practices?

I really would like to hear from you, even if it's just references to other people talking about. But, if you're working on platform engineering in a large organization, I especially want to hear from you. Hopefully, I can get enough responses to write-up how people are introducing and doing the product management part of platform engineering.

Now, here’s a long explanation of why I’d like to hear from you:

Product management is what makes platform engineering different than "what we're already doing"

I'm focusing on product management because I believe that practicing product management is what separates platform engineering from "what we're already doing." And, over the past year, this feels like it's emerged as the consensus. Once you make product management part of platform engineering, it moves the phrase past being a marketing-driven buzzword that relabels what we already have to focus people on buying new bottle for their old wine.

Product management wasn't always part of platform engineering. A few years ago when the thought leadership around platform engineering started, "platform engineering" just meant putting an internal developer portal in place (Backstage and friends). Then the platform engineering thought leadership train loaded up "making Kubernetes easier to use for developers." This caused a lot of existential angst from us DevOps and PaaS people, especially when Humanitec declared that DevOps was dead. We were all left wondering: how is this different than what we've been talking about for 15+ years? That is: what we’re already doing.

Once the 10+ year old idea of "platform as a product" was reintroduced into the platform conversation, "platform engineering" became a new enough thing that it was worthy of having its own name. It became a thing.

In my world of pre-Kubernetes PaaS, I've worked with large organizations who've been practicing platform as a product for many years, using Cloud Foundry as their platform. You could say that platform engineering is “just” a re-labeling of platform as a product, but I think it’s ended up being more than that. Platform engineering wants to do platform as a product with Kubernetes, not with existing PaaSes.1

Platform engineering focuses too much on Kubernetes

This is the second aspect of platform engineering that I think makes platform engineering a real thing: it means using Kuberntes as the basis for your platform. I don't think this is good, and I’d rather we change it so that it doesn't matter what CaaS/IaaS you use. But, that’s currently platform engineering as she is spoken.

Like I said, for 10+ years, there've been a lot of big enterprises that have used, and continue to use, Cloud Foundry to run thousands upon thousands of real-world applications. And, there's other platforms out there, not to mention all of the VM-based ways of running apps that seems to be the majority of how people run apps. There is always a platform, whether you know it or not. And if you don’t know it, it usually means its an accidental platform and hundreds of them in your organization, which is very much not good.

But, the people building and talking about platforms now want Kubernetes, it seems. They just assume there is nothing else. This has been a 7 year distraction from improving how organizations develop and run software, and a great example of how us tech people get too focused on using new and interesting tools for their own sake. And, in that way, a triumph of thought leadership and devrel.

Over those years, after finally focusing everyone on the PaaS layer, that re-focusing on the CaaS/IaaS layer has sacrificed the never ending task of improving the "business outcomes" of better developer productivity and improving all the -ility's in production. You know: becoming an "elite performer" in DORA terms.2

(Alright. I've tried to write this post a few times and it always goes dark and negative. So I'll stop it with the you kids get off my lawn existential crap.)

So, that's where we are with platform engineering: it's applying product management to building the platform, and building the platform with Kubernetes.

The two platform approaches we'll end up with

There's all sorts of people working on solving the Kubernetes problem(s): that it's complex, you don't want to expose developers to it, and you have to go to the buffet and assemble and then care for your own platform. Kubernetes is not a ready to use out of the box platform. Indeed, when you look at the CNCF cloud native platform definition, Kubernetes doesn’t even show up!

Following historic examples, the problem with building a platform from Kubernetes will resolve itself in two ways:

The Overlay: platform as abstraction layer

There will be a few winners in the "wrap Kubernetes/whatever in layer to hide it from the users" approach. This is what we're trying to do with the App Engine/Spaces framework, and, as I shallowly understand it, it's what Syntasso/Kratix is trying to do. You’re essentially saying “the APIs and config for Kubernetes aren’t tuned for the platform engineer needs, so we’re going to make the ones that are, and do all the glue work integrate that back to Kubernetes.” This is one of the most popular patterns in computering: adding an abstraction layer to make it easier to use the wrapped layer.

This platform building pattern is trying to give users (platform engineers) the ability to customize the platform to their special needs3 while still avoiding building everything from scratch, the “DIY platform.” To use PaaS-talk, this approach allows you to form your own opinions rather than (be forced to) use the opinions of your pre-built platform.

Platform engineers define the "API" of the platform components and can then build the platform out of those components. You can also throw in promise theory, contracts, and some aspects of negotiated platforms and SLOs from SRE-think. Colin Humphreys made a good pitch for this approach recently, and I’ve been dragging my feet on interviewing the Tanzu people who’re working on this approach. 

We've seen what this ends up looking, good and bad, like in historic examples, so we can start to think through some long-horizon strategy moves.

DevOps 1.0 was all about creating an abstraction layer for the mess of configuration and release management with Chef, Puppet, Ansible, Salt, etc. Years later, DevOps got bogged down in solving ops tooling and culture problems (which is great!) and rarely got up to the application developer layer - but, the intention was (usually) always there!

Then there's our current example of Kubernetes. The point of Kubernetes was to displace AWS as the standard IaaS model by creating an open standard for how infrastructure was represented, managed, and used. To use the Kubernetes term, to creat a new “API” for IaaS. It worked!

Like DevOps, Kubernetes also stalled out on the way to delivering a better developer experience. And, in fact, the Kubernetes creators eventually backed off from that ever having been a goal.

For both Kubernetes and DevOps, making the “inner loop” (if you remember that term) better was, perhaps, never the point, and thinking otherwise resulted in over-inflated expectations.

I think what the people working on the platform as abstraction layer approach want is what we hoped the Kubernetes API would be: much higher up the stack, even developer facing, and including a governance framework. Essentially, a developer-ready system with all the enterprise grade blah-blah tools.

This is great! It'll be fantastic if it works!

What’s important is that you have to product manage all of this to figuring out (1) what those overlays are, (2) how you customize the overlays for your environment, (3) how you pick and choose which overlays to assemble into a platform, and (4) when you add in new functionality.

The vendor and open source community around the overlay will help with some of that, especially number one and four. The vendor/community will gladly tell you what it thinks the defaults should be and even provide you an out of the box, ready to use enterprise grade blah blah platform (see the next section) based on those overlays.

But, the whole point of the platform as abstraction layer is customizing the platform to the user’s needs, so, like, the user needs to do that. And product management is how you do that.

Paas is cool again

Since 2007 we've been through several cycles of people trying to build their own Heroku.

It goes like this:

1. A new platform comes out that makes it easy for developers to build their app, connect the app to a database, etc., deploy the app to production, and scale it for performance needs all on their own, self-service, using the latest frameworks and services.

2. It only runs in the public cloud.

3. Large organizations initially reject it for two reasons: (a) it actually will not scale. (b) it needs to be on-premises for very important enterprise reasons. "We want that awesome developer experience and velocity," the large organizations say, "but, uh," looks down at notes, "I was told that we work in a 'highly regulated industry.'"

4. This brings in phase two of the cycle: vendors make on-premises platforms. Strangely, maybe even heroically, Heroku never entered this phase. But, you saw it with things like the container wars of the 2010's, which drove on-premises platforms like Cloud Foundry.

5. Our attention goes back down the stack to infrastructure instead of the fully build PaaS. PaaS is no longer cool. The last phase of the cycle is usually caused by a disruptive technology coming along and pulling the user and buyer's attention away form the now boring platform that just works. Docker was the first to disrupt PaaSes in the late 2010s, and then Kubernetes came in. In both cases, the user assumptions was that each was a viable PaaS replacement. But, as capital-D Disruption, in each case, neither was a full-on replacement for all the enterprise grade blah blah. And yet, these less feature-ful disruptors drove organizations away from the PaaSes that they once loved. E.g., Heroku and its children.

I've made a satire out of that cycle and the thousands of highly paid professionals who make those decisions along the way.

But, I mean: I'm not sure why people don't just use Heroku or its many on-premises focused descendants like Cloud Foundry.

There's "fashion." People wanting to use something new. I've heard this sentiment many times recently: "Our PaaS is great, but if I don't learn Kubernetes, it'll be harder to find a new job. So, we need to migrate to Kubernetes." What with enterprise Kubernetes build -out being just at the beginning, that sentiment is optimized for an individual, but not for the organization that already has something that works in place.

Other than "fashion," I think what drives people away from PaaSes is: 

1. Pricing - The first grumblings about Heroku were that it was awesome, but expensive. This has been a common sentiment about all PaaSes. Showing the value of any platform is hard, so it always looks expensive when you start running thousands of applications. All you see is a price, and linking it to the revenue that those thousands of apps drive is not a normal way for traditional organizations to think. They treat IT as a cost center, not a part of the business. So when someone comes and says "we could build that platform ourselves and remove however many millions in licensing/cloud cost," management gets excited.

2. Difficulty in customizing or "swapping out" components, and lack of new features. The last is what introducing product management into platforms is trying to solve: you're actually supposed to talk with developers and deliver new platform features that solve their problems and make them happier.

In this part of the cycle, the Kubernetes problem is solved by hiding or even removing Kubernetes. It doesn’t matter what CaaS/IaaS is at the bottom of the PaaS. Maybe there’s even two, or three! You might even introduce a totally a new compute, uh, “paradigm.” Maybe serverless will finally fulfill those Wardley-dreams! Unikernal, WASM - whatever! Just a few weeks ago my mind was thoroughly exfoliated in the sauna with the idea of Isolate Cloud. ANYTHING COULD HAPPEN.

The role of product management here is different. If you’re using a PaaS, you’re not given a lot of tools to do all of your own customization. You more rely on the PaaS vendor and community to do much of that work. The overall community does most of the product managering, which mans they need to do a lot of it. It also means you need to upgrade the PaaS when there are new versions. That is a big challenge. People at large organizations don’t like upgrading their stacks.

Maybe one way of looking at it is that a PaaS outsources platform product management. It’s probably more that what you’re product managing is (like the platform as abstraction layer) the selection and assembly of pre-built components.

Without product management, platform engineering will struggle

This is why I've typed this far: the long-term success of platforms relies on product management. Once you stop adding new features to the platform, people look for new options. If you can't customize it to your needs (real or just made up enterprise blah blah), you'll start the platform cycle all over again. This means you don't get the full benefits of many years of platforming. You'll start neglecting what you have, focus on migrating your existing apps to new ones, and experience those ups and downs of benefits achieved when you see surveys of new tech usage. ROI depends on years of payback, and if you restart in the middle of that period, the math doesn't work.

So! That's what’s driving my interest in learning how organizations are introducing and sustaining product management in their platform groups.

How's it going for you?

Logoff

Colophon

Three things go me thinking on this above, which I want to call out:

First, this from Figma’s write-up of migrating to Kubernetes:

Having users define services directly in YAML can be confusing. Instead, we worked to define a golden path for users and allow customization for special cases. By being explicit about what users can and should customize—and otherwise enforcing consistency by default—you’ll save users time and energy while also simplifying maintenance and future changes.

That seems like a pretty compact explanation of the developer-facing goals of platform engineering.

Second, as referenced many times above, Colin’s excellent piece of “let’s make better mistakes this time” for platform engineering enthusiasts. I like that he managed to sneak in a link to an old version of Pivotal paper on platform engineering.

Third, Betty announced that she’s the new CMO at Heroku. When I was looking around at new job opportunities this summer, almost every person told me I should talk to the new people at Heroku. They’re trying to get the band back together, etc. I don’t really know anyone there, and I decided that my current job is just fine. But, it’s exciting to think that Heroku will start doing more in the platform area. I think the timing is right for a public PaaS only play - you’d be cutting out a lot of enterprise customers, but over the next five years, I think all that enterprise blah blah will be less of a barrier. I mean, that’s what all the CIOs are saying: in three years they’re planning to almost double the amount of workloads in public cloud. Maybe they’ll actually do it this time.

While writing this, I came across this huge write-up of platform engineering ahead of releasing a new book on the topic. It’s great! I’m looking forward to that book.

Also, we have our big annual conference next week. I’m thinking we’ll have some options about the above. You can watch some of it as a live stream, or scrounge for coverage and videos later. I’ll write-up anything relevant here. Probably.

There’s something I chopped out of my initial, thankfully thrown away draft of all this: we don’t really talk about “operator experience” in platform engineering. It’s very developer focused. This is fine! But, more than likely (as with DevOps), the story will turn inward to making the tools and lives of platform engineers better. Put another way, we’ve long had the 12 factor app manifesto, but what is the other side of that, the 12 factor platform manifesto?

Figuring out what kind of podcast you’re doing

One of my co-workers is started a podcast and had some questions. Here’s my answers. As with most “how do I do this?” sessions, it focuses a lot on gear which I scoot away from in my answers, you know, following the cliche that the tools matter less than what you do with them. Also, the tools are tedious, but easy to learn.

What podcasting software do you use?

This is all for recording remotely, over the Internet. For recording in person, there’s a different set of gear and practices.

For SoftwareDefinedTalk.com we use Restream. When I’m recording an interview, I use SquadCast which is now bundled in Descript subscriptions.

I suggest using one of those services so that you can record separate audio tracks and get video (whether you want the video or not). You don’t need to livestream your recordings.

Before those services existed, I’d use Audio Hijack Pro to record the incoming audio and outgoing (my) audio. But that’s a lot of work compared to just using one of the above. You can also use Zoom. I think it’s pretty good, actually, but I haven’t checked it out recently.

What are the features of that software?

Recording.

The main thing each does is get a video chat going and record separate audio tracks. Most of them, now, will record the audio locally (on your and your guests laptop) as well. So, if the connection is bad, you’ll get good audio in the final recording. These services usually will give you recordings of each participant and a recording with them all together.

Editing

For Software Defined Talk used Hindenburg for many years (ten?!). It’s at the sweet spot between lots of functionality and easy to learn and use. It’s built around editing voice, has good, basic audio filters and effects (leveling, noise reduction, etc.), and good setting for exporting podcast MP3s (setting cover art, putting in chapters, etc.) It looks like it had editing by transcript.

Now-a-days when I edit podcasts I do it in Descript. You can edit the video (or just audio) and export an audio only MP3. It has all of the export things that Hindenburg does.

If you want a free option, Audacity is probably pretty good. That’s what I used long ago in the 2000s and it was just fine.

Distributing

Here, I assume you mean hosting a podcast: uploading it somewhere so that it makes an RSS feed that people can subscribe to.

In addition to hosting the MP3 and creating the RSS feed, the service should create a basic podcast website for you. You want an index page that lists each episode and then each episode should have its own page, the show notes. You want to be able to edit those show notes to put whatever you want in there. The service should allow you to automate all of this each time you upload an episode.

Each episode should have a URL you can go to. The better services will automatically create a URL based on the episode number, for example: https://www.softwaredefinedtalk.com/480.

These services should also have metrics too for episode downloads. You can’t tell much from podcast downloads: just number of downloads and geography. Some of the nicer services will pull in more detailed metrics from Spotify and Apple Podcasts.

I’d also look for a platform that manages your podcast listing in Spotify and Apple Podcasts. You can actually do that on your own, but many of the services will do that for you.

We use fireside.fm. My co-workers use podbean.com and transistor.fm. I haven’t used it in a long time, but libsyn.com is one of the original hosters and probably good.

A lot of big name, highly professional podcasts (the NPR style below) have terrible show notes. It can be hard to even find where the show notes are. This is baffling. Have show notes and good ones. Check out the example podcasts I cite below, they all have good show note sites…except the most professional one! Here is the test: if a person wanted to link to an episode, is it easy for them to find the web page (does it even exist?!) and get a URL that they can share?

Do you edit your podcasts? If so, any advice?

I don’t edit the Software Defined Talk ones anymore, one of my co-hosts (Brandon) does. But I used to for 10+ years. Plus, I edit the Tanzu ones and one-off ones I do. Brandon is a much better editor than I am.

Learning the basics of editing take a little bit of time, but it’s basically chopping up your audio file into chunks, arranging the chunks in the order you want, and deleting the chunks you don’t. For most podcasts that are interviews, you won’t be re-ordering the chunks. Instead, you’ll delete parts you don’t want. Most podcast editing is that: deleting parts you don’t want.

You’ll know you’ve gotten good at podcasting editing when you start to use the keyboard short cuts, and when you can imagine the edits you’d make as your talking in the podcast. As you listen to other podcasts, you’ll also be able to detect when they’ve done edits.

You can put music and standard bumpers in the intro and outro. I’m not a huge fan this as a listener or maker. If you do have music, make it brief and use the same music each time. This will help listeners slide into the comfortable sameness of each episode.

Do you have any general podcasting advice?

I would decide on the style of show you want and then edit accordingly.

Do you want (1) the full This American Life/NPR style podcast with summing up intro and hook, music in the background (“ducked”), narrator spliced in with interviewee comments, edited segments, and music? Or do you want (2) the cold open, we just recorded two people talking style? There’s an in-between that most people do where (3) they have some intro music that fades out, and maybe they do some editing of segments.

I do the second type because as a listener I don’t like the others and it’s the quickest and easiest to make.

Deciding the format and style you want is important. Once you have that you can use it to guide what you do like editing and even selecting guests. The style you choose will determine how you structure and run the podcast, and also what you’ll do during it.

If you’re doing the NPR-style, your goal is to get other people to do all the talking and edit together a story. NPR-style podcasts aren’t really podcasts at all: they’re professional radio shows that are distributed as podcasts.

If you’re doing the other two (“real podcasts”), you have to remember that listeners are as interested in you as they are in the guests and topics.

The success of “real” podcasts relies on establishing a parasocial relationships with listeners, often lasting many years. Listners want to hear the topics, learn abut things, but they also establish a friendship with the hosts. Listeners look forward to hearing what their friends are up to each week - hanging out with them each week.

This means that if you’re doing this style, if you’re interviewing someone you should interject what you think instead of just asking the guest questions. And if you’re discussing some topic, you should offer lots of opinions and “thinking outloud,” not just covering “the facts.”

Also, this means you should be consistent in your release period (weekly, every two weeks, monthly) and post it on the same day. For example, we post Software Defined Talk episode every Friday at 7:30am Amsterdam time. I know the release days for all of my favorite podcasts and look forward to them.

Here’s another distinction in types of podcasts: guests and no guests.

Having guests is having (mostly) different people on each episode to interview them about whatever - in tech, usually something they’re an expert, or at least knowledgeable on.

In these cases, you want to get the guest talking most of the time, but you should also think of yourself as a proxy for the audience to ask and clarify things that the guest is saying. It’s also good to rephrase things from time-to-time, and then, as always, offer up your own thoughts.

People have a lot of opinions about length. You should ignore that advice and figure out what you like and what works for your style. I like long podcasts, some other people like short ones. If someone tells you to target ten minutes because “people don’t listen to long podcasts,” chances are this person doesn’t listen to podcasts. This comes up a lot when you’re doing an official company podcast. Only take advice about podcast length from people who actually listen to a lot of podcasts.

There is no magic number for length. Start with having it be slightly longer than it needs to be, and back up from there if you want to.

Keep in mind that people won’t always listen to a podcast beginning to end in one sitting. They might pause it and come back to it. Sometimes it takes me two or more days to fully listen to a podcast.

Again, your listeners are there to hang-out with you each week - they’ll appreciate you spending more time with them rather than less. And, if it takes them several days to listen to it, they will because they’re interested in hanging out with you.

(4 hours might be too long, but I’ve listened to many enjoyable 3 hour podcasts over the past ₂₀ years, and hundreds of good 2 hour ones.)

As with writing, the other thing you should do is listen to a lot of other podcasts in the style you like. They can be in your topic area or a completely different one. For example, even if you’re doing a tech podcast, you can learn a lot about podcasting from The Flop House and Blank Check.

Once you’ve made three or so podcasts and edited them, you’ll be able to pick apart how good podcasters operate and start learning from them. And, also, you’ll just learn the format, and what you like. With this you can figure out the podcasting style you like and start to build - and refine/evolve - your style from that.

Here’s some more podcast example:

• The Political Gabfest - this is a very professionally done “the same people three people talk about the news of the week” podcast. You can see that they stick to a format - there’s usually three topics, the host intros/summarizes the topic and then asks the other two hosts what they think; the host will say what they think to. Also, at the end of each episode each host recommends something. I stole that idea for Software Defined Talk when we started our podcast. This is the podcast that has terrible show notes - see how frustrating it is the look at their page?

• Software Defined Talk - this my podcast, so it’s obviously the best in the world. We patterned it off The Political Gabfest, but after 10 years it’s developed its own style. I would call this style “the mess that works.” It’s the same three people each week discussing a selection of tech news and any side topics. Here, the format is: (1) Coté’s inane cold open, (2) one to two tech topics we discuss, (3) listener feedback and interesting conferences, (4) recommendations from each host, (5) usually an after show with some goofy outtakes or an extended, off-topic conversation. A more professional version of this is Sharp Tech, and the Cloudcast News of the Month.

• Oxide and Friends - this is another “mess that works” example. It is very much a personality-based podcast, based on Bryan Cantrill. The format here is the classic: his co-host Adam is the straight man and Bryan is the goofball. This is also an interesting podcast to study if you’re making tech podcasts and you’re making an official company podcast. Oxide is on an impossible mission: making on-premises hardware! So, part of their marketing is embracing the absurdity of that business scheme and somehow converting it to tech-cult energy, to hope and belief that on-premises hardware is cool and interesting. It’s like the early days of Kubernetes where Kelsey would run around doing demos. This podcast does a lot more than that, of course, but part of it is feeding that tech-cult energy.

• The Changelog - I don’t listen to this podcast much (it’s usually too technical for me), but it’s very popular. Compared to other podcasts it’s high-production.

Finally, with most of my advice about content, my number one recommendation is to just do it and publish. The moment you hesitate because you think you should edit more, polish it up, or (worst) re-do it, you should instantly click publish.

If you’re doing this right, you’ll always think the episode could be better, you might even think the episode is bad. You might even regret questions you asked, that it’s boring. Just keep publishing. It’ll take time to discover your style. Eventually, the audience will find you. But if you engineer it too much you get the equivalent of “data sheet” PDFs and shallow enterprise software web pages. Something that looks perfect, but says nothing.

Publishing the imperfect is how you get around that. As I keep emphasizing, a “real” podcast is about establishing a very intimate relationship between the hosts and listeners.

By doing it weekly and publishing it you start learning how to choreograph that all.

We plan on having guests on our show… what do you do to help guests have the best possible audio quality, especially if they’re not likely to have professional equipment?

Getting good audio from guests can be tough. The first thing is to get the to use headphones. Then having them use something other than a laptop mic. If they have a headset with a mic, that’s good. And iPhone headphones with a mic are actually pretty good; you just have to ask them to hold the mic away from their beard if they have a beard.

Very importantly: make sure they check their audio settings to make sure they’re using the good mic. If their audio sounds off, ask them to double check. I’ve been doing podcasts for about 20 years, and I mess this up as a host and guest at least once a year.

Also, experiment with using the Continuity Camera with a iPhones. The mic can be pretty good, and the placement of the phone mic on the top of their laptop screen will position the mic well, pointed at their face.

And beyond audio quality, you need to learn how to steer your guests. This is one of the things you’ll learn from listening to other podcasts. The best steerer is Tyler Cowan, though, I could see how some people would find his style insulting and cringe-y: too controlling.

And while not a guest, if you’re doing the multi-host thing, you need to learn how to be the host that runs the show and moderates it (let’s call it the active-host) but also how to be the other hosts (the passive hosts).

For the active host, on our podcast, Brandon is good at this (which happens in the episodes I’m not on), and Plotz is good at this in The Political Gabfest.

The important thing about being a passive host is that you have to stop talking when the host changes the topic. You’ll get tuned to each other, and even pick up on the natural rhythms of each other. You’ll know about ten seconds ahead of time when a person is wrapping up so you can prepare to go next.

A lot of the convention about how to be a “good listener” in life doesn’t apply to podcasting. You have unlearn polite conversation topics, and almost do all those things that people tell you are offensive and rude in meatspace talk. Interrupt each other, talk over each other, say what you think. Or not: it depends on the style you’re doing. But don’t bring all the “how to be a good listeners” and nonviolent communication stuff to the table right away: evolve to that if that ends up being your style.

In summary, what I’m saying is: finding and tuning your style of podcasting is more important than gear. Part of that is creating the your podcasting character and being conscious of playing that character. It might be a lot different than the character you are in other parts of your life. You listeners want to hear that character, they’ll become friends with it. Your listeners won’t show up just for that character: they want the actual interesting content and guests! But, that character is what will make your listeners keep listening, subscribe, and fill in the gaps between impossible awesome and what you actually published. So, you have to cultivate that character.

Relative to your interests

• Why Every Java Developer Should Attend SpringOne - the online version is free to watch on August 26th to 28th.

• Travel Spending On Track To Return To Pre-Pandemic Levels By End Of 2024 - ”Global travel spending is roaring back and will fully recover to pre-pandemic levels by the end of 2024, surpassing $2 trillion.”

• Walmart used AI to crunch 850M product data points and improve CX - “The primary in-store improvement is that associates’ can use in-store technology like mobile tools to quickly locate inventory and get items on shelves or to waiting customers — a significant upgrade from the ‘treasure hunt’ of finding items in years past” A few more details here.

• Apax to take consultancy firm Thoughtworks private in $1.75 bln deal - Summary from Justin Warren: “Software consulting company Thoughtworks is getting bought by private equity firm Apax Partners for about $1.75 billion. Thoughtworks has been struggling a bit lately, with revenue down 12.4% YoY to $251.7 million and the stock down 87% since 2022. It’s already done a bunch of cost-reduction restructuring, and it looks like more is on the way with 630+ staff to go” out of ₁₀,500 staff.

Wastebook

• “billboards festooned with three-dimensional meat bearing messages such as ‘You never sausage a place!’” Here.

• It’s hard to forget a bad idea, and you have to work hard to remember good ones.

Conferences, Events, etc.

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

This year, SpringOne is free to attend and watch online. Check out Josh’s pitch for the event. There’s an on-site conference as well at Explore if you’re interested. But, for those who can’t, now you can watch all the fun!

SpringOne/VMware Explore US, August 26–29. DevOpsDays Antwerp, 15th anniversary, speaking, September 4th-5th. SREday London 2024, speaking, September 19th to 20th. Cloud Foundry Day EU, Karlsruhe, Oct 9th. VMware Explore Barcelona, speaking, Nov 4th to 7th.

Discounts! SREDay London: 20% off with the code SRE20DAY. Cloud Foundry Day 20% off with the code CFEU24VMW20.

Logoff

I’ve spent a lot of time “researching” and learning this week, not much producing content. It’s like input versus output. This is difficult, mentally for me. I only value publishing, so if I’m not doing it, I don’t think I’ve done much work. This is not healthy!

To get around that by thinking about what other creators do. How often do they publish? How much time do they spend “puttering around” building up to the ideas they eventually publish. How much stuff do they work on that never gets published.

When I’m in this learning mode, I’m creating lots of content: I’m taking notes, trying to rewrite things. I’m also talking with other people a lot, testing out my understanding of the “input,” getting them to explain it to me, thinking about things we could do as output. It’s sort of like a podcast that never gets published.

//

Part of that “input mode” is listening to lots of videos. I can’t watch videos at my desk. I’ll get distracted with other work and then I’m no longer paying attention. This a good opportunity to walk the dog on long dog walks. So, this week, I’ve found several new Garbage Chairs of Amsterdam.

Just fun finds and links today.

Wastebook

• “FWD: RE: radioactive fungus email from grandma” Here.

• “I don’t know about you, but I think a campaign setting ruled by evil angels and their witch-wives, populated by giants (perhaps not 3,500 metres tall) who eat one another and human beings, and who have sex with animals to produce many weird varieties of beastman, is one that somebody could do a lot with.” Here.

• ”AI enables action without thinking.” Here.

• “Agent Double-O Soul, baby.” Edwin Starr.

Relevant to your interests

• How We Migrated onto K8s in Less Than 12 months - Always hide the yaml: “Having users define services directly in YAML can be confusing. Instead, we worked to define a golden path for users and allow customization for special cases. By being explicit about what users can and should customize—and otherwise enforcing consistency by default—you’ll save users time and energy while also simplifying maintenance and future changes.”

• 5 Lessons For Building a Platform as a Product - They’re doing a good job trying to evolve the Pivotal Cloud Foundry philosophy of platforms. // “I talked to a CTO at one of the world’s top banks, who explained that he loved what Cloud Foundry could do but wondered what would work for the other 99% of workloads he had responsibility for.”

• Who uses LLM prompt injection attacks? Job seekers, trolls - ‘“At present,” Kaspersky concludes, “this threat is largely theoretical due to the limited capabilities of existing LLM systems.”’

• AI or bust? Only one part of US tech economy growing - “Assuming the bubble does not burst, S&P forecasts global AI spending to grow by more than 20 percent through 2028, when it is estimated to account for 14 percent of total global IT spending, up from 6 percent in 2023.”

• How to go-to-market: Measuring Marketing Value - “The key areas that your marketing team can drive impact for the business are in Awareness, Engagement, and Pipeline.”

Logoff

Some local under-the-bridge graffiti:

Creating ROI models for platform engineering is difficult. Here’s three examples of approaches I’ve come across recently.

You’re trying to convince your organization to put an app platform in place (probably either buying one or building one on-top of Kubernetes), to shift your ops team to platform engineering (just after HR finally changed titles from “Systems Analyst II” to “DevOps Engineer”!), or, if you’re like me, sell people a platform.

ROI

“Yeah, but what’s the ROI for it?” the Director of No responds. What they mean by that is “convince me that this change is going to have benefits that we can represent as money, either saved or gained.” A variation is “show me that what you’re proposing is cheaper than the alternatives, including the alternative of doing nothing.” That’s probably more of a “Total Cost of Ownership” (TCO) analysis. Indeed, ROI and TCO models are often used the same way, if not the same spreadsheets. This kind of analysis is also often called a “business case.”1

This is especially true in the post-ZiRP world. When money was “free” and G2000 companies were deathly afraid of Tech Companies, they’d change how they operated based on the capacities they gained, not just on an Excel spreadsheet filled with cash-numbers. Those were good times!

Showing the ROI of a platform is difficult. I haven’t really come across any models that I like, and I’ve seen many of them.

The problem is that platforms don’t generate money directly, so you have to come up with a convincing model that shows how platforms contribute to making money.

Let’s start with the benefits of platforms, and see if we can stick some money to them.

What platforms get you

The benefits of platforms are explained in terms of either:

1. Developer productivity - which leads to improving how an organization can use software to run.

2. Operations productivity - removing the “toil” of day-to-day management and diagnosis of production, but also reducing the amount of time (and, thus, people) needed to manage to platform.

3. “Enterprise grade” capabilities - ensuring security, compliance, scalability - all the other “ilities.”

There’s a fourth category when a platform is a tool in an overall program: usually migrating from on-premises to public cloud or modernization applications. We’ll call this the “enabler.”

These are valuable things, but I’m frustrated with them because they don’t link directly business outcomes, things like: making more money (customer facing), performing a government service in a reasonable way (low cost and good citizen experience), or running a company better (internal operations).

That’s because platforms are just “enablers” of applications. And it’s the applications that directly create those benefits, that “make the money.”

Here’s three approaches I’ve come across recently that are representative of doing ROI, really, for any “enabling” technology.

VCR, IAR, and DTR

In the paper “Measuring the Value Of Your Internal Developer Platform Investments,” Sridhar Kotagiri and Ajay Chankramath (both from ThoughtWorks)2 propose three metrics and an overall way of thinking through platform ROI. This is the most thought-provoking, nuanced/complex/comprehensive, intellectually juicy, and thus all around useful ROI model of the three I’ll go over.

First, they have this excellent chart of linking platform capabilities to business outcomes:

A chart like this is great because it does its primary goal (showing how platform capabilities link up to business benefits) and also defines what a platform does. Here, the three things that directly give you ROI are CX (“customer experience,” I assume, which I’d call “good apps”), innovation (introducing new features, ways of working, ways of solving jobs to be done, and, thus, selling products and services), and cost efficiencies (spending less money).

Cost efficiencies is something you could do directly with a platform. It could cost you less in licensing and cloud fees, it could consume less underlying SaaS, it could require less people. The first two are fine and provable. The third is where ROI models get weird.

ROI by firing people versus doing more with the same

If you’re doing an ROI model based on people working more efficiently (“productivity”) the assumption you’re making is that you’re going to get rid of those people, reducing the amount of money you staff. But are you? Maybe long-term you’ll consolidate apps and platforms and then, a year or so out, layoff a bunch of people, realizing that benefit. If this is your goal, you’ll also need to contend with those future-fired employees reading the writing on the wall and saying “why would I tie my own noose?” and deploying enterprise-asymmetric psyops counter-measures.

Historically, the idea that automation is going to reduce staff costs has been dicey. You encounter Jevon’s Paradox: the cheaper it is to do something, the more of it people will do, often in excess.3

Thus, the more clever thing to do with productivity is to talk about how you can now do “more with the same.” You can give developers more time to work on more features, driving “innovation” and “CX.” Your operations people can now support more apps. Your cost of adding new stuff is cheaper. When you add ten more apps, you don’t need to add another operator or more developers because your existing staff now have more time available.

But, then you’re back to the problem of platform ROI: you’re talking about capabilities you get. And, until those capabilities are “realized,” you won’t know if your platform was useful. Also, there are so many things that could go wrong - or right! - that might be the more direct cause of success.

Nonetheless, I think the framing of “we never have enough time to do everything the business wants, right? If we had a platform, we would!” is pretty good. Instead of ROI, you’re directly addressing a problem, and a problem that’s stressful and probably keeps people up at night.

Three formulas for predicting and tracking ROI

The paper encourages the use of three formulas to track your platform’s value. You could use them to predict the platform’s ROI, but that would rely on you believing the input numbers you, uh, made up ahead of time.

• Value to Cost Ratio (VCR): VCR = (Projected Value / Projected Costs) * 100.

• Innovation Adoption Rate (IAR): IAR = ((Adoption in the current year - Adoption last year) / Adoption last year) * 100.

• Developer Toil Ratio (DTR): (Total Time on Toil / Total Time on Feature Development) * 100.

Here, you encounter one of the basic problems with any platform metrics: how do you collect those numbers?4

• VCR - this is what most people are after with “ROI.” However, how do you figure out those numbers? Proving the “Projected Value” of a platform is the whole problem!

• IAR - counting the apps on your platform versus all of the apps in your organization is achievable, more or less. People struggle with accurately tracking IT assets counting: most people don’t trust what’s in their CMDB, let alone have one, or, worse, even know what a CMDB is. But, I think most people can do some helpful app counting. This metric is tracking how much your platform is used. It assumes that usage is beneficial, though, which, for me, de-links it from ROI.

• DTR - this is the productivity metric and a good one. Collecting those two numbers, though, is tough. It’s probably best to stick with the “just ask the developers” method that DX encourages. That is, don’t waste your time trying to automate the collection of quantitive metrics, and instead survey developers to get their sentiment of “toil versus coding.” What I’d to this is that you should also consider the OTR: Operator Toil Ratio. How much time are you operations people spending on toil versus more valuable things. In the context of platform engineering, this would be product managing the platform: talking with developers and adding in new features and services that help them and other stakeholders.

I like this paper, and I think it creates a good model for even thinking about making the case for a platform and doing some portfolio management of platform engineering. Linking up platform functions all the way up to business outcomes (the big chart above) is great, and in many cases just using that big chart to explain the role platforms play in the business is probably very helpful when you’re talking with the Director of No. If that chart grabs their attention, the next conversation is talking about each of the boxes, what they do, and why doing it in a platform engineering way is better, more reliable, and “cheaper” in the “do more with the same” sense.

The Big Spreadsheet

The second model uses a large spreadsheet to track common developer activities, the cost of operations problems, and staff costs to show platform ROI. If you’re lucky, these are usually large spreadsheets with upwards of 50 numbers you need to input from salary, cost of hourly downtime, number of applications running on the platform, and the benefits of improving apps.

Once you “plug in” all these numbers, a chart with two lines intersecting usually shows up: one line is cost, and the other is benefit. At first, you’re operating in the red with the cost line way up there. Within a year or two, the lines streams cross, and you’re profitable.

Gartner has a pretty good one for platforms which, of course, I can’t share. Here’s another example from Bartek Antoniak:

One line I don’t see often are one-time-ish costs like the cost of migrating apps to the new platform and training people. Even cooler - but hard to quantify - would be the future cost of tech debt in the existing platform and app model.

Getting all of the input numbers is the problem, once again. How do you measure "increased speed of software delivery" and "mitigate security and compliance risk," or something like "optimize the use of infrastructure due to the self-service and developer portals"? How do trust those measurements and even the more straight forward ones like

There's a good trick here though: if it's difficult to gather those numbers, chances are you have no idea what the ROI of your current platform is (the "do nothing" option when it comes to introducing platform engineering). I suspect this is how most organizations are. The Director of No is saying platform engineering is a bad idea...but has no idea how to quantify how well, or poorly, the current "platform" is doing.5

Filling out the giant ROI spreadsheet will probably drive how you think of and decide on platform ROI.6 Tactically, this means that you want to be the first one to introduce a complex model like this if you're in a competition to get a platform in place. This could be if you're battling internal competition (some other group has an opposing platform and/or the option is to do nothing), or you're a vendor selling a platform.

Whoever introduces the ROI model first gets the define the ROI model.

Like canonical ROI calculations, these models are also showing you return over time, usually in three to five years terms. This can introduces an executive ownership problem. While the average tenure of CIOs is actually longer than most people joke about - four or five years, depending on the industry and geography - people move around on projects and within groups in IT.

A positive ROI model assumes you’ll see it through to the end without changing it. So, if the “owner” of the model has shifted and given ownership to someone else, you may not stick to the original plan. There’s also the chance that people will just forget what the point of the ROI model is and, more importantly, the plans that go with it. Pretty soon, you’re making new ROI models. A good test here is to see how quickly you can find the current ROI model (or “business case”) that you’re operating with.

Aggregate ROI

Instead of making a template for your ROI spreadsheet, you can aggregate the outcomes from several organizations. You still have The Big Spreadsheet in the previous example, but the point of the aggregate ROI is to show that the platform has worked in other organizations. The aggregate ROI is trying to convince you that the platform benefits are real and achievable.

Vendors like using these, of course, aggregating their customers. We put one of these out recently, done by ESG.

As ever, the problem with using this type of ROI is getting your input numbers. However, I think aggregate ROIs are good for both figuring out a model and figuring out a baseline for what to expect. Because it’s based on what other organizations have done, you have some “real world” numbers to start with. When vendors do it, these types of studies often contain quotes and testimonials from those customers as well.

You can hire Forrester Consulting to do their “Total Economic Impact” studies. Here’s a very detailed one from 2019 on Pivotal Cloud Foundry (now called Tanzu Platform for Cloud Foundry, or tPCF for short). Because they do these for multiple vendors, it’d be cool if they somehow aggregated all the aggregates. And I wonder if they use the same models for the same technologies?

You notice how I typed Forrester Consulting? That’s because it’s not “Forrester the industry analysts you’re thinking of.” Because you’re commissioning people to work on these TEIs (and other aggregate ROIs), it’s easy to carelessly dismiss them as paid for.

Sure, there’s certainly selection bias in these studies - you don’t hire them to analyze an aggregate of failures. But, these aggregate ROIs are still useful for proving that the platform works. That old TEI report interviewed four companies and based their model and report on them, same for the newer one. As with all the ROI examples, here, the aggregate ROI is also showing you an ROI model for platforms.

Us vendors have an obvious use for these PDFs: to show that our stuff is great! If you’re not one of us vendors, and you’re using these kinds of ROIs to get past the Director of No, I’d suggest looking at PDFs from rival companies and doing a sort of “aggregate of aggregates.” You’re looking to:

1. Prove the concept of platform engineering and the worth of platforms.

2. Show that it’s achievable at similar organizations - it’s not just something that Google or Spotify can do instead of “normals.”

3. Establish a baseline for results - we need to achieve results like these four other companies for it to make sense.

4. Create/steal a model - as with the last two ROI models, just having a model to start with is useful.

Beyond ROI

All of this started because someone asked me to help them put together a developer survey to show the value of platforms. A couple years ago I helped get the developer toil survey out. That survey doesn’t really address the value of platforms. You could use it to track ongoing improvement in your development organization, but attributing that to platforms, AI, or just better snacks in the corporate kitchen isn’t possible. I’d still like to know good survey questions that platform engineers would send out to application developers to gauge ongoing value.

Logoff

That’s enough for today! I’m already late for a call (tangentially on this topic!) so I didn’t even proof read the above. NEWSLYLETTERSSSSS!

Just links and wastebook today.

Relative to your interests

• Spring Boot 3.3 Boosts Performance, Security, and Observability - All these years later, Spring is still in wide use and still evolving.

• ‘You are a helpful mail assistant,’ and other Apple Intelligence instructions - Not that many, but interesting.

• Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025 - ”At least 30% of generative AI (GenAI) projects will be abandoned after proof of concept by the end of 2025, due to poor data quality, inadequate risk controls, escalating costs or unclear business value, according to Gartner, Inc. ” // Also a chart with rough estimates for initial and ongoing costs: input for an ROI model. // The other take here is that you need to start slow and small with enterprise AI: no one knows what will work, what good business cases are, what customers (and channels/suppliers/employees) will rebel against, etc.

• Nike: An Epic Saga of Value Destruction - The risks of shifting to a direct, Internet-based go-to-market. And, also, of focusing only on growing revenue from existing customers instead of also getting new customers: 'Obviously, the former CMO had decided to ignore “How Brands Grow” by Byron Sharp, Professor of Marketing Science, Director of the Ehrenberg-Bass Institute, University of South Australia. Otherwise, he would have known that: 1) if you focus on existing consumers, you won’t grow. Eventually, your business will shrink (as it is “surprisingly” happening right now). 2) Loyalty is not a growth driver. 3) Loyalty is a function of penetration. If you grow market penetration and market share, you grow loyalty (and usually revenues). 4) If you try to grow only loyalty (and LTV) of existing consumers (spending an enormous amount of money and time to get something that is very difficult and expensive to achieve), you don’t grow penetration and market share (and therefore revenues). As simple as that… ' // A little more commentary here.

• Where Facebook’s AI Slop Comes From - So cyberpunk! // ”the YouTuber who was scrolling through images of rotting old people with bugs on them.” // Related: ‘we don’t need the term “slop”. Consumers have decided that “AI” in its entirety is bullshit.’

• Teaching to the Test. Why It Security Audits Aren’t Making Stuff Safer - Bullshit Work in enterprise security. // Plus, why not start with basics before going advanced: ‘The world would be better off if organizations stopped wasting so much time and money on these vendor solutions and instead stuck to much more basic solutions. Perhaps if we could just start with “have we patched all the critical CVEs in our organization” and “did we remove the shared username and password from the cloud database with millions of call records”, then perhaps AFTER all the actual work is done we can have some fun and inject dangerous software into the most critical parts of our employees devices.’

• The Six Five: Advancing DevOps: Infrastructure as Code, Platform Engineering and Gen AI - “we see in our latest research that 24% of organizations are looking to release code on an hourly basis, yet only 8% are able to do so.”

• Why Is Demand Marketing An Obstacle To Its Own Success? - ‘Too many marketing subfunctions (demand/ABM, field marketing, customer marketing, digital, and events) create strategies unique to their function, independent from the others. Marketers often say that they have a “unified” plan, but it’s more like a PowerPoint deck with “chapters” for each team’s individual plan. This approach prevents marketers from orchestrating programs to reduce overlap and waste, and what’s worse, it has a direct, negative impact on buyers and customers.’

• The Prompt Warrior - Posts on prompts for all sorts of things.

• fabric/patterns - Whole bunch of prompts on a range of topics, even D&D!

• Why CSV is still king - We have a running joke on the podcast that every (enterprise) app needs CSV export. It’s only 10% a joke.

• Epic corporate jargon alternatives - Poetic alternatives to business bullshit jargon.

• 2025 Demand and ABM Budget Planning Guide: Do Better With Less - Enterprise software marketing budgets mostly flat, if not less: ”On the surface, it may appear as if most budgets are increasing, as 82% of global B2B marketing decision-makers report their budgets being increased by 1% or more. But once you adjust for inflation, it’s the same old story, as only 35% of organizations will see a real increase in budgets (with 31% of the 35% saying that the increases would be in the 5–10% range and 4% saying that their budgets would increase by 10% or more).”

The Dutch love Egg Salad and Potato Salad

This is in our small, neighborhood store. The larger ones have even more!

Wastebook

• “Kerfulle.”

• “gas station sushi” ROtL, 547.

Logoff

This is a really well put together presentation, with good content. It manages to introduce one, simple idea (and notice how she returns to/reminds you of it at the end), and yet not make it TED-talk level surface-level-simple. It gives you practical things to do if you want to work on “developer productivity.” And, it’s a perfect example of giving a vendor-pitch that doesn’t seem like a vendor pitch (one of the chief skills of a thought leader): customer cases with ROI, mention of the product being sold, and even screenshot-demos! It’s also re-usable and mine-able for EBCs, sales meeting, etc.