2026 is a great year to be a Java developer and a Spring developer using the Spring Framework, and I'm gonna go over why that is. Of course, the most interesting thing going on at the moment is how AI and especially code generation is affecting things, which I'll touch on a little bit.

So there's three things I'm gonna go over. One is that Spring developers are thriving nowadays. There's a lot of activity, probably more than ever, and they're doing great. It's the number one framework used for enterprise applications - the applications running the world. It aligns perfectly with the top CIO priorities, with what organizations are doing, and as always, it's got all the great new features that developers want to use and that are actually useful in the applications you make.

Now, like I said, AI is incredibly popular and "impactful," if you'll pardon the phrase, and this is where Spring is really showing a lot of its worth and its value. I think that a lot of the people doing Spring development are working in private cloud settings. They're running and managing the stacks on their own, as we'll see. In that setting where you're adding AI to your applications, or you're using AI in your tool chain, the way that you're doing development, once again, Spring is very well positioned, especially when you pair it with a proper platform like the Tanzu Platform.

All of that said, something that's very important for people to focus on in 2026 - as it was in 2025 and all the twenties - is making sure that you are upgrading Spring, that you actually are using the newest versions of it. Not only for those new features so that you can do AI stuff, but also so that you're delivering on the security and performance you want to have.

Spring is thriving

Now let's talk about the thriving nature of Spring. Especially if you're watching this and you're a Spring and Java developer, you have a sense of how much Java and Spring are used in the world. And when you actually look at the numbers, these numbers demonstrate it. You can see the amount of downloads from various repos, the number of GitHub projects that are out there, all that kind of stuff that you use to track the momentum of Spring. You can also see the breadth of functionality. As always, Spring has a tremendous amount of libraries.

The goal of Spring, at least in my mind from when I was doing Spring development, is to make it as easy as possible for developers to do the common things they do day after day, and just to let them focus on the actual business logic - the application they're doing, not all that wiring together and framework stuff.

There are other sources for the thriving nature of Spring. Let's look at it by looking at the usage of Java. This is from the RedMonk Programming Language Rankings. I used to work there quite some time ago, and you can see what they've tracked over the years based on conversation on the public internet and some of their own analysis - that is, at Stack Overflow and GitHub. You can see Java has consistently been in the top three for well over a decade. And this matches the intuition you have, right? Everyone uses JavaScript. It makes sense. So it's almost like a secondary language that people have, although it gains in popularity as its own thing in recent years. Java has been up there forever, and only recently in the RedMonk ranking did another language - Python - take over.

Now I still think that if you look at the bulk of Java running out there, that's not on the public internet where RedMonk is basing the survey data on. You'll find that the majority of applications running run on Java, and therefore they run on Spring. And therefore the majority of applications out there are using Spring. If you're using Java, you're probably using Spring, or at the very least, it's the number one framework out there.

And to add credence to that, if we look at another analyst at IDC who focuses more on enterprises, and whose survey methodology doesn't just rely on public sources, what you see is that over the years when they do their surveys, in enterprises and large organizations doing business applications, Java is the language used the most.

Whatever surveys you look at, whatever they're based on, what you'll find is that the surveys match the intuition you have. Especially when it comes to business workloads - as boring as that sounds, but things at banks, insurance companies, manufacturers, retail. Things that aren't basically taking pictures of cats wearing hats eating sandwiches, or people dancing, or things like that. Java is the underpinning of what those applications are, and has been for decades. And again, if you think about the momentum and the importance Spring has - also based on surveys and intuition - Spring is probably the number one framework used in all of these applications. So having that knowledge is not only more relevant, but is gonna allow you to have the widest amount of applications you work on. The biggest, if you'll pardon the phrase again, "impact" - the most importance in what's going on day-to-day in regular application development.

Spring matches CIO priorities

