Why Oren and I are doing this talk

Coté: Hi, thanks for joining us. Oren and I have been talking about this for a little while, and it's always fun to present with Oren - that's why I showed up for this.

What Oren and I are going to go over is how the suite of things that we work on, the Tanzu Platform, really, in my opinion, finishes out building up the private cloud that you get with VCF and that many of our customers use. I'm going to try to bring the perspective of the application developer, the applications, the PaaS level, the platform level. And then Oren, who is fully capable of covering that on his own, will be great at talking about how the infrastructure plugs into and supports that.

We of course have our disclaimer slide, which I think we're always required to put into a presentation. But it's a great moment of poetry, a time to take a pause in your life, appreciate very wordsmithed things, maybe take a screenshot and add it to your collection, which I'm sure you have nowadays.

So this is me. I started at Pivotal a long time ago, then VMware, then Tanzu, which is part of VMware and now Broadcom. So I work at Broadcom VMware Tanzu, I think, is where I am. I've been really lucky to focus on how organizations use software, build it, think about how it fits into their strategy, manage the whole process of it, the platforms they run it on - and talk with people who do that and write it up in several books. I used to have a real job being a programmer for some time, and then I slowly went into other work where I was an industry analyst at a place called RedMonk, and another place. I'm originally from Austin, Texas, so if you're from there and you work in tech, you know you have a compulsory two-year term you have to work at Dell. So I went to go work at Dell and did corporate strategy and M&A, which - if you're like most people in this audience, you've probably never worked with MBAs and those types. It's a real treat. You should do a little tour there once.

Delivering a blinking cursor

I'm often told, coming from the part of the stack that I do, the application stack, that when I talk with operations people, VI admins, whatever you want to call yourself, they don't really - it's often said more politely than this - they don't really care about developers and the application layer. They more just want to work to provide the services that they need, the infrastructure, and then sort of move on with their life.

I think of this as delivering a blinking cursor. You set up the infrastructure, you tell the development teams what to do, and then they start off and they have a blinking cursor there ready to go. They've got the VMs, the containers, the networking, all that stuff set up. And then what ends up happening is the developers are left to build out a platform - all the stuff above that blinking cursor.

What I've found talking with those large organizations over the years is that this is not really the ideal state of things, especially in large organizations. What you need instead is a platform in place. And what I've observed is there's a good balance between developer people and operations people - not quite in the DevOps fun world that we talked about in the 2010s, but there's a lot more involvement, if you will, from the infrastructure than is commonly done.

Four reasons you need a developer platform

The first thing that I think is very important is thinking about why you need a developer platform. I'll just say platform from now on, but it's for developers.

The first reason is obvious but well worth stating: organizations run on their software - the software that they make, the software that they buy. Within my lifetime, and I'm going to assume Oren's too, though I don't like to guess how old someone who looks as young as he does actually is, we lived through everything becoming an application that you interact with. And if you're not interacting with an application when you work with a large organization, you always wish you were. All of that needs to run somewhere. Developers make it, it needs to run. That's a critical part of any organization.

The second one is more representative of what's going on at the moment: artificial intelligence, generative AI, however pedantic you want to be about calling it. As we're figuring out, really just in the past couple of years, how AI gets applied in organizations, that's another type of workload, another thing that needs what a platform brings - especially once you have developers using it, not only for tools but in their applications.

Third, and this rolls into the large organization, the enterprise if you like the word: a platform is incredibly important, as you know in the infrastructure layer, but in a similar way for enforcing - let's broadly call it security, or governance, or compliance - all of the illities that you need when you're running enterprise-grade stuff. You don't need just taking-a-picture-of-your-cat-and-sharing-it grade infrastructure, and you need the same seriousness at the platform layer.

There's also a fourth reason you need a platform, which is that you already have one. Usually there's the infrastructure layer and the developers, and the developers come in - which I know for infrastructure and operations people might seem like a horrific tale, so prepare yourself - and start building up their own platform, their own way of handling things. They often have this view, which I'm blatantly stealing from Oren, that what they need is a whole bunch of knobs and dials. They need to dial in the perfect type of coffee and customize it to their exact needs. So you end up with platforms written by application developers that fit their ideal need of what they thought they needed. It gets to be very complicated and strange.

Not my mistake, and now my problem

The issue becomes that the larger your organization, the more developers and applications you have, and the more of these platforms that you have. It starts to proliferate. You have more and more of these bespoke platforms out there and they start to run rampant on their own as things age - as the company is more successful, so the software lives longer, is still used, and still needs the stack underneath it.

You quickly move into the situation with platforms that I think is one good description of what operations people's job is when it comes to applications. It fits into this very specific technical term called "not my mistake, and now my problem." You have this landscape of platforms out here that have been built to fit what developers need, and the developers move on to do other stuff - rightly so, they're working on applications. But you're handed this landscape of things. Some of them work, some of them don't work so well. And now you're left dealing with it. At the start you were just like, huh, I don't want to deal with platforms.

This is part of the reason why it's important to get ahead of that and start to work with platforms - not only to clean up this mess but to make sure it doesn't happen in the first place, especially with new workloads like AI coming into play. You'll see more and more of a proliferation. You're probably seeing this now, where you've brought in other groups, consultants, centers of excellence, people who've built up various AI things that had all these requirements, probably written in Python and TypeScript, and they need their own platform. They can't just use the platform that you have, so they've got to build this thing up. And now you're starting to be asked how you can manage that, how you could bring that forward into the future and fit it into your lovely landscape here.

What developers actually want and need

Let's think about how we can avoid that landscape of functioning and smoldering coffee machines, and start with a little bit of product management. I don't know about you, but when I'm consuming a product or a service, I appreciate it when the person who makes it kind of understands what it is I need and helps me satisfy those things.

One of the most important things I've noticed over the years is that you can build a platform that actually seems great, but if the developers don't want to use it, they'll figure out a way not to use it, and they'll figure out a way to subvert the intentions that you had. Paying attention to what works for them helps you actually be successful at it - which is something you find out when you try to get people to use software that you write.

So here is what developers want, and also what they need:

• Self-service for everything. They want that experience we expect from cloud-like infrastructure, where you just ask for the thing and you get it. You don't even ask a human for it. This is kind of obvious, hopefully, but it's a good guiding principle: how self-service can we make this?
• Bring your own framework. A developer, like anyone who has tools that they use, is very interested in the tools they know how to use. It's not only that we do Java development, it's that they'll want to use the Spring Framework, which speeds up and makes better application development with Java. Or, as much as I would make fun of it, they might want to use Python or TypeScript.
• Easy access to data and services. Think about all the other services, especially all the data, that developers will need to access. Retail banking is always a good analogy, because chances are you have a bank, unless you bank at the mattress bank. Just logging in to see your account - think about all those data sources and services behind it. Developers want that to be as easy and seamless, to use that word, as possible.
• SDLC integrations. Think about the workflow developers go through from the idea of what they want to do, to speccing it out, building, automating the build, testing, staging, and finally production - the configuration, the version control, all of the policy things, the entire software development life cycle. My experience is that the SDLC, the pipeline, is just like frameworks: very sticky to what the developers want to do. You have to fit your platform into it and align with it, or they'll come up with some excuse not to use it.
• Automated security, compliance, and governance. Developers are not very interested, as you may have experienced, in making sure they're compliant and doing security things and following all of those rules. As a former developer I'd like to speak on their behalf: they'll do it because it's responsible, but it's not really the kind of thing they'd rather be doing. So they want that to be automated, built into what they're doing - which is exactly what a platform does for them.
• Quick access to new technologies. This is what really breaks the deal with a lot of developers. We have the perfect example with all of the AI tools and frameworks. It's the return of shadow IT, if you remember that - you've got shadow AI, as Oren likes to call it. Developers will figure out how to bring these tools in because it helps them do their job better. So the platform needs to accommodate rapidly bringing in whatever new features are out there, and doing it in a responsible way. It's not a frozen point in time.

What a platform actually is

To give you a more technical view of what a platform is, I like to use this slide first, because usually I'm asked to be vendor neutral in how I'm doing things - though we'll go vendor biased here very quickly. This is a good place to start. It's from the Cloud Native Computing Foundation. They came out with it a few years ago: the reference architecture for a cloud native platform, which is pretty much any application development platform.

There are two things I want to point out. One is realizing that the infrastructure layer is not really part of the platform. The platform layers on top of and integrates with the infrastructure layer - the capability and service providers, if you will. You can see there's integration with the infrastructure, it fits in the box, but it's really a separate concern from what the platform is.

As you look through the other things, you can see it maps to what the developers need. There are the APIs and command line interfaces for self-service, easy deployment, quickly bringing up services in a command-line-oriented fashion - all sorts of ways to essentially expose what the infrastructure can do. And all the services, like identity management and databases, in one place, in a platform, to make it easier for developers to not only do their job but do the right thing along the way.

To expand that out into the Tanzu Platform, we of course have a much more tidy, pretty diagram. We spent a lot of time making sure it looks good, but it's also representative of what's in there.

You can see that in our platform we put a lot of value on that notion that developers want to bring their own frameworks, that they want to use the tools they have, so that they're interested in using the platform. They want integration with data - we have a whole Tanzu Data Intelligence suite that pulls in standard databases from the open source world, high performance caches, MPP databases, all integrated into the platform. And we've been delivering for a long time on getting whatever the new, interesting, helpful technology developers want added to the platform very quickly, at multiple layers.

The relevance here is that it's very tightly integrated into the VMware foundation, into VCF. That's part of the benefit of having a platform on that private cloud stack: it's not just one of many types of infrastructure that it layers on top of. You really get the benefits from that, instead of having to do all of the duct taping and wiring together of things on the underside.

Built on enterprise requirements

To go over some of the main concerns, the requirements that we build it on, that I've seen us do over the years:

One, I've mentioned private cloud a lot, obviously, in this community. What I've seen especially in recent years, pulling from my analyst background, is that the balance between public and private cloud has more or less leveled out, depending on what you look at and where. It's somewhere between a 60/40 spread or a 50/50 spread. It could be 60 public, 40 private. It could be 60 private, 40 public. But it's been level like that for a long, long time. What that means is there's a tremendous amount of workloads, of applications, that run on private cloud. So a lot of what we build into the Tanzu Platform, again integrated into the private stack of VCF, is servicing the needs of that private cloud deployment.

Part of that is having a developer layer, but also thinking about how we have the API-driven abstraction layer, the GUI integration layer between the developers and the infrastructure. That's a whole lot of what is also done in the platform. When a developer goes in and requests a bunch of VMs, a bunch of containers, whatever they have, there's a bunch of work that goes into the platform that makes sure it works at the infrastructure layer and doesn't ever really have to expose the infrastructure layer to the developer. It all works into the workflow that they want.

Organizationally this is also interesting, because we know that in large organizations those groups actually do pretty well to separate their roles and responsibilities out. You don't necessarily mix the developers and the operations people together. You take advantage of the expertise they have as separate organizations, and you do that layering - and the software actually helps out with that instead of battling it.

And finally, back to that security and control. A lot of what is in Tanzu Platform, especially as we add AI things, starts with this assumption, this acknowledgement of reality, that what you want is as much control, as much security and governance as possible. That means starting off with templates - "template" is almost too weak a word, but I'm going to use it anyway. You start off with a template of what an application looks like, and that template is approved. A lot of thought has been put into how it is secure, how it lets you upgrade things very rapidly, how it manages the life cycle of a container or the application deployment unit, how you provide access to databases and secure it, how you do all the logging and auditing. We start with that notion: how can this be managed, how can it be governed, how can it not only be secured from a hardening standpoint but also be upgradable very easily, as we see a lot nowadays.

Then, to use a fancy word - because I don't really like the word observability - you add in a lot of legibility. The ability to look into it, monitor it, see what's going on, and from both an operations standpoint and a developer standpoint understand what's happening in there. This is a lot of what you'll see in Tanzu Hub. It's a great way of getting legibility into the stack.

I want to go over this because it's not just a standard platform that you would encounter out there. It's really built specifically for the needs of enterprises running in a private cloud context, with the requirements and the needs that you have when you're running in that method.

AI is just another workload, if you have a platform

To give you an example of how this all comes together, let's look at everyone's favorite topic. Well, maybe it's not your favorite - let's look at everyone's frequent topic, AI, and how we brought that in. Same architecture, but highlighting the AI portions of it.

What you should notice is that in the same way we make it possible for you, when you add this platform on top, to allow developers to choose the frameworks they want, the ways of working they want, to integrate with the pipelines and the SDLC things they want - you can see that we've embraced that same way of doing things when it comes to not only serving up inference for AI and hosting models, but also the frameworks that people use.

For example, I think most enterprise applications out there are written in Java, and if you look at the number one framework when it comes to developers using Java, I believe they use the Spring Framework. If you look in Spring, there's support for - I'm going to use a technical term here - pretty much anything you want to do with AI, and it's been built in for several years now. Every new release they add new features that are in the AI world that developers want.

One of the ways of interacting with AI is through the Model Context Protocol, which came out in November 2024, I think. A few months afterwards, people on the Spring team ended up writing the official Java implementation of MCP. That's evolved into a huge - in a good way - varied set of libraries and tools in the Spring Framework. And because we're the stewards of the Spring Framework, this of course integrates into the Tanzu Platform, and then integrates into the entire private cloud stack that you have.

What that means is that when the developers come to you, as they probably are nowadays, and say they need a place to run their unique, bespoke, special AI applications that require a brand new coffee machine with all the knobs and levers and things, you can depend on the Tanzu Platform to be the place that has the new functionality in there. You've already got a platform that supports them, and you're not adding to that landscape of odd coffee machines.

The MCP gateway

To zoom into an example of what that looks like - and I think it's one of the more interesting things you get with a platform. I mentioned Model Context Protocol, MCP. The fundamental thing there is that you're in a chat application, you want to connect to some other service, and the agent is going to ask that other service to do something. It's essentially a standard way to provide an API to an AI to call out to tools to do things. The canonical example is silly, checking the weather, but it could be searching through a database, moving a workflow along, whatever you would do to call out to a service from an AI - and doing the enterprisey stuff with that: authenticating, tracking who does what, doing the performance tuning, making sure you've got good reliability and all that kind of stuff.

Normally you don't really have any ability to do that, because these MCP servers just sort of live out of band of your infrastructure. The developer, the application, goes directly to it, running somewhere, maybe even on the public internet if you allow for that kind of thing, and you're completely cut out of the loop from controlling it. Which starts to sound a lot like the "not my mistake, now my problem" situation.

So instead, what we have in the Tanzu Platform - and what our own IT group uses for this as well, so it's been used in a very large organization, if you know how large Broadcom is - is something called the MCP gateway. It's a very easy to understand architecture. Implementing it, of course, is difficult. You put something in the middle: a broker, a gateway, a proxy, whatever you want to call it. Instead of your developers and the applications that are using AI going directly to those MCP servers, it's now brokered or gatewayed, if that's a verb, through the MCP gateway that we have. This is a huge advantage of having a platform rather than doing one-off ways of securing and controlling and managing an MCP server. It's not only accessing your own MCP servers - we also do brokering out to publicly hosted MCP servers.

We follow the same pattern all over the platform. To give you an interesting example, I mentioned that we can also route your model requests, whatever model you might want to be running. You can host one in the Tanzu Platform, you can run it in the VCF stack, or even use the public ones. But you're given the same kind of person-in-the-middle control over who gets access, controlling and counting the tokens, shutting down access. Or, if you want to be sneaky, you can even reroute the request to lower cost or more secure models than what the developers originally requested in their application - which you might want to talk to them about instead of just doing it to them. But it gives you a sense of the control that you have in place when you have a platform there.

Developers just want the button that gives them coffee

That gets down to what I think developers actually need and want, and what I've seen become the revealed preference over the last decade or so of people who use the Tanzu Platform. Maybe they want to have knobs and pipes and things like that, but they're usually perfectly happy with just a button you press that gives them the coffee. If you build out the platform, if you provide the platform that meets those criteria I was going over, they really don't need this weird customized coffee machine out there - let alone a landscape of them that you now have to manage and worry about. That's the notion you want to move towards with the platform: let's make it easy instead of highly customizable.

It works: the ops-to-developer ratios

And it actually works. I mentioned several times that we've been doing this for over a decade - more than I've been employed here, for sure. I guess that's why I stick to a decade. What you see here are some excerpts, most of them publicly referenceable if you want to go see the stories behind them.

The platform not only achieves those things for developers, it has tremendous efficiency to it. One of the things we like to track over the years are these ratios: the number of application teams you can support with the number of operations people supporting it, the number of developers you support with the number of operations people, and the number of apps with the number of operations people. Because of all that automation, that consolidation, the standardization, and definitely layering on top of a stack like VCF and making sure that integration is seamless and works well, you can achieve these kinds of efficiencies.

For my argument here that you should care about platforms more: hopefully what you see is that it's not going to be an entirely brand new set of work that you need to do. It's actually just a little bit more work, a few more people, maybe a team of platform engineers - but it's not an entire constellation of new things you need to do to provide this, as shown by our customers over the years.

