Platform-Centric Cloud-Native Apps with Broadcom’s Purnima Padmanabhan

This is Textron tv. Hey guys, thanks for the throw. We're here with Perma Kaba, who is general manager for Tansu, for the new Broadcom that's been created as a result of the acquisition of VMware.

And we're gonna be talking about, well, everything from where is Kubernetes being used today, what are some of the issues that we're encountering? And for that matter, is AI gonna drive further adoption of Kubernetes. And we'll get into it from there.

But Pima, welcome to the show. Thank you, Mike. Great to be on the show and good to connect with you again.

I feel like, you know, I've been following Kubernetes for longer than I care to admit. I feel like sometimes there's us old timers and then there's a lot of newbies and nothing much in between. But, um, one of the things that seems to be happening is, I would argue Kubernetes is maybe becoming a victim of its own success.

It's finally getting enough adoption and enough traction in the enterprise and production environments. But as it does so too, does the course of complaints about the application development experience and the data scientists are now involved and they're saying, this stuff is hard. So where are we on this journey and where do we need to get to?

Yeah. It's interesting that you bring this up because, um, uh, I was at C**n Europe just last week in Paris, and you are a hundred percent right. The frenzy of innovation around Kubernetes is just crazy.

The energy was amazing. And I would say every time I turn my head around, there's a new little project solving a problem that is specific to Kubernetes. So what I saw, as you said, is all the newbies and all the d iy ourselves, you know, DIYers, who are connecting dots and building a lot of stuff, a lot of open source contribution.

But the interesting thing was, I also met some enterprises that were saying now I have slowly grown my Kubernetes platform team from, you know, I was experimenting with five people and now I have 75 people. Uh, and ultimately still my developers don't have a simple interface to deploy and manage their applications, to build their applications. They are, we are trying to teach them yaml.

We are trying to teach them configurations. We are trying to teach them how to handle Kubernetes itself. And so the thing that I ca take came away is no doubt, the innovation in Kubernetes is amazing.

We have been early, uh, we early to lean in into that, and we'll continue to lean heavily into that. But I think the bringing that promise of Kubernetes to developers is where we see a gap. So the container platform to the app platform, and that is where we wanna strictly position tan, right?

And that's where you have positioned tonsil to say, how do you take the power of the innovation that is happening and put it at the fingertips of developers without having them to learn 25 different projects and 35 different configurations, right? That's the, um, that's the promise. So it was very interesting on the Kubernetes side.

Yeah. Do you think there's a correlation between adoption of Kubernetes and this platform engineering movement that we hear a lot about, which is heavily focused on increasing developer productivity? And does this all kind of tie neatly together with some higher level of abstraction that we're looking for?

My goodness. Uh, absolutely. You see the, it's not as if platform engineering as a discipline has not been there before.

You know, of course, you, you know, from tan Zu platform, we also have the Cloud Foundry around time, and there's a very strong platform engineering discipline that was built around that. But that same demand, or it's like a drumbeat is coming up now for the modern app based on Kubernetes work to say we need a platform engineering discipline. And the discipline is not just about products and platforms, it's also about fundamentally how do you think about the relationship between developers and platform engineers?

How do you think about the cultural transformation? How do you think about the processes and what we have, uh, now an industry term called define golden path to production, that is all part of platform engineering. And if you want to do platform engineering, right?

We know you cannot expose the guts of the platform to the developer. Why does a developer care? And so imagine if you could just give that abstraction to a developer to say, Hey, you have written your code.

You want to build it, you want to bind external services, you want to deploy it, you want to update it, you wanna scale it and secure it. That's it. You don't need to know how to configure a cluster.

How to configure is to your service mesh to connect to each other, how to configure a particular load balancer to talk to that environment. And that is where I see the next generation of evolution happening. Mm-Hmm.

In the market, and at least the, whether it's happening or not, it's really the demand is coming up now, right? And, and more so as you start talking about AI ml, I can't help but wonder though if some of the complaints are tied back to, well, we just didn't think through the application we were building and whether it was fit for this particular purpose or not on Kubernetes, because there's a lot of people talking about, well, we should do everything in microservices. And then there's other people who say, me, you shouldn't avoid microservices at all costs unless you absolutely have to.

And then there's other folks who are somewhere in between. But do we need to get smarter about what kinds of applications we're deploying on Kubernetes? 'cause maybe a little bit is people are just like, well, it's the cool new thing.

I should build an app for it. Yeah, I think that's a very interesting thing, which is, is it the tail wagging the dog thing, which it'll start. And our, um, philosophy and premise, and this is what chat Tansu has championed for a long time, is it has to start from app down.

Ultimately, that drives the business need and technology choices. You don't pick a technology and say, okay, I'm gonna build an app for that, which now unfortunately is happening a little bit. But if, when you start app down, then you say, what is the right architecture?

Then you say, what is the, you even say, what is the right language I'm building? Right? It starts from there.