Another way of looking at that: if you look at surveys about what the priorities of organizations are, based on CIO priorities, you can look at the list and pretty much all of these map to what Spring will deliver for you. (The list I'm showing comes from a Forrester study commissioned by Broadcom, "Modernize Or Fall Behind: Rethinking IT Infrastructure For A Competitive Edge," October 2025.)

Security is always the top ranked one, and we'll get into how Spring - if you keep it upgraded and run it in a proper environment - really addresses the security concerns you have, and has been relied on for decades by large organizations to do that. If we look at these other things, especially things like modernizing applications, figuring out what to do with AI, putting it in applications, taking advantage of it, also getting performance improvements on infrastructure - I would argue each of these things is something Spring really helps with. It will help deliver on these priorities your CIOs have.

So think about this as far as the thriving nature of Spring. By my reckoning, it's the number one framework used for the most enterprise applications - the most real applications out there. This is derived from Java being likely the top language used to run these applications, and Spring being the top framework used there. If you look at what organizations are focused on - what they want to deliver on their priorities - you can see how Spring helps out with every single one of these things.

AI: the existing-Java-codebase flywheel

Now let's get into the AI part. This is where Spring and Java really has strengths, and where you see the nature of Spring, the philosophy it has, and the investment you have taken in learning Spring and doing it - and also as an organization - really starts to pay off. You can see the long-term strategy of Spring demonstrate itself when something new and interesting and very important like AI comes along.

The first thing is what you might call a flywheel effect, a perpetuating source of being good. And that is because Spring has been used for so many decades. And of course, Java. If you look at all those applications out there, there are so many of them written in Java. And more importantly, a Java developer understands the business logic that's codified in Java code, and therefore in Spring code.

What this means is that when you're using software, when you're writing software to run your business, the code you write personifies and does all the operational stuff, the process of your application. We all interact with businesses through software now, and so software is core to the business. If you took away software - if you took away all those Java apps - the business would collapse. And because of the importance of Java, I would say civilization would have a bummer of a time after that, if you just sucked it all out.

Because there's this momentum, this huge amount of Java applications running the world, what you have is an expression of how businesses run. It's codified there. You don't have to discover it and make it up. It's right there in the Java code, and not only is all that business logic in there, but it's actually running. It's performant. It's been road tested and battle hardened. We know how to run those things. And by definition, because it's there running civilization, it works.

That's why I think, when organizations are thinking about applying AI to their applications - putting AI in their applications - a huge amount of them go to Java, because that's what they have. That's where the business logic is. That's the part in their stack, the software they've written that runs their business. They don't wanna just start off writing a brand new thing from scratch in Python, let alone TypeScript, even if they're vibe coding it. Because you've got years of testing it, years of making sure it works, years of day-two operations that you need to do, and that's all taken care of with Java. All you need to do is add AI into your Java workflow. 62% of enterprises are now using Java to power their AI apps - that's not a coincidence; it's where the business logic already lives.

Rod Johnson - the original creator of Spring - said something similar recently: "The critical adjacency for building business apps with LLMs is existing business logic and infrastructure. And the critical skill set is building sophisticated business applications. In both these areas, the JVM is far ahead of Python and likely to remain so."

Spring AI keeps adding what you need

When it comes to AI, this is where the strategy of Spring - the long-term strategic value of Spring - is incredibly important. If you've been watching the project Spring AI over the past two years (and a little bit before that), you've seen it consistently and very rapidly add whatever new AI functionality is there. In the beginning, it was just about doing the classic Spring thing of having an abstraction over accessing whatever models you have, whether they're publicly hosted or locally hosted. Then it adds in support for evals, for tools. When MCP comes along, it adds that. And on and on - multimodal things. If you follow this, it's actually astonishing the rate that they add these new features.

That's the point of Spring: to always be that layer that's gonna be bringing in the new functionality you need to use for your applications, and having that be where you focus what you're doing. Making it as quick as possible for developers to use, so they don't have to figure out how to do all of that integration. I mean, you know this - you're a Spring developer. What you see in the Spring AI reference are all the things Spring AI has been adding, and therefore, when you're using the Spring framework and Spring AI, you just get all of this stuff for free.

Let's look at a specific case. Last year, in 2024, when Anthropic came out with Model Context Protocol - MCP, the way of adding plugins, of adding tools, of adding code to how you use AI - the Spring team's implementation was done very rapidly, and then it became the official implementation for doing MCP in Java. That's evolved over time, going from its own standalone implementation to Spring AI MCP. That's a great example of the strategic value of the Spring framework: the team is constantly adding new things as they become valuable, and you'll keep seeing that in Spring AI - which is why it's great that you've chosen to use it. You don't have to shift over to a new framework to take advantage of AI in your applications. You don't have to learn it, you don't have to test it out. You just gotta upgrade to start using the newer versions of Spring, and you get Spring AI in there.

You need a real platform, not a blinking cursor

Let's look at the next thing that's important. I've talked a lot about the frameworks - the thing at the application layer - but what's really important is to think about the platform you're running things on.

The first orientation here: if you work in a large organization - those kinds of organizations that use Java and that use Spring - chances are very high that the AI stuff you're doing is gonna be running on your private cloud. An IDC survey sponsored by Broadcom shows that a lot of the usage of AI - especially in large organizations - is something they want to own and control. They don't wanna just use the publicly hosted services. They need that control, which makes sense in highly regulated industries: governments, pharmaceuticals, and especially finance. As with any other service, you wanna start off having as much control over it as possible and figure that out.

What this means for a Spring developer is that you will be relying on a platform - something running in your environment, in your private cloud - that's doing a lot of the work to host and provide access to those AI services. Not to mention running your applications.

The issue that comes up with a lot of infrastructure providers in this kind of private cloud environment, in an enterprise setting, is that the infrastructure people - even fancy-pants titles like platform engineering people - they think what they need to do is deliver this to the developers: a blinking cursor. If you've ever just been given like a cluster, or a namespace, or some templates and whatever configuration management stuff you've had, you've experienced this. The infrastructure team - maybe the platform team, if you wanna stretch the definition - has set up and run this, they're managing it. And now it's your responsibility to do all that work between the blinking cursor and how your application runs. All of that work has nothing to do with the applications you're doing, and I (and many other people) would argue it's not worth very much at all to your organization. It's worth it to have it, but to build and customize that on your own is not good. There are all sorts of other reasons why building your own platform - why being given a blinking cursor as your platform - is not good. But let me illustrate what a good platform looks like, especially for the needs of AI.

How Broadcom IT runs MCP and models inside the platform

Our own IT organization at Broadcom - which is a huge company, you might have heard of it - has thousands of developers and they had these needs as well. They're running in a private cloud environment, like most large organizations, and they really wanna take advantage of using AI in the software development process: to run MCP servers, to connect to not only things on our own network but Atlassian and GitHub and all these sorts of things. Of course, because they have the concerns of a regulated industry, they don't wanna just let anyone run these things locally - they don't want their developers to have uncontrolled and unaccounted-for running of MCP, which kind of slows down the ability to take advantage of AI.

What they found with a good platform in place - the Tanzu Platform - and you can see my kind of crude representation of it above - is that you can run these MCP servers in the platform, and this instantly gives them all the controls they need to allow developers to do this. You can also run models, you can broker access to other models you have, meaning that developers can start to - in a very secure, governed way - use AI in their tool chain. This applies, of course, when you're running AI as part of your application as well. You need a platform that provides these services, that allows your infrastructure people - your platform team - to bundle up these services, make them secure, govern them, and provide them to the developers to use. You don't want your developers building on top of that blinking cursor thing.

If you wanna read more details, I'm not really gonna go into it here, but there's a great article written by some of my coworkers - and also some recordings on Cloud Foundry Weekly - that go over the implementation of this. How this kind of way of hosting MCP servers (whether it's for your development tool chain or for actually running your applications) - the architectural pattern they've been using, that Broadcom is using, and others of our customers are using. It's something you can put in place now, and chances are high that you actually have the Tanzu Platform - and even the VMware stack, the VCF stack, a full private cloud stack - that has this right now. Instead of having to build this out, having to test it out - just like the Spring framework, you have this right now and can start using it to get moving and start using AI in that secure, governed way, both when you're doing your development and also in the applications when you're running it.

Upgrading: the part we all need to do better at

Now let's look at a part I think we all suffer from and we all know we could do better at - but is even more important right now in 2026 (and was important in 2025) when it comes to meeting those priorities and especially thinking about how you're using AI in your apps.

Maybe it's not the case for you and your organization, but when you look at the versions of Spring and Java that people are running, it often lags behind. We see this in the numbers - there's a high percentage of people downloading unsupported versions of Spring Boot.

There are tons of people running older versions of Spring, older versions of Java, and they can't quite prioritize and get their organization to focus on upgrading. It seems like a lot of work, a lot of hassle. Usually they're motivated by external forces, like price increases (as the Java world has been seeing), or the need for new functionality. Sometimes they're motivated by good architectural principles, which is what we would like.

But when you look at surveys, there's this tangible feel with executives that the Spring community needs to connect to better. The executives understand they're running on older versions of Spring, and it's really holding them back from features, from evolving their business based on the software they're running. Now this figure is actually from 2020 if you read the footnotes - 76% of executives say legacy software is holding them back, per a 2020 Forrester study commissioned by VMware - but I would challenge you to think: has it really gotten better? Would executives in most organizations say, "Oh yeah, we're totally fine with our IT - it has every single thing we need, we can implement whatever features I can throw at them, and I can change the business on a dime to match what they need"? I don't think so. I think maybe it's gone down zero percentage points. You'd find the same thing if you asked executives today.

Upgrades give you performance and cost wins for free

Let's look at another reason why it's important: performance gains. When it comes to cost and performance, every time you update your Java VM (and Spring along with it), you're just gonna get performance improvements for free. Memory usage is less. CPU usage is less. Things start faster. Which means you can do the same with less, or you can do more with less or the same.

The point is, upgrading - and we see this very frequently with our customers who go through the upgrade process - they start to save money. They start to be more efficient simply because they don't need as much memory, they don't need as much compute. With the price of memory nowadays, it's a very valuable thing to look at. So that's a motivation for upgrading: it's proven that when you upgrade Java, when you upgrade Spring, you're gonna consume less resources, you're gonna have more efficient use of it, and we see that over and over again. Tanzu's internal studies show that on Java 21, organizations have observed up to 20% lower memory consumption and as much as 2x faster startup, with even stronger results on Java 25.

Also on the performance side: when it comes to functionality, if you look at a recent performance test of Spring for MCP, what you'll see is that it's the most efficient (measured by latency and a few other things) MCP implementation out there.

Again, this is showing you that all of the performance improvements - when you're using a newer version of Java, when you're using a proper framework like Spring AI - you're gonna get the most performant thing versus the other languages out there. This is the kind of thing you see with Java, and it shows you again why that long-term strategic bet, not only on Java but on Spring, pays off consistently no matter what's out there.

Tanzu Application Advisor: upgrades in an afternoon

Upgrading is hard. We've observed this over the years, and over the past couple of years we've really refined a tool we have: the Tanzu Application Advisor, to make it as easy as possible to upgrade your applications. This started off in Spring, but it's been changed to be more of a generic application upgrade thing. What it does is look at the applications you have running in the platform, scans them, and using OpenRewrite and some of our own technology, it suggests not only the easy things to upgrade but the more difficult things, and gives you a way to automate as much of your upgrade as possible. As you can see from an example in the slides, it not only shows you dependencies to upgrade but starts to go in using our recipes - and standard OpenRewrite ones - to show you the diffs for upgrading.

This sounds phenomenal, and it actually is. If you look at some of the customers who've talked about using this - here's one from Alight - it sped up their ability to upgrade by 70%, as was mentioned on a panel at our conference, Explore, last year. My colleague DaShaun likes to talk about this - how he's seen other organizations go from a team of five people who have to rove around the organization, probably over the course of years, to being able to do upgrades of applications and services in an afternoon using this tool.

So, the Tanzu Application Advisor: again, a tool you probably have access to already, because most large organizations have the Tanzu Platform - or can easily start running it on top of their VMware stack. You probably have access to start accelerating and speeding up the upgrades. Because that's really what holds a lot of upgrade stuff back: "it's just gonna take us a long time, it's hard to analyze all this code." But you start using these new tools you have - not to mention starting to use AI, which you are now running securely and highly governed in your platform environment, just like Broadcom's IT department is, and others I went over - and you can start to speed up that upgrade process, get those performance improvements, and also get access to new features, including AI things.

You can get access to some of that stuff with Tanzu Spring. It's our support offering around Spring. Not only does it bring you many of these options and support for it, but it's gonna help with that securing and governing side of things. It's gonna help you make sure you're upgraded - and if you're not quite ready to upgrade, it has long-term LTS support around older versions so that you can plan out your upgrading. But I think it's probably important to really focus on upgrading this year, for those performance needs I was going over.

To sum up

To sum up: when I look at all of this, this is the best time to be a Spring developer, a Java developer. And it's kind of always been the best time to be a Spring developer and a Java developer. Sure, there are other languages that are coming in and being helpful in this AI world. But as we apply AI - not only to the development phase (running tools, helping out in the tool chain) but also adding AI to your applications - everything you can do as a Spring developer, as an organization already using Spring with decades of applications in there, is gonna meet the CIO priorities, the priorities of your organization. You're gonna be able to address performance and cost, and security, but at the same time have all of that built-in business logic - that knowledge of how an organization works that's encoded into your applications and that's really doing just fine, now, if you think about it. And you'll be able to add in all of that AI functionality.

I think the best way to do this, as you'll see when you talk with my colleagues, is to run your Spring applications in the Tanzu Platform. We are the people who work on Spring - we're the stewards of the project, we have the most people committing. I've shown you that they're constantly adding new features. We wrote the official implementation for MCP and Java, and now it's in Spring AI. So we have all of the knowledge, the work, the care and stewardship of Spring running in the Tanzu Platform. There's a very tight integration between the two. It's the easiest, the best place for organizations to run their Java apps. And like I keep saying, you probably have access to it already, so you can just start using it.

If you wanna get the slides, there's a link above. Click on those things, look up all these studies yourself. And with that - thanks. I hope you have a good time doing your application development. You've made a wise choice by working with Spring.

Why platforms, why now

What I want to go over today is platforms - some observations I've had, things people have told me. I don't actually do real work, I just make slides, so this is all through other people's experience. Seven things. Some of them are kind of the same thing, but they're things people stumble with when they decide to build their own platform. By "platform" I mean platform as a service, an internal developer platform, an application platform - whatever you want to call that kind of thing. It has several names that it goes by.

I've been an analyst, I like charts, so a quick warning: if you don't like industry analysts and surveys, prepare yourself. Surveys could be right, they could be wrong, they're somewhere in the middle. As the chart people say, they're directional. Better than just making a claim without a visual.

So why are platforms interesting now? Here's a chart from the most recent CNCF Annual Survey. If you look at the dark bars, you see a steady rise in containers running production applications. I mostly pay attention to production, because that's what's actually running, not just dev and test and staging. Containers - which is to say Kubernetes for the most part - are starting to be a significant part of what's running the world.

A little tempering: if you ask worldwide what percentage of all apps are running in containers, it's actually a hard number to find. Last time I tried to figure it out in the fall, my estimate was around 20% tops, depending on how you count hyperscalers versus banks versus everyone else. Here's another cut from IDC showing the same momentum - the green is VMs, the red is containers, and you can see that same steady rise. Funny enough, as the report writers note, most of those containers run inside VMs anyway.

Now we have all these containers, presumably running applications, and what becomes important is how we manage them. Per Gartner, by 2027, 80% of large organizations will embrace platform engineering - up from less than 30% in 2023. I never quite trust an 80%. Even if 80% is accurate, you should bring it down to 78 or 82, because of the 80/20 spread that people just kind of make up. But the direction is real: most organizations are interested in building platforms.

This is part of a cycle that's been going on for a while. New infrastructure shows up, everyone gets obsessed with the infrastructure, builds it out, often redoes it instead of improving what they already have. Around 2007 you got Heroku and the first wave of platform-as-a-service. Around 2018-2019 the orchestrators arrived, and Kubernetes consumed everyone's attention - container as a service. Now we don't call it platform-as-a-service anymore (erase that from your mind, even though I'll let myself say it), we call it platform. The interest is coming back. Now that all these containers are running, people are finally asking: how do we make it easier for application developers - or our robots, if that's how you're doing it - to deploy and manage things at scale?

The annoying pattern I see: everyone kind of knows they need a platform, and they might appreciate platforms out there, but they're like, "we have special needs, we have unique needs." We might be one of 300 of our type of organization, or one of 3,000 in the world that does pretty much exactly the same thing, but the way we do our platform - something special. Sarah Wells said in 2024, "Don't build something if you can buy it." Kelsey Hightower said in 2025, "Do not blindly start with Kubernetes. Seriously. If your application can get by with a simple PaaS or serverless offering I'd consider that first. Even VMs make sense for most situations." Abby Bangser at Syntasso put it as: "It's not about rebuilding what we can purchase that is available on the market. It's about making sure we spend our time building the things that are bespoke and important for our organization." The experts hint that building your own thing is a bad idea, but we keep doing it.

What is a platform? A couple of years ago the CNCF came out with a platform reference architecture, which is great because when I'm told not to give vendor pitches, I can show you a neutral industry-consortium one. There's a lot of stuff on it, not all of it strictly in the platform - some of it is what your platform integrates with - but the components it covers should feel familiar if your frame of reference is platform-as-a-service. The whole thing is centered around: you write your own application, you want to run it, you want to manage it. Of note, the infrastructure is kind of unimportant in this picture. You run on whatever you want.

And if you're really into 3D diagrams, here's a fun view from Forrester of everything in the IT stack. Maybe they can use this for Tron 3. It's hard to tell if the back part is in front or in back. Good optical illusion. Take the slides home and ponder it.

#1 Unexpected scope creep

I guess all scope creep is unexpected, but this is the kind you can predict. What people often think a platform is - and what they end up building the first time and then abandoning - is base container images, templates, maybe a namespace in a cluster handed over to developers. As a former application developer, I think of this as the blinking cursor problem: the platform is a blinking cursor waiting for me to do everything else. Sure, the templates and base images are best practices. But what you're leaving out is huge.

Here's just stuff off the top of my head: app delivery, backup and restore, patch management, observability, service management, RBAC, vulnerability scanning, dev framework integration, high availability and the other -ilities, multi-region, sovereign cloud, auditing, multi-tenancy, upgrading the platform itself, gateways, brokers, load balancers, CI/CD or its integration. When I look at platform teams in large organizations, they're heavily involved in all of these. They're not just delivering a pipeline and base container images. They have a whole finished thing that takes the toil and worry out of the developers' hands and out of the security and audit people's hands. It automates a ton of work. Adib Saikali made a related point in his Cur8s talk - "Stop Renting Your Knowledge."

To drive the point home, here's the new CNCF Cloud Native Maturity Model, summarized by ChatGPT. I warned you I'd use phrases like "maturity cycle." Across five phases - Build, Operate, Scale, Improve, Adapt - you're constantly expanding from that original scope, adding new features, integrations, and changing the org around. That's a lot of stuff. The point of unexpected scope creep is: you initially think building a platform is going to be easy. I think it's only application developers who think everything can be done in a weekend. Other people, a little wiser, give it a couple of weeks. And then it ends up being more features than you thought, you're partway through, and you don't actually have all of the features.

#2 Underestimating the ongoing investment

That partial scope ends up underestimating the ongoing investment - which is to say, the money you have to pay for it. Model out a platform team. Use whatever currency, it's just simple math. One team of three to eight people, paid 125,000 currency units per person per year - which I realize is not all-in pay depending on region, but bear with me. Chart that cumulative cost out over five years and you start talking about real money for one team that builds the platform, runs it, maintains it, and does the ongoing work a platform team does.

But you don't have one team. Depending on which components you actually build, you have more like three to eight teams of three to eight people. Do that math and the cumulative spend gets big.

And there's a related thing. I was talking with someone three weeks ago at a large bank who pointed out that with the blinking cursor model - just giving developers access to namespaces and clusters - what ended up happening is each application development group needed shadow ops people on those teams who finished out the platform and managed the platform that was given to them. This is a delightful big-bureaucracy enterprise conversation: the managers of those teams loved it, because now they have more headcount and responsibility and they seem cooler. It's a vicious cycle to get caught in unless you want to seem cooler.

In contrast, when teams don't spend their time building out their platform but instead spend it managing one, helping people use it, doing the integration - over the past eight years or so you see pretty impressive ratios. Number of operations people running the platform versus number of developers and apps supported. 30,000 devs to 50 ops. 6,500 devs to 16 ops. 1,200 devs to 6 ops. 350 apps to 7 ops. All based on true stories. If you bank at Rabobank, they're up here in one of these. Run your own platform against these benchmarks and see if you're hitting them.

#3 Platform as a project (instead of as a product)

Number three is the same face from a different angle. People run their platform as a project. What this ends up being is platforms as sprawling projects. You have many different platforms, because someone thought it would be a one-off thing. Someone this morning was saying: probably no one in this room, but everyone pretty much does 80% of a project and then moves on to a new thing. That sprawl is what you get.

Often this happens because people have very important critical needs that only they can build, that can't be achieved through buying a platform or using the corporate standard. Abby Bangser at the last KubeCon had a great 15-minute talk on this. Her analogy - or metaphor, I always get those mixed up despite all the studies I've done - is that those platforms are like Christmas puppies. Or, if you're wealthier, Christmas ponies. I've got three kids and every time they ask for a pet I tell them: I know you want a pet, but to use one of my favorite phrases, that was your gift and now it's my problem.

You can see the consequences in the survey data. People want fewer platforms. They want to consolidate. They want to standardize. There's a bank in this area on the continent whose whole initiative is: we spent five years on silos and specialization, let's stop doing that. They've put initiatives in to consolidate. You see that over and over again.

Instead, you want platform as a product. The product part is the important part. If you have a product and you want it to stay around, you have to realize you have customers - or users, if you prefer. For a platform, the customers are primarily application developers, plus stakeholders like compliance and security people. You product-manage it: how do you build it, add features, gather feedback. Onno Ceelen and Roy Triesscheijn from bol.com - the Amazon of the Netherlands, for those who don't use it - had a great DevOpsDays Amsterdam talk on this, with the platform team in the middle of the silos, unifying and integrating things for developers.

The point about product-managing a platform is: it is a fair amount of work to monitor what your customers want, run experiments, and gather feedback on whether they worked. If you're doing that, you're probably not going to want to spend a ton of time also building the goopy innards of the platform. Here's a survey of the kinds of questions you'd send out to developers if you were product-managing it - drawn from "Developer Toil: The Hidden Tech Debt" by Susie Forbath, Tyson McNulty, and me, plus Michael Galloway's interview questions for platform product managers. These are what a platform team is interested in, versus the plumbing underneath - which you could just outsource.

#4 Homegrown lock-in

Number four: homegrown lock-in. Or, to use a word from earlier today, artisanal lock-in. As a vendor, I encounter this all the time, and like every time you get punched in the stomach - which I assume is very memorable, I imagine - it's memorable for me. People insist they need customized stuff. And, even worse, "if we were to buy a platform we would be locked into it forever." If you ask them what lock-in is, they say, "it's lock-in. We know we don't want lock-in." So we'll get some open source, integrate it together into our own thing, and we're fine. We've avoided lock-in.

Of course, as the title says, what you've built is your own form of lock-in. You're assuming the design and knowledge persists past the people who find a new job after building the platform. You've built your own cage. You can't really go talk with other people about how they do things - you can only talk to yourself, which is delightful on other topics.

Better ways to think about this. Way back in 2006, Simon Phipps at Sun had this notion of "the freedom to leave." It was essentially another way of talking about portability. Back when proprietary versus open source was very controversial, this was the more sophisticated take: you can use whatever, but it should be easy to leave. There's also switching costs - not just license or subscription, but the time you put in, the risk you take on, the time it takes to move and rearrange. You probably want to maximize freedom and portability and minimize switching cost. Gregor Hohpe's "Don't get locked up into avoiding lock-in" and Keith Townsend's "Thinking About VMware Alternatives?" are useful here. Run those criteria against what you actually want, rather than the reflex "if we spend money on something we must be locked in."

#5 Retaining skilled people

Retaining the skilled people who can build platforms - the ones who know about that exciting plumbing - turns out to be hard, because they're very valuable, highly skilled people. As proof, look at the CNCF surveys from the oldest to the newest. Lack of skills around cloud native and Kubernetes has been at the top since 2017. Obviously there's a typo on the slide - that's supposed to be 2025 on the right. We've gotten 4% better at it since 2017. Skills and knowledge of how to run cloud native is always a problem.

Security is always the number one issue in these surveys, so I'd raise up skills above it - of course security, you don't even need to ask, and who's going to answer "top three? Security? No way, don't care"? You almost feel obligated. The skills to build a platform - not just run it - are very valuable. So you hear the story over and over again: lots of organizations try to build out their own platform on whatever container or Kubernetes stack. At the end of a year, most of them haven't really delivered much. Scope creep, boredom, a new executive comes in and redoes the strategy. A few of them actually succeed in building something with a bunch of production applications, and they get up on a much bigger stage than this and give a keynote, and then mysteriously, three or six months later, they're working at a new organization. From a worker perspective, that's great. From the organizational perspective, losing the people - sometimes whole teams - who just built something really cool is not great. You're left with this platform the wizards made for you, and a lack of wizards who know how to do anything with it.

The flip side of homegrown lock-in: if you buy a platform, there are many other organizations using it. From a worker standpoint, the value of the workers goes down a little - sorry about that - but the chance of retaining them goes up, and you don't have the interruption of depending on poached skilled labor. If you're a manager, an alternative strategy: never send your successful platform builders to a conference. Don't let them present. Even more impressive to think about, but it might be effective.

#6 Keeping up with security and compliance

I am by no means a security expert. Security people start talking to me and I start thinking about how I have to finish book four of Dungeon Crawler Carl to get to book five. I just found out there's actually eight books. I thought number five was going to be the last and I'd be caught up. So I'm busy. What was that guy talking about? I forget. I just zone out.

So I tried to think how to represent the increasing time required to worry about security if you've built your own platform. Think about that stack again - all the integrations, all the dependencies. Jerry Gamblin's 2025 CVE Data Review shows it just gets worse every year. Things are constantly attacking what you're doing. Christmas puppy: not only was this your gift, it's also your problem. Security is going to consume a tremendous amount of your time. Meanwhile, you've still got to have your daily standup to figure out what new features you're going to give your developer customers - which is to say, product management.

And not only security. There's also the thrilling world of governance and geopolitical climate and macroeconomic trends - sovereign cloud, all that. If you've built your own unique Christmas platform - a gifted platform - it's also your responsibility to figure out how to move things around to keep up. That sounds like something you'd want to outsource.

#7 Resume-driven development

Number seven is highly related to the skills point, but it's more an effect to watch out for. You've probably heard the phrase resume-driven development. There's actually a paper - it's not just funny tweets or skeets or tootses or whatever they're called now. Some Germans got together and wrote it, of course.

The cycle: when you want to hire people, you make the job seem interesting, at least in tech. You list out new technologies, new opportunities. Hirers signal "work on this cool technology." Potential employees figure out: I have to know this new thing to get a cool job, or just a job. Whether you're an operations person or a developer or in IT, you start thinking you should be working on cool new things, not the old stuff. Consciously or unconsciously, that drives use of new things and moving on from what already runs. There's the joke that we want technology to be boring - which means it runs well, we understand it, it's stable, and we can start making money or providing services to citizens. But boring technologies get ignored as people pursue resume-driven development.

I wouldn't have shown you the paper if its conclusion didn't agree with me. The authors find a cluster: less knowledge about the system, an overall worse system, a high degree of - as they delightfully call it - RDD. There's even a technical term for it.

Bonus: build vs. buy with a Wardley map

That's seven, but I usually skip five slides because I cram too many in. This time it's actually short, so here's some bonus material. If you're into business stuff and you're older, you might remember Wardley maps. I've got to be honest, I never really got into them. But people were thrilled with this stuff when it came out. Here it is for those who like it.

The point is: when you're building a stack, figure out what you should customize - what you should do yourself - versus what you should buy. Find the things that aren't a competitive advantage. Or, the way I think about it: what are the things that do not cause your customers to give you money? When I go to Albert Heijn, the home of our hamster friend, I have no idea what platform they're running. I don't go there because of their platform. I go for the groceries and the mobile app experience - on the self-checkout I don't have to print a receipt, I just scan the barcode on my phone and walk out. They even know to put a trash can right by the gate, because they know that piece of paper is useless. Their applications are good. I have no idea if they run Kubernetes or Mesosphere or whatever. It's not valuable to them. Don't spend time on it - transform money into not spending time on it, and buy the commodity thing.

In contrast, also in the Netherlands, there's a delivery service called Picnic - I don't know how to pronounce it in Dutch, sorry. They custom-build these tiny narrow trucks. I found this out waiting for a lunch a year or two ago. They've customized that because they're a grocery delivery service competing on getting through narrow downtown streets quickly and cheaply. So they built that platform - unlike the Albert Heijn and Jumbo trucks that are just trucks, because what do they care, they pop up on the curb with your groceries. When it comes to building versus buying a platform - or anything - go through one of these exercises. Ask: if we built our own platform, are we going to get more customers? Is anyone going to think, "I really like your discount pants, but the fact that you built your own platform - that's why I'm buying you over the H&M pants"? Probably not.

And one more bonus thing: AI. Maybe I haven't mentioned it until now, which is perhaps a personal best. We're going to be adding this whole new workload - applications written by AI, running models, running plugins. As a platform person, that's a whole other load on your plate. Even more reason not to spend your time building your own platform.

Stop building platforms. Start building apps.

So that's why I generally think you should stop building platforms and start building apps. Don't worry about building your platform - there are plenty out there you can have. Buy everything you can, as Abby Bangser put it. With that, thanks for coming. Email me, grab the slides at cote.io/diy/. There's a paper this is based on if you want to read more.

What's actually a priority right now

What I'm going to go over is what, at least as far as I can determine, seems like we know about doing platform engineering, or operations, for AI in private cloud. This is important now because people want it, which is always a good reason to do something. A lot of you are being asked to sort it out, or you think it's super cool and you want to do it on your own - which is also a great reason for a technologist to do things, especially if you can give the mess to someone else when you lose interest.

I'm an application developer, so I just lump operations, SRE, DevOps, platform engineering all together into "stuff I use." Or I used to be one. But it's worth knowing what's actually valuable. Here's a recent Forrester survey asking management types what's important. Multi-bar charts are complicated to read, but if you collate them, security is always at the top - which is like asking what your number-one priority with food is. It should taste good. You're not going to answer "security? Nope, not a priority." Take that for granted. The interesting stuff is below it: lots of interest in AI, but what dominates is the old crap people have to deal with all the time - modernization, maintenance, just keeping things up and running. If you're picking what's most valuable to your organization for the next 12 months, probably upgrading your stuff. But in the meantime, why not some AI? That'd be fun.

The new things platform engineers will do for AI

Here's a summary of what operations and platform-engineer types will probably focus on, drawn from talking with Tanzu customers and looking at what other people have written. The question marks are things I'm not sure about. Some of these are obvious: hosting models - or, if you want to be all technical and cool, "inference" - so people can just use them. Application frameworks. Registries for plugins. If you've ever hosted a platform before you'll look at this list and go "ah yes, every single thing I've ever done in a platform." There are a few things particular to AI: notably the extension/plugin layer - whether that's Model Context Protocol or whatever ends up generalizing it. And of course you all are going to be in charge of the cost controls, observability, and the AI-FinOps-BizSRE-DevOps-Eng stuff that's going to emerge. Get ready for that.

As for roles and responsibilities, this is a good early cut. The top is what platform teams already do. The bottom rows are where AI changes the picture. Developers develop - they use access to the models they're given, write apps around them, tune to their users. Platform/AI teams run the models, keep them updated, handle controls and costs, do the autoscaling and the integrations - just like any other middleware. Where things get up in the air is on the optimize side: who decides which models to use, who fits them to a purpose, who decides when to update them. Is that an operations person or a data scientist - whatever that means? It's a very cool term. Maybe you should rename yourself a data-scientist reliability engineer. They're the subject-matter experts, so maybe they're the ones who start to do it.

Why private cloud

I work at Tanzu, formerly Pivotal, formerly VMware, now Tanzu by Broadcom - almost 11 years come January. I've been lucky to work with large organizations figuring out how to do their software better, which is a handwavy way of putting it. I've written a few books and used to work at analyst firms - RedMonk and 451 - and I'm from Austin originally, so you have to serve a compulsory two-year term at Dell. I did M&A and corporate strategy there in 2010-2011, when they wanted to do software and public cloud, which was thrilling at a hardware vendor.

For homework: Nick Kuhn's "Tales from Production" at VMware Explore 2025; Manjunath Bhat's Gartner work on platform teams scaling generative-AI delivery; Patrick Debois on why AI needs a platform team and on AI platform engineering; Angie Jones from Block on operationalizing MCP at scale, which is the surprising one - they have normals using AI and they go over how they're running it; Abi Noda and Laura Tacho from DX on the evolving role of platform teams in the AI era; and Keith Townsend's "The Emperor's New GPT - Why Your 'Custom AI' Is a Demo, Not a Product." I haven't watched all of them, but the Gradle conference also has several great talks on how people are delivering AI inside their organizations, mostly for programmers.

Why the private-cloud angle? Partly because that's what we're interested in where I work, but that's not satisfying on its own. If you look at IDC's data and at what people in larger organizations are actually saying, a lot of them are thinking about running AI on their own - not just hitting publicly hosted ones. Whatever "premises" means or wherever it's located, the point is they want lots of control over how AI is used, not just developers going directly to it. Back home in America no one cares about this, but the trustworthiness of America as a premises to run your stuff in has been steadily plummeting, which is fantastic for people like me. Whether you call it sovereign cloud or "not-America cloud," there's a lot of interest. Also just purely having it on your own for other reasons - I was talking with some banks in London who are very interested in: assume all of our IT just shuts down because of hacks, now we need to stand it up from scratch. There are all these scenarios that make private cloud interesting for AI.

What is a platform

Whenever you talk about platform engineering you have to have the famous Evan Bottcher quote from 2018: a digital platform is a foundation of self-service APIs, tools, services, knowledge and support, arranged as a compelling internal product, so that autonomous delivery teams can deliver product features at a higher pace with reduced coordination. Done. For a better visual, here's the CNCF Platforms reference architecture from a few years ago. People don't call this platform-as-a-service anymore - that's a terrible word you're not supposed to use, except when you want to. But it's basically what you'd expect: if I'm supporting people writing applications, what's all the stuff they need - services, middleware, configuration, dependency mapping, infrastructure interfaces.

What makes platform engineering different from every previous go at this - probably since Babbage - is that we should go up the stack and integrate tightly with portals, the build tools developers use, the way they look around for APIs and other projects. You can't just search Google and go to GitHub to figure out how to interact with the payments team. There's a whole discovery layer. There's a great talk from a couple of years ago at DevOpsDays Amsterdam from the bol.com people that goes over this - the Backstage-y internal-developer-portal layer, if you want to dive in.

Here's how people are thinking about a platform with AI capability running through it. This is from the people who said DevOps was dead - Gartner - giving you a cross-cut of all the activities going through a platform that involve AI: data access, an orchestrator controlling the various AI things, the close-to-developer portal/IDE layer. If you want the all-in view of the technical boxes that get added to a platform, read the articles cited at the bottom of the slide.

And if you're a management type who doesn't immediately tune out when "Gartner" shows up: that talk goes over the process, strategy, and layers in the platform area. What's nice about Gartner if you work at a large organization is that's who they talk to multiple times a day. They get a sense of what happens in regular large organizations that do more than let you show your friends what kind of sandwich you've eaten.

Two things you should do right now: a gateway, and frameworks people will actually use

So here are two pretty obvious things you should be doing right now if you're going to run AI in a platform way. First: developers, in my experience, are a little too fun-loving. They don't mind looking stupid. They don't really care about much beyond writing their applications. If you're worried about security or runaway things or great unknowns being brought into your system - they don't really care to be told they shouldn't be doing it. So there are plenty of developers using these things already. Find the ones who complain about your virus scanners and I bet they're hooked into public AI services right now. The lesson from the past: if you don't find something developers like and start managing it - don't use the word "controlling" - you'll lose very quickly.

Step one is a gateway or broker. Before you lose track of these crazy developers, put a gateway in place and make sure they go to it. You're controlling where the gateway goes. The contract is: it won't be terrible, they'll be able to access the kinds of things they want, it'll be sanctioned, it'll be easier than DIY. There are several gateways available now. Putting one in place early is way easier than reigning developers back to it later.

The same logic applies to MCP. Whatever the plugin/extension layer ends up being, run those things in severely locked-down VMs or containers - maybe with no network access except one little thing. If you've played with Claude Code's skills, that's exactly what it does, and it's kind of brilliant. It's not MCP, but it gives you an idea of how to architect securely contained execution. And then on the private-cloud point: you can host your own model serving, do your vGPUs, shard things out, all the thrilling stuff. It's available now. Worth standing up so developers don't run wild.

Meet developers where they are

When you deliver infrastructure to developers - even the coolest models, inference, and APIs - you're basically giving them a blinking cursor. They have to bring their own framework, methodology, and scaffolding. So think about what you can do beyond the cursor to guide them. That's the philosophy of meeting developers where they are.

In larger organizations and private-cloud setups, be aware of which languages are pervasive. JavaScript and Python are extremely popular, but the other two languages that usually put people to sleep when you talk about them - Java and C# - are pervasively used in large organizations. So when you're considering frameworks to provide, ask which ones have easy integration and compatibility with how you want to run AI. You don't want to leave just a blinking cursor, because then developers layer all sorts of stuff on top.

That ties to platform-as-a-product, an older notion exemplified by Thomas Müller at Mercedes-Benz: "We are building this platform not for us, we are building it for Mercedes-Benz developers." He used to run their Cloud Foundry platform and now runs Kubernetes too - a thrilling comparison to be running in his head. The point: you treat developers as customers. You're making things secure, reliable, performant - and you're product-managing the capability. Are you talking to your customers frequently? Are you observing whether what you provided is useful? When you get feedback, are you tuning and improving?

Speaking of "know your customer" - which usually means something else in banking - there's a new type of customer for platforms. You still have programmers who want public code-generation tools or want to instrument their workflow with little MCP things. There are data scientists running Jupyter notebooks who need a platform too, or will very soon. There's the obvious case: writing applications that include AI features. And then there's a new category: the normals - or, if you're a Harry Potter fan, the muggles - non-technical people using something like Goose on the desktop, or that web-based one with the tragic name that doesn't tell you what it is. In a private-cloud context, people are being given "here's a chat app, hook it up to your own models." That's a new constituency for ops/platform-engineer types to support. Worth checking out the Angie Jones Block talk to dive into what that looks like.

Avoiding centers-of-excellent-bottlenecks

Probably in your organization there's a center of excellence for anything new and excellent. We used to have cloud centers of excellence. Now there are AI centers of excellence, or roundtables of architects, or policy people. Their job - well, what ends up happening - is they become centers of excellent bottlenecks, slowing things down rather than letting them go at a pace.

If you want to speed that up, two groups should get involved at minimum. First, the security people. Even though they can be a little ornery, they're actually pretty good at this kind of process - understanding something, doing the risk modeling, making a ruling. It's what they do. Second, everyone's favorite: legal. Right after procurement on the popularity charts. There's a lot of weird ambiguity in laws around AI, so legal is going to want in. Get them involved early in the center of excellence and at several organizations the mix of those two roles has actually sped things up more than people expected. Then you can start approving the models you use and how you want to use them.

When you don't know what you're doing, do a lot of it quickly

Remember the digital-transformation era? Airbnb was going to destroy all hotel chains, Google was going to destroy banking, Tesla was going to destroy basically every company, and tech companies in general were going to destroy the existing ones. I don't know about you, but I've been enjoying none of the companies that existed in 2015 existing anymore. I just work with the new ones - which is to say, they all adapted and did just fine.

What we learned back then: if you don't really know what you're doing, you should do a lot of it quickly. In a structured way. Most organizations aren't sure what they're going to do with generative AI, so set up a sandbox - a practice, a way to iterate quickly on ideas. Thankfully, that's what platforms are built for: a structured environment that lets developers focus on the applications and business ideas instead of the infrastructure, while giving you tremendous control. Platforms have a great role to play here.

Lucky enough to have it already?

Some people are lucky enough to have this stuff already in a data center somewhere. I was here at an internal ING event recently kicking off the VMware, Tanzu, and VCF stack as a way of doing this. If you're at ING, find that person and ask about testing it out. If you don't know them, I can tell you who they are. If you're not at ING, you can get our platform - I'm not supposed to say "free," but you can get a 90-day trial without paying for it, so I'll let you figure out how much that costs. Try it at TryTanzu.ai. It'll be fantastic.

(Enterprise) AI is a failure. Or disappointing. Or improving.

If you take the launch of ChatGPT 3.5 as a starting line, the past 30 days of AI talk has basically been a pile of horse hockey. James Governor had that Bloomberg diagram in his talk - the circular power strip plugged into itself, money circling around. People are doubting whether this stuff actually works, and there are plenty of studies about the lack of effectiveness of enterprise AI. Which is a bummer for me, since I work at one of the companies that's benefited massively from AI. I enjoy compensation as much as the next person, so I'd like this to be successful.

I've seen this movie before. My first job in 1995 was an Austin company called Shop Us where the brilliant idea was to sell cowboy boots online through a virtual-reality shopping mall. We sold a total of two boots - one to someone in Australia. Sometimes you have to wait a while for a technology to be useful. So for the sake of my portfolio and early retirement, let's say things have been improving over the last few months. Better way of looking at it.

If the robot can play D&D, it can play enterprise software

I keep saying enterprise software, so it's worth explaining. It's the software that runs our lives - banks, supply chains, payments, online banking, governments, militaries, manufacturers, pharmaceuticals. Everything except videos of cats eating sandwiches. Civilization as we know it would crumble without it. And if you look at what enterprise software actually looks like, it's very complicated processes - one stage to another, choices to make, contract negotiations, physical supply chains. The kind of thing you'd think you'd want to apply AI to.

Here's the move. One of the diagrams I've been showing isn't enterprise software at all - it's a flow chart of how to cast a spell in Dungeons & Dragons. Equally complicated, different domain, a little less boring. So my theory is: if the robot can play D&D, it can play enterprise software. Solve for the nuance there - combat, sneaking behind a pillar as a rogue, all the weirdness - and your procurement workflow gets a lot easier.

1991, then 2023

I played D&D every weekend as a kid in the early 90s with my friend Mason - very nerdy, staying up late, questionable t-shirts. Eventually friends got cars, I discovered socializing, and it fell off. Fast forward through Pivotal, then VMware, then VMware Tanzu by Broadcom, then Tanzu by Broadcom - if you've been through corporate worlds you enjoy walking through and figuring out what your identity is - and in 2023 I had four days in a South Amsterdam hotel with not much to do. So I tried this ChatGPT thing for solo role-playing. Sounds pathetic and sad, but it's actually nice. There's a whole structure for how you introduce randomness when you play on your own, and AI seemed like a great way to have a dungeon master that's always available. That's where ChatDM came from.

What "agentic AI" means, depending on who you ask

What you want from a D&D AI is the same list everyone in the trade is now calling agentic: creative, takes initiative, knows the rules, applies them, moves the plot, and is fun. Which lines up with the various definitions floating around. Erik Pounds at NVIDIA in October 2024 framed agentic AI as systems that use sophisticated reasoning and iterative planning to autonomously solve multi-step problems. The Letta blog in November 2025 talked about LLMs tasked with outputting actions, running in autonomous loops, with state management and tool execution. Chip Huyen, author of AI Engineering, in January 2025 went simpler: an agent is defined by the environment it operates in and the tools it has access to. Three different definitions, all pointing at the same thing - something that acts on its own, has opinions, executes tasks. Which is a dungeon master, or a player.

What the robot is good at

A few things hold up. The robot never gets bored. It's always available - which is great for solo play, especially at the end of the day when I'm a little exhausted. Our brilliant idiot in our pocket is always ready to go. It's recently gotten much more imaginative - early on it was terrible at coming up with stories, but now it'll quickly set up an opportunity-rich scenario. It's OK at following the rules. The robot has read all of the internet, including 20 years of Reddit, so unlike obscure Hungarian contract management it has a huge body of D&D knowledge to draw from. Solid B student. Goes to a good state school. And it's dirt cheap - 20 pounds, dollars, or euros a month. I shouldn't do the math on the annual figure.

Showing AI prompts is a little like sharing your dreams - tedious for everyone but the dreamer - but here's a quick example. I run a chaotic neutral gnome fighter named Spin, because chaotic neutral lets you respond to anything without rhyme or reason and a fighter can get out of any situation without specialized gear. I drop the prompt in, Claude Sonnet 4.5 immediately throws Spin into a village being tormented by bandits (would have been cooler if it picked goblins, but bandits will do), runs decent tactics across three of them, adjusts as I drop one, and the bandits eventually back down and the villagers offer cheese and a free place to stay. Very typical D&D. The grading at the bottom of the slide: good tactical decisions, excellent numbers tracking, minor error - spears have a reach of 5 feet, not 10.

What the robot is bad at

The robot is predictable, boring. I'm no expert on how AI works, but I'm pretty sure it picks the most likely next thing. So if you've played D&D and you're going down a road and there's a dead horse, a fallen tree, or a curve in the road, you already know what happens next - you're getting ambushed by goblins. Same with taverns. Walk into a tavern and there's a mysterious hooded figure in the corner. Goblin ambush is cliche number one, hooded figure in the corner is number two. You have to specifically tell the AI not to do that.

It's clumsy. It tells you what's about to happen - the goblin's stats, its tactics, what it's going to do next - which a player isn't supposed to know. It's passive, mostly. And it forgets. I've been playing these characters for two years and the AI doesn't remember everything that happened, the way a human DM would. Same problem you'd have with a contract you've been negotiating for a year.

Two specific failures worth calling out. First, data leak: the AI cheerfully narrates what the goblin in the bushes is doing while it's still hidden, exactly the information the player isn't supposed to have. Second, it skips special features. Goblins have Nimble Escape, which lets them disengage as a bonus action - which is what a goblin in trouble should do, because goblins, like most of us, don't want to die. The AI just keeps it attacking instead.

Tools and plugins to fix the gaps

Solo role-playing has a long, rich tradition of tools - call them thought technologies - for injecting randomness and getting around the AI's predictability. The most famous is the Mythic Game Master Emulator, which is the nerdiest phrase I have ever said out loud. There's also the Plot Unfolding Machine, which sounds a lot cooler. These are systems for asking oracle questions - "is there a goblin hiding in the bushes?" - and rolling dice for unexpected outcomes, NPC reactions, encounter tables, meaning tables (old, meaningful), reactions (usurp, refuse), encounters (manticore, cobbler).

These are easy to wire up as MCP tools. I've written a few in Java and TypeScript - the Spring AI MCP intro is a good starting point. Hand the AI a randomizer, tell it to call the tool, and you start getting interesting results. Same combat scene, but now the bandit leader does something more human and less mindless-automaton. To solve the memory problem you give the AI a dungeon master journal that saves state across sessions. The tools make it work better, and it's a lot more fun. Code at cote.io/chatdm.

In an enterprise context you obviously need a lot more around the AI than "I'm fighting some bandits" - compliance, security, regulation, all of that thrilling stuff. People put together platforms and stacks. More on that at TryTanzu.ai.

The "yes, but" about AI productivity

All the "yes, but" about AI productivity is right. It's a lot of work to get the effortless thing - to borrow Mark Pilgrim's old line from the Python days, a lot of effort goes into making this effortless. That said: I'm programming again and it's super fun. I haven't programmed since 2005, I've been trying to get friends to teach me and they're busy with their lives, and the little guy in my pocket who's never bored is really good at teaching me. And I'm playing D&D again, even in my sad solo life. I should probably play with my kids, but they have homework. So that's my excuse.

The enterprise AI paradox

Why is AI so great for individuals and yet at the enterprise level people are saying this doesn't seem to be doing anything? Here's the way I've been thinking about it.

For a person: if you're 20% more productive with AI, you can do 20% less work. Don't tell your bosses. Leave earlier, book your trip at work, take on less responsibility. Obvious benefit to an individual.

For an organization with 4,000 ICs who are 20% more productive: now what? The most imaginative thing organizations have come up with is firing 20% of them. But what do you actually do with that aggregate productivity? Historically, enterprises haven't been great at figuring out what to do when there's a huge productivity gain. They have to sort it out over time.

I think it's because it's hard to know, manage, and see the value each individual is having and how it bubbles up to the top. AI is valuable to people. Yes, but, AI is not legible to enterprises. In Seeing Like a State (James C. Scott, 1998), "legible" means comprehensible and manipulable to centralized authority - the process by which complex, local, lived realities get simplified into standardized forms a state can record, monitor, and control. The individual sees the value. The enterprise can't yet read it.

That's been my experience over the past couple of years. And if someone at work is insisting you do AI, tell them: first I need to play some D&D, I'll sort it all out, come back in six months.

I'm from marketing, and I'm here to help

Hello, I'm from marketing, and I'm here to help. If you remember one of our former movie actors from the 50s. Thanks for having me, and thanks for being here. What I want to go over is three - actually four - stories, or if you'll pardon the word, case studies of people who use Cloud Foundry. Unlike my usual introverted cocoony self - staying at the hotel, running off to my room between sessions, looking down at the ground so I don't have to talk with people - I actually talked with people here. So I got an extra one, which was delightful. The numbers might be a little wrong on the new one, but I can point the finger at the person who gave it to me if you want the corrected ones.

The perfect time for Cloud Foundry

This has been said many times, but it really is a great time for Cloud Foundry, for any PaaS to be around. There's the sentiment of wanting a platform around to do more rapid application development - I don't know if you've heard of that concept. Let the developers focus on what they're doing. There are a few other things supporting it too. By my reckoning, each year about 40 to 50% of applications run on what you want to call dedicated cloud, or private cloud, or on-premises, or "I manage my own stack of stuff" cloud. That doesn't initialize very well. But the number has stuck for many years if you look at the analyst reports. There's a whole presentation I have going over that, with charts. If you really get into charts, I'd love to talk to you - there aren't that many of us around.

Speaking of charts, when you ask people where they want to do their AI stuff, a lot of them want to do it in - I lump edge in here, it seems extreme to care about something called edge, but I know it's important - in their own environments. Which again is a perfect situation for a platform. And then thanks to my friends back home, lots of discussion about sovereign cloud, or as an American I like to think about it, the not-American cloud. The rest of the world instead of just the US-based ones. Again, a great opportunity for a PaaS, for Cloud Foundry, to be around. As long as you don't call it PaaS. We can't say that anymore. It's got bad memories and connotations - "where did the three-layer stack touch you, make you feel bad?" Just say platform.

Not enough people know about Cloud Foundry

The issue is, not enough people know about Cloud Foundry. They know of it distantly, in the past, as sort of a thing. We don't really get the story out that much, which is what I want to go over. I'll give a quick intro to myself, because I enjoy it when people engage with my brand, as one of my old friends used to say. I've been in this area for about 10 years - at Pivotal, then VMware, then VMware Tanzu, then VMware Tanzu by Broadcom, and I think now we're Tanzu by Broadcom. I just put "Tanzu" because it's a lot faster than all of that other stuff. I don't know if I successfully showed you how much brand training I've been through. Kind of a bad student.

The case-study runbook

Part of what I want to do for this community is a little bit of, if you'll forgive it, pedantry. We should be putting together a lot more of these stories, or case studies - I'm going to go between those two words. This is kind of a template for what you want to do with a case study. The point is to show people who are interested, or people who need to be told this, that what you have is worth their time, that it works, and that it fits their problems. If you go look at the Cloud Foundry site, there are actually a lot of case studies. We just don't have a lot of new updated ones. That's something I think could be pretty easy for us to do as a community.

I'm going to go over four. These aren't the technical terms from a textbook - I just made them up. The first one we'll call "It just works."

Story 1: "It just works" - one bank since 2018

What you do with this kind of story is show that this isn't some wacky crazy science-fiction stuff. There was a time when everyone was like "we want to be like Google" and you'd be like, "I don't think you know what you're talking about. You probably don't want to be like that, and you don't need to be like that." This is the opposite. This is "we'd like to go home at 4:30 every day and not have to do some crazy exotic stuff. Be stable, be running in a normal way, be good." Not in a moral way, in an effective way.

This one is anonymized. Here's a bank - I assume most all banks are beloved, a nice beloved bank of the world. You can see what their Cloud Foundry foundations are supporting. The number I like the most, the most tangible to my mind, isn't the application instances or the containers - if you tell that to someone outside this community they're like, "I have no idea what you're talking about. Is a container an AI?" I focus on the number of applications they're supporting, and what they're actually doing with the platform. Because that's why this is a good "it just works" example: this is a regular organization, in a good way. Something people depend on every day, if not multiple times a day. They're running their retail banking, payments, open-banking integrations, and the Gen AI stuff Oren and Josh were going over earlier.

The other side of the case study is outcomes - business outcomes, if you want the marketing term. Why do I care, other than a bunch of big numbers? These are sometimes harder to quantify but equally important. This bank can deploy during working days, and I had to learn this technical term, "heightened awareness periods," which sounds like whenever my kids are home for me. Faster setup time, faster patching, and equally important - we don't talk about this as much as we used to - happy developers. What's good about the "it just works" story is we're not generating images of kangaroos riding horses here. We don't have exotic needs. We just want to make sure you get paid, or that you pay your bills. The things that run not entire, but huge parts, of our lives.

Story 2: "The Open Sourcer" - Rabobank since 2017

If you're one of my coworkers, close your ears and your eyes for this next part. If you're watching the film, definitely if you're in my upper management chain, just pretend this didn't happen. Here's an example of the open sourcer. Any community like this needs to be more - despite my compensation - than just one person selling the stuff. To put it one way, all of our Cloud Foundry stories are all of our Cloud Foundry stories. This is Rabobank. They first started using Cloud Foundry, probably PCF Pivotal, back in 2017, and four years ago they migrated to open source. Great to see them in the community. I live in Amsterdam, so unfortunately I'm not a Rabo customer. But I encounter them all the time. When I first moved there they were the first ones with Apple Pay, on the bus stops everywhere. I'm going to assume they're the most technologically advanced bank available, just because I could pay with my phone in 2018.

You can see their numbers - a Netherlands bank with reach outside the Netherlands, a bit smaller, which is fine. Supporting 300 developer teams. All their retail banking runs on Cloud Foundry, payments too, and lots of internal applications. One figure we in the community like to quote all the time is the developer-to-operator ratio - 300 developer teams supported by a four-person platform team. Astounds people. The last outcome is my favorite: zero outages blamed on Cloud Foundry in the past year. Which reminds me of another case I'll anonymize - pretty much all of their stuff went down, and the executive team was like, "What's that over there in the corner that didn't go down?" And it was their Cloud Foundry platform. Which reminded me that in marketing you often have to tell people you exist. If something is stable and just running well, it's worth telling people about over and over.

Story 3: "Impressive Performance / CompliantAF" - Schwab since 2014

Next one we'll call the impressive performer. This is the one where you say, "oh, they're operating at Google scale," or whatever scale. Another financial institution. This is also a great example of why the cameras at the back are a fantastic marketing asset, because all of this is from a recorded talk the Schwab people gave at a conference. Once you have something on YouTube, it's a multiplier. Speaking to you in this room is very nice - I love it, pleasant, good to see you - but YouTube reaches the people we haven't talked to yet, the ones hanging out finding videos. That's who we want to reach most.

I was showing this to one of the people whose stories I'm telling here, and they took a pause and said, "whoa, that's huge." I use Schwab. They're great. Or Charles Schwab - us insiders just call them Schwab. Retail trading, my retirement account basically, all those RSUs I love are there, wealth management. If you watch their panel, I think they do something like 5.4 million trades a day, and on average they manage around $9.4 trillion in assets. So in the financial world, it's Google scale, whatever that means.

The importance to me is what they do with it. The chart on the outcomes slide is what they call a "market storm." When Wall Street opens, the first 15 minutes are bonkers. Everything is nice and calm, you're getting your coffee, maybe your third cup of coffee, and then craziness. Handling that load, being reliable, five days a week - that's supported by Cloud Foundry. Showing a chart like that draws people in: it's real, it's mature, it works at any scale they care about. Even if they want to operate at Schwab scale. Maybe we should start saying that. That'd be thrilling.

Story 4: "The Transformer" - DATEV

Since we're in Germany, I thought I'd go over a German company. The transformer. There's a lot of computers and software in the world that we'd like to be better - whether we want to change the infrastructure or make the applications better. Most people are interested in transforming how they go about things. That's the journey DATEV has been on. They're an accounting firm that helps out accountants in Germany. I've been told German accounting is even more complicated than American accounting, which sounds really complicated. Now that I live in the Netherlands, taxes are basically three boxes - you put a number in each and everything else is preloaded. It's so crazy this doesn't happen everywhere - the government taxing you knows what you have, why don't they just send you a bill?

They've been modernizing the mainframe and the Windows-based applications they use to support their co-op of accountants. You can see the magnitude scaled to what they're doing. Showing how many teams you're supporting on Cloud Foundry is very valuable - it gives people outside this room an impression of how much is being done. Not just some strange exotic thing from times past, actually running things people depend on every day, or at least during tax season, but also payroll, office management.

It's great that Jürgen shared all of this with me and corrected some errors I had. Always good to be truthful in most marketing. They've been using Cloud Foundry not just for the runtime - I'm sure they have crazy market windows when some fun tax day occurs - but as a standard way to do things. A standardized way of running applications, even architecting them, so as they take their legacy apps forward they have a standard place to go. They have a plan, instead of the very enterprisey "whatever you might want to do" way of thinking about things. And, by the way, they have very beautiful slides. Worth zooming into when you grab the original.

More: Mercedes-Benz, JPMorgan Chase, SB Payment Service, Comcast, militaries

There are many other cases. I caught up with some Mercedes-Benz people. Always lots of banks. Another open sourcer down there, Comcast - similar story to Rabobank, much different industry and scale, but there are all sorts of things. And every time someone mentions a military or security force, they're always like, "but I can't tell you who it is, it's very, very secret." It's great when people talk out loud about it - very helpful for the community.

Call to action: tell your stories

Someone mentioned this term today, so I won't be teaching you it - call to action, which sounds militaristic now that I think of it. If you're a user, figure out how to tell your story. The angle here is: sure, you've got paperwork and comms people, but if you say, "this is about open-source software in a community, for Cloud Foundry stuff," they'll probably be like, "oh right, that's great, because we're in this contract negotiation with this vendor and we don't want you to talk about them." If you talk about how you're using an open-source thing - which you will be, however it's bundled together for you - that generally is a lot easier. Especially over the next 12, maybe even 24 months, get the story out there. Talk about how many people are doing it and what you're doing with it. Hopefully I've given you a sense of the bullet points, the raw ingredients you can stick in a blender and make a delicious smoothie. There's always a little bit left over - have some kids and feed it to them.

Speaking of things you can do right now: there's Cloud Foundry Weekly, and I mean that in a good way - Nick and Nikki, the two Nicks, are always interested in guests. There's cfgmgmtcamp in Ghent in February, very low-level and technical - if you fancy yourself a BOSH aficionado, the last BOSH talk there was when I first joined Pivotal in 2015, when Andrew Clay Shafer went and gave one. KubeCon EU in Amsterdam in March has a platform engineering track Paula was talking about earlier. And The New Stack - if you ever want to put an article in, we have basically unlimited access to help you publish. Wherever there's a button that says "publish," try to click on it. Thanks again - the more we get stories out there, whether updates on existing ones or new ones, the more it'll help us all.