Well, you're back here on Tanzu Talk. Why don't you introduce yourself? Yes, happy to be back, Coté. Purnima Padmanabhan, General Manager for Tanzu Division at Broadcom. So last time you allowed me to take you on a walk down memory lane of like our, all the time we've spent in the IT infrastructure area was delightful and fun. In this episode, I wanted to get more in the present day and specifically for like what we at Tanzu do and what we've been working on for a while. I've been recently, well, more than recently. I do this all the time. I'm always trying to figure out over the last 18 years or so of cloud, like how much public cloud there is and how much on-premises private cloud there is. And I found some stuff recently that I've been writing up that I think kind of gets me in the mind that it's pretty even at the moment. I mean, you know, there's always lots of it depends and footnotes and things. But my main, the main thing that I noticed is there's a lot more private cloud out there than you would assume from reading the headlines. And in fact, as we know firsthand, there's a lot more. What do you encounter out there when it comes to private cloud? Wow. Age-old debate of private cloud, public cloud, and to some extent, quote, it's no longer a debate. It is what I see is we have now well into 18 years of public cloud and we see tons of growth in public cloud, but we also continue to see growth in what we call the private cloud or the private infrastructure. And so rather than a versus debate, it's often in customers' mind an ant debate. And it is which applications do I land on which type of environment so that I get the best advantage for my business. And in fact, the goal of Tanzu is to really make that decision for a customer as seamless as possible, right? Where do you land an application, whether it's public cloud or private cloud, based on the needs?
2:02Now, when we look at private in cloud, often people start not with private cloud. They start with private infrastructure. It's compute virtualization that is often passed off as, or even sometimes just a Kubernetes runtime that is passed off as private cloud. And what we have done, of course, at Broadcom with our VMware Cloud Foundation, etc., has truly laid the foundation for a private cloud. And I talk to many customers about this. Why do you still want to invest in private cloud? And actually, why do you want to invest in public cloud? What I find about private cloud is there are a few big reasons that stand out. One is, hey, my application is already there. It works seamlessly. It may be running on private infrastructure. And to get more agility, I want to move it to a private cloud. But it's all there. Second one is often about data gravity. People underestimate how much data is there about their businesses. And often these applications need to use the data. And this world of AI, ML now, they need to use it. It's hungry for data. So you're grabbing all that data. And trying to move all of that back and forth between clouds is a very hard proposition. So data gravity, AI, ML. And I would say tied to AI, ML and data gravity is also being able to access the ecosystem of existing applications that I already have in the environment. You know, no application sits in an island. It's often talking to an ERP system, maybe talking to a supply chain system, maybe talking to an ordering system. How do you bring all of that together with high performance? And I would say the last pillar often tends to be security, privacy, and governance. I don't want to take all my information and put it out somewhere else. I want to still have control. I want to have control of data locality. I want to be able to do compliance better. So there are many reasons why people prefer the private cloud. But again, as I said, it's not an either or. Many times,
4:02and often the primary reason I see for public cloud, on the other hand, is velocity. Hey, I've already got an easy environment. I've got a simple API for my IaaS. I've got a set of services and I can have the developer be off to the races in terms of consumption, ease of consumption of these infrastructure services. As you were going through that, you know, the term data gravity, that's been a good one for a long time. Very clever. I forget. I should remember who came up with it. But you brought up the idea of, you know, you have these existing, let's call them services, whether it's, you know, your supply chain stuff or ERP or just other existing applications. And, you know, maybe there's sort of like that like services gravity that you have, like all the other existing things to integrate. which I think gravity, yes. Yeah, exactly. And it's your own applications, ones that you might have with your partners in a business sense, like people, suppliers and people that you work with. And then also just whatever, you know, caught software and things like that. But that does seem also, you know, it kind of adds to, if I were to summarize a lot of what you're saying, it's the old phrase, like if it ain't broke, don't fix it, which I think is maybe not like the flashiest thing, right? But it's sort of like this works and it's cost effective and it's achieving what we want, right? And so we don't necessarily need to gratuitously move something around. And I think, I think, I think when I, when I've been looking through like where, you know, this kind of equilibrium between private and public cloud, that's a lot of what you're saying and that notion is what I've come back to a lot is the applications have kind of sorted themselves into where they belong by the criteria that you would have for selecting where they are, which, which I, I think works out well. And the other thing that I think is, is worth bringing up is, of course, our concerns for the most part are scoped down
6:02to applications that people write. Like you were saying, if you're only concerned with infrastructure, it's kind of a different set of thinking, right? And, you know, you might end up on either side of the firewall, but for software developers and the people supporting them, like, what is it they're looking for to layer on top of that infrastructure? I mean, look, maybe the way I would talk about this is, you brought up a very interesting thing. Nobody should go to any environment just for the sake of it, right? Oh, I have an edict to go to public cloud or I have an edict to go to private cloud, right? You have to go back, unfortunately, and look at some more mundane things. What am I trying to drive? Am I trying to drive business velocity? Am I trying to drive better ROI? Am I trying to drive better security, better governance? And so, and can I, if something is missing, how do, what is my fastest and most economical way to get to the right answer? And often when you look at this type of questioning, which is an apps down or a business down questioning, then you say, okay, there is one choice which is probably called private cloud, but the second one is, how do I get the business velocity that I want? And many times people make the move to, let us say, they are, they've got a good platform running on-prem and then they move to a public cloud and say, oh, I moved to EKS, I moved to EKS and I've opened the floodgates to my developers, but now the developers instead of writing code are managing public cloud infrastructure components. They're trying to figure out how to patch and update it. They're trying to figure out how to scale it, how to do availability zones and regions. So what you do is you still throw a lot of complexity and so from a business goal perspective, when you start measuring yourself, did you achieve that velocity? How long does it take from the time you write code to getting into production? Be it public cloud cloud or private cloud? What we find is
8:02often there is a missing element. developers should not, whether self-service or not, be managing the underlying infrastructure because when they have to do that, that is when they lose velocity. Imagine if all the developers had to do was write the business logic, write the code, specify their intent on how the code should run and walk away. When I say intent, hey, I built an application this is the business logic, I wanted to run HA, I wanted to have high, low latency networking, connectivity, I wanted to automatically do PII data filtering and by the way, when it hits more than X number of transactions, I want to automatically scale. These might be the kinds of intent that the developer does, but today instead, a developer is sitting and managing YAML files and configurations, so they took a whole bunch of workloads, moved it to, let us say, a public cloud, but still on the raw infrastructure, be it Kubernetes or VMs, and they are sitting and managing those. And that is where the debate changes course or directions and it becomes less of, hey, you will get a cloud and an IaaS layer anywhere, but that is insufficient to truly drive business value. What you need is that platform layer that sits on top of any IaaS, and that abstracts that infrastructure so that a developer can just write code, say a command saying deploy it with all my intent and walk. And that is where Tanzu fits in. And we have fit in there always, right? You know that. The thinking, you know, you're kind of, you're putting in my head, not forcefully, but you know, through what you're saying is scopes down to developers and, you know, your own applications to put it in air quotes like the cloud, is less important than the platform, right? Like, if your idea is we're going to move to the public cloud
10:04and that there's a period at the end of that annual strategy, right? Like, like you need for app, for some workloads that might make sense, for infrastructure, you know, if it works out for it, then sure, and there might be good on-premises reasons as well, but there's more nuance when it comes to application developers and they don't necessarily benefit from infrastructure as a service. They want a platform, right? And so, that's really like where the conversation for developers is important. We need a platform. cloud parts. Exactly, right? Otherwise, as you're saying, you end up being a YAML programmer or whatever else comes along, right? And I think you're right. That's what I've seen a lot of people lose sight of when they're figuring out whatever infrastructure they want, wherever it might be run, is to kind of lose sight of that developer experience that you get with a platform. True, true. And this is where, you know, we often have to spend some time talking about, okay, so what does that platform do? What does that platform need to do? And if you say that, look, it's all about velocity, application velocity at scale with security with performance, then the platform has to have adhere to certain tenets. Now, look, Coté, we have been in the platform business for over 10 years. We've got customers who are running massive scale applications on top of our platform, be it on public or private cloud. And what we learned from all of that is while now the platform engineering is getting in vogue and I'm very happy for that, the years of experience have taught us that there are three simple things that you should always consider. If you truly want that business velocity, the developer experience has to be simple and should be abstracted from the infrastructure. It has to be tied to what the developer needs which is, hey, how can I build
12:04my application faster? How can I write my application faster? So do I have the right scaffolding? This is where all the pioneering work for example that we have done with Spring and Spring Framework really fit in. The second one is, hey, once I've built it, once I've written it, can I quickly build it into a secure container without worrying about packages and where the dependencies come from? Can I, with a single command, deploy it? Can I, with a single command, bind to external services and scale? That is it. It is interesting when you look at the sum total universe of what developer commands are needed. That's all. VM as a service, Kubernetes as a service, database as a service, all become subcomponents at the infrastructure level. But that is what a developer needs. So that's number one. Developer experience must be simple for it to be truly effective, safe, and secure. And the simplicity just is build, mine, deploy, scale. That's all you need. The second tenet is that the platform, a template-driven provisioning doesn't work. Imagine, you know, somebody curates and says, oh, I talked to the developer, their app has got a front-end, it has got a back-end database and it is replicated across two regions. I'm going to write a nice template to go deploy it. And every time the developer clicks deploy, the template will go and deploy it. That is completely a rigid model that breaks, I would say, within a few hours, right, when you suddenly decide to make a change. So template-driven provisioning is not what you need. The second tenet is infrastructure must be dynamically provisioned to meet the app needs. And that is where the platform layer comes in. It takes these commands, takes the intent of developer and translates it dynamically into what the infrastructure needs to be. It may call templates to do it, but it doesn't matter. It is, you know, dynamically done. And then the last tenet we heard and we have learned is there are some boring things that people have
14:04to do and platform has to solve for it. Logging, auditing, credential management and rotation automatically, automatic connection and brokering and brokering to external services, right? Automatic repaving of your underlying infrastructure that app runs on and automatic repair of app. If all of this is not taken care of, this boring stuff and you just do a flashy nice deployment and then let the communities do the load balancing but really none of the other stuff is done, you still have an incomplete solution. So the platform has to meet these three tenets. Simple developer experience, dynamically provisioned infrastructure and something that does day two boring operations like repair, rotate, you know, rebave. And that is what we have done with tons of platform, which as we said, look, it is, and since this is still in people's minds, it's still a new area. What it does is instead of issuing, I want a cluster or I want Kubernetes, this, that, etc., which people are very enamored of, you say, hey, you go get me the Kubernetes clusters I need. I just want to say I want to deploy this app at scale. That is the big change or transformation. And often when business decisions are made, these are not understood. So I get a perplexing conversation sometimes, which is like, yep, we have a great platform on-prem and we are going to go to a platform in cloud. I said, great, what is a platform in cloud? Oh, platform in cloud is Kubernetes. I said, Kubernetes is infrastructure, it's not platform. So even when you go to cloud, you need a platform and even when you're on-prem, you need a platform. And the value of the platform is not measured based on the bean counting of how many VMs I'm managing, how many clusters I'm managing, but rather it's managed in terms of business outcomes. how much
16:04time did it take for me to get code to production before and after? If it is six months, does it go in six days? If it is six days, does it happen in six hours? How many security issues have I automatically avoided because of repaving and automatic repair? How many times have I managed to make sure that no external service, and we know many of those recent cases, impacts my application because I have got automatic credential timeout and credential rotation? And when you start measuring TCO this way, the value is just pretty immense, but more importantly, it becomes very clear to the business owners, and that is kind of what we have to do better as an industry. I like the distinction you made of a lot of people think of their infrastructure as their platform, and I think that thinking comes from, you know, you listed kind of the three things that a platform needs to do, and, you know, even using the word boring to describe that third bucket, it emphasizes the point, it emphasizes the point that a platform thinks like a developer, right? So you take on the developer's point of view and their perspective of what they, of course, what they would like to do, but what fits best to their skills. Yeah, what they would like to throw over the wall. Exactly, and that's where this disconnect of, like, if we just give the development organization cloud, and that cloud is infrastructure, we haven't given them enough, right? There's something missing, which is that platform, and it's always nice to talk about platforms and platform as a service because for many years that hasn't been the discussion. It's all been infrastructure kind of at this Kubernetes layer, and I think now we've kind of finished out the infrastructure layer, and people are hungry for that platform stuff, right? They want to see those. They're building it to
18:04themselves, right? Without knowing, they're building it themselves. Well, next week as we record this, we'll be in Barcelona if everything goes well. Hopefully our planes will get there on time and we'll get checked in. But we'll be in Barcelona at the EU, the Europe version of our big conference explorer. And, you know, you'll be up on stage. What are we going to be talking about there? Give us a sense, a little preview. You know, exciting. So, look, we have done, as you said, Tanzu has been in the platform business, especially with the Pivotal legacy and Cloud Foundry legacy for a long time. And we have made it very easy for developers with Cloud Foundry and for container based modern application, right? 12-factor apps, et cetera. But what has been missing in the industry is that same type of seamless developer experience with that build, buy, and deploy update and scale on Kubernetes. Kubernetes has tended to be this alpha bit soup of little projects that go around it, a separate networking layer, a separate compute layer. Now I stitch together pipelines, now I stitch together my build, et cetera. And so, what we are announcing is Tanzu Platform 10, it gives you three main things. One is it extends that simple developer experience now, not just from Cloud Foundry-like developer experience, also to Kubernetes. So you are not building the furniture yourself with your own screwdrivers, you actually get the whole desk and the chair and so on, right? You are getting everything you need. The second thing is, look, we are all about helping people build apps and build apps faster. Spring continues to amaze me with the power of the community and we are doubling down further on Spring but we have also enhanced Spring with some powerful libraries that make Spring run faster on our platform, make run Spring more secure with FIPS compliance, as well as make it
20:04easier for Java developers to write AI ML based applications on our platform, right? And not only easily write applications with Spring AI, but very easily deploy it to these cloud environments with the right type of Gen AI broker, right? So what you want is as you're building apps, you may be changing models and you don't want to change your APIs and your application every time you change a model. So we have created a simple API surface within what I call an AI API broker that then takes it and brokers it to any external models, takes care of governance, takes care of token management, takes care of security, and really the entire build to deploy of applications embedded with Gen AI becomes much easier. So that's kind of, so I would say that those are the three, you know, big extending the power of Kubernetes, extending the power of simple developer experience to Kubernetes technologies and making it available seamlessly by the way on VCF, right? That is a big one for private cloud environments, air-gapped environments. Number two is really fuel charging, right? The spring ecosystem with even higher performance and higher security capabilities as it runs on the platform. And then finally, you know, making Gen AI accessible. We talk a lot about, you know, the nuts and bolts of Gen AI and the picks and shovels of Gen AI as they call it. But, you know, if I'm a Java developer and tomorrow I just want to enable, you know, the use case of let us say a chat interface or a summarization use case or a filtering use case, how can I do that easy, right? While staying within my Java environment, writing a quick set of APIs, calling the models that I want and then getting it deployed with the safety and security of the corporate environment. And that is kind of the third big pillar.
22:04So, a ton of good stuff on Tanzu Platform 10. And then, you know, no application can live without data. So, we are also, we have Tanzu Data Suite and we are announcing enhancements to Data Suite with better, you know, data warehousing is now back in vogue. So, Greenplum, we are seeing a resurgence of our Greenplum data warehousing and analytics solution. We make it available with HA, multi-data center replication. We have improved the power of our caching solutions with 10x, the power of speed in terms of read-write with Gemfire. And what we also did is we took some of our core open source data solutions like Postgres, MySQL, Valky, and then we have also added RabbitMQ, which we are offering that as a fully supported enterprise-grade managed offering on top of BCF with Tanzu data services. Now, the Tanzu data services are included if you buy the platform or the data suite, but the nice thing is if you just want to run it by itself on BCF, you can also do that now. So I think you went through just there two great examples of why thinking about a platform is different than thinking about just give them cloud and let them sort it out, right? Like, you know, there's, you know, most all applications will have data around it, right? And in various different ways and the same benefit you get from managing infrastructure for people, for developers, you get from managing the data from them and making that integrated and part of the platform. And then I think, you know, before that, right, like, what's interesting about whatever you want to call it, I always think of it as enterprise AI, but using AI in large organizations is a lot of the, let's say, lessons that we learned going through kind of the Kubernetes era of cloud are
24:04pretty much the same for AI. Like you were just saying, you don't want to just give infrastructure or just give AI to the developers, you want to appreciate their point of view and build a platform around it. The platform has to adapt, right, to these in large use cases and it has to give choice and flexibility, right? So, again, the always operative word is if the platform is not taking away toil and it's not taking away the boring parts, then it's not doing its job. All right. I think we've got a good notion of, let's almost call it thinking beyond private and public cloud, right? Like what we care about and I think what's interesting for developers is the platform, right? And one of the aspects of the platform that's valuable is like as a developer and as the people supporting the developers, you don't really have to think too much about the infrastructure. You can do whatever works out best for you, right? And, you know, we went over several of the things of why private cloud is good, why public cloud is good. And then I think there's finally that notion that it'll be fun to see how it evolves over the next year or so is what's the return of this platform notion to the industry and how are people, not so much relearning, how are they building on what we've done in the past with platforms? So that's great. Thanks for the overview. Thank you, good to chat. Yeah, I know you're over there in LinkedIn, I'll put a link to it, but of course, for both of us, there's always tonsu.vmware.com where you can dig deep into everything. All right, well, this has been another tonsu talk. You can find the show notes for this by going to tonsutalk.com and hopefully we'll see some of our listeners in Barcelona. That'll be fun. We'll have to report back on that. We'll see everyone next time. Bye-bye. Bye-bye.