So that you want to reduce the toil as much as possible. And let us say, I'm building a new modern app. Maybe I will start with spring.

It's already given me all the connectivities. It gives me the framework, it gives me this beautiful place in id, I start building my business logic. That is where the biggest power comes, right?

And developers building the business logic for your environments. And so you build that business logic and then you say, okay, let me make a call. Where do I want to have this run?

Do I want to run it on a Kubernetes based platform, or do I want to run it on maybe virtual machines or do I just go for pass services from, uh, certain types of things? I don't even, uh, need to build something, you know, build and package something there. And so that decision comes next.

And then the decision is a which environment do I deploy? Maybe if I have a lot of proximity to data and I don't wanna ship it around, I do it on a private cloud. If I have very little, you know, if I, if network traffic is not gonna kill me, maybe I do it on public clouds, or if I need a lot of geolocation and proximity to end users, I get the power of a public cloud.

So you have to pick based on the application judgment call. And that is where I feel the transformative, uh, power of platform engineering comes in. Platform engineering should make these choices as intent for the developers.

So imagine I build my business logic, then I say, Hey, look, I don't want to, uh, curate my own database. Give me an external database to bind into it, for example, or external data source to buy into it. And with AI ml, now people are saying external model that I can start using, because I'm not always, everybody doesn't build models.

Most people use models, right? And, and so that could all just be intent of what you want, the language bindings and the environment that you want. Another intent could be, Hey, I want high availability.

Give me across multiple clusters and payload. Give me low latency. Gimme access to data.

All these things, rather than it be defined by the developer at a Kubernetes level, for a Kubernetes sake, you define intent at this level. And ideally, the platform, the platform solution product as well as the platform engineering team should then drive the translation of that. And, um, and, and then ultimately the deployment of the applications and management of applications.

That is the ultimate state where we have to be. By the way, this is not new. This is a pattern we've seen before.

If you remember, uh, I, I, I, I say I was in cloud before cloud. I was with a company called LoudCloud, uh, mark and recent and Ben Horowitz's company in, uh, you know, 98, 2000. And we were building a cloud.

And at that time, I know customers used to come and say, Hey, I want to see my server. And we said, you, you don't get to see your server. It's virtualized.

You know, we have virtualized it. And uh, you, you are, it's a shared pool. I think it's the same thing.

You don't need to own your Kubernetes clusters and Kubernetes environments and know your service meh architecture that has to get abstracted at the app level. So this narrative of container platform getting elevated to app platform is key. We talked about the platform engineering team, and a lot of those folks are basically trying to manage DevOps and scale.

But there's been this ongoing conversation about, uh, do I deploy Kubernetes on the virtual machine? Do I encapsulate the virtual machines so it runs in a container on Kubernetes, or do I put everything on a bare metal server? It seems like we're still all over the place.

So what drives people one way or another? Um, sometimes it's logical decisions and sometimes it is religion, right? You know that.

And so, but if at least our philosophy, and when I think about tan zu and I think about B, C, F and VMware is just like with virtualization, we just gave a runtime that just works. Do you ever think about ESXI? No, it just works.

You ask for a vm, you get a vm, and we are doing the same thing with Kubernetes in the, so rather than thinking, so we are separating the runtime in that platform. So we're saying the runtime just needs to be a fundamental dial tone that needs to be part of the infrastructure. And so with our VMware cloud foundation that I talked about, we are saying just like you can go and ask for a VM and you can ask for it to be highly available.

You can move it around. You can do all this dynamic workload balancing. Imagine you can just go and ask for a Kubernetes cluster, a Kubernetes environment that is just simple namespace.

These things are, um, something that an infrastructure admin just sets up as, uh, table stakes and you don't really start think worrying about. And, and what we have done in internally is of course made it highly performant on top of, um, the BSPHERE and ESXI infrastructure. So whether it is bare metal or not becomes a material, it's just easy and the dial tone is there, and then the question becomes, okay, how do you start using that dial tone that is Kubernetes?

So I feel like at this point, the Kubernetes dial tone is a moot point. It's like you either get it as part of your private cloud infrastructure with vSphere, or you go and get E-K-S-A-K sgk, these offerings have matured a lot. They're pretty good, and they are continuously innovating.

So for somebody to be sitting and thinking about kuber style tone and trying to spend in inordinate amount of effort on that is a waste. And then the question becomes, what do you do after that? How do you now connect the dots between the container on time and start putting services on it so that it becomes usable?

Right? I should not be, again, asking ever for clusters, right? I should be saying, Hey, this is my app and this is my intent.

So how do you define networking? How do you do mesh type of characteristics so that you can connect all these clusters? How do you define regions and availability?

That's where platform engineering power comes. We're starting to see some new folks hanging around the proverbial Kubernetes cooler, and it looks like AI workloads are becoming a killer app for Kubernetes, but we have all these folks who are, uh, data scientists and they're using MLOps to build these models. And then somehow or other we want that to get handed off to the DevOps slash platform engineering team and throw in some data engineers and a few security specialists on top of that.

How do we structure this so that it, it, it, it kinda works. Again, this is a philosophy that we have and it's changing, right? What, uh, we all are learning as we go, Mm-Hmm.

But I think we need to separate model development from model use in. And, um, I think if you start doing that, that becomes a lot. First of all, you have to think, you know, hey, how many people are actually building net models from scratch?

How many people are versus how many people are fine tuning with their context and then incorporating it into their business AppSec, right? We have got all kinds of very powerful models being innovated. There is a, and, and, and there are all these cloud services that are offering, um, AI ML services.

So when you do that, then you say, okay, of course, Kubernetes as a place to run AI ML workloads has become very popular, uh, at CubeCon. In fact, the keynote was AI m everything was about ai, ML and AI workloads. Now, if you separate and whether it runs on Kubernetes or not, once you separate those two, then you say, okay, what things can you do to help the model developer's life easier, right?

How do you do the data cleansing? How do you do the, you know, data engineering? How do you do the, um, fine tuning of parameters?

How do you do the closed loop cycle to get the model right? And then the second part is, hey, how do I let us say I have a model that is developed for a particular industry vertical, and it has got all the right data, everything. How do I start using it within my AppSec, right?

'cause model by itself does nothing. You still have to put it in context of the business AppSec or to their end customer in terms of the interfaces that you're giving to the customers and so on. And so, um, that is where I was talking earlier, we have done some amazing innovation in spring, uh, called spring ai, and now it is part of the Zu platform with, uh, spring accelerators and AI ML accelerators and tiles.

And the idea is how do you bring the power, power of these models that are being developed in Python, but to a Java developer, most of these enterprise AppSec, 50% of the enterprise AppSec are in spring and even more are in Java. And ultimately the data sits here, the context sits here, et cetera. So how do you bring that power?

So with bring ai, we have created these Java APIs that allow a Java developer to then access these Python models or other types of models that may be connecting to public cloud models, bedrock or OpenAI, any sort. So you are getting, making it easier from a usage perspective. And that of course, naturally fits within the platform engineering piece.

It fits within your, um, build and deploy infrastructure very easily. Do you think we might soon apply AI to the management of Kubernetes itself because, um, it's still fairly difficult and requires a certain amount of expertise. It's getting easier, but I can't help but wonder if, uh, maybe we can use AI to cure what ails us.

Um, absolutely. And we have already done that. So not just specifically Kubernetes, but uh, we launched something called as part of this tan zu portfolio, right?

We have really bought the tan zu platform together, right? The, the one that I've talked about it, and it's anchored by something called Tan Zu Hub. Tan Zu Hub essentially takes the data associated with your operational environment, your performance, your metrics, your logs, your information about your architecture, your dependencies of Kubernetes clusters to the, um, you know, virtual machines, if it's running on that or your networking dependencies.

And then we have a gen AI based interface on top of it where you, rather than saying, looking at red, blue, green blinky lights in a dashboard and then saying, clicking and saying, what went wrong? How do I solve? Often management is less about initial deployment.

Initial deployment happens somehow, but then the minute the next, you start deploying AppSec and, and now your latency goes through the roof, your logs are not getting collected properly. How do you debug all of that, right? That's where the problem start.

And so this AI ML interface, and we'll be happy to show you actually, or send you a video of it, allows you to just ask questions, Hey, which application is having trouble? Show me where the trouble is. And then it takes you to the right screens and walks you through the process and then also gives you answers on what you can do.

So while it is not a just purely a single but button magic, but the AI ML is a very powerful way to help humans interact with operational data. Operational data is fundamentally complex. And you shouldn't have to sift through operation data or write massive queries to understand operational data.

You should be able to talk to it. And that's what we have done with Council Hub. So Ultimately, what's your best advice to folks?

Or, um, since you've been around the block a few times, what do you see folks doing in the land of Kubernetes today that just makes you shake your head and go, folks, we need to be a little bit smarter than that. I think, uh, you hit it when you asked the first question, please go and understand what is the goal and outcome you're trying to drive. Kubernetes is not an outcome.

Kubernetes is a method to get to the outcome. And as long as we keep that sanity, you know, anytime, uh, technology becomes popular, everybody wants to adopt it. They just want, it's great on your resume, it's great on your skillset, but even on your resume, if you can say, not just that I know Kubernetes, but I have managed to use Kubernetes to drive this outcome.

Just even if you're thinking about your resume, do it that way. So the whole industry as a whole, and many, many do that by the way, but as a whole, as we, if we start looking at these projects and start making them outcome driven, right, that you're doing within your organization, that will actually drive a lot of value to you as an individual, but also to the company. Alright, folks, you heard it here.

Kubernetes, it's a means to an end. So start with the end and work backwards. Hey Pima, thanks for being on the show.

Thank you, Mike, And thank you. And back to you guys in the.