With that, I want to hand it over to Oren to dive even deeper into all of this. But hopefully I've at least convinced you a little bit that looking at platforms and thinking about them is a good idea, if not maybe a little bit fun and enjoyable to tinker around with.

What a platform service actually is

Oren Penso: Great. Thanks, Coté. In the rest of the session what I want to focus on is the private cloud stack, and how that platform service that we as an infrastructure team need to expose to our organization, to our developers and our consumers, integrates into the same stack and the same VMware Cloud Foundation 9 that you know from the rest of the portfolio we have in the company.

I haven't introduced myself. I'm Oren Penso, global field CTO in the Tanzu division. I've been around for 10 years, came from VMware originally, so from the bottom up an infrastructure guy, in and out.

In general, when we think about a platform, what does that actually mean? It means it's a service that allows you to take code into production in a single pre-engineered stack. If you break that into pieces, and if you think about the different platforms you have today and the way you're thinking about the runtimes of those platforms, you probably think about Kubernetes and the Cloud Native Computing Foundation ecosystem - a lot of different components and projects that are integrated together, because you've built your own platform.

The platform service inside the private cloud, the Tanzu Platform, is the exact same architecture, but it's closed as a pre-engineered product. It's very similar to other services you see in other public clouds, like Google Cloud Run or AWS App Runner.

On the upper layer of the platform you have the entire CI/CD pipeline: the way you're building the code, creating the images, storing them in a registry, creating the configuration files, running those in a runtime - and everything is preconfigured, managed, and curated. It's basically making a consistent way to take code into production, which is very significant because it allows you to maintain a very high level of security. That consistency, especially with application modernization, microservices, and a lot of different images spread across the organization, is something you really need and want. And if we take a half step forward into the AI workloads, it's going to be even more important.

So in general the runtime of the platform is very similar to Kubernetes. We have foundations, which equal clusters. We have the Diego brain, which is similar to the Kubernetes scheduler. Diego cells, which are the workers. The blobstore, which is the registry, and so on. You can see it's very similar - but for a long, long time it was decoupled.

From black box to integrated: the new CPI

For a long time that was decoupled from the actual stack. It was decoupled between VCF with the supervisor cluster, the Kubernetes API, and the platform, which was a black box that sits aside and interacts with the vSphere APIs or the vCenter APIs, not connected or part of the same integrated stack of the private cloud.

In the last couple of years, since the supervisor cluster in VCF, we had a Kubernetes service, VKS, that was interacting with the Kubernetes underlay. One of the major things we have in VCF 9 is that the Kubernetes API layer, the supervisor cluster, now allows you to declare and manage all of the different workload types you have in a Kubernetes structure. You're configuring a CRD for a VM, or for a pod, or for a Kubernetes cluster, and everything is landing on the same networking stack with NSX and VPCs, in a project and organization based on VCF Automation. VCF 9 plus became very productized - a private cloud in a box, if you want to call it that. And so the platform has to be part of that, and that's exactly what we've done.

We've basically decided that the platform should be an advanced service of the private cloud, not just in slides but also on an architectural and technical level. Which means that now the Tanzu Platform lands as part of the same ecosystem of services you know, that can land on the supervisor cluster. Just like you're creating a Kubernetes cluster, or creating a VM based on VM service, or creating a native pod - exactly the same way, you can now create an entire PaaS service that is part of the same private cloud.

The experience should be exactly like any other experience you know from any other hyperscaler. As a consumer I'm getting access to my project, and in that project I can now enable Tanzu Platform. That will allow me to expose a PaaS service that the developer needs to consume with only one command, pushing the code into production, which will create the entire pipeline, the entire CI/CD and SDLC. Eventually those consumers can also create other services in the same ecosystem and bind those applications to those services. So the entire experience of a full-blown pre-engineered PaaS is coming inside the private cloud, VCF, exactly like any other service.

There were a couple of things we had to change in the architecture of Tanzu Platform along the way to make that black box the platform used to be more integrated into VCF. As I said, the orchestration of the platform was interacting with the vCenter APIs. It was also a very large footprint. It was decoupled from any other technology stack in the vSphere and vCenter environment, and we wanted to bring everything together.

The platform is built on an orchestrator called BOSH, and BOSH has CPIs, cloud platform interfaces, just like Kubernetes has. BOSH, or the Tanzu Platform, can land on a lot of different types of infrastructure providers. One of them is vCenter or vSphere, which is the traditional CPI we had to VMware. But the same platform black box can land also on Azure, Google, and AWS. Just keep in mind that the platform itself, the black box, the pre-engineered PaaS, can land on different infrastructure providers. Either way, coming back into the private cloud, into VCF, we had to make something more integrated as part of the same ecosystem, network boundaries, security boundaries and everything else. And that's where we created a new CPI for the Tanzu Platform that connects into VCF.

Smaller foundations, profiles, and Tanzu Hub

Along the way we've changed the architecture a bit. We are now more aligned with the best practice of the community, where we have smaller foundations - equal to smaller Kubernetes clusters - and those small-footprint foundations have different profiles. You can decide that you have a foundation only to run applications, a foundation to run only services, or, in the new types of use cases, a foundation to run only AI workloads. The most important thing is that those different foundations can now be provisioned and deployed into the same namespace of the supervisor cluster. So a vSphere namespace, a supervisor namespace that is part of a VCF Automation project that is part of a VCF Automation organization - and the Tanzu Platform lands on the same architecture with the same capabilities.

One important thing about that change of architecture is that to create it, we had to change the way we think about managing those different foundations. When you create smaller clusters, like in the Kubernetes ecosystem, you now have to introduce a new control plane to manage all of those different clusters, life cycle management of all those clusters, and so on. The Tanzu Platform introduced Tanzu Hub. Tanzu Hub is the control plane that manages all of those different small-footprint foundations with different profiles. That hub sits alongside VCF Automation, VCF Operations, and all the other tools used to manage that kind of VCF entity.

From a consumption service point of view, once you create that service inside your project in VCF Automation, the consumer has the same access as to any other service he has inside that project. He will have his own application space, and then he can decide if he wants to create applications and services inside of that or outside.

A Kubernetes runtime inside the platform

Now I'm getting to a bit of the new things. We didn't stop at creating that integration between the Tanzu Platform and the private cloud, and we didn't stop at creating that foundation architecture integration with the CPI to VCF. Now we can leverage the fact that we are landing on the same vSphere namespace, with the same NSX project and NSX VPCs, and we can actually leverage other services of the supervisor cluster on the Tanzu Platform's behalf.

The first thing we decided to do - because even though it's a pre-engineered platform, we want more use cases and more types of workloads that can have the same pre-engineered platform experience - is we introduced a new Kubernetes runtime for services. The Tanzu Platform has exactly the same experience from the consumer. He isn't even aware that something is running on Kubernetes or on the Cloud Foundry side of Tanzu Platform. From the consumer side it's just creating a service, and that service can either land on Cloud Foundry or on Kubernetes.

What's the difference between this VKS cluster and any other VKS cluster? This one is only for the platform's use. It's managed by the platform, it's part of the pre-engineered platform black box, and it's not exposed to any use case other than the platform use case. So you can think about extending those different platform runtimes to support new types of workloads. But if you as a customer still need a Kubernetes cluster, you will go ahead and create your own VKS cluster outside of the platform, and you will use that for your own DIY platforms - or the coffee machines with the different knobs that Coté showed before.

So in general what we're now providing is both sides of the coin. We have two different PaaSes. We have the coffee machine with a lot of different knobs, where you can keep going and using upstream Kubernetes CNCF tools that are supported and maintained by us - that's the open platform approach. But if you want a pre-engineered approach, and you want a platform that has that kind of guardrails and consistency and a stack that is fully managed by the platform itself, that's another thing you can do.

That type of service that lands on Kubernetes is not going to be the only thing we land on Kubernetes. We will also allow you as customers to land applications on Kubernetes, again as part of the black box. So the Tanzu Platform will allow you to push a container image, or push anything that needs a Kubernetes backend, and it will run in a Kubernetes backend inside the Tanzu Platform - again, a Kubernetes cluster that is managed by the Tanzu Platform.

I'm saying that a lot of times because it's important to distinguish between the different types of services. The Tanzu Platform is a pre-engineered PaaS service that will allow you to run that kind of custom apps and other apps or services on different types of runtime. From the other end you have VKS, which is a Kubernetes service just like any other Kubernetes service in the cloud. If you want to think of an equivalent in the hyperscalers, think about GKE and Google Cloud Run. That's the difference: GKE or AKS is basically VKS, and Google Cloud Run is more like Tanzu Platform, where it's pre-engineered and managed as a product.

Connected clusters: the Tanzu operator for Kubernetes

We understand that we're still going to run a lot of different workloads on Kubernetes outside of the platform. The platform is not something we're going to move everything towards, or use for any use case, like any other hyperscaler. We have those different options, and now we want to also connect the dots between those two different paths to production, between an open platform and a pre-engineered one.

The way we're doing that is by introducing a new Tanzu operator for Kubernetes. That operator will be deployed on a VKS cluster that is not related to the platform - it's external to the platform. The operator introduces new CRDs: service plans, service offerings, service instances, service bindings, and secrets. From the experience of the consumer on the Tanzu Platform it's going to be the same. It's going to bind an application to a service, or decide that an application running on Kubernetes needs to talk to a service running on the platform. But from the implementation standpoint, the workload can run on VKS and the service can run on the platform.

A simple example I'm hearing a lot about: if you're running your agents, some kind of an agent within a harness on Kubernetes, you already do that. You have that, it's running. Now you want to leverage all the capabilities Coté just mentioned - the AI middleware, the AI gateway, the MCP gateway, the vector database, the cache layers, the message queuing, or any other service you can get from that platform. You can keep that workload on VKS outside of the platform and then connect the dots between that workload and services in the platform. So we have a backend Kubernetes cluster inside the platform, for the platform, and we have an external Kubernetes operator that allows you to connect external clusters to services on the platform.

Same platform API on any cloud

As I mentioned before, the Tanzu Platform is a pre-engineered PaaS service that has CPIs. So in a case where you want to leverage any other clouds outside of VCF, and you want to burst to public clouds, or you want to navigate and transition, or create an active-passive or active-active situation between different infrastructure, that can be achieved with the Tanzu Platform. The platform will maintain the same API layer. So the consumption side of the house, the experience, will stay the same, and the developer will use the same APIs, the same automations or orchestrations he's using - but the workloads can land on different foundations that land on different infrastructure providers, based on whatever you configure underneath the CPI of BOSH.

One thing I forgot to say before: I talked about the fact that the orchestrator for the Tanzu Platform is BOSH and that we've created a new CPI for Kubernetes. What we actually created is that connection between BOSH and Kubernetes. On a technical level that means BOSH is creating the desired state, but Kubernetes is the scheduler. So the supervisor cluster is now the scheduler of the workloads, and BOSH is the one to create the desired state, the configuration manifest, and everything else. That's how we created that CPI. Having said that, we also have the CPI to AWS, Azure and Google, and you can decide where you want to land with that platform.

Q&A

Coté: The first one is from an anonymous attendee. It says: isn't the Tanzu Platform based on PCF and not Kubernetes-based? I think you answered that.

Oren: Yeah, I've answered that, but let me clarify again. The Tanzu Platform has Cloud Foundry as a backend, as a runtime, and what we've done is we've extended that runtime with Kubernetes alongside Cloud Foundry. For different use cases we land on different runtimes based on the placement engine of the platform itself. So it's right - in the past we evolved the platform.

Coté: And then the next one, also from an anonymous attendee - might be the same one, who knows, since they're anonymous: I'm hearing the services are similar to Kubernetes. Does that mean the services are proprietary and not open source?

Oren: Oh, that's a great question. All of our services, or most of our services, are open source. The services that I referred to were RabbitMQ, Valkey, Postgres and MySQL. And there are services that are also proprietary and closed source - those are the massively parallel processing database that we have, like Greenplum, and the high-speed caching layer, like GemFire. So we have both. I haven't said this, but all of the Bitnami Secure Images, which is 500 open source projects, are part of the same landscape of the Tanzu Platform, and you will be able to consume them as part of that extension I mentioned to Kubernetes. So we have a lot of open source projects in there, and we have some products as well.

Coté: And also, I mentioned at the developer layer the Spring Framework - that's all open source. There are some support offerings and things on top of that that are not fully open source, but it's an open source ecosystem there, and then the various services that people use. So the platform is composed of open source with little bits and pieces here to integrate it together, and like Oren said, a few other things that are proprietary, if you will.

The next question is: what is container as a service in VCF Automation? Is this the same as vSphere pod?

Oren: That's something that's not really related to Tanzu Platform, but yes, it's the vSphere pod or the native pod running on the supervisor cluster - at least that's what I know.

Coté: Well, there you go. There's one thank you from Thomas, but thank you for attending, and everyone else, thanks for attending. It was a pleasure talking with you, and Oren and I are always happy to talk more if you want to get a hold of us. With that, enjoy the rest of the conference.

The build versus buy decision

(0:10) Hi, thanks for having me. What I want to go over today is what I think is very important, and that is thinking about the build versus buy decision when it comes to your platform. This is very important nowadays because - I mean, we're here at PlatformCon, we all know there's an extreme amount of interest in platforms. What's happened is that over, let's say starting about two years or so ago, people have been seriously looking up from the Kubernetes level and thinking about how we layer something on top of just infrastructure. Which can be fine, if that's what you want, but make it more friendly for application developers.

AI makes platforms more important, not less

(0:47) Of course, I can't let even a minute of talking about something go past without talking about AI, but I want to mention why I think platforms are even more important because of AI stuff. Normally we think about platforms for application developers. But if you look at how agentic coding is going - I use Claude Code, you could use Copilot, whatever else you want - a lot of what's going on is that you have a new type of workload, a new type of customer for your platform, and that is, for lack of a better term, the normies. The knowledge workers, who are now using agentic AI to actually write code. They're not writing the code, but their little robot friend does.

(1:25) And those applications, as someone at a bank was telling me, they need to run somewhere. Most platforms that I see out in large organizations aren't quite set up to be that easy. But I think over the next year or so you're going to need the platform not only for application developers, but especially as more and more non-IT, just regular people, start getting access to AI apps that allow them to just code things up. And again, they need to not only run it somewhere, they need to connect to the services that any developer would need to connect to, in the secure, enterprisey way of doing things.

What a platform gets you

(2:02) Now, these are some numbers. I've studied platforms and application development for a long time, and over the years I've collected several numbers. Having a platform has great results. These are all based on people who use Tanzu Platform over the years and currently. As measured by the amount of applications that run and also the amount of people used to manage it: part of the point of the platform is not only running those applications, but doing it in a very efficient way where you don't need a lot of operations people to handle it. You're not running your own company inside of an organization to do it - you're supporting thousands of applications or developers with just a handful of people.

(2:44) And these are apps that banks use, very mission-critical things out there that have high-performance needs. Someone like Charles Schwab - you can imagine the trading when the day opens up and their volume goes way up. They run on top of a platform that supports that kind of doing things. Of course, the best platform in the world, the Tanzu Platform. But I'll try to keep it a little vendor-free here for you.

This is me

(3:10) So, speaking of me - or me speaking - this is me. I've been lucky to work at, starting at Pivotal and then through the acquisition by VMware and the acquisition by Broadcom, now in Tanzu. But I've worked in the same group and role over about 11 years or so now, looking at how large organizations work and really following my interest of how they get good at software. I've written several books. I've got some podcasts, the Software Defined Talk podcast, which has been around for a good 30 or 40 years, it feels like, that we do weekly. And I was a programmer a long time ago. I worked at RedMonk and Dell, all kinds of stuff like that. If you're really interested you can go check it out - there's a blog and a newsletter, all the nonsense that you would want about me.

Seven ways people fail at doing a platform

(3:57) So let's look at these seven ways that I have cataloged that people fail at doing a platform. And, well, "fail" - there's degrees of failure, but they're not completely satisfied. This is based on a paper that I helped revise and update and kind of do the second edition to, that I'll give you a link to at the end. So I'm not the sole person who came up with this stuff, just to call it out. But I think it's important to go over these things again, so that as you're figuring out the platforms you want to put in place for regular workloads or for AI things - or, as we'll get to, maybe you've discovered you have been building your own platform and you discovered some of these issues - these are the things you want to avoid.

#1 Unexpected scope creep

(4:44) So the first one is unexpected scope creep. To get an appreciation of this: most people go into building a platform, and of course very few people say it takes a weekend, but being an application developer, I think all of us developers were always like, why would we use this off-the-shelf thing, or buy this thing, or even this open source project? I could probably code that in a weekend.

(5:07) This sentiment - whether it's a weekend or whatever - tends to exist because organizationally people don't really understand the full scope of a platform. Just as a reminder, I know everyone here probably knows what a platform is, but as framing: here's two examples of platforms. You've got the CNCF platform reference architecture, which is fantastic. You've got one version of it, the Tanzu Platform, over there. But it has all of the things, as you well know, needed to run a platform. It's a very large scope.

(5:36) To put it another way, you look at all of the things, the outcomes, the capabilities that a platform delivers on. As you start writing them down, especially for a large organization, you start seeing that this is a huge list of things. An important thing here is that Kubernetes - the most popular infrastructure, it seems, that people think about in the platform space, or talk about - is not all of this, to put it in an odd way. What you're doing is building a lot of stuff on top of your infrastructure, Kubernetes. Think about all of this stuff. That becomes the full scope of what you're doing: not just a portal, not just a CI/CD tool, not just integration with YAML copying and stuff.

• App delivery.
• Backup and restore.
• Patch management.
• Observability, logs, monitoring.
• Service management and use.
• RBAC, etc.
• Vulnerability scanning.
• Dev framework integration.
• High availability and the other -ilities.
• Multi-region deployment.
• Sovereign cloud.
• Auditing and compliance.
• Multi-tenancy.
• Upgrading the platform.
• Gateways, brokers, load balancers, etc.
• CI/CD, itself or integration.

(6:23) To give you more of an idea of the scope, if you look at the Cloud Native Maturity Model from the CNCF - this is from a beta version, I think - you look at the phases of an organization as they become a platform organization, all of the stuff that they go through. And if this slide looks overwhelming, that's the point of it. There's a lot going on there. When you read it, there's kind of an offhand estimate that this is going to take you about three to five years to get through, and most organizations don't actually get through the whole maturity model. So the scope of what you're doing is much larger than most people anticipate. It seems like it's going to be something that's simple at first, but again, you look at the full scope of what a platform is - there's a lot going on there.

(7:08) Plus integrating with all of the stuff around it. All those services that you're bringing in, whether it's databases or nowadays your AI services, your brokers, all of that kind of stuff.

#2 Underestimating the ongoing investment

(7:18) Once you underestimate the scope, you also underestimate the investment. I see this a lot, over the years, where people started up an initiative, often to build on top of Kubernetes - and sometimes they even do that on their own, which seems like madness - and after one or a couple of years they realize that the cost of doing this is going to be a lot more than that initial team they had. Remember, the scope is bigger, so you end up needing more people.

(7:47) So you start off thinking, even if you think you only need one team of three to eight people, you can see that when you think of it cumulatively over time. Because in a buy versus build decision, you're comparing the amount you're paying to buy something with the cumulative amount you'd be paying in salary. If you see the cumulative amount you're paying for one team, you can see over a five-year term that it gets to be, I don't know, around 5 million or so. Now, as a person, that's wonderful. You want to be hired for that.

(8:19) The other thing that I think people miss is that you're not going to have just one team. Again, think of the scope of the platform, all those things we just went over that it does. And also the project management, the product management, all of the associated things around it - and you're talking about somewhere in the order of three to eight teams, which multiplies your cost out much, much more. These kinds of expenses creep up on people if they didn't have the right scope, and therefore they didn't have the right thinking about how much it was going to end up costing them. So your scope is generally bigger than you think it will be, and the costs you take on therefore tend to be bigger than you anticipated as well.

#3 Platform as a project instead of a product

(9:01) The next thing that often happens - and this affects the scope and the ongoing cost - is that people think of a platform more as a project instead of, as we all know, a product. It's going to be a one-time deliverable of functionality. They stand it up. You hear this from infrastructure people all the time: that they stood it up, and the developers aren't using it. The difference in thinking about something as a product is that it is an ongoing, continuous - you could say investment, but effort - where you have to add new features to it.

(9:36) Your platform has to evolve. It's got to adapt to what your developers want. Nowadays we've got it right in front of us: all of a sudden you need to add a whole bunch of AI services, not only for code generation and supporting developers using AI, but also for using AI in your applications. These are things that need to be added in, not to mention every single other thing. So it's not a one-and-done sort of thing that you do.

(10:04) It's an ongoing staffing, an ongoing project. It's something that you now own and are responsible for. Doing things in this platform-as-a-product way is widely understood to be what drives a lot of success for platforms in organizations, as you can see at Mercedes-Benz. As Thomas Müller there put it: "We are building this platform not for us, we are building it for Mercedes-Benz developers." It's a great talk if you want to dive into that a little bit more.

#4 Homegrown lock-in

(10:28) Another thing that comes up: one of the reasons you want to implement your own thing is that you want to avoid lock-in. I think the problem in thinking here is getting ahead of yourself about what it is you want when you're trying to avoid lock-in. Of course, if you build your own platform, you are locked into your own platform. You're now responsible for all the security updates, which we find more and more of, as I'll get into. Adding all these things and supporting it. And it's your unique thing that isn't really compatible with other stuff, versus a more widely used platform that's out there.

(11:07) So I would think about the goals you have with your lock-in avoidance. You probably just want the portability, the freedom to leave, as Simon Phipps talked about it. And you want your switching costs to be low. So think about these lock-in problems in those terms - not just "we're using proprietary stuff," or "we're using something backed by a vendor, we've got to use this open source thing or this thing that we did." It's all kind of mixed together nowadays with how this is done. So no matter what you use, rate it by these categories and really pay attention to what the lock-in thinking is. Gregor Hohpe's "Don't get locked up into avoiding lock-in" and Keith Townsend's "Thinking About VMware Alternatives?" are both useful here.

#5 Retaining skilled people

(11:40) Next, the issue that you have is retaining skilled people. Every time a survey comes out about a new technology, the same issue arises: we don't have the skills. Now, the people surveyed often also don't spend a lot of time training people.

(11:59) But when you get skilled at something like Kubernetes or other platforms, that's an incredibly valuable skill that you have. And I see over and over again that often the core team of people who built the platform can now go get another job somewhere else. And they often leave. So if you've built your own platform, the people who know about it - there's a high chance, or at least a non-zero chance, that they might leave. Which kind of is a bummer, now that you're locked into that platform.

#6 Keeping up with security and compliance

(12:27) Next - I mentioned this earlier - you are also responsible for keeping up with security and patches and compliance. This is an older chart, it doesn't include 2026, but the amount of CVEs and the need to patch have been increasing incredibly fast. And now with the way that AIs are finding things, it's insane how many bugs are found and how much patching needs to happen.

(12:55) This becomes a huge deal if you have to manage and do this kind of hardening yourself. Whereas if you're using a standard platform - if you're even buying a platform from someone - you have someone else who's doing that for you.

(13:11) Now, the other thing that's very current at the moment - hopefully not for much longer - is people wanting sovereignty, wanting control of where their platform is running, where the applications running on it are.

(13:28) You can think of this broadly as governance and compliance. This is another thing that you now own. Do you need to run in multiple regions? Your platform needs to support that. Do you need to comply with, for example, the DORA banking law - not the DORA DevOps stuff? That's something you now need to take care of in your platform. So you can see how these things pile up more and more when you start to build your own platform, instead of having it shared amongst all the people who are using a common platform in the industry.

#7 Resume-driven development

(14:01) So the final one is that a lot of people succumb to doing a platform because of resume-driven development. They do it because it's cool and fun and will help their resume out. And there's actually a paper, which is great and fun to go read, where they've studied this phenomenon. As you can imagine, when you do resume-driven development, it doesn't really result in fantastic usable technology.

Stop building platforms. Start building apps.

(14:27) Finally, I think there's a lot of other voices out there, people who will tell you that building your own platform is not a great idea. It's much better to focus on what you actually want - those capabilities, the applications - and to spend as little time as possible on this commoditized thing. Your business isn't really going to succeed because you've got a unique, cool platform, when you could have just gotten a platform that is equally cool and functional.

(14:58) So I would encourage you: one of the ways to avoid failing at platforms is to stop building platforms and start building apps. With that, thanks for having me. It was fun talking with you. And if you're interested in more, feel free to reach out.

Intro: who I am, and why this talk

I've come in and out of smaller places, larger places, places that have been acquired, boring places, innovative places - all manner of stuff. I've even worked in strategy and M&A in addition to programming and whatever it is I do now. I'm on Josh Long's team, so ostensibly I do similar sorts of stuff to what he does. And over the years I've kind of collected together what I do to stay sane and be profitable at a personal level in large organizations - and also try to be able to morally sleep with myself at night. So this is a collection of some of those things.

There's a related thing I've worked on for a little while called The Business Bullshit Dictionary. It's a good way to filter if this talk might be applicable to you: if you've encountered phrases like the ones in the dictionary one or more times a month at work, this talk might have something for you. There's also an O'Reilly video series that goes over a lot of this in more depth if you want a certificate.

The 360 review: the "270 review" rule

Let's just randomly pick, maybe, the most useful one to have as far as helping support your peers: the 360 review. Whenever you're in a job you get performance reviews. They're framed as "we'd like to give you this feedback so that you can grow and mature," but really they're figuring out if you're worth what we're paying for. You get an individual review from your manager. Maybe a self-review. And every now and then, you get involved in what's called a 360 review, where they go out to all of your peers and ask them what they think about you. When I've been involved in these, it's usually: what's good, what could they improve.

Here's the point of the 360 review - and your manager maybe won't tell you this. If you're asked to give input on a 360 review, there's an unwritten but now-spoken rule amongst us workers: you skip that question that says "what can they improve on." You just leave it blank. You don't say anything negative about your peers, even if you feel like "ooh, wouldn't they like to know." You can go tell them privately if that's your thing. But that is going in their file, in their record - a tool that can be used by people you didn't grant access to your knowledge, to do something not cool. So: if you're ever involved in a 360 review, and someone asks you what the person could improve on, say nothing. Give them a good 270 review.

What a big company is

Let's level set on what a big company is. Most of this stuff only applies to big companies. Small companies have a different dynamic. Of course, you can have a big company feel at a small company. People say "small company feel at a big company" but I don't know if that really exists.

I think a thousand people is almost too small. Ten thousand is better for a big company. But mentally, the shorthand is: if you've ever found yourself talking about "them" - "they won't let us do this," "they told me I have to do this," those people over there - you're probably in a big company setting. A bunch of silos and groups that need to coordinate. That's where a lot of the 360 reviews and other framework stuff comes in. Instead of just people talking with each other and syncing up, they rely on a framework of how they're operating.

Whatever a company says its mission is: they want money. Money comes in, it costs them what it takes to run things, and what's left over is profit. Keep that in mind as the basics of what your organization is doing.

Then you have the multiple groups. Judging by how much dry cleaning most people in this room do, I'm guessing you're towards the bottom of the stack - individual contributors, workers, the people doing the stuff. Then middle management - the measurers, as the Cloudflare CEO recently put it. Then outside consultants, thought leaders, strategy people. All the way up to management.

Especially in an American company, and more or less in Europe as well: at the individual level, you're getting cash as compensation. You might get nice vacations, but as you go up the stack, what people are getting is equity. Stock. A share in the company. The motivations at each level are different. Down here you're trying to maintain your steady cash flow, do your job. Up there, they're interested in the overall value of the company.

In tech, two important distinctions to remember. A lot of the career advice you'll read comes from people in tech companies and people in startups. The way tech companies operate is very abnormal. The way startups operate is very abnormal too - the goal is to build up the perceived coolness so someone either buys the company or you have a public offering, and then someone else figures out how to profit off of it. In a normal company, there is no exit. It's just forever. There's no major event where cash extraction comes. That shorter time horizon in tech companies affects how people think.

You as a P&L

Companies are very into telling you what their culture is and how they want you to fit in. I would take everything they say as the baseline culture and start to act like a company acts. Think of yourself as a P&L - a profit and loss. How much is coming in to you, the worker? How much expense, time, effort, sanity is going out? What's left over for you? Manage that basic equation.

Now, sure, having fun and putting a dent in the universe - maybe that's part of the revenue too. But beyond just doing a good job, figure out what your cash flow is, what your profit is in the situation. That's exactly how most big organizations work. The people at the top of the pyramid, they don't get together at the end of the year and say "we did a good job, see you later." A few companies focus on not being terrible. But they usually change their mottoes around from "don't be evil" to "sell more ads."

Craft your character in the story

This is something one of my bosses at Dell indirectly taught me. Think about the organization as an ongoing story - a book, a TV show, an audio drama, whatever. Think about yourself as being a character in that story. What is your character? What's your role? Not just identifying what it turns out to be, but identifying what you want it to be, and then crafting it.

Maybe I'm the character who's the programmer everyone goes to when something's broken. Which - we've read The Phoenix Project or we've been told we need to read it, so we know that's terrible. But it's cool for a book. Maybe you're the person who's friendly and cheery, or the one who fixes things. Figure out how you fit and cultivate it. This ends up defining your responsibilities, your roles, and how people in the organization perceive you. If you think about it in a programming way, it's kind of like their perception of your API. When they interact with you, they'll do it through that perception. So craft what you want the API to look like.

One thing: if you want to just be left alone to do your job, you should never suggest a better way of doing something to a large group of people. Because then you're going to have to do something about it. Think about your role and how you want to behave. And once you figure it out, remain consistent. In a David Lynch movie, it's cool when characters suddenly become a whole other character - Lost Highway, right? It's also not great at the box office. Large organizations don't like chaos. Figure out what your role is, remain consistent, and change it very carefully over time.

You can be a wild person all over the place. That's the character with a long LinkedIn profile of places they've worked. There's a great phrase - I should put this in the dictionary - a resume-generating event. If that's the character you want to be, it's very entertaining for the rest of us. So do it.

Homework: avoid getting assigned it, use it to filter requests

Homework is something you have to do that you kind of don't want to do. Some people enjoy doing homework, but you wouldn't usually call it homework if you wanted to do it. It's some labor you have to do that isn't the stuff you'd rather be focusing on.

If you want to be the character that's left alone, the main thing is to avoid being assigned homework. You get assigned homework in all sorts of ways. I've been told several times that I say yes to everything, which probably explains why I see a therapist frequently. Maybe I should say no to them more frequently. You get involved, you talk with people, and very often you get "oh, could you take a look at this?" "Could you give me your feedback on this?" That's another form of homework. They probably do want your feedback, but usually that's not part of your job, and now this is extra work you're being given.

There's a good way to avoid homework - which is also a good way to filter what's worth your time. Ask about the dates, the requirements, and the budget. Assign homework back to the person asking. If someone comes to you asking for feedback on a design or a proposal, before doing it, ask them to do a bit of homework for you. If they're not willing to do homework to assign you homework, it's low value to them and probably not something you should pursue.

For example, if someone says "could you go look at all this code and tell me what you think," and there's no documentation or design diagrams, you can say "could you give me some design diagrams first?" They now have to spend time to show it's worth their while. Three things that are always worth asking for:

• Requirements. Why are you doing this? If people don't have answers, they're probably dreaming up things and hoping you'll figure it out.
• Dates. When do you need it by? "Whenever" means it's low on the list. They're outsourcing their workload.
• Budget. This is the worst kind of homework to be blindsided by - someone comes to you with a big exciting project, you work on it for a few months, and then you find out there's no budget allocated, and now your job is to go put together a whole proposal for why there should be budget. You've done the work that they should have done to make it an official project.

So: be very careful about being assigned homework, and use it as a way of establishing the collaborative playing field.

Hiding out to innovate

You want to innovate, do cool new things. In a large organization, realize that most big organizations don't want to innovate. If you work in a big org you've probably had "why don't we do this brilliant thing?" - and for some reason it's not done. Going back to establishing your character and being consistent - big companies don't like a lot of innovation because it's extremely risky and chaotic. You could spend all this money on something new and then you have to live with, say, one of those voice things from the 2010s that don't really work out. Innovation is taking on risk to damage your current business potentially, which is frustrating if you like doing new things.

If you do want to innovate, the best way to go about it is what I would describe as hiding out. Carve out space where the large organization doesn't discover it. Because once it does, imagine 3,000 people giving input on what you should be doing - people in that homework mode who don't have any control or budget but want to set up a meeting to align on your priorities and your slides. You'll get eaten alive.

Case study: my friend Barton George at Dell. If you go work at Dell, or if you know developers who know Dell, the first thing they say - other than congratulations - is "you know, I'd really like to go to dell.com and order a laptop that just ships with Linux." Every single time. Barton was like, we should do that. He spent about two years - and this is a good level set on what innovation in a big company is - and eventually shipped Project Sputnik: the XPS 13, their MacBook Air equivalent, running Ubuntu with a partnership with Canonical, in 2012.

The way he did it: he didn't engage with the official way of innovating. He didn't get into the annual planning process, didn't figure out his total addressable market, didn't do any of that. He just talked with people, built up a network from the bottom, got into the meetings where the software could get on the hardware. Very unofficial. The line lasted through something like twelve generations of laptops. If a laptop line survives that long, it means it was profitable. But if he'd gone in 2010 with "hey, I've got an idea," the response would have been "developers don't buy anything." That's the common sentiment for people who sell things.

Try to just do it on your own until you can't do it on your own anymore, because you're going to be crushed by the organization otherwise. And as my IBM friends say: at IBM you're never given a new job, you're given an additional job. You still have your day job. This becomes extra energy. Which gets back to thinking about your role in the story and how you want to spend the energy you have.

Mentors, and - more importantly - champions

If you work in a large organization with well-trained HR people, at some point you'll be told you should get a mentor. You might even have an official mentor program - which, I've been in one, very weird and awkward, but whatever. Mentors are fine. What I want from a mentor is someone I can have some work therapy with, someone who has more experience getting by in this type of organization than I do, so I can be like: is this bullshit or not? Tell me what you'd do about this.

One thing I learned early on is: you want mentors, but you also want to cultivate champions. Your mentors can do this, but it's not necessarily in their role. Champion is an apt word. What champions do for you is they fight for you or advocate for you. They do things on your behalf in an area you otherwise couldn't access. Just like a mentor, you want a champion who's not in your same group, a few levels above you. Someone more powerful than you, who you get friendly with, and who you can ask to do things for you.

Back to Barton - he had several champions. He'd just say "I've got to get in that weekly what-stickers-we-put-on-the-laptop meeting, because those are the people I need to talk with." He had an ask, and a champion could get him in.

Now, the reverse relationship. As you might expect, the higher up you go, the less honest access people have to what's happening at the bottom. Your champions and mentors want to know what's actually happening down at the do-level. That's part of what you give back in return - an honest assessment of what's going on at your level. Cultivate those relationships, know what you can offer them.

Presentation craft: a document that's been accidentally printed in landscape

This is the most important section if you work in a big organization and want to get more involved. My friend Mark Cathcart - always an IBM person, right, who used to work on some gobbledygook storage array in 1970-something and slept on a mainframe at ExxonMobil and warmed up his curry on the mainframe floor - Mark once summarized the importance, as you go up the big organization, of being good at presentations. It's quite incisive.

Unlike these slides and a lot of what you'll see at conferences, corporate slides are extremely different. All the great presentation secrets of Steve Jobs, all the TED Talks - just ignore all of that in a large organization. You don't have big pictures and single words. There's a rule that a presentation should require you to be there to give it - it shouldn't stand on its own. In a big organization it's more important to think of a presentation not as a presentation, but as a document that's been accidentally printed in landscape.

Once you have that mental shift, it clicks. A presentation is a social artifact. It gets used more outside of being presented than during. It gets emailed around. People use it as a reference. They look at it on their own. They might even - horror of all horrors - use it for project management. Those 300-slide decks with dates and project notes. PowerPoint is a very powerful tool - it's right there in the name.

So think about a presentation as a document instead. Here's what that looks like. Normally you'd have a document that says "here's an issue we have, I'm discussing it, here are some charts." The corporate presentation is a condensation of that: a big quote, a conclusion. You're doing one of two things - telling people what you want them to think, and telling them what you want. And giving them proof.

A slide with a lot of text on it - normally you're told never to do that. But that kind of slide is gold for a corporate presentation. Again, it's a document accidentally printed in landscape. This is going to be sent around; people are going to read it on their own. It's mentally disconcerting because everyone's told not to have a lot of words. But use it judiciously.

One of the best micro-tactics: the McKinsey title. If you can achieve a McKinsey title, that's the pinnacle of professional awesomeness for deck makers. Normally the easiest thing to do with a slide is describe what the slide is - "a developer toil survey has questions." That's a stupid title. Instead, use the title to tell people what you want them to take away, what you want from them. Use the title as an argument. Instead of "here are common metrics used by DevOps organizations," write "use metrics to build trust in your organization." What action do I take from this slide?

The other important thing: most organizations or groups have a house style - the way they do presentations. Notice this if you study it. When someone has their own way of doing slides, it's very difficult for the organization to understand what's happening. Adapt to the house style. The people who decide things, who give you budget, who give you permission - their brain is programmed to consume information in that presentation format. Figure out what they see most frequently. Do they like McKinsey slides? An executive summary? An executive summary with one big line and one small line under it? Craft things that way.

Have an ask

If you want to move around in an organization, always have what they call an ask. An ask is what the word means - something you want from someone, something you want to ask them. In some cultures this is called an elevator pitch. The importance of an ask in a large organization, especially if you're innovating: you'll randomly encounter people who could give you something if you just knew what to ask them for.

In Barton's case: I want to ship this laptop. I've got to certify for these markets. I need to figure out how to work with Canonical. I need to know the roadmap for laptops next year. He always had these things in his head - if I met the right person, I could ask them this. In figuring out your role in a story, what are the things you would ask people? And then - the part I always mess up on, because despite being at the individual level I don't really like talking with strangers very much - you actually have to ask them. Which is sometimes difficult. But think about what you want, and have those asks ready in your back pocket.

Price yourself, and know what you'd rather be doing

Back to the beginning - the P&L framing. It's not that straightforward as an individual, but start thinking: how do I act like the company? What's my revenue, what's my expense? Is it really worth my time to work more than 40 hours? Is it even worth my time to work 40 hours? Can I just get by with not doing that? What do I actually need to do to achieve my part in this story?

Many people I encounter in tech suffer from having nothing else they're interested in. If you're thinking in terms of revenue, expenses, and profits - literally or metaphorically - pricing becomes important. How do you put a price on your time? Pricing is a dark art, mystical and magical. One way to figure out pricing is: what would I rather be doing? Do opportunity costing. I could put this amount of effort into the big company, but that means I'm not going to have time to paint my Warhammer miniatures. Or help my kids with homework. Or just go to bed early. Build up your strategy around the other things you'd rather be doing. Figure out your pricing, so you can manage yourself like a P&L.

You don't want to be in the situation of not knowing the price of anything - including yourself.

Books, and one last cultural note

There's a certain interpretation that this comes off as cynical and dark. I don't know. I think it's just how things work - a dismissive amoral way of saying something's okay. But in my experience, it is what happens, and people are totally fine with it. This is how organizations function.

Two great books if you're interested in how this stuff actually works. First, Moral Mazes. Fantastic. A bunch of studies from mostly consumer packaged goods companies, conversations the author had with middle management and other layers to figure out how they actually work. Done in the late '70s and early '80s. You might be thinking "the age of typewriters doesn't apply here" - but it's all very similar. Second, Wolf in CIO's Clothing. A modern rendition - Machiavelli for digital transformation. Brief, fun, gives you a different mindset.

One more recommendation, especially if you're working with multiple nationalities: The Culture Map by Erin Meyer. It'll give you all sorts of ways of understanding how to work with people outside of the culture you grew up with.

One example from that book - one last piece of business bullshit. I'll call it the American performance review. I'm American. I live in Amsterdam now, so I'm getting a little deprogrammed. The thing about us Americans: we like to deliver what I call the reverse shit sandwich without the top piece of bread. The open-faced reverse shit sandwich. There's something bad to tell you. We're going to talk about all the delicious Nutella and chocolate spread, all the great stuff in the middle. Maybe it's not even a sandwich - it's whatever that dry crispy cracker bread is that people around here really like. For a 45-minute meeting, we talk for 44 minutes about how awesome that sugary stuff in the middle is. Then at the end: "Oh, also, I heard that people are having some difficulty with your code reviews, so maybe you should look at that." And the meeting's over.

Three or six months later, at your review: "Hey, how's it going? Let's talk about the jelly and the chocolate spread." Then: "Hey, we have a problem. I mentioned to you that you should pay attention to how the code reviews were going, because people were complaining, and you didn't do anything about it." And you're like: "What? You talked about that for thirty seconds." Congratulations. You've received the open-faced reverse shit sandwich.

The point The Culture Map makes is that you've got to identify when a manager is talking with you like that. All that stuff about the Nutella was nonsense. You could ignore it. That last bit was all that mattered for the meeting. Obviously, here in the Netherlands, it's not necessarily like that. Which is great and bad depending on how you like to live.

So - hopefully some things helpful here. There's the video series, all sorts of terms and what I think they actually mean. With that: you've survived another conference. Congratulations, and thanks.

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.

Platform engineering, for private cloud

(0:10) Hello, thanks for coming to my talk. This is an exciting fisheye view of a large hall, which will be thrilling. As my talk says, I'm going to go over platform engineering for private cloud - one of the more thrilling titles I've ever used in a presentation. What I want to cover is not only platform engineering itself, but some of the things that are different when you apply it on your dedicated environment, your own infrastructure. Now, what exactly private cloud is, is fluid, but I generally think of it as: primarily, you're running it on premises, on your own infrastructure. And to some extent it could also be if you're treating cloud infrastructure as - and this sounds pejorative - let's call it dumb infrastructure. Something that you build your own stack on top of and run your own thing, instead of using something that is very close to developers.

(1:11) It's very popular nowadays, and there's an evolution from all of these things. What's great about being in the line of work that I'm in is there really is this continuous evolution of trying to finally crack making infrastructure easier for developers to use. Thinking about how we make it easier for them to deal with infrastructure directly, or, as we like to say, write more code and think about their application more. Hopefully this time it'll stick. This is definitely the most characters we've used since IT service management in the 2000s to describe this endeavor. So maybe, instead of shortening it like we've done in the past, once we finally have a long descriptive word, it'll hold. But we'll see - we like to go in cycles for things.

(2:04) So why private cloud? I've been interested over my career in where workloads are, what the movement towards various types of infrastructure is. It's good to check in every now and then - depending on how feisty you're feeling, every year or every two years - and ask the question not so much what kind of excitement and revenue is around the various places, mostly public cloud, that you could move to, but where are the workloads? Where are the applications?

(2:55) This is pretty important for platform engineering, because - unless you've figured out some strange exotic use case - if you don't have applications, all the platform engineering you're going to do is not really important or worth anything. The point of platform engineering is to support applications that you're running. Sure, you want to have things that are secure. It should be performant. You probably want some database services. I always think it's important to remind ourselves of the number one requirement: it should work. But those are things that any sort of engineering or approach could give you, or would purport to.

(3:26) So I'm going to spend the first part talking about that location of workloads, because I don't think it's really discussed very much, and the implications of what you need to do for platform engineering to be successful and useful are always tied to this place that they're running. It's kind of a - if you remember - the medium is the message. Or the medium is the infrastructure. I'm going to work on that phrase a little bit more, because that didn't work out so well.

(3:53) A brief introduction to myself. I've been lucky to work at Pivotal, and then that was VMware, and now it's the Tanzu division by Broadcom, as I recall, for 10 years. In that role I've spent most of my time talking with large organizations about how they get better at software - their custom-written software. And I've gotten to write several little books. Before that I was a software developer. I worked on cloud M&A at Dell - you remember when OpenStack was a big deal and everyone was going to build a public cloud out of OpenStack? There's fun stories there. And I've been an analyst at a place called RedMonk for a while and then 451 Research. And I was a programmer way before that, long ago. I host a couple of podcasts. As my friend Andrew Shafer used to say: engage with my brand.

Where are the apps?

(4:48) So let's get into that thing: where are the applications? And again, to emphasize this, knowing where these applications are is going to drive some significant ways in how you think about doing platform engineering. Finding this out is surprisingly hard. There are estimates locked up behind analyst paywalls, one of which I'll show you here. But if you spend a bit of time looking at the experts on where they say applications are, you can start to get some idea and get to that number I had up there - that it's about 50%. Maybe it's 40/60. I don't know, we'll see.

(5:29) First of all, back in January, we could go to some people who are the best experts at this: the people at Amazon. This is a quote from the AWS CEO, and it is scoped, as you can read, down to large organizations - which are the ones I'm most interested in, and the ones where platform engineering probably has the widest relevance, and where this idea of platform engineering and private cloud certainly has the most relevance. I try not to do math in public, but if you do this math here, I think that amounts to 90 to 60% of workloads in large organizations being on private cloud - or whatever you want to call it, dedicated infrastructure, on premises. They're running it, or outsourcing it to managed service providers, but it's not cloudy infrastructure. That starts to give you an idea, with a crazy big range. This isn't an average, it's just various customers.

(6:33) Here's another one. If you read IDC, like I do - being a former analyst, I have maybe a different relationship with analysts, I think their work is pretty good. If you read them year over year you get a sense of the momentum and who you can trust, who's making up surveys and who's not. I think IDC is quite reliable here. This is some recent findings from their Cloud Pulse report, a survey they do about every year. Unfortunately they get very upset if you use their data from 18 months or older. I'm not sure what that says about its validity 18 months ago. But you can trust me - remember, I wrote all those books, I have a smiling face, I do podcasts, so I'm trustworthy. What you would see is that these numbers more or less have been creeping around the same level for about 10 years or so. I don't know, maybe eight years. I lose track of time as I get older. And this is why I keep saying dedicated environment: they're very prickly about not saying private cloud. It's dedicated environment. Which sure sounds great. But if you add these up, you see that it's just under 45% dedicated environment - although they slip into "dedicated cloud" down there, so maybe we should send them a note. Again, you get this sense that it's around half and half, around 40/60, something like that.

(8:06) There are all sorts of other figures, depending on what kind of charts you like. There are some from Barclays and Goldman Sachs that are particularly good if you really want to get deep into looking at where these applications are. But when you look over all of them, you kind of arrive - or at least I arrive - at this conclusion. And especially, as the AWS CEO was saying, when you look at larger organizations, this holds a whole lot more. Thankfully I have a philosophy degree, so I'm very comfortable with ambiguity and approximations. These numbers make me happy. I don't really need much more precision than that to figure out the area we're working in.

(8:49) So the point being: there is a significant amount of applications running on premises, running on private cloud, running in a dedicated environment. What this starts to mean is that there is, let's say, organizational ownership and responsibility of the stack, in both good and bad ways. So when you come in and you want to build a platform - a platform being to support applications, to support developers - we'll get into what that entails as far as different things that team or those teams need to do, versus if they were just supporting a full stack that they didn't necessarily own and have responsibility for.

What is a platform?

(9:30) With that, let's define what a platform is. It's always good, when you're talking about something, to define it yourself, so you can say "well, that's not my definition of something" when you're objecting to it.

(9:45) First of all, if you haven't been following platforms and platform as a product for a while, there's a great talk that was just given and then published by Paula Kennedy, who I used to work with. You can see that the timeline of platforms is quite long - if you want to throw in platform as a service, if you remember that term, with places like Heroku and others way back when, it goes back further. But this is a really delightful overview of the idea of what a platform is, and you can see the long timeline it's gone through, and a lot of funny subtle jokes about how we keep repeating ourselves over and over again. I realize you can't click on that now, but perhaps later. Maybe there are some talks you're not interested in, you get worn out, you want to enjoy a croissant or a hearty sandwich. It's a good 25 minutes to spend if you're really into platforms.

(10:44) Any talk on platform engineering is required to begin by quoting Evan Bottcher's 2018 definition of a platform, which I have here. So I'll move on.

(10:56) Recently, in the past three or so years, there was a resurgence in - and kind of a creation of - the category of platform engineering. Arguably the good folks at Humanitec kicked this off when they were taking their internal developer portal and they wanted to do some market category creation. Which is great: you want to create a market category that perfectly fits the thing that you have to sell. And if you remember, they declared that DevOps was dead, and that kicked off two years of fantastic conversation. But I think we've arrived at this notion - as I was joking with that Dune picture at the beginning - that platform engineering is what we call all of this stuff. How infrastructure people, operations people, are trying to support developers as much as possible.

(11:38) Now, like I said, I lose track of time, so let's say about two and a half years ago the first thing that emerged was that the P in internal developer platform actually stood for portal. This was when Spotify open sourced Backstage. It was this great internal portal, if you will, for developers - hence an IDP. There was a lot of interest in it, and there still is, and a lot of thinking about it as - this is going to be not quite accurate - the UI for Kubernetes, the UI for a stack that you have, mixed in with the project management that goes with making what various teams are doing inside a company legible, knowable, a lot more standardized.

(12:41) Now, very quickly, as happens often, the analysts swooped in, did some great diagrams, and what happened is the notion of a platform expanded to be more of the infrastructure, going further down than just that portal on top. And then a memo was sent out to all of us in the platform world that the P now changed to platform, from portal. Portal is just a part of what a platform is.

(13:09) Here are two diagrams of what a platform is. The one on your right, of course, is the best platform you will ever encounter. You should definitely be using it and insisting that you have it, because I work there and I like to pay my bills and profit from that. Thank you for sending me here, Tanzu division by Broadcom.

(13:29) Now, if you're not into vendor pitches and you want a vendor-neutral way of thinking about the world, which is always great, the CNCF, the Cloud Native Computing Foundation, has a great reference architecture that they came out with a number of years ago. Bridging to the portal part: you can see that the portal is just one part of that big old - whether you think of it as a cake or a very complex tasty burger, depending on how hungry you are and what you like to eat.

(14:08) As you look through all of those things - maybe it's not too insightful or revelatory - what you see is that the components in there are all oriented around what people whose hair color is getting slightly lighter and whiter, like me, would call middleware. Maybe that's a terrible word. You could call it services if you like, components, frameworks, whatever word you enjoy using that makes you feel younger and more zesty instead of something like middleware. But you can see you've got databases, event queues. There are some things that are a little subtle to see in there: how you package and deploy your applications - we used to call it a release train, I think, then it was a secure software supply chain. All sorts of phrases and words, if you like these things. But there's also a little chunk of infrastructure stuff included in there as well.

(14:56) I think the theory of this - I guess it's the practice of this - is: the more embedded you have all of these things, the more you can integrate all of these things, the easier it becomes for developers. Because the more automated and standardized you can make them, the more self-service you have, and hopefully the less your application developers have to spend time thinking about how they package up this application, how they express the dependencies, or a multi-regional deployment of things like that. And especially not wanting them to invent those things.

(15:30) The third interesting thing about this to have in your head is that, even coming from the home of everyone's favorite Kubernetes, the CNCF, Kubernetes doesn't really show up here. And that's - at least in this diagram, nothing against Kubernetes - more to say that the infrastructure is not really part of the platform. That's not the important part of it. Infrastructure is some other thing, down there in the purple layer. I don't like to criticize people's work, but I'm not really into those Easter-color pastel things, I like darker colors. But that purple Easter egg down there, that's where the infrastructure lives.

(16:11) So that's another thing that you want with a platform: more or less infrastructure agnosticism. Now, is that perfectly possible all the time? We sure would like it to be, every five or ten years. To bring back another phrase from history's past: we want multicloud and portability, we want to avoid lock-in. It'd be great to hear from anyone who's been consistently successful with that over the past few years. That would be a breakthrough paper. Maybe we can go to IT Revolution Press, put together a working group, and have a five- or ten-page PDF about how we did it - multicloud application portability. It only took us two days to move to a completely different stack of infrastructure.

What does a platform team do?

(16:56) So what does a platform team do? Here is a good roles-and-responsibilities division of things. There are a lot more things, but this is a nice summary. You've got your application teams, developers as people would say. You've got your platform teams, and then more that your platform teams do along this spectrum. Your developers are there writing their code, doing the things they're responsible for, hooked up to the tools that you have, the pipelines, all of those things. And the sense you should get from what the platform team is doing is that they're curating and developing the services that are in a platform. They're making sure that it's integrated together. They're taking care of all those thrilling meetings with networking and security people and auditors. They're doing a lot of the work to say this platform not only makes the application developers' work easier - I don't know about their lives.

(18:00) This is a fun thing about AI. You should be asking: I'd love to use AI, and if I'm 25% more productive, does that mean I can go home early and maybe work four days a week? Because really, if you're more productive and you don't get anything from it, you're getting kind of a raw deal. So make sure you pay attention to what your productivity increases are, and be like, now I'd like to not do more work, or get compensated for it somehow. Anyhow, where was I?

(18:27) Yes. So what you see these platform teams doing is kind of upward, making it easier for developers. But a lot of the hidden work they do is making sure that all of the downward-facing things - and there's nothing pejorative about the directions, you could reorient it to 45 degree angles, or if I knew my nautical terms, port and starboard or something - you can see that they're doing a lot of the work to fit it into the rest of the organization.

(18:52) And there is, I think, a little unknown - I haven't heard a lot of discussion of this - about who actually does what I would call the management, the monitoring, the troubleshooting, the root cause analysis, for things up and down the stack. I think the platform engineering team does a fair amount of that. But at some point you probably need to open up some phone call, or create some channel depending on if you're a Slack, Mattermost, Google Chat or Teams person, and talk to your friends the network engineers and the storage people to troubleshoot what's actually happening. Maybe even the developers, if they care to show up at that time. This might be one of those free times they have because they're 25% more productive, enabling you to be 120% productive when they don't show up.

Is Kubernetes a platform?

(19:40) A logical question. Is it - how do you say that guy's name, law or something? Whenever there's a headline with a question, the answer is no. But let me explain why, because I think there has been a lot of positioning, if you will, which is to say thinking of Kubernetes as a developer platform. I know that because I've paid attention over the past 10 years, and I've also talked to numerous operations and infrastructure teams at large organizations, and we have the same conversation. The brief version: they say, these application developers - and then we talk about how great they are, and special snowflakes for a while, little gun shooting, having fun there - they asked us to stand up Kubernetes, and we did, and they're not using it. We don't see them going to it, so what are we doing wrong? I think that is because there's this perception that that's what you would do: that it's this complete developer platform that's fully ready to use.

(20:41) But you see this: this is a survey that we used to do annually. As Kubernetes has spread more and more - that's why there are five years of questions here - as there have been more people using it, you see the benefits of Kubernetes dropping in the survey base. That's what you would expect as a new technology rolls out: new people are using it, they're figuring it out, figuring out how to use it in their organization. But the one highlighted here, to give you a quick summary: the top green one is the most recent year, which is 2024, and the bottom blue one is the first year. You see one of the developer-facing metrics - the ability to deliver code faster, or shorten software development cycles - has been dropping over those past five years. It'd be fun to do a survey this year and see what the result is. A little weird is that you see that similar kind of movement for a lot of the areas there. Again, I think that is largely an effect of: you have a new technology, you've got to figure it out. But I think it's particularly distressing, disheartening, unfortunate for people who think about Kubernetes as the full application developer solution, the thing you would put in place for a platform.

(22:06) And indeed, despite some weirdness in the Kubernetes world over the years, I think the original Kubernetes people have been telling us this for a long time. Here's a summary of the quotes from several years ago. Craig McLuckie used to work in my organization - or I guess technically I used to work in his organization - at VMware, when Heptio was purchased. And you can see this almost like: hey, sorry about all that Kubernetes stuff, it really wasn't our intention that you, the developers - not Google people, not public cloud provider people - would actually be exposed to that.

(22:46) There's a great two-part documentary on Kubernetes, and if you go back and watch it - which you should do after that Paula one, I'm going to assign some more homework later, so you might need a new sheet of paper - it's really a phenomenal look into strategy. Because you realize that the whole strategy of Kubernetes was basically to slow down Amazon. I'll let you look into that, but one thing you should notice, if you pay attention to these things, is they interview everyone in the industry except Amazon. And Amazon is portrayed as a continuous looming, kind of Darth Vader-y drone shot of one of their buildings, which is the only way they show up. Which should tell you a lot about the relationship of Kubernetes, originally, and the strategy that they were going after.

How do you run a platform, in private cloud?

(23:42) So we know that Kubernetes - or at least I believe, and therefore know. Going back to my liberal arts degree, what's the difference between believing and knowing? Effectively they're more or less the same thing, until you stop believing something, I guess, but that's a talk for another time. So how do you run a platform? We know a platform is all that exciting goop on top of the infrastructure, including services that developers might want to use, ways of supporting it, that sort of thing. So what does it look like in private cloud? Well, the first important thing, and why that talk by Paula is a great reminder, is this product part of it. Maybe one day we'll change the P to product - internal developer product - which would be fun. This point you've probably heard a zillion times if you've ever been to a platform engineering thing, but it needs to be emphasized over and over again, because I don't think it's actually practiced that much. Saying that you should treat your platform as a product is kind of like the idea of standing in a stand-up meeting, where everyone obviously sits down the whole time. It's subverting the spirit that's right there in the wording of it.

(24:43) So why is it important to have product management, to have at least one role that is actually a product manager? They can go get their Pragmatic product management certification. Maybe they can just read a stack of books to figure out what it is. But a product manager is what you have when you have a product. Of course it means something different when you're selling toothpaste and cereal, more or less. But in the IT world - having worked mostly in the vendor world for lots of my career - you get very familiar with a product manager, and application developers generally know this idea.

(25:20) But the important thing, other than selecting the features that you have, guiding what this product looks like, is something even further up the concept chain of a product manager: in order to have a product, it's great to have customers. If you don't have customers, as a product, this is the equivalent of having a platform without applications.

(25:42) And so then it's good to ask: who are our customers? As you can imagine, as Thomas Müller at Mercedes-Benz said a couple of years ago - "we are building this platform not for us, we are building it for Mercedes-Benz developers." If you are running a platform, you're the product manager for the platform. You think about the developers as your customers. These are the first people in line. Hopefully they're the people you're doing things for. Sure, the platform needs to run. That would be cool. It needs to be secure. You've got to have all that stuff. But that's like saying it would be cool if Earth was hospitable. Those are basics that you need to have.

(26:12) But the product manager is constantly going through and understanding what the developers are doing, what they do great, what they like, what they dislike, and thinking about how we can change this feature, how we can make it better, how we can add new services to it - that would make our customers happier, that would keep them using our product.

(27:00) If you're more of a developer, you obviously have a notion of how your day-to-day work could be happier. I remember when I was an application developer, we could up our productivity by stopping complaining all the time, because it was a huge amount of the work, so to speak, that we did. But what I advise to people who have more of an infrastructure background - and even if you're from a developer standpoint going down the stack - is that it's good to start asking the developers what they need. The way you do that is either you talk with them directly, which is fantastic if you can do it. A lot of these product managers, especially at large organizations, will travel around. You can imagine at large organizations they have a campus, a hub, whatever you want to call it, various geographic locations, and going around and talking with them - even sitting with them as they do their work - is very valuable. But you can also do things like, to use a word everyone loves, survey them. Ask them questions.

(27:44) So what questions should you be asking them? Here's a set that you can use. There's a white paper I worked on with a couple of people who do this kind of platform stuff, that goes over the theory behind this and some of these questions. It's something you can start with. You can use whatever survey thing you have, put it on a one-to-five Likert scale, and then the first time you do it you can crudely - not crudely as in impolitely, but just the basics of it - stick it in an Excel spreadsheet, and if you know the magic of sort-by-ascending, you can start to get an idea of what the most important problems are.

(28:28) That initial pass is great product management thinking, but what's even better is when you survey them again in three months or six months. You want to see if things have improved. Have some of those high-priority things moved down? Are people happier about things? And if not, that's feedback that you need to improve the things you already shipped, that things could be better. Again, thinking about developers as customers, you're interested in them being happier, I guess. There are some other metrics you can be interested in, like shipping time and stuff like that. But you're constantly - constantly is the wrong word, because people don't like to take a lot of surveys. Although I often say, going back to the 80%-true joke: if you were to offer developers "would you like to take a survey," or if you said "would you like to tell me everything that I'm doing that you think is wrong," they probably would be happy to talk about the second thing. Maybe developers have gotten to be more optimistic and happy since I did it way back when, but probably not.

(29:30) Anyhow, figure out some way of getting feedback from your customers - not just initially, but ongoing - and thinking about how you use that to guide what's in the platform. Product management, just like any product manager would, just like anyone who has a product that they want to, if you will, sell or drive usage of amongst their customer base.

Internal marketing and community management

(29:52) Now this next one I think is something that's especially important in private cloud, in large organizations, and that is marketing. A term I'm very comfortable with, because in my developer relations and whatever role, I've worked in marketing over the years. But if that phrase makes you unhappy, just ease into it - you can also call it community management if you like that better.

(30:24) What you're doing with this internal marketing: think about it, you stand up a platform in a large organization, or you already have one. You're already probably competing with, I don't know, three, four - depending on how big you are, 10 - different platforms. Plus any developer teams you have who are just like, I don't know why I need a platform, that sounds like a weekend's worth of work. Also that DHH guy said that you can just do it, so no problem, right? Building your own platform. Now, why are they going to work on the weekends? Maybe that's what they do with their 25% improvement. I'm not sure, but it seems like you should not do that. Maybe you should say, I could spend a week doing it instead of a weekend.

(31:09) Anyhow, you're competing with a lot of other platforms. Again, thinking about your platform as a product, you're in a market, if you will - an ecosystem, if you don't like that word. What that means is you need to talk about why your platform is good. There's some standard marketing stuff: you want to get your positioning, your messaging, your value propositions, or as us marketing people like to say, value props. Who can be bothered to say two words?

(31:40) But part of that is not only narrowing down what your pitch is - or, if you prefer, having really good documentation going over what it is - but also thinking about core community management or marketing things like branding. I see this over and over again in all sorts of large organizations: one of the first things they do is come up with a t-shirt, as my friend Deshan would joke. And when you come up with a t-shirt, one, you've proven that you can get budget, which is thrilling. But two, you come up with a snappy phrase, a logo, a color scheme, an identity.

(32:20) As developers, we're like: I'm immune to marketing, doesn't work on me. And I love using my Apple Mac. I will defend to the death the type of code editor that I use. I can tell you why the shell I use is extremely important and you're wrong. So forth and so on. Obviously we're affected by identity and marketing and brand. Sure, it's more about the functionality, not the actual identity that you have. But the same is true for any technology, in any platform. So you're trying to define the type of person that someone is, or becomes, or can be - the identity - by thinking about what your marketing is.

(32:41) And again, you see this across the board with companies. A great example is the US Air Force - I think they still do this - they launched this platform and this whole initiative to get better at software, and they called it Kessel Run, because of course they're going to make a reference to Han Solo and Star Wars. That idea of, we're kind of like renegades - not a word you would like your military to use - but we're doing things differently, we're a little more savvy, and we're going to identify with this thing that probably a lot of the people involved really like as well. And then we can also make this t-shirt that has a double meaning. There are other things that AF could stand for instead of Air Force, if you remember those days. But this kind of brand, this kind of internal marketing, helps bring that in to a great degree.

(33:33) Now I joked about calling marketing community management, but genuine community management is also a huge part of what the platform engineering team does. Setting up internal chat channels. Having quarterly internal conferences where you bring application teams that have used your platform to talk with other developers - which, by the way, is a great marketing technique called customer references, or word of mouth. Having people tell you they were successful with your product, your platform, on more of a peer-to-peer basis, rather than having someone who has no idea what they're talking about saying that it's great: the platform engineers being those people versus the application developers. I have this really distressing, ribald idea about application developers. I should probably go revisit that at some point.

(34:32) But you can see that having this - what I would call a developer relations effort - starts to become important for a platform team in a large organization, in a private cloud environment. Indeed, if you look at large organizations like JP Morgan Chase, big gigantic global bank, last I checked they have a team of about seven or eight people internally who are developer advocates for the handful of platforms that they have. And they do all of these activities. They go around. It's not only training, it's not only awareness building.

(35:04) But it also becomes a channel. This is the part about developer relations that all DevRel people aspire to - very few of them get the chance to do it. It's also a feedback channel going back to that product management. So if your internal community people are out there talking with your customers, your developers, they can bring that feedback back to what the product manager, the platform, is doing. They can start to give some advice on how to prioritize features.

Continuous financial metrics

(35:28) So now, I think maybe this is perhaps the most important thing that is different about platform engineering in private cloud, in large organizations, and that is - let's call it continuous financial metrics. The way finance, which is to say oxygen, works in an organization, particularly large organizations, is you're on a 12- or 18-month budgeting cycle. It's supposed to be 12 months, annual, but essentially every year you have to go through an excruciatingly delightful process of saying, this is the budget that we need, proven by the return on investment we had last year and our projected return on investment in years forward. You're basically saying, the reason we need 5 to 10 million is because we're awesome. And they're like, yes, I'm sure you're awesome, but I'm going to need some spreadsheets. What this amounts to is metrics. And these metrics are associated with some aspect of helping the business out. Unless you're working at a tech company - which is great if you are - that metric is usually not oriented around raw growth, because we're looking for a large startup valuation and then an exit, and then actually making money is someone else's problem.

(36:49) So you need to start thinking about how, from day one, you are not only tracking what these metrics are, but very tactically and wisely saying what the metrics are, framing them. Because in my experience, knowing the value of it, if you will, is extremely difficult unless you're in something that's very close to the business's business transactions - like retail, or other things where you can directly connect a line of code changing to people booking more airplane flights or something.

(37:22) But things get a little more obscure. I like to go back to banking. What's the return on investment of me being able to see the balance in my bank account? It's theoretically infinite, because if I couldn't, I wouldn't bank there. But you can't really put infinity in a spreadsheet. That doesn't really work. So you need to start coming up with metrics that map to why the platform is valuable, that allow you to talk upward to your organization - again, I don't mean to be pejorative - to talk in terms of finance and business and that planning.

(37:56) There are all sorts of metrics you can come up with. Here's a default set that's been evolved over, I don't know, the past five or eight years. It's even formatted in a dense way that I think people in large organizations can do. Have you ever noticed they're very good at reading documents in landscape? That's kind of the mindset you have with the rest of the organization. If you want to print something, go up to that little thing - you really want to print it in portrait because you've read about the Amazon memos, all the people complaining about how documenting something is better. Just select landscape, you're good to go, and things will be fine.

(38:37) You can see a lot of these things are capturing what a platform is trying to do. Everyone wants to speed up. Now, speed can be gratuitous, but the point is that the faster your organization - I'll just say business, but you can imagine how this maps to a nonprofit-oriented organization, whether you're helping citizens or otherwise - the faster you can change your software and get that software in front of users, the more that business can evolve. So speed is an interesting indication of something. I guess I could reference the DORA reports - the DevOps one, not the European banking one - to show that that was important as well.

(39:26) A lot of the rest of these are based on that kind of table stakes I was going over. But it's also important to emphasize and track to the rest of the organization why the table stakes are good, and why the investment in your platform is paying off, and to represent that in some way. A lot of these middle ones I think of as indoor plumbing. The value that we put on indoor plumbing is basically zero until it stops working, and then it has infinite value. We really enjoy it when it turns back on after not being on for a while. Thinking about how you represent that so that you don't have to remind people with a catastrophic event is a good number to start tracking.

(40:05) Now, of course, savings is good, and that gets into some weird stuff depending on how you think about things and what the situation is. You've got to be careful if you're trying to get money. It's good to track savings of how much you could have spent versus how much you are spending, because you don't really want to be in a situation where you're like, "and guess what, we need less budget than we had last year, we're saving you money." So think about how it's more of a good investment. Savings is up there because the other ones are S's, so you can call those the five S's. You don't want to be the four S's and the I, which would actually be kind of fun. But think about how you represent the money made, the money you're attached to, the kind of savings you have versus theoretical alternatives, and start tracking those things.

(40:55) Now, for developers, kind of inward facing, there are all sorts of other metrics you can track. Here's a default set as well. This is good for people who aren't so concerned about your budgeting, but they're good things to start measuring and tracking.

(41:09) And I think the point with both of these metric things is, again, thinking of your platform as a product: a product needs to have measurements, needs to have metrics. And I know that once you start measuring something, that becomes the goal of doing stuff. Hopefully now that you know that, you won't fall into that mistake. I always think that's a weird paradox, that people should know that's the issue. So you need to constantly be thinking about, are we just doing the metrics or not? Good luck. But it's good to have some indicators, some dashboards if you will, of how things are going and how you can talk to other people through spreadsheets - metaphorically and literally speaking.

Scaling the platform: pairing and seeding

(41:47) Just a couple more things, thinking about how you spread platform usage through your organization. Again, this is particularly relevant to large organizations, and large organizations use a lot of on premises or private cloud, so it's particularly relevant to that sphere of things. What I've observed, and many organizations have gone through over the years, is this kind of slow-at-first spread of a platform, and then a very rapid spread of it. I'm sure there are some math terms I could use there, but see my credentials earlier when it comes to mathematics - or maths, as people like to say.

(42:27) What you see at the beginning of the platform is selecting an initial development team, maybe even two development teams, and working extremely closely with them. They're your first initial customers. As you're planning and developing the platform, you want to talk with them to figure out what their needs are and build it around them. You're getting good feedback about stuff, and you're also starting small so that your learning function - which is to say, when you fail - is as risk-managed as possible. You don't want to do everything at once. If you're thinking, in the first year we're going to move 120 to 500 application teams to the new platform, because that's the only way we can make the business case - you should probably look around the rest of your organization for alternate jobs that you could have after that doesn't work out. But you see more of this slight rise in development teams on the platform.

(43:26) Now, another side effect that's interesting, that goes back to community management, is that as you build up these initial teams and as they're successful, they become advocates or customer references for you, that you can then use in your efforts to spread the goodness, the great cheer, of your platform. So you're building up the case in these peers that other developers will probably listen to more than weird infrastructure people who have a strange title - aren't they basically just DevOps people, people may be thinking - who are more of a trusted source for spreading the idea that a platform is good. And if you're very lucky, you can even take some of those initial people who are interested in helping others, who have that more senior, principal-engineering mindset of "my job is to help the rest of the organization," and start to seed them in other teams. So you're taking direct knowledge to new teams of how to use the platform, and so on. But planning out that gradual-and-then-sudden ascent becomes very important.

(44:35) And then, getting into more of, let's say, planning - planning out the activities that you'll do, what it's going to look like, even getting into budget, what you might even call strategy if you're not too pedantic about the definition of strategy in a corporate context - there's another great CNCF working group, the platform maturity model crew. That's not their name. But they've been working on a platform maturity model which I think is great. They're one of the few people who have managed to cram a maturity model down into, I think, less than 50 pages - I think it's maybe about 25 or 30. And I hear there's a new revision coming out. This is well worth your time reading if you're doing platform engineering, or especially planning it in a larger organization, because it's the best version of what a maturity model is. Another word you may not like, but a maturity model is sort of like: here's a bunch of mistakes people in the past have made and how you can avoid them, and what you can expect to happen over the course of things, how you can organize the activities and the stages of what you're doing. It's a lot longer title than maturity model, but maybe it makes you more comfortable.

(45:46) But if you read through this, some of the key things you'll see are that you can expect it to take more or less three to five years to go through this entire cycle - to have, let's say, undeniable success with your platform. Which means, to use the technical term, a lot of applications running on it. If you've got a big platform and there's only a few applications running on it, it's kind of questionable what the overall value of that is. There's an important point that all maturity models make, which is that maybe you don't need to go through all five steps. You might reach step two and that's sufficient.

(46:28) There are all sorts of interesting results from the maturity model, and in a good way it's self-reinforcing about a lot of the notions I went over and didn't go over about what a platform engineering team does. In particular, it's paying attention to the developers. One of the steps in the maturity model is: do you have a product manager? Are you getting feedback from the developers? You'll get an idea of what those are and be able to plan this out a lot better.

What about AI?

(46:59) So finally, no talk nowadays is complete without talking about AI. So how am I going to fit that in there? That's a great question. I'll tell you. Here we are talking about large organizations and private cloud. What is relevant to platform engineering with AI is a couple of things. One, the notion of large organizations, where as we saw the CEO of AWS say, a lot of it is private cloud, somewhere between 90 and 60% depending on which organization you talk with.

(47:38) You also survey those organizations and you see that their intention - at least, we'll see how it pans out - is to run a lot of their AI stack on premises. Which makes sense, because of data and wanting to control things. I think it's a little early to get too settled on where the workloads will be, but that's the early feedback you get: the intentions at the moment are to have a lot of it in a dedicated environment, and about 50% of it.

(48:04) Now, what that means is that the way platform engineers - the way I and some of my coworkers and other people in the community are seeing them start to think about how to support AI in their platforms. And by this I don't mean the assistants or copilots coding in your IDE. That's a whole other sort of thing. Here I mean adding actual AI functionality, actual features, to your applications, to how your business is running.

(48:37) So what I think is emerging is that the platform engineers get all enamored of AI. They start freaking out about whether it's going to replace their job, as we all do. And then they actually start using it day to day and they're like, oh, this is fine, it'll be great. And they start to think about that AI functionality as services that they're providing, as middleware.

(49:11) Once you appreciate the magic of what all these AI things do, and the mind-blowing awesomeness, and then you come back down to reality - maybe you've had a huge lunch so you can think more clearly - what you start to think about is: oh, I'm just providing another piece of middleware, a service to developers. How does this fit into the workflow that they have, which I know because I've talked with them, because I'm a great platform engineer, product manager type? What can I do when they need to use this and fold it into the way they're doing application development? It's probably similar to when they use a database or they need to do some sort of messaging thing.

(49:34) And that's where having a platform is going to be a huge advantage, because you'll have so much of that scaffolding, so much of that stuff built in already. You're already providing access to services. You can start to think about how you add this new type of service, how you add access to all sorts of models, all sorts of supporting frameworks - whether you want to run those models on your own, whether you want to broker access from your own models to publicly hosted ones, whatever it may be. If you've been doing platform engineering for even a short amount of time, you're used to dealing with that kind of thing with the other services that you have. It's not that it's not going to be a problem - every service has its own unique cool things that you get to experience - but at least you're going to have done a lot of the conceptual work around it.

(50:18) So, thanks for coming to my talk. It's always a pleasure to talk with people and go over this. If you're interested in clicking on the links in the slides, there they are. And it's always fun to hear people's experience with platform engineering, or other things - it's not like I only get super happy to talk about platform engineering, there are other things that are fun as well. But it's always good to hear from people. Enjoy the rest of the conference. Thank you.

The nerd fight about developer productivity

(0:04) Well, hello. I usually like to avoid having meta commentary if there's a recording, because that's a little weird - you've got to do that little "t equals some seconds" for the recording. But there have been some great talks and it's always nice to be here at DevOpsDays. I really appreciate it. So far, if the rest of the talks are good, even if mine's terrible you'll have a good time from the two that you've had.

(0:29) What I want to go over - and I assure you we didn't coordinate ahead of time, the previous talk and I - but it's great, because that gives you a kind of tools look at what things are definitional. It was really nice to look at. What I want to focus on: this started off as talking about metrics and things like that. I don't know if you read the same thing I do, but there was a great nerd fight last fall when McKinsey came out with this developer productivity metrics thing, which spawned all sorts of discussion. It wasn't as good as, I think it was maybe the 2012 bimodal IT discussion - maybe that was 2009 - which is fantastic, very choice. You should look that up if you haven't read it. I don't think anyone who was saying bimodal IT was bad paid the $5,000 for the Gartner PDF, but that shouldn't make you think it was not good. Good stuff.

(1:16) So this is a little bit of an evolution of what was going on way back then. But I think it's also thinking about what we are going to do in this era of DevOps. How can we prepare for it? I like the idea of DevOps X - that kind of has a nice feel to it.

The quick answers

(1:35) Now, the first thing when you're thinking about developer productivity and metrics that I think you want to know is: you just want to know which metrics to use. You're like, I don't know, do I really need to sit through 20 more minutes of this nonsense - can you just tell me which metrics I should be using? Of course, all the thought leaders and the masters are going to tell you you're a terrible person and you shouldn't be asking for metrics, which is what the rest of the talk will be like, so you can say I'm not a terrible person. But let me give you the answers right now. As I covered: it depends.

Now, whenever I encounter "it depends" I'm like, how much is this consulting bill going to be? I want to know - why don't you just give me the answers? But it is true, as I'll get into, it's very genuine that it's hard to apply lots of these metrics perfectly the first time. And especially since I imagine a lot of you are lower down the hierarchy, you've got to be really careful about just going in with some metrics that may have retributive sorts of actions based on not really analyzing that "it depends" much.

(2:41) Now, ideally - nonprofits and governments aside, but you can substitute in there what you would like - what you want with metrics is as direct a connection to money as possible. You want to say: am I being productive? Here's how much money I helped you make. Now, it's a little dangerous to say here's how much money I saved, because that usually means here's how many people I got rid of. But somehow you want to connect what you're doing to the actual outcomes, as we say in the business, the value, these sorts of things.

(3:07) But I think the problem with software, especially in what I would call - in a good way - normal companies, enterprises I'll say to bring that word up, is that the connection between the business and the IT shop, those people in the poorly lit, out-of-date sort of facilities, probably using machines that are six years old because the refresh cycle is out of date - you can kind of see that they're not really valued and thought about as contributing to the business so much. So that connection is very tenuous and difficult to make.

(3:41) And so instead we come up with a series of other metrics. This is kind of an overview - there's another one I'll get to later - but this is probably the last two, three years or so. If I could read that tiny type I could tell you.

(3:55) What we've really evolved from is this nice sort of "it depends" situation, where it depends, and here are the frameworks that will help you - no pun intended - figure out what your depends are. They ask you a series of questions, have you look at what you think productivity is and how it applies, and eventually you go down to one.

(4:18) And I'm going to very much simplify it: really, the state of the art in developer productivity is, are your developers happy? And if you can say yes to that, chances are they've got good productivity. I'm no academic, I just read PDFs, but that's sort of what a lot of this amounts to. Which is great, and it intuitively makes sense. The other way I think about it, back when I was a developer, is just stop interrupting me - that's a lot of developer productivity as well. But I would encourage you to look at these and think of them almost as sensing mechanisms for coming up with what the metrics will be, and the answer to what "it depends" is.

(5:00) The second thing, to give you the answers, that I'm going to build up to: what I've observed over however many years - it's good not to remember how many years - is that when organizations are talking about developer productivity, they're not so interested in, I don't know if you kids still use these terms, the inner loop. What developers are doing when their fingers are on the keyboard, or what apparently AI is going to replace at some point. If you're interested in another career that involves not coding, I could give you my tips on doing that - I had a similar thing in the 2000s. Anyway: not really the inner loop, but more what happens around the application cycle. Getting your code into production, going through all the governance, all those sorts of things. One of my theories is that if you focus on that a lot more, you probably won't really care so much about developer productivity, but you'll improve why you care about developer productivity - which is more about release cycles and getting features out.

(6:06) So before that, this is me. As you can tell, I usually wear that shirt, but my dog got very nervous and ripped a big hole in it, which is unfortunate, so my run on that shirt has run out. I've been really lucky for the past 10 years, and many years before that, to work at Pivotal, and then VMware, and now as we call it VMware Tanzu by Broadcom. I've had the chance to write lots of books and do lots of podcast stuff, I was an analyst, all sorts of nonsense like that. As a friend of many of us here likes to say: engage with my brand. I won't show you my various hair configurations, because it's been the same forever, which I stress out about. You ever notice when you were younger you were like, what's up with all the old people with the same hair all the time? And now I think I've become that.

Who's asking?

(6:54) So if you're worried about developer productivity and metrics, the first very important thing to do is to ask who's asking. This is not the most important thing - I don't like to rank things - but it's definitely top three, and it's really going to let you narrow down what you would do out of all the possible things.

In normal organizations and enterprises, the person who's asking is usually this guy - or gal, or non-identifying fantastic hair person. What you need to understand from them is that they're the ones who are responsible for the success of the business, or the organization. If you're in a nonprofit, it might be the success of satisfying our citizens' needs and renewing their passports with minimal impact, and not showing up in front of parliament or Congress to answer why things went wrong. But whatever those motivations are, the bosses, if you will, they're the ones who are first going to be looking at productivity and very interested in it.

(8:03) Now there are great reasons why they would be interested, and I'm going to shift into the commercial area. Hopefully competition isn't something that you have your governments doing too much - that tends to not go very well. But generally you might have competition in the industry you're in. We had bol.com up here earlier. Here's a joke: how do you know if an American's an expat? Because they tell you. So when I moved here to Amsterdam about six years ago, Amazon wasn't here at all, because bol was here and they were great. And they still are pretty great, they're very competitive. So from their perspective, the more they can get features out, the more their software drives things, the more they can succeed. Admittedly Amazon's pretty good now - order from Germany, which is great. The great thing about Europe is things ship around really quick. It's kind of like ordering from Kentucky when I was back in Texas, I guess. So they're interested in shipping features. They're interested in getting parity with their competitors, being better than their competitors, and what this really manifests as is just: ship, get features out. They're not really interested in updating your Java VMs and things like that. So that's the way they're going to be measuring things.

(9:17) And then of course, as I mentioned, they're interested in growth. They want to make more money, as many of us probably do - and if you don't need the extra money, I'll be available after this with a large bag, if you're satisfied with the amount you have. They'll also be interested in how we increase productivity in kind of a financial way: if we want to enter a new market or do more business, can I just get 10 more developers and I'm going to get better productivity? Or do I need to focus on making what I have productive? Do I need to do more with the same? This is the kind of thinking that went into the side of that nerd fight we didn't like, where managers of companies wanted to know how to program the system and get observability into how their software function was working.

(10:04) Now, the reason I would advise you to really think about your metrics is the other thing our white-toothed friend is thinking about, which is: I don't really understand the connection between all of this stuff. I've got one thing I can do, and that is pay less. So when I'm managing the IT function that I have - this is why in regular companies you see a lot of IT under the CFO, because the CFO's job is to be like, how about I don't pay that much. I'm grossly simplifying it, but from that perspective it's how do I get what I need at the lowest cost. Think about it: if it's August and you're in Texas, which is very hot, you don't want to paint the outside of your house on your own like my wife and I did a long time ago. You want to hire someone to do it. Do you hire the most expensive person because they're high quality and they've got artisanal brushes and they've figured out the perfect way to paint things and they've talked at conferences? No, you're going to hire the cheapest or the second cheapest person. It's the same kind of perspective that people will have.

(11:10) And again, this is what causes a lot of problems: from their perspective, the way to control costs is people. This is why they want to get down to individual developer productivity measurement. They want to know who are the underperformers I can get rid of, who are the overperformers I can retain and, if really cool, maybe give more money to. How do I manage that flow of people? And as we know, measuring developer productivity is very difficult. That's the main idea I want you to take away: if anyone asks you about measuring developer productivity, don't tell them it's only an inward-facing thing that you want to focus on - unless you're in the generative one, I forget the DORA three columns of success and doom depending on which way you go. If you're in a cool place, talk about it all the time.

(11:59) And then of course - I think it was called PSP, if we were talking about Delphi and Turbo Pascal from that era - there was this idea that you can track these things to improve your own craft and get better. It's good to keep up with those metrics, but that's more of an inward-facing thing that you have. Which is great, you should do that. Or not. But that's not really, as you can tell, what my concern is. I think the individual craftsperson can measure and do things on their own and it'll be pretty much cool.

What is "developer productivity"?

(12:31) So let's go over what developer productivity is, dive into it some more. Well, to emphasize the point: it of course depends. Which I think is a very accurate answer, but not a helpful one. It's not really going to push you forward into doing things.

(12:53) So thankfully, one of the great outcomes of this nerd fight was that Kent Beck wrote a two-part reply with Gergely Orosz. I should meet that guy, he lives here and our wives kind of know each other. Think about productivity in any area as basically the amount of effort I put in versus the outcome that I get - and can I lessen this as much as possible? How much of that productivity could be cost, time, friction. And the way you measure it is not just output, but really - if you'll forgive the marketing terms - it's the impact, it's the value to the customer, the money that you make, the time you reduce on that passport renewal, whatever it may be.

(13:33) So that's your basic framework for productivity. And then if you apply that to application development, it's all about this cycle - the product management cycle that the bol people went over in one of their slides. What's a problem or an idea, how do we implement it, how do we design it, how do we code it, how do we test it, then we've got to get it out to the users. And this part is the part that, when I was a programmer, we didn't do: we only monitored when people were suffering, with bug reports. But you actually monitor the people using it and see if behavior has changed, and then you say, is that good or bad behavior? This is the productivity cycle we have in software. You're putting things out there, you've got to see if you get the outcome that you wanted, and maybe cost. But the productivity you're getting through here is: are we actually making a difference?

The metrics buffet

(14:28) So in an "it depends" situation, what you end up doing is going to a buffet or a cafeteria. Or nowadays there are those hot pot places where you've got all these ingredients and you can pick from the metrics and throw them together and cook them yourselves, and feel a little weird the next day. Similar experience for metrics, probably.

(14:53) Let's go a bit more into what these metrics are, a history of them if you will. All of us here, we probably know the DORA metrics - there are four of them - and these are a good way of measuring that sort of impact and outcome. Depending on the values you have, these are some of the ideal states you'll be in. But they don't necessarily tell you about the productivity of what developers' activities are. They tell you if the machine, if the factory, is operating well. We're here at DevOpsDays, I'm sure you all have read the Accelerate book five times and got lots of bookmarks. They're great from that perspective.

(15:38) But more, what thinking about developer productivity and metrics has evolved into is looking at the activities - as much as that's disliked - of what developers are doing, but looking at it with respect to their day-to-day work, the flow that they have, the way they're thinking about things. These are just a sample from the SPACE framework, but it really starts getting to the point that here are all these attributes we can monitor, including well-being and the mental-ness, the kind of mid-era DevOps vibe that we had before we went into the observability era. All your sort of cultural stuff. It's a great framework for buffeting that stuff out.

(16:25) More recently, the - I'm going to call it the DevEx framework, I don't know if it has a title - from that same group came out. Again it's this buffet you can go to. What it's trying to get at, as I was saying earlier, is that we know when we look at it what a hygienic, well-running software factory looks like. What that looks like is this flow through it. And what it also looks like is: people are happy. Or satisfied, depending on how nuanced you want to be. So it almost starts with what makes people happy, what kind of environment you set up to encourage this flow, and therefore what metrics we're going to monitor that instrument that factory we have. And then that gets into all of the tools and the way you start fixing things.

(17:16) There's another group of metrics I first heard about at Monktoberfest last year, from Cat Hicks and friends. They're at Pluralsight, of all places. They picked up the great marketing advantage of the DevOps report, where they're like, what if we contextualize the market we're working in by doing some academic work in here, and think of the leads. They actually have a very similar sort of study across multiple papers of how you figure out that thriving that you want your developers to have, and all of the little attributes around it. So those are some good buffets for you to go look at. I think they're quite useful for sorting things out.

Tools: surveys, pipelines, platforms

(17:58) So, getting to the tools that you might use. And by tools I don't mean the excellent overview we saw of the configuration things, the IDEs - the paintbrushes, to use my old analogy. These are more the things in the outer loop.

The first thing - and I keep referencing it because it was great - if you think about what the bol people were talking about: product managing your factory, that loop. The thing about product managing is it's good to know your customer and what they're doing, otherwise you're just making stuff up, which is nice for poets and fiction writing but not really great for engineering sorts of things.

(18:45) So really, I think the state of the art of figuring out what your developers are up to - again, in a large organization with hundreds and hundreds of developers; if you've just got a handful you go have a 90-minute lunch with them and sort it out, which is probably fun - is just sending surveys out. This is a survey we used at Pivotal Labs, now Tanzu Labs, VMware by Broadcom or something. I worked with them a couple years ago to make it free. I think there's a CSV you can download, or you can copy and paste stuff. If you look over it, it's asking about tools usage and sentiment and about how long builds take, all of these attributes that are in our buffet.

(19:27) What you want to do with a survey like this - again, think about that loop of "we deploy a solution and then we need to actually monitor it" - is you send it out initially, and then depending on what period you want, maybe you send it out in a month, maybe a quarter. What you're doing there is you've got that instrumentation, you can see if you're improving things. You want the bad things to go down, otherwise you need to try again. Having this kind of input about how the productivity is going, based on attributes like this, gives you that good feedback loop, that sense of what to do. There are all sorts of other surveys, but that's the one I have on the slide.

(20:09) The other thing on that outer loop - and I always feel a little ridiculous bringing this up. I kind of count the start of DevOps as, I think it was 2008 or 2009, with the agile infrastructure presentation from Andrew Clay Shafer, as he fancies himself nowadays. Because of course we all have continuous integration and continuous delivery, or deployment, whatever, in place. But if you don't have that in place, then your productivity is going to be a little weird.

(20:46) Just as a refresher, this is what we're talking about - I'll probably say pipeline after this. More or less what we figured out, and this is why paying attention to this outer loop is important, is that in each of these boxes, especially the developer box, I think they kind of know what they're doing. They're really optimized. You could say they're locally optimized, or you could say they know what they're doing - in their domain things work really well. But of course, as we all know, it's those lines between that we're really all the problems are. The wait times, the dependencies, the passing authority over. This time of year you're in Europe, you're like, nothing's happening until September, so we might as well forget about the velocity of releasing things - to get past the architectural board you've got to schedule meetings, all that kind of nonsense, get your security stuff set up.

(21:41) So having these kinds of pipelines in place and automating them, as we've known and I'm sure as everyone here does, is extremely important for actually having productivity.

(21:52) And the history - I looked this up especially for this presentation. Grady Booch, if you remember him, wears a lot of Hawaiian shirts nowadays, which is fantastic. Maybe in 1994 he had his object orientation book. I think I read that book when I was like 17, and I feel like I was hazed by my fellow programmers for reading through that, and then I did object-oriented Perl, which is super weird in retrospect. So he wrote about this idea that we should do continuous integration because it'd be great. Then of course XP comes out in 1998 - I don't know if they got 15 or 20 or 10 sort of principles - and that also has continuous integration. Then we had the lovely ThoughtWorks people, as always going from radar to implementation at breakneck speed, they had CruiseControl. Then we had Hudson, then Jenkins. And then of course continuous delivery, represented there by a fantastic book. And then, as if to say you can't apply this everywhere, this guy Gary Gruver, who was working at HP at the time, was like: I do the firmware for printers and I can do CI/CD for that. It took him about a year or so, but he wrote that up there. So you can pretty much do this for any sort of thing, as I'm sure many of you are doing.

(23:09) But when you talk with your peers after this conference and they're sort of upset and they're like, our productivity is not so good - maybe you can be empathetic for them based on this kind of chart that I've been looking at. This is from the State of Agile report. Sadly they stopped asking this question, and it's got a little more - you know when you get a survey that's in landscape you're like, I don't know what's going on here. They've kind of removed some of the disclosure from it, but you can see I collected it up to 2021. Surveys, blah blah blah, they can be good, bad, whatever. But what I like about this one is that it's many, many years. What you see is the green tells you continuous delivery or deployment - someone smarter than me can tell you the difference between those two - and the blue is just let's say automating your build and your test. What's remarkable here, you could almost remove the numbers from it and say the worst thing is that it's flat. We're not necessarily improving as an industry. We're not somehow getting better. Which maybe is why we're still here having DevOpsDays. When we get this up to, I don't know, 75, 80%, maybe we can just shut it down and we'll have solved the problem.

(24:26) They did stop that in 2021, but thankfully - thanks to the largesse of the Linux Foundation - the CD Foundation picked up the slack here. Again, surveys: don't worry about the transition of the numbers, but you can see over the years there's still a small amount of people that are actually doing CI/CD, and it's not really improving over time.

(24:51) And just to emphasize this point - I like to do a little chart education at least once in my talks. Here's a tip: if you want to emphasize something, do a 100% chart instead of just a bar chart, and then just go crazy with the colors. Here what I've done is: never mind people doing CI, what's the percentage of people not doing it? Again, you are probably the 29% of people who do it - congratulations, that's good. But there are a lot of people who are just not automating their build and their test, which is ridiculous. So all this effort you're going to spend on developer productivity, you're going to have this great box of productivity, and then this. It's just going to languish and sit around somewhere.

(25:35) So that's why I start to think about the box that you have around things - the outer loop is important as well.

Stop building your own platforms

(25:45) Now, also, especially for a DevOps crowd - we probably know what a platform is, but this is a similar area where if you look at those lines between the boxes, you have a lot of issues. Thankfully there's this reference architecture from the Cloud Native Computing Foundation, the CNCF software factory, that defines what a platform is. Which is great, because then all of us vendors doing one-minute pitches, we don't have to give you a vendor pitch about what a platform is. We can be like: that. And it's wholesome and good and true. But all of us platform people, we pretty much do this. We just don't use Easter colors for things.

(26:22) But these platform people are building these out all the time, and that becomes quite the issue. You spend a lot of time on that, and it's not only the time you spend building it, but the variation you have across your hundreds of developer teams using things.

(26:51) And this was a thrilling moment that we had in the past five years, where we were like: let's strip down all this stuff, all the way down from the platforms as a service and the platforms that we had, and let's just build it all the way back up. This has really pulled in a lot of time building the stuff out. But I think we've emerged from building up from the Kubernetes layer, and now, if we want to focus on improving that kind of flow through the factory, we've got to really address this issue that's persisted for a while - which is that you weren't really meant to use this Kubernetes stuff, application developers, or maybe even DevOps people. It's kind of unclear over the years what the thought leaders of the Kubernetes community have thought, although there are some pretty clear statements here and there.

(27:28) But it's this idea of: if we keep building all these platforms instead of using more standard ones, whether they're open source based or whatever - and even worse, if we have 5, 10, 20 platforms in our organization - you're going to end up having all sorts of issues. Those lines between the boxes will elongate.

(27:44) And you see this in a survey we just came out with. We've done a state of Kubernetes survey for about five or six years, depending on how you count it, and you can see that the more platforms you have - we only ask four or more, but the more platforms you have, the more issues that you have. Anyone who works in infrastructure knows that the more different types, the more variations and variability you have, the more annoying it is. You've got to context switch between these different things, you have to understand them. And then you also add in - I can never remember the difference between a combination and a permutation, because I'm a liberal arts person - but you also bring in all the different development teams using all these different platforms and these different tools, and you're in a mess.

(28:28) So you want to go down to as few platforms as possible. And I think that comes back to the point about developer productivity. The tools are important, of course - you want to go to the buffet, figure out what metrics make sense for your organization so you can talk about the impact you've achieved. You want to have that inward-looking "how am I doing, what's my health assessment" for stuff. But then think about the bigger picture. Make the grand first-generation DevOps move, which is: ah, it's the end-to-end process. That's really what we're here to solve. Always pull back to that and ask, am I the 68% of people who don't automate their build, or the 29%? I don't think those numbers add up, but we can roll back the tape and look. And really think about how you can focus on that outer loop part.

Wrapping up

(29:14) Just as another endorsement, I think what the bol people went over today was great. What I really like there is they said not only product management, but they were like, design - which blows people's minds. They're like, how would I get a designer working with the infrastructure people and the operations people? But that's really what I've seen over the years: if you've got engineers, product managers and design people, you kind of engage in building up that nice outer loop.

(29:44) So then finally, just two things. These are the people - I'm sure there are others, but these are the people I read and listen to the most about developer productivity. They've got a great newsletter, and they also have a great series of YouTube videos. If you're in marketing like I am, I'm thinking of awarding them best thought leadership marketing campaign of the year, because they're really cornering this developer productivity conversation. I mean that in a good way and also a snarky way, but genuinely: if you follow what they're doing, you'll get a good sense about the evolution of developer productivity and metrics.

(30:23) And then of course, if you're interested in not doing ridiculous platforming, we have many fine pre-shaved yaks at VMware Tanzu by Broadcom, which I would endorse. You can check those out. And with that, thanks for having me. It was nice to see everyone and present here. I appreciate it, and enjoy the rest of the conference.

Why this recording exists

(0:00) So if you're watching this online, what I'm doing here is recording a talk to give at an online conference. It's the culture talk that I give. I'm just going to give it straight and chop this intro off for submitting it to the conference, but I'll upload it here and you can see a sample of what this talk is like. This is the 30 minute version - there's a 45 and a 90 minute version, just a lot of content to go over, but I've compressed things down. As always, if you want to see more things like this, I do a show twice a week and all sorts of other little videos. If you go to TanzuTalk.com you can find the archives and all sorts of things like that. I try to broadcast on Tuesdays and Thursdays at 10:30 AM Amsterdam time. So with that, let me roll into here and we'll see what happens.

What we're driving towards

(0:47) Well, thanks for having me here. I want to go over the talk that explains what it is we're driving towards when we talk about improving the way that we do software - the reason we install Kubernetes, and the reason we're interested in application development and DevOps and product management, all of these kinds of things. Not only to go over what the goal of that is, but more importantly, when it comes especially to large organizations, what that culture looks like. And also how you scale that culture in a large organization.

(1:17) First of all, just a tiny bit about myself. I'm pretty lucky that I get to spend pretty much all of my time in a professional capacity studying how large organizations get better at software, how they transform from a project way of doing things to a product way - and interview people, talk with them, and put them in book form. Here's two books that you can get for free if you want to, you can go to cote.io/books. And I do a lot of podcasts and other things.

Why we care about culture

(1:48) In our industry there's always a lot of talks about culture. I talk with a lot of management and executive people, and one of the top things they want to know about is: how do I change the culture of my organization? What I've found over the years is that in this conversation, in the talks that people have about it, there is this definite idea of what the end goal is - we want to have an innovative, creative, DevOpsy kind of culture. But there's really not that much talking about how to get there. How to get from where you are now to that kind of fully finished owl. Over the years I've found it pretty unsatisfying to figure out exactly what that is, so I've spent some time researching it. This is a brief overview of some of the things I've found, and the way that I frame this notion of what culture is.

(2:32) The first thing is to ask this question: why do we care about culture? If we're in a large organization, we already have plenty of culture, lots of stuff going on, lots of software that we're working on. In recent years, what companies and organizations are focusing on is that instead of just delivering a project way of doing software - a set of features - they're really thinking about software as a storefront, as their primary way of interacting with their customers or with their internal employees. What they've found is that the more they can improve that customer experience, that user experience, the more it will allow them to improve and innovate their business.

(3:04) You hear a lot about people wanting to be like tech companies - "we're not a bank or a car company, we're a software company." What they're expressing is this idea that we can start using software as the primary engine of how we do business. Getting to where you can indeed be like a tech company, where you have this product way of thinking about software, is a lot of what people are driving at when they're talking about changing culture. They're not just talking about installing VMs, like we were in the 2000s, making something more efficient and easy to manage. They're talking about fundamentally changing the way they think about software, the way that they do software - so that software becomes that expression of the business they have and how their business functions. And then, in an advanced way, allows them to innovate what their business does.

(3:57) Now the problem is that the way we've been doing software thus far doesn't really match this product way of doing things. Organizations that are not tech companies tend to deliver software in a different way, and where they are at the moment - as you can see from these sad donuts - is not quite at the point where they can rely on software to be that core thing that runs their business.

(4:19) One of the primary ways I judge this is the frequency that they release software. Because the more frequently you're releasing software, the more you're evolving it, and the more of a chance you get to discover what the market is, discover what customers are doing, and really evolve and innovate. As you can see from surveys, many organizations don't deploy improvements to their software very frequently - just about half, which is an astonishing amount.

(4:51) What that means is that your software is static. Your software can't really be relied on to evolve and innovate your business. You can see some other sad things there too: a lot of organizations are really stuck with what they call legacy apps - their existing application portfolio, their existing software - and just the inability to change it and evolve it is really holding them back from changing how they operate, from improving the way they do their software, and from changing what their business looks like.

(5:12) So most organizations, many organizations, are in this state - this land of sad donuts. A lot of what this changing culture gets to is: how do we get ourselves out of these sad donuts and get to some happy donuts?

A happy donut: Daimler and the Sprinter vans

(5:24) Let me give you an example of a happy donut, and that is from Daimler, the company that makes Mercedes and many other things - they've got trucks and things like that. There's a team there that has this culture that we're looking for, this culture of innovation. They're in charge of a storefront for buying cars. There's a search engine, you can go customize the car, kit it out however you want. They tell me that a lot of people go in and build this ultimate sports car, and then, like me, they end up getting realistic and configure a station wagon in the configurator. And depending on the geography you're in, you can schedule to go talk with a dealer, all sorts of things.

(6:01) If you think about it from the standpoint of selling cars, this is a lot of the first interactions that you have with your customers. It's your storefront. So you would want the software you use to do that to be very good, and to be evolving, to always be adapting to what customers want to do.

(6:17) The team doing this had a very product-mentality way of doing things. They noticed on their site - the front end for doing car searches - that a lot of people were searching for these Sprinter vans, which are not normally part of that line of business. This is what ice cream people will drive, or plumbers, things like that. A completely separate part of the business, so obviously their software is done on their own and doesn't work with the people selling station wagons. Again, completely separate part of the business, so it sort of makes sense.

(6:45) But the team there, because they had this culture of innovation, saw that people were interested in finding these vans. So they put a theory in place. They said, "well, despite the fact this is a separate type of business, why don't we integrate the backend for the Sprinter vans and allow people to look at these vans, not just the sedans and cars that we have?" As we'll get into, having a team who are even curious enough to look for that kind of data and think about something to do is part of this culture, and is valuable.

(7:12) But the tool that they use to pursue those theories and evolve the business, to innovate, I think is equally valuable. I call this loop the small batch loop. It's nothing that I've come up with - it's like the lean startup loop, it's a design loop, it's even the scientific method if you think about it. But following this loop, in this product way of doing culture, is very important because it makes it more disciplined, instead of just creative and exploratory.

(7:41) In this example, there's a theory that people looking for station wagons will every now and then look for a Sprinter, and there might be a reason why they want to find a van. So what kind of theory would we come up with, that they're looking for a van and that they would buy one, even if they're not an ice cream truck driver or a plumber?

(8:01) In development, the way that we run an experiment is we write code. You have to write the code for it, and you put that code in front of a user, and then - this is the vital part - you somehow measure what's happened. Do people end up buying those vans? And if they do, then you've validated your theory and you've come up with a new innovation, a new feature. Going through this loop over and over again until you discover what works, and backing it up with the rigor of measuring and looking at your assumptions, of validating and invalidating things - that's really at the core of how I see the software teams that we're aspiring to be, these product teams, really explore what their software can do to help their business out.

(8:44) So lo and behold, as you might be guessing, what the team found when they integrated with the Sprinter backend is that there were many people who wanted to buy one even though they were consumers, not professionals. They wanted to buy Sprinter vans to use for RVs or caravans, or whatever you want to call them, so that they could go on trips.

(9:05) Like many great examples, it seems ridiculously obvious in hindsight. But if you recall the situation - these were two separate lines of business that felt like they had no reason to integrate with each other. Until you had this kind of culture of innovation playing out in a team, no one had really thought to merge the two together and explore the possibility that they could sell Sprinter vans in the same channel, the same way they're selling these other cars. That there might actually be, in the view of us, the people buying this, a sense that we don't care that they're separate lines of business - and so therefore the way the software is managed and delivered should be merged together.

(9:42) It's going through that small batch loop that you can discover this, and also prove out that this is a good idea and a way of doing business. And then, as in this example, you get pretty much free revenue. This isn't something where - you're just integrating systems together, which costs some money, but then long term you don't have to create a brand new business.

What even is "culture"?

(10:04) So that's kind of the end goal, that description. I'll give you a couple more examples, but let's talk about how we get to that end goal, which is by putting in place this culture of innovation - as I like to call it, a product way of thinking about software.

(10:16) As I was saying earlier, I've always found it hard to define what culture is. I started thinking about this when the DevOps reports started coming out and they went over the Westrum way of thinking about things. It's a good way of describing what a culture looks like, so you can diagnose what kind of culture you're in. I will let you guess which ones are the undesirable ones.

(10:44) This is fine. But this is more like a state that something exists in, attributes that you have. I've always wanted more than just this, because it describes what something looks like.

(10:57) Thankfully, back in the 90s there were a whole lot of books written about changing the corporate culture, when another gigantic notion of how organizations work was changing over. Digging through those books, and some other ones that are fun to look through, there are some references for you, and some quotes from there to summarize the way those books looked at culture.

(11:19) What these ideas of what culture is boil down to, in a very tactical, pragmatic way for me, is: culture is how we do things around here. It's the processes that we have, the norms that we have, the expectations. You can think of them as thought technologies, or meatware.

(11:36) So when we're talking about changing the culture, and the type of culture that we want in an organization, we're really talking about how that organization functions and the mindsets that people have. Are you more command and control, where people wait to be told what they're doing and someone has to tell them what to do? Or is it more like that Sprinter example?

(11:54) Now let's focus on the area of software development, and managing that whole software capability you have in your organization to be the main way that you're running your business. How would we do things around here in this kind of product-driven culture of innovation that we're shooting for?

What the team does: innovative, risk takers, people-centric

(12:06) I want to go over what the individuals - we would normally call them developers, but let's call it the product team: the developers, the product managers, the designers, the people working on the software - what attributes they have, how they do things. And then I'll go over, maybe even more importantly, what management does. The context, the system that management sets up so that these teams can be successful.

(12:32) First of all, these three things. There are other attributes, but these are the three I think are the most important, and they're all kind of the same thing. If you look at how people who are on teams like the Sprinter van team do things around here: they're innovative. They want to come up with new ways of doing things. They want to apply that small batch loop to explore and imagine new ways of running their business, of what their software looks like.

(12:57) Now, to do that, they're comfortable taking risk. They're risk takers - or, if you prefer something safer, they like to learn. Learning is all about taking risks and failing. I think about when my kids are learning to read and do math and other things: they're constantly failing at it. But because they're failing, they're learning, validating and invalidating things, and they're learning the way to go about doing things. They're taking risks. There's a reason why I'm bad at learning things, and it's that I don't want to take the risk of failing, so I just do the things I know over and over again. But people on this team will try out things. They'll go through that small batch loop and try out a new way of doing things, and if it doesn't work, they try out a different way.

(13:36) Another attribute they have is that they're very people-centric. That doesn't necessarily mean they need to be extroverts, but they think about a person using the software. I move pixels around on the screen; a person is using the software. So I want to get into their head and think about what that person is doing, what their motivations are, how I might help them out. I'm curious to observe what they're doing, because I'm helping that person. Their focus is not on features that they're implementing, or just doing their job. Their focus is: I want to make this person's interaction with my software, their time spent with the software, better.

(14:13) Now, in order to have a team like that in place - a team of people who are allowed to use software to go through that small batch process, to innovate, be curious and explore - if you think about what's required for that, most software organizations are not set up that way. They're set up where the developers, first of all, don't necessarily have product managers or designers. They're just developers who are told what to code. They might even be given wireframes: code exactly this screen. So they're not really given the opportunity to explore and innovate. They don't really have those attributes.

What management gives: autonomy, trust, voice

(14:48) So management, or leaders, need to change what they're doing. They need to rewrite the way that they are doing their system of management. You can think about it as the context, the system they set up - but I like to think about it as what management gives these teams.

(15:04) The first thing is that managers give these teams a huge degree of autonomy. You can think of this as ownership. If you go to that Daimler example, they're giving that team ownership of that interaction, of this idea that we could add in the Sprinter vans. They have the autonomy to make a decision about what features should be in the software and what to do next.

(15:24) Now this requires a huge degree of trust in the team. Management has to trust that the product teams - the developers, product managers, designers - care and will do a good job. This is a huge, huge issue for most people in large organizations, to actually trust that people are doing things, which takes some time to get to. And it's also, if you think about it, kind of a failure of management: if you have this organization and you don't trust it, you've done something poor.

(15:52) The other thing is that the team needs to have voice. Again, these are three aspects of the same thing. That voice is: because they have autonomy, because they're curious, they can voice that I think we should do this thing. I think we should pursue - even though it's a separate line of business - showing Sprinter vans to people.

(16:10) So if you're in management, think about these, in addition to other things you need to do to set up your system. You want your developers to start doing their software differently. You need to think about how you're programming the meatware of your organization, so the teams of people have this and they can start doing that more culture-of-innovation way of doing things.

The industrial kitchen: they went for recipes and found mayonnaise

(16:32) Let me give you another example of what this ends up looking like. This is from an industrial kitchen management company, also food service. They deliver food and they'll run the kitchens for you. This is a great example of all of those six attributes. This organization - like all organizations that want to run things more efficiently, have better customer experience - you can outsource your kitchen at a campus or a business. And they were using paper recipes. You'd have three-ring binders full of the recipes of how to cook pasta and stuff like that.

(17:02) So the idea of management was that to be more efficient, to have more consistency in the recipes, and to have newer ones, of course what we need to do is digitize these recipes and put them on an iPad.

(17:13) They got together a team of people, and thankfully it was one of these product-driven teams that had this kind of culture of innovation. In a very command-and-control way, they said: go digitize these menus. Despite this, they gave the team autonomy and they trusted them, and gave them voice, to do the following.

(17:31) The team, being people-centric, said: "all right, well, why don't we go observe the people using this software and see what it is they're doing, so that we can write the software to be most helpful for them?" So the team got up at like 4:00 AM in the morning, got to the kitchen at five or whatever, and for a week or so they observed the people actually going about their duties.

(17:51) What they discovered is that while the paper recipes were maybe not as great as they could be, an activity that took up a tremendous amount of time and task switching was measuring mayonnaise, measuring chicken, making sure that various ingredients were kept at a safe temperature.

(18:09) Because they were people-centric, because this team was curious, because they wanted to take risks and be innovative, they used the voice that management gave them to say: we're not going to digitize the recipes just yet. We found something that we think is even more important, that will make the kitchen run more efficiently.

(18:30) So they went and digitized the temperature taking. They did some Internet of Things stuff, and they kept more of a digital record of it, instead of the piece of paper that tracks the temperatures. Indeed, this saved a tremendous amount of time for the kitchen staff. It made what they're doing more efficient, because they had to spend less time on measuring the mayonnaise. And it also makes compliance - that is, health inspections - a lot easier, because you don't have all these sheets of paper that you have to keep track of. It's all computerized.

(18:57) And then eventually the team went on to digitize the recipes on the iPads and so forth. But overall, because the team had this culture of innovation, because they had this product-centric culture in place and those six attributes were scurrying around there, the team was able to meet the original business goals - and even exceed what those business goals were, because they discovered a whole other problem that originally management didn't want to solve.

(19:23) Those kinds of results, that kind of discovery that really changes the way that you operate - to me, when we talk about digital transformation and "we're a software company, not a food supply company," that kind of mindset really gets down to that thing. Using the small batch process, the software process, to discover new ways to run your business, to optimize it, and really constantly be learning how you can make the way your organization functions better with software.

How do you scale this?

(19:50) So with that, we've got this idea of what a culture is and the kind of attributes that management puts in place to allow for the team there. I want to spend the rest of the time going over how you scale this kind of culture. This is the question. This is what I've been interested in the last few years, because I talk with and work with primarily larger organizations. Their issue is: we don't just have three or four teams over there in Stockholm who we can all go out to lunch together with and sync up and sort out how we're doing. We have tens of thousands of people, thousands of projects, thousands of apps that we need to switch over. How do we hope to scale that kind of thing that's normally done in a person-to-person way? So I want to go over some tools, mostly that management uses, to help scale that kind of culture.

(20:40) The first, often under-appreciated, under-done thing is to really look at something that normally is not very helpful at all: your company's vision. Your vision, your values, your mission statements. These are often very nice and aspirational, but they don't really tell those development teams what they should be doing.

(21:03) Ask yourself: do I know what my company's vision is? The mission statement for my company? And if I had to decide the next task I'm going to go do, does that actually inform how I'm going to make that decision?

(21:15) I think this is a great example of a very pragmatic vision, from DBS Bank in Singapore. It gets to this idea that every time you're making a decision about a feature you're doing - even what Kubernetes distribution you might use, or whether you'd use one at all, all these kinds of decisions - if you have any doubt, or you need some way of guiding it, you can use this vision to determine if you're meeting that need of: I don't want our customers to have to spend too much time with our software getting whatever they need from us. I want them to do it quickly, because they need to get on with the rest of their life.

(21:48) That's easy if you're in the app layer, where you're moving pixels around on the screen. You just constantly go through that small batch loop to make the workflows and interactions that people are doing with your bank as quick and efficient and easy as possible.

(22:01) Think about, especially in the upper parts of management, how you can get a vision that is a tool that can be used - not just something that creates a nice identity or aspiration, but an actual tool that people can use. You can decompose this down into principles and things like that. But really think about codifying those kinds of principles, that kind of vision that you have. That will help you scale, because all of the people in the organization can look at that for guidance about how to act, instead of having to ask about it and being told directly.

Start small, and seed people between teams

(22:33) There are two key things that are really vital to figuring out how you scale. The first is to start small, and slower than you think you should. A lot of people, if they look at the thousands of applications that they have, want to, over the course of the first year or couple of years, have each team be responsible for modernizing it. For the most part, that couldn't be a worse idea.

(22:56) Instead, what you want to do - you're learning a new way to operate, a new way of thinking, you're using new technologies to run your software on, you're going through that small batch loop on a weekly basis. This is all stuff that's going to be new to your organization and the people doing it. So you want to apply that same learning loop, that same small batch loop: start with one project for a month or two, start with two projects after that, scale it up to five, and go through that line over the course of the first year, where you are learning what works in your organization. You're learning to use this new meatware and software, this new way of doing things. And you're adapting a lot of these standard practices to fit exactly what you're doing. You're also building up a track record that you'll use to prove that this new way works when you're trying to scale it to the rest of your organization.

(23:45) The other key thing is that you identify some of the people in those initial projects, the product teams working on it, who are more people-centric, kind of outgoing. Then as you go to new applications and start up new teams, you take these individuals and you seed them into those new teams, to be someone who already knows how to do things in this new way. So they can help that team do a little bit better than bootstrapping from nothing. They can help train up that team, help build the trust that this new methodology is working - and then they train someone else. So now you've got two people who can be sent out into another seeding, and then four people, and so on. You're slowly but surely training these new people by starting small with some initial applications, instead of doing everything at once.

(24:40) Doing everything at once generally won't work out, because you won't have the chance to learn how to do it and adapt it to what works in your organization. I see this time and time again: organizations methodically start out smaller and they just build up slowly, by seeding people and spreading that knowledge through their organization.

Brand it, and market it internally

(24:51) The final thing I want to cover is: about midway through, when you've validated that this is a good methodology, you've gone through a couple of teams, the next thing you're going to want to do is really brand what you're doing. Now, that sounds kind of like a crass marketing thing. But remember what I was saying: you want to adapt the off-the-shelf methodology to what works in your organization. So you want to codify what that is, write it up, and boil down that pragmatic vision to a set of principles, how you operate.

(25:20) You also want to come up with your own name for it, like you see at BT, British Telecom. They call this whole new way of doing things Canvas. It has the Tanzu Application Platform that runs on it, the Tanzu Kubernetes stuff that they use for it, and they follow the Tanzu Labs way of doing product management. So instead of calling it all Tanzu stuff, or calling it agile or lean product, they've come up with their own name for it. They own that. And they really have the branding around it.

(25:52) This comes up time and time again - you can see it with Duke Energy and Daimler there. It's very important that you own this new process. That it's not some other process, an external thing. It's the one that's yours. I see this over and over again.

(26:07) Another thing that's very important is to have at least one person that is full-time dedicated to being an advocate for it, a marketer for it. Initially, what this person will do is go visit lots of teams and do some educational and awareness driving about what this culture is like, how to use it, and really help spread that word. They'll also get input. If you think about what they're doing, they're treating those developers, those product teams, as customers for this culture. So they're almost advocating for and helping product-manage what that culture looks like.

(26:40) After you get through a few initial teams, what this should turn into - about quarterly, once you have maybe five or six teams, six months or so into this - is you want to start having quarterly internal conferences. They can be online, in which case about half a day, or if they're in person they should be about a day long. You have some of those initial teams that have been successful present at that conference about their experience. You do training at that conference about the platform they're using, about the small batch loop, the product mentality that you're doing.

(27:14) You're using this quarterly cadence of an internal conference to build up awareness and to build up trust, because all the employees are talking to themselves. It's not just fancy pants outsiders like myself who have a bias to make you buy some VMware Tanzu stuff. You're almost talking to yourself, and you're spreading and training this culture. That begins to be a way that you can scale it out. And if you have recordings, it's easier to do this as well.

(27:42) I like to go over this point because this is an amount of training and really marketing that I don't think most IT organizations think about for their software. It's not really just a program office or a center of excellence. It's almost the reverse: these people are going out into the field, if you will, and really working with those teams. You don't get a lot of presentations from the center of excellence - instead you get presentations from the teams themselves in the culture, and they're trying to take ownership and really drive spreading that culture around.

Drawing the rest of the owl

(28:16) So that's just a sampling of, I think, some of the most important things when it comes to scaling culture. There's all sorts of other things, if you want to go read the two books that I have. But I wanted to try to fill in some of those things between the simple circles and the owl. You can see my personal example of the metaphor here - I've tried to show how you go between the circles and the owl. I think that's pretty good. I'm always trying to improve. I'm a risk taker.

(28:44) But hopefully you've gotten an idea of what that culture looks like when people talk about culture, when they're trying to use software as that primary way that they're doing business. And you've got an inkling of the system you need to set up: the attributes that the team has, the attributes that management needs to put into their system. And also a little bit, if you're in a larger organization - or really any size, but especially a large organization - how you can scale that out, how you can be successful enterprise-wide instead of it just being the lucky few teams that are doing it. And with that, thank you.