You are a company of one: Click here to watch the video.
If you liked that, there’s more of my take on “employee mode” in the ten part video series I did for O’Reilly: “How to Survive and Thrive in a Big Company: Tactics and Practices to Manage Your Time and Relationships.” How about that title, huh?!
If you work at a large company, you might even have access. Or, just get 10 days free.
Anyhow: watch the videos, and if you like them, leave a cool review. HEY GUYSZ!1!!
We’ve got to stop using the “is dead” thing. It’s hardly ever accurate and mostly a cheap trick. (It works in zero-sum marketing and community management sometimes, though: 10% to 20% of the time?)
“Autocado.”
‘(In his essay, Parini recounts an old story about the literary critic, Harold Bloom. Bloom was famously prolific, and the story goes that a graduate student once phoned Bloom and his wife answered and said: “I’m sorry, he can’t talk–he’s writing a book.” The student responded: “That’s all right. I’ll wait.”)’ Here.
‘The term “pseudoclarity” refers to a misleading sense of clarity that arises from overly simplistic metrics and frameworks, like those often used in Scrum methodologies. It highlights the danger of relying on superficial calculations and symbols that may obscure the true complexity and uncertainty of real-world projects, leading to a false sense of control and understanding.’ From “Tossed Salads And Scrumbled Eggs,” as understood by Perplexity.ai. Related:
It’s better to reverse engineer the strategy from how it gets implemented than pay much attention to the annual planning PowerPoint.
Or: strategy is defined execution, not PowerPoint.
“‘Deep doubt’ is skepticism of real media that stems from the existence of generative AI.” Benj Edwards.
I wouldn’t say they lied. More so that they did a bad job predicting.
“Rye is Canadian, right?” “You better find out.” Mad Men.
And: “I’m living like there’s no tomorrow, because there isn’t one.” “I don’t think I realized until this moment: but, it must be hard being a man, too.” Ibid.
Living the memento mori corporate life.
IDC #US52372824 (June 2024). Source: IDC DevOps Survey, - “79.1% of respondents are extending, using, or piloting Wardley Mapping to diagram the value chain and application components, demonstrating the value it can add to strategic application planning.” IDC #US52372824 (June 2024). Source: IDC DevOps Survey, November 2023, n = 311. // I never would have guessed that, but people do talk about those maps a lot.
Digital transformation strategies focus on reducing costs, upskilling - Highlights from Macroeconomic Outlook, Business Trends - ”Digital transformation focuses on employee productivity and automation. Nearly 44% of respondents either have a formal digital transformation strategy (32%) or are planning to develop one (11%). The primary drivers for adopting a digital transformation strategy are improving efficiency through process automation (59%), improving employee productivity (56%) and customer experience enhancements (47%). The main priorities in digital transformation are to improve workforce productivity and engagement experiences (44%), followed by intelligent automation to reduce/remove need for labor and manual processes (43%). Modernizing legacy back-office (e.g., ERP, supply chain) and front-office (e.g., customer relationship management, e-commerce) applications is also a top priority in digital transformation.”
Free ‘JavaScript’ from Legal Clutches of Oracle, Devs Petition - This seems like a don’t wake the sleeping bear situation.
The types information available on the internet and why AI is bad for all of them - ”For example, if I’m looking to buy an ergonomic chair and I read a review that says “I’m a 6’3” man and this chair is absolutely perfect for my size,” this anecdote provides helpful information to me in a way that simply reading the measurements does not.”
AI is great for churning out apps, but don’t forget to test - Enterprise AI needs testing just like code needs testing. // “Research published by Leapwork, drawn from the feedback of 401 respondents across the US and UK, noted that while 85 percent had integrated AI apps into their tech stacks, 68 percent had experienced performance, accuracy, and reliability issues.”
Customers don’t trust AI, and the rift might be hurting business - ”Participants were then asked questions to determine their willingness to buy the TV. Those who saw AI in the product description were less likely to make the purchase.”
CIOs: Get Tech Sprawl Under Control - “According to Forrester’s Q2 2024 Tech Pulse Survey, a staggering 77% of US technology decision-makers report moderate to extensive levels of technology sprawl. This sprawl can result in unsustainable costs, slower IT delivery, reduced operational resilience, and increased security risks.”
Business leaders are losing faith in IT, according to this IBM study. Here’s why - “Fewer than half (47%) of business leaders surveyed think their IT organization is “effective in basic services,” down from 69% surveyed in 2013, the survey shows. Only 36% of CEOs in the survey see IT as effective, down from 64% since 2013. Chief financial officers give a bit more credit to IT, with 50% seeing its effectiveness, but this is down from 60% since 2013.”
IBM buys Kubernetes cost control startup Kubecost to expand its FinOps suite - They’ve bought a lot in this category - solution suite’ing. ”IBM said Kubecost’s capabilities will be integrated into an expanding FinOps Suite, enhancing the combined capabilities of Apptio, Cloudability, Instana and Turbonomic to provide what will perhaps be the most comprehensive cost monitoring toolset around. The company didn’t say so, but there is clear potential for Kubecost’s technology to be integrated with IBM’s OpenShift application development platform too.”
How PepsiCo capped cloud overspend - ‘“FinOps is all about evangelization,” Woo said. “This is probably the most difficult side of running a FinOps practice, because when you are a FinOps practitioner you’re trained to do IT work. You may have had a finance background. You weren’t trained to be a mediator or therapist.”’
Talks I’m giving, places I’ll be, and other plans.
Cloud Foundry Day EU, Karlsruhe, Oct 9th. VMware Explore Barcelona, speaking, Nov 4th to 7th. GoTech World, speaking, Bucharest, Nov 12th and 13th. SREday Amsterdam, speaking, Nov 21st, 2024.
Discounts! SREDay Amsterdam: 20% off with the code SRE20DAY. Cloud Foundry Day 20% off with the code CFEU24VMW20.
// I’m pretty sure it was Brandon who came up with the phrase “employee mode,” just in the off-handed way that you do in a podcast. It’s great, right?
// Thanks for subscribing! I think we’re on track to 1,000 subscribers sometime over the next two months. That’ll be thrilling! You know: tell a friend, recommend it, etc. IT MAKES ME HAPPY.
See you next episode.
There's not that many people who've worked through the early years of cloud, the rise of cloud and IaaS, DevOps, cloud native apps, and now platform engineering...but my colleague Purnima Padmanabhan sure has. So, it was fun to talk with her about the history of all of that - something I've been involved in and equally curious about these past 20+ years. We also discuss the differences between startups and large companies - most interestingly Purnima’s take on what large companies can learn from how startups operate. Listen to it here, it's was a fun interview
Here’s a more detailed overview:
In this episode, Purnima Padmanabhan, the general manager of Tanzu at Broadcom, talks with Coté about the evolution of DevOps and platform engineering. Purnima has worked at many interesting over the years LoudCloud, BMC Software, and VMware. That experience gives her a great perspective on the industry's ongoing journey to empower developers to deploy code into production quickly and reliably. The discussion follows the industry innovations and trends from early infrastructure automation to the rise of cloud computing and the emergence of platform engineering.
Purnima highlights the enduring challenge of bridging the gap between development and operations, emphasizing that the core objective remains consistent: accelerating the time it takes to move code into production. She underscores the importance of continuous improvement, noting that the industry is still striving for perfection. The conversation also delves into the nuances of platform engineering and DevOps, exploring the balance between standardization and flexibility, the role of automation in fostering trust, and the enduring need for both development and operations roles.
Purnima also discusses her experiences at various companies and the lessons she's learned throughout her career. Listen in to this 20+ year journey from LoudCloud's early foray into cloud computing to BMC's focus on process automation and VMware's cloud management solutions, all the way up the Tanzu's focus on cloud native development and platforms.
I keep putting off rounding up interesting links and fun fines. It’ll finally be in the next episode! // I’m speaking at SREDay London this week. I’ve got plenty of time to actually take in the presentations and talk with people this time so I’m hoping to get a little snap-shot of what’s up with SRE now-a-days.
Let’s start with some good looking cheese:
Establishing an internal community is one of the keys to enterprise platform engineering. A lean platform team can’t support all the support and consultative requests from thousands of developers. When you create and garden an internal community you’re trying to get the developers to talk with each other and help solve each others problems.
In a talk at Explore going over their general platform engineering group, Jürgen Sußner went over this tactic. I wrote-up my take on using internal communities for support and platform innovation over on the Tanzu blog.
Jürgen works at DATEV, a German company that makes widely used accounting software. They’ve been running on Cloud Foundry (via the Tanzu Platform) for over six years and now are supporting over 1,200 apps and services that span 18,000+ containers and 8,000 virtual machines. There’s over 2,000 developers using the platform. So, the stories and advice they have are pretty enterprise-y, exactly the kind of scale I like the study.
Anyhow, here’s my write-up of Jürgen’s story of the internal community their platform team relies on. This pattern comes up a lot in other organizations that have been running platforms for a couple of years, like Mercedes and Garmen.
Take a listen this week’s podcast episode:
This week, we discuss Dell's growth in AI servers, GEICO’s transition from VMware to OpenStack, and the concept of Kingmaking. Plus, plenty of thoughts on USB hubs.
Talks I’m giving, places I’ll be, and other plans.
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.
There’s not enough links or wastebook entries to include, so I’ll ball up some more and put them in the next episode.
Today it’s just links and fun finds that I’ve been storing up for a about a week.
I asked Perplexity about the US presidential debate last night. I wasn’t very interested in “fact checking,” but in how different the coverage in the New York Times and Fox News was. I added in a “partial transcript” of the debate as well to compare both to what actually happened.
The two outlets obviously watched a different TV show than the other, possibly broadcast from two different parallel universes.
The other interesting part was asking the AI what was not covered in each article: climate change is the biggest one, it seems. At the end, I asked it to make D&D characters for each. Overall, it was pretty good - at least enjoyable to read.
Anyhow, I also asked it to write an overview at the end. It was predictably boring in that it was devoid of any point of view. Meanwhile, here’s the view from across the pond in The Economist - plenty of PoV and style as usual.
Oh, and Gemini just flat-out chickened out and wouldn’t do anything. I tried to outfox it by saying it was a fictional transcript, but it was too wise.
(And, yes, obviously generative AIs don’t actually think anything about the debate, they’re just doing their thing outputting what seems like the word that follows the one before it.)
Charles Schwab Adopts PostgreSQL (With VMware Tanzu) - Why Charles Schwab chose Postgres over Oracle, and chose to pay for Tanzu Data Services support.
Cycle Time - Time spent figuring out this nuance is time spent not coding and getting your apps out the door and kicking in the product management feedback cycle. Still, good discussion of the nuances of the phrase.
2025 IT Budgets See 5.5% Increase as CIOs Invest in AI and Cloud - “With a projected 5.5% increase in IT budgets, the year ahead is set to focus heavily on artificial intelligence (AI) and cloud computing.”
Executive translation - “Many high-agency managers try to prevent executives from doing silly things, but it’s almost always more effective to translate their energy for a silly thing into energy for a useful thing. It also leaves the executive feeling supported by your work rather than viewing you as an obstacle to their progress.”
How Heroku Is Positioned To Help Ops Engineers in the GenAI Era - “We decided that the best thing for us strategically was to use Kubernetes underneath the covers, essentially to replace a lot of the code that we have been using to do the same thing. That’s a big migration effort for us. There’s a lot of expertise that needs to be built.”
Oracle Runs OCI Clones At Rival AWS, Google, And Azure Clouds - Oracle runs its stack in the various clouds.
Admins wonder if the cloud was such a good idea after all - ”According to a report published by UK cloud outfit Civo, more than a third of organizations surveyed reckoned that their move to the cloud had failed to live up to promises of cost-effectiveness. Over half reported a rise in their cloud bill…. Although the survey, unsurprisingly, paints Civo in a flattering light”
Five Lessons Learned From a Lifetime of Platform-as-a-Product - Text version of a good talk.
DOJ, Nvidia, and why we restrict monopolies - “A company getting it right does not give it some kind of permanent license to coast while printing money. The question that all antitrust seeks to answer is simple: how much is enough? When do the well-deserved riches and power that accumulate to companies that make big bets, execute well, and invest wisely start to be toxic for society or humanity as a whole, and for competition itself? Are the riches that the largest companies make earned, or are they simply the product of being large? If it’s the former, great! But if it’s the latter…”
Platform Engineering Reshapes Software Dev at Bechtle - Customer case or Bechtle using Humanitec.
What with our big conference, there’s been lots of coverage recently of VMware. Here’s some. I think the new strategy - focusing on private cloud - came across clearly.
Under New Management: Impressions from VMware Explore 2024 - “Tan made comments about not chasing ‘bright shiny objects.’ The context around these comments – particularly from the analyst session – indicate Tan’s statements could reasonably be interpreted as pointed commentary about Kubernetes. The Tanzu platform has two available runtimes: Cloud Foundry and Kubernetes. More airtime was given to Cloud Foundry than Kubernetes, and the leadership team made statements about ‘focusing on existing customer success.’ All together, there were signals that read as the company focusing on nurturing the assets from the Pivotal acquisition over the Heptio acquisition, and prioritizing solutions centered around its VM-centric past more broadly.”
Tanzu 10 Sets New Standard for Private Cloud-Native Platforms - ”According to a recent survey by Futurum Research, organizations that have adopted cloud-native technologies have seen an average of 20% faster time to market and a 15% reduction in IT costs.”
Broadcom CEO: VMware still ringing the cash registers - 'That translates into 32% quarter-on-quarter VMware bookings growth." And: ‘When it comes to revenue tailwinds, AI is driving “about two-thirds in compute and one-third in networking” said Broadcom CFO Spears.’
Broadcom VMware acquisition sees profitability amid disruption - “As long as [Tan] keeps the [total cost of ownership] for running a workload under the cost of the public cloud and under the cost of comparable competitors, he’s good,” Ellis said. “But the bar was low … essentially [VMware] was the discounted enterprise virtualization suite for Dell and EMC, and they used it to sell hardware; they used it to sell the other parts of their infrastructure. The price was artificially kept low, and essentially Hock Tan is allowing [time] to figure out, ‘Will it sustain this higher price?’ I think when you talk about the inertia, when you talk about how well embedded it is within the tech stack, the answer’s probably going to be yes.”
“At the average organization, 56% of teams utilize a DevOps methodology. Organizations expect this to grow in 12 months by about 6 percentage points. However, it has been 15 years since the inception of DevOps, and organizations are still struggling to expand the adoption of DevOps across their application estates.” IDC: “Development Tools and Applications, 2024.”
In tech, don’t confuse the story that drives your valuation versus the features that get customers to buy your products.
Life is short. Don’t waste it eating chicken breasts.
“tentacles of spend”
“no Facebook employee has, to my knowledge, been killed by cannon fire” Here.
And: “who remembers DR-DOS?”
“We become Old, before we have been able to taste the Pleasure of being Young” Here.
It’s one dimensional chess at its finest.
“galaxy-brain peanut gallerians” here.
Talks I’m giving, places I’ll be, and other plans.
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.
In AI-land, I’ve been using Gemini and Perplexity more than ChatGPT. I re-signed up for Gemini and…it’s fine? I use Perplexity to the most for basic search and summarizing. Gemini isn’t that great at D&D - ChatGPT feels better. But, I’m still at that ceiling of usefulness for chat AI: without spending a lot of time, I can’t get the results I’m looking for. And that’s the point: it should be quick and effortless.
What I’m liking about Gemini is: it’s integration into the rest of Google (Gmail, docs, Google Drive, etc.) and that you get 2 TB of storage. This means I can use Google Photos again. ChatGPT can import Google Docs, and you can of course upload files, but it’s a lot different to just have Gemini right there in a document you’re working on, or in email. One theory: chat AI is just a feature, so without integrating with and/or owning the rest of the apps, it’ll quickly become less useful.
I used Gemini to help me figure out what to write about for a recent blog post, but it wasn’t good at doing the actual writing. Still, as an assistant it worked, this once at least. The “copilot” idea is a good one.
Gemini still can’t tell me the top five people I emailed in the 2000’s. It just says it can’t do that, despite having all of my email. Something like perplexity would figure out how to search all my emails, sort them by frequency, and then output that. I think?
I still think that the only people who think AI is going to change everything, is super-cool, are people who don’t use it much. The initial impression is amazement, but then you realize it’s just a dancing bear.
The DevOps community is running on fumes and at the lowest point in mindshare and interest that it’s ever been at. This is stupid. The practices, tools, and mindset of DevOps are vital to how most organization run their software1 and DevOps has improved the way the software we use everyday is built and run, improving all of our lives. If DevOps wasn't a thing, the world of software would be worse and each day would be a little more tedious because the apps we depend on would be worse.
Here's what I think DevOps needs to do to come back from the dead:
Developing software and building digital capabilities is becoming ever more complex. By 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components and tools for application delivery - up from 45% in 2022. Gartner, circa 2024.
"Platform Engineering," is fine, but creating it as separate, new method of work has done a disservice to DevOps. Shoving DevOps into a grave was also a bit rude.
Platform engineering was a very well done marketing strategy to establish a new market for a handful of portal vendors to start working in. All of us joined the momentum of platform engineering. I have done it many times, and probably still will!
Much like The 12 Factor App, a piece of brilliant technical marketing, platform engineering has actually become its own, legit thing now. But, that early strategy of stealing the sun-light from DevOps made platform engineering seem like more than it is. Platform engineering is just DevOps with one small thing: adding in product management.
The rest of platform engineering is just adding new tools to the DevOps toolchain: primarily internal developer portals and all of the work and tooling that goes into making Kubernetes usable for developers. Over the next 12 months, platform engineering is going to take hold in "enterprises" (see Gartner prediction above), which is what I call large organizations that are not tech companies: you know, IT normies. There's early use here-and-there in enterprises,2 but not at the scale of DevOps, or even cloud native (you know, architecting your applications in containers).
The DevOps community has to take over, gobble up, or otherwise “ride” the platform engineering wave or get drowned by it, lost in the deep like some ancient city. It's too late to reverse the name. And, really, "platform" as a name is incredibly valuable and descriptive, and "platform engineer" is a fine synonym for "DevOps engineer."
The job title might even do a good job to clean house on what exactly a "DevOps engineer" is. This is the case with DevOps in general: it's become so dominate that “DevOps” has started to mean most anything, and everything related to building and running in-house applications. This is not good!
When suggesting such a thing, one must always begin with praise.
The community-driven, global DevOpsDays organization is one of the most unique assets in the IT world. At the moment, there's nothing like it: a vendor-independent, volunteer-led organization focused on industry best practices that holds regional events to educate and enrich the community.
Let me do some boosterism here:
Being vendor-independent is important for two reasons. First, it means the content is actually practical and "true" without the bias of a commercial agenda. Second, it means that all vendors feel comfortable sponsoring DevOpsDays. Vendors are incredibly important to the DevOps community. They're the ones who have funded its existence! If the overall community and DevOpsDays was owned by a single vendor or an oligopoly it wouldn't have been successful nor valuable. Vendors have an agenda to sell their products and their market category (people who sell on-premises software want to show buyers why private cloud is the best, people who sell public cloud software want to show buyers why on-premises software is better, people who have new tools of monitoring and log management want to explain to you why the old ways suck - shocker!). Vendor's budgets also come and go at the whim of their business, new technologies, and macro-economic headwinds. One year, the company is focused on growth at all costs to drive company valuation, the next year the company is focused on cutting costs because a PE firm bought them. One year, money is cheap, the next year money is scarce. One year, DevOps is important, the next year generative AI is important. Budgets shift! In short, depending on vendors to support an ongoing, multi-decade community is risky.
The volunteers are the ones, then, who make it all happen. The passion that DevOpsDays volunteers have for the DevOps community and event is extremely rare in other parts of IT. Even the agile community doesn't seem to muster enough energy to put on so many conferences. I don’t think application developers can be bothered to look up from their IDEs. There are regional meetups and user groups in IT, sure, but I don’t think there’s anything close to the scale of DevOpsDays. While my overly utilitarian, cold heart might ache at all the "culture" talk in the DevOps community, that vibe is incredibly real and important: it becomes part of the identity and lives of these volunteers. I don't want to see that lost, and it's a huge asset that the IT community should cherish and protect.
Focusing on best practices means that the talks, workshops, and discussions at DevOpsDays are focused on continually improving the IT community. There have been four, maybe even five stages of DevOps over the past 15+ years. The DevOpsDays talks focus on what the DevOps community needs help with at the time. You can see this in the community's shifting from automation (infrastructure as code, immutable infrastructure, Puppet, Chef, etc.), to monitoring and management (observability, chaos engineering, etc.), to culture (how people work, the mindsets that lead to good outcomes and good lives), to filling the usefulness-gap created by people's over-enthusiasm for Kubernetes, to the present.
DevOpsDays are in-person which is the most effective way to educate the community and keep it thriving. More than many other in-person events, the edge that DevOpsDays has is that the events are regional. They’re all over the world. This means that people in the DevOps community don't have to pay to travel, and if they do, it's usually just an hour or two to go to a nearby city. Compare this to one, large event a year in Las Vegas or Barcelona. The audience and community reach for DevOpsDays is so much larger and, thus, more effective.
The survival of DevOpsDays is more important than the survival of the name DevOpsDays. Because the platform engineering community successfully stole so much of the mindshare, they've sucked much of the sponsorship money out of the DevOpsDays. Worse than redirecting the money is drying the money up all together. Marketing budgets are tight now-a-days (I'm not sure why: vendors want to sell more than ever) so the people controlling event sponsorship money is looking for an excuse to cut costs. And, of course, there’s the redirection that platform engineering, drawing attention and therefore people away from DevOps.
There is currently no platform engineering set of conferences like DevOpsDays. PlatformCon is a good, online conference. I enjoy the recordings, have presented at them, and have encouraged other people to present. The PlatformCon crew is building up momentum for more in-person events (see all the regional group on their above page) - this is great! Good for them! Yay! RIP-TAYLOR-CONFETTI-BLAST!
But it will take years to replicate the reach and assets that the DevOpsDays community has.
I know it feels weird to the DevOpsDays people - it feels weird to me! - but renaming DevOpsDays to PlatformDays would solve a lot of problems quickly. Maybe the PlatformCon community could even merge with DevOpsDays, joining up the benefits of both. I don’t know. Maybe.3
DORA is probably the most important marketing asset DevOps has and has had. And it's a genuinely useful tool! DORA’s work is what helped spread DevOps into the mainstream, all those "enterprises.” And the annual cadence and DORA community has helped DevOps evolve, and kept it alive.
The problem DORA has now is that most people focus only on the four DORA metrics. Common lore is that those enterprise normies don't look beyond the four metrics. This extends to DORA's annual clustering of elite, high, medium, and low performers: these are rankings. Those are just small parts of the overall knowledge in and utility of DORA. I don't think this short-sightedness of DORA users is intentional, or even conscious. It's how just people work.
Whenever you put metrics and rankings in front of a corporate-human, eventually they'll focus most of their intention on upping their ranking. People do this because they think that being successful means being ranked high, getting a good score/grade. This is because that's how rewards are given in most organizations! Gaming metrics is the most rational thing for a person to do in most organizations. Each year, DORA refines high-grade fuel for this way of working and thinking.
Just as it's not really the fault of the users, it's not really DORA's fault either. But, DORA can help people do better by re-orienting their annual work.
First, the value of DevOps practices are not really in dispute. We all know that they're good. As with flossing, we all know that we should do the practices. DORA shouldn't stop gathering and analyzing these metrics, nor reporting on them.
What DORA needs to do is move the focus reporting on the actual practices people follow. The activities they do day-to-day, the tools they use, that lead to the great results and clustering.
Of course, DORA currently cover this, but over the years the reports have focused more and more on a discussion of the survey and mechanics of the research rather than actions to take. This is fine! I get it - I have an engineering mindset and I would rather tell you about the internals of what I build, how I did it, and, most of all, what's cool about it. But the DORA-users need a tool. They need to know what to do, not why they should be doing it.
Sure, there's a danger that the users apply tools the wrong way, and you end up with a similar trap of focusing just on the four metrics. But, I mean: let's have a little more faith in people, and DORA’s ability to avoid that.
Let's also take a lesson from Extreme Programming. Extreme Programming is incredibly prescriptive. And, while I don't want to speak on behalf of the priests of that community, over the past few decades there's been a latent operating principle of using Extreme Programming: start with following all of the strict practices, learn what works and doesn't work in your organization, adapt the practices, and start the loop over again. That is how the DORA practices should be applied, and it should be the mission of DORA to make it happen.
In the most recent DORA report (2023) an easy to use discussion of these practices doesn't start until page 81 (out of a total report size of 95 pages). I confess my laziness here and apologize if it resulted in error, but after a few quick flips, I couldn't even find where the practices are covered after flipping through the 77 pages of the 2022 report, the 45 pages of the 2021 report, and had to go all the way back to 2019 to find this on page 31 of 82 pages:
…and page 57 to find the equally valuable this:
There's a snark in the DevOps community that the problem with Accelerate is that everyone who read it came across the four metrics on page 17, declared that they had all they needed, and then closed the book. Well, how about we put a discussion of practice - these very charts - on page one, or, at least page 9.
People in enterprises who are struggling to get better at software need this kind of material: easy to understand, focused and quick, and possible to put into place practices. How do you ensure you floss everyday? First, buy some floss. Second, put it where ever you brush your teeth. Third, notice when you do it and don’t do it. Fourth, keep trying to do it better each day. Life-hack: put it on your desk and turn off the camera when you're bored in a dumb Zoom meeting you can't get out of, and floss. You could also keep the camera on.
The "model" (as I think DORA calls it) is there, and it's even nicely done on the DORA community site (see the figure at the beginning opening of this section). What I'm suggesting is that it should the primary, the first focus of each report. When you email around a 45 to 95 page PDF in enterprises you have one shot to get people to read it and benefit from it. They're looking for the most effective tool they can use right now to achieve whatever goals they have. That practices chart is the tool they're looking for and it should be the first thing they see in the 30 seconds they're going to spend on that PDF. The rest of the work is great, valuable, and hard to do, but those are the "backup slides" that you'll use once you get people's attention and show them what you're proposing.4
We don't need further proof that flossing is good, nor to be told that people who floss have elite teeth. We need to know the mechanics of flossing and how to build a system that lets us put in place continuous flossing.
I give platform engineering a hard time because the people who launched it tried to push the DevOps community in the grave. Or, I don't know, maybe they were just having fun with the headline. Har, har, har…good one.
But, rasing the prominence of product management is an incredibly valuable thing that the platform engineering community has done. And it’s why I think it’s a good, helpful body of work.
The ideas of product management - identifying your customers/users and using, their problems/jobs to be done, crossed with what is technically feasible, and using feedback loops to continuously build a product that best solves their problems…with software - haven't been a large part of the DevOps community. The platform engineering community frames their work as building platforms for application developers, treating them as "customers," and, therefore product managing infrastructure for application developers.5
Sure. Absolutely. Without a doubt. The DevOps community has wanted that outcome and worked towards it. It's right there in the name: Dev! But product management as a practice hasn't been a focus in the DevOps community. It should be! There is a-funny-because-it's-true joke that there are very few devs at a DevOpsDays conference.6 The same is true for the community as a whole.
The good news here is that product management is one of the most understood, well documented, and proven methods of working in software. Thus, from a regular person's perspective - those people enterprises - product management is straightforward and learnable.
Despite product management being easy enough to learn, I think it’ll be incredibly difficult for enterprises to add product management to their infrastructure/DevOps/platform groups. They’re going to need help, and the DevOps community has a proven track record for such tough work.
Some of the people who introduced product management into infrastructure ("platforms") over the past ten years have done a great job grafting their term of art, “platform as a product,” into platform engineering. And it's stuck! I wish this had happened in the DevOps community, but because the platform engineering fig vines took over, it didn't.
Well. You know. We should bring product management into the DevOps world.
For example, DORA could start incorporating it into their studies. While product management is understood for applications, there's not a lot of work on applying it to infrastructure (yes, again: "platforms," if you prefer) and developer tools. Us vendors know about it since it’s our business, but figuring out how to do it in enterprise infrastructure (or even apps!) isn't much studied. DORA can do that, and it'd help clear out some of those vines if they did. (I know the Puppet study-surveys are going for it, so good on them!)
In fact, I'd go as far to say that product management is the missing piece for the wider success of DevOps.
(Now, if you wanted to be clever, you would think this: platform engineering is focused on developers and product manages for them. DevOps will do that, of course, but what a DevOps person will tell you is operations people are also customers [and maybe security people if they behave]. Why not product manage for ops too?)
Listen: I know! I hear you.
But, I'm not saying your efforts are wasted - it's all good stuff. We just need to do more. We need to adapt and change. Fast feedback loops, continuous learning, and changing to do what works are core principles of DevOps. This is what I'm seeing in the feedback loops and the theories I have for how to get better.
I give a huge, massive, rainbow-smelling shit about the DevOps community. It's been a positive force in my career and life. Many of my friends are in the DevOps community and going to DevOpsDays is how I see them. It’s fun! DevOps has also had an important, large impact on how the world builds and runs software. And not just “hats on cats” apps, but apps that you and use everyday to run our lives.
There's a lot of existential malaise going on in the DevOps community, especially among the most enthusiastic and committed members of the community. Some (many?) of the original DevOps community members have drifted out of the community, and will sort of roll their eyes over the whole thing over drinks. There isn't a better community in IT than the DevOps community - it's managed to remain kind, helpful, and nice. I'll be sad if we can't keep it alive and thriving.
I guess what I’m trying to say is: DevOpsDays Antwerp was good. It was nice to visit with everyone and see some great talks.
Lazily aggregating analyst surveys, I’d say that about half of the relevant IT people “do the DevOps” in the surveyed organizations. And, if you look at the progress made in things like speeding up release cycles, things have improved a great deal even since just 2018. DevOps is successful, so much so that we don’t really think of it much anymore: “this is water” and all that.
Please, oh please, ask me about the VMware Tanzu by Broadcom customers who’ve been doing platform engineering for five to ten years and how the products that help pay my monthly bills have made it possible. I’m just waiting, right here. Pick me, pick me! Still here. Yup.
I mean, if Gene Kim is going to rename his DevOps event, it’s probably OK and it might even feel good.
The irony of this post being well over 2,700 words is not lost on me. More now that I wrote this footnote.
Here are three great places to start with exploring what product management means for infrastructure: (1) "Platform Engineering at bol: Unveiling Insights from Adopting a Web Portal," Onno Ceelen and Roy Triesscheijn, June 2024. (2) “Boosting Developer Platform Teams with Product Thinking,” Samantha Coffman, March 2024; (3) “Designing for Success: UX Principles for Internal Developer Platforms,” Kirsten Schwarzer, March, 2024. There’s also an emerging understanding that you have to market and even devrel your internal platform. That’s something equally kind-a-sorta not covered in the DevOps community.
As a rule of thumb, you can tell that someone is new to the DevOps community if they ask how many developers are in the room and especially if they start addressing developers, “well, as the developers in the room know…”
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:
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?
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?
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).”
“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.
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.
As more examples, there’s some general IT/business alignment cheap-tricks discussed in this excellent video.
It’s hard to find a list of the 12 proverbs. But, later in life he did a much larger picture, in the Brueghel style you’d expect, of Netherlandish proverbs which are much better documented.
Just links and fun finds.
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.
“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.
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!
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.
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:
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.
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.
There are data services built into Tanzu Platform as well: Postgres, MySQL, Redis/Valkey, Rabbit, Greenplumb (data warehouse), GemFire (in-memory data grid
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.
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.
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.
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.
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.
You’re supposed to just drop the “The,” as in “Tanzu Platform is super cool.” I can see that that’s, like, grammatically correct or something (you don’t say “The Red Hat Enterprise Linux”). But, I don’t like it. Pardon me if I slip in and out of the’ing.
As an old Pivotal person, I would like to point out that you can call it TPCF. You could even just say tPCF. And if you were really being off-brand, you could say “you, know, the ‘T’ is silent.”
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!