VCF + Tanzu Platform = The Private Cloud Enterprises Actually Needs

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.