Platform Engineering and Kubernetes Adoption – Venkat Ramakrishnan, Portworx

This is Techstrong tv. Hey guys, thanks for the thrill. We're here with Venkat Ramer, Christen, who's Vice President of Product and Engineering for Port Works by Pure Storage, and we're talking about Kubernetes and the rise of platform engineering.

Venkat, welcome to show. Hey, Mike, it's great to be here. Um, and, uh, it's a fantastic topic, one that's close to my heart, so I'm, uh, let's get going.

All Right. How closely are these two things joined at the hip in your mind? We hear a lot about platform engineering as a form of centralization of DevOps, and of course, we have talked about Kubernetes and the single set of APIs for continuous delivery.

But, you know, are, are these two sides of the same coin? Ah, that's a fantastic question. I like the way how you framed it.

Uh, exactly right. Platform engineering is a, is a centralization of kind of mul. The, the DevOps is a practice, uh, into, you know, one group that manages the infrastructure, manages the, uh, the stem cell of the application stack manages the, uh, you know, the community's, uh, distro and developers access, uh, to the developer platform.

Uh, essentially providing, uh, you know, reliability, availability, governance, uh, compliance, security and cost control and observability and, uh, you know, all the chargebacks and show backs that, um, you know, that large organizations want. Uh, you know, an winter comes to Kubernetes, uh, Kubernetes, I look at it as the, uh, great unifier and the great democratizer, right? I mean, what I, what I mean by that is that Kubernetes, uh, kind of hides, uh, and, you know, uh, the, the different, the disparities in the underlying cloud infrastructure in a data center or cloud, uh, but also it flattens the arc structure in a way that, you know, your developers can simply build and deploy their apps and drive them in production like never before, right?

So, what happens with these two when they, when they, when both of them come together? Now, platform engineering organizations are, platform organizations are under a lot of pressure today, uh, because the, uh, most companies have centralized more, most large enterprises have centralized their, uh, uh, software operations, uh, under these teams. And they have been asked to provide a lot of services.

At the same time, they've always been also been asked to build these services agnostic of the data center or the cloud. So they can, uh, have the application agility, uh, to go from one environment to the other environment, or move one cloud to the other cloud, or even to be able to deploy their apps, the, the, their businesses build, uh, closer to their end users and customers. Uh, and almost always, these platform engineering orgs are understaffed that, you know, they are, you know, they're coming into the it, they come outta the GA budget many times, G and a budget, many times, they're almost always understaffed and they support large application development organizations, uh, uh, and support a lot of applications in production.

For example, I can give you, uh, an example of one of our large, uh, uh, telco customers, uh, has about, uh, uh, 10,000 to 12,000 application developers. The platform engineering a that supports all those developers is only 15 people. Hmm.

I'll let that sink in. Yeah. Right?

That's a huge imbalance. It's, it's a lopsided imb, you know, uh, uh, disadvantage on, on the platform engineering side. Uh, and, but they are all rising up to the challenge.

And with the help of Kubernetes and, uh, our partners who ship enterprise Kubernetes, uh, uh, offerings like, uh, open ship, they're able to rise to the challenge, run these, uh, applications in production, help their developers deploy and manage their apps in production without having to, uh, individually manage each application in production, right? And that is where the power of Kubernetes really comes in. And when they've now built it on Kubernetes, because it's, uh, standards and Kubernetes, the developers can self-service provision their apps and data, you know, when they run, uh, things, uh, on Port works, uh, not only that, they can also, uh, run the same application in on, uh, on a cloud or a public cloud or any other private cloud of their choice because, you know, there's no more, uh, expensive porting and, uh, you know, moving of the, uh, infrastructure that they need because the app and data move together, uh, when you combine something like communities and portex together, right?

So that kind of agility, uh, these developers and the platform engineers get. So this unifies, um, the need democratizes the infrastructure and makes the app and, uh, and the data a lot more agile than ever before. What is the right size for platform engineering teams?

Going back to your earlier point, because theoretically we were talking about DevOps as ruthless automation, and we don't measure things anymore by number of administrators per virtual machines. So what is the right kind of way to think about how many people I may need on a platform engineering team? Yeah.

You know, it depends on, uh, how well automated you are and what's your, uh, application stack and tool chain look like, right? If, uh, you know, for the emerging platform organizations, uh, I think a ratio of, you know, maybe a one or two platform engineers for every a hundred developers makes sense, right? But, you know, as the number of, as your platform expands, and as you onboard more number of developers, it's not a linear curve anymore.

So what we see the platform engineering organizations continue to optimize and automate their environment. So they make more and more of these application, uh, orchestration, deployment, uh, self-service, right? They, they, they, they offer them, start offering them the self-service.

So a developer can, uh, based on, you know, declaratively based on a spec or through a ui, can self-service deploy an app and, you know, from dev to staging to production and manage the entire, uh, deployment pipeline all on their own, a developer and application team. So the platform engineering team does not have to staff a per app. So, um, you know, typically what we see is that there are, uh, you know, a couple of folks involved, uh, in, in administering their, uh, servers of ems, uh, uh, you know, maybe, uh, at, in at least one or two team members on the networking side.

And, uh, you know, and, you know, one or two on the platform on the Kubernetes platform side and maybe one for security. And then, uh, you know, and then maybe, you know, and, and things like storage, when they deploy something like Port Works, they almost always don't need a dedicated person to run even in a large scale. So it's one of the cost savings we delivered to our customers.

So, uh, you can see that, you know, the ratio gets to, you know, one or two platform engineers per thousand developers at, uh, at scale. But it all depends on how mature that organization is and how much of automation they have deployed in their stack. That, and how much of self service they have enabled there.

Uh, uh, they're, um, uh, they're, uh, in their organizations, and that is why choosing, uh, the right, the right partner and the right, the right software vendor to be as part of that platform engineering stack, uh, is, is extremely crucial because the moment you open the fraud gates, a lot of these applications come in and you just cannot keep staffing up, you know, based on the previous ratios. If you go by, um, you know, one administrator for X number of VMs, I can tell you, uh, there's a customer of Port Works that runs about 15,000 VMs in production today, right? And all in all running communities as part of the Kubernetes platform and running Port works, right?

And this is not a scale that's managed by, uh, a large team of humans. It's a scale that's managed, uh, by a lot of automation and intelligence that you've built into the system that can, uh, you know, that can pretty much self-manage autonomously and heal and recover, uh, you know, at scale. We, of course, could say that DevOps exist because it was born of a, uh, reaction to the centralized IT mantras that were out there for ever in a day.

And now we're talking about centralization of DevOps. So, um, will people embrace this or will they resist? Because, you know, this is another example of, you know, central IT is here to help once again.

Yeah, that's a great question. And I, you know, and, and I'll tell you my perspective on this, um, I think it'll be, I would be wrong to say, Hey, this is where a hundred percent of the organizations are going to, right? I mean, there is a, to a large extent, uh, it's also dependent on the culture of the organization, the maturity of where they're at and how they want to transform what their vision is, right?

And like anything, one size fits all never works, right? In the sense that we cannot declare that centralized ops, all organizations should go there. And for some of the organizations, it may not be a good fit, right?

And especially, uh, for like, you know, what we have seen is if somebody is building a purpose-built, built, uh, purpose, uh, driven or purpose-built SaaS, right? Complete, uh, SaaS offering that's built on Kubernetes, but they're extremely careful on what what part of the app gets deployed, uh, in production. So they may not kind of let their developers completely run their absent production.

They may let give them some amount of self-service in their dev and staging clusters, but the entire application cluster is actually managed by a production support team that curates the, uh, uh, the, the, the binaries that go in after extensive testing and all of that. They're, you know, uh, uh, DevOps may still kind of more belong into the application teams and the production support and SRE teams manage, manage what's running in production, right? But in the case where customers have building largely digital experience for their internal apps or external phasing apps, uh, and these are, you know, disparate applications, uh, that are of that kind of come together to provide a unified, uh, customer experience.

Uh, and you know, when these applica, these companies are essentially kind of building platform as a service, that means, you know, there are, uh, hundreds of development teams with 10 to hundred developers each, that are working on either some of the common aspects, common layer that thread through all the organization, or have different application, uh, development and deployment needs, uh, that cater to a certain set of application use cases internal to the company or external to their stakeholders. Now they build on a common platform. And, you know, on those kind of companies, the centralized DevOps team becomes a lot more important.

Uh, and that's what we see. You know, we have, you know, customers in every vertical, uh, that I can talk about, large telcos, large automotive manufacturers, large pharmaceutical companies, large technology companies, uh, retail companies, you know, uh, and that are, and then, uh, we have companies in the, you know, in, in tourism and in, uh, in transport and all of them. So we see in every time when there's a large enterprise and when they're digitizing their entire enterprise and they're kind of approaching their business as a digital business, uh, the centralized platform team becomes more and more critical banking organizations and insurance companies.

Yeah. So that's where I would see it's a great fit. Do you think we fully appreciate the value of that Kubernetes api?

Because historically, every machine that we tried to deploy Somo on was a snowflake, and that's why we didn't really get too far with things like continuous delivery and some of the more advanced parts of DevOps. And now, are we gonna be in a different place where we have a unified api and I can do all kinds of interesting things that previously would've been just too hard? Yeah, I think, uh, I think overall I can say the community has done a fantastic job in, uh, in delivering a unified, uh, community's api.

Uh, I think C N C F has played a good, a good role, uh, as well there. And I think that the vendors have been extremely responsible during to the community standards of, uh, you know, of communities. So if you build and deploy your app on one Kubernetes dis, uh, you're assured, you know, uh, almost always that it's going to run another Kubernetes distro distro, and then you don't have to worry about the underlying infrastructure.

And in fact, port Works, um, you know, kind of, uh, sticks to the same philosophy as well as that you build and deploy an app on port, works on one infrastructure. Uh, we unify, we're not too opinionated on which infrastructure or distro we run in. As long as you run us there and the other infrastructure, we make sure you get the same experience.

So from that standpoint, I think the standards, uh, the, the, the, the standardization of the api, the uniformity across different deployments, uh, and the consistency has been really solid across, uh, across a lot of implementations. Um, and the proof is in the pudding, right? I see customers deploying Kubernetes everywhere.

We have customers, uh, retail customers who run three or five node Kubernetes clusters in their stores, and they have, they run a manage, they, they, they leverage a managed humanity service on their, on the cloud, you know, but they're constantly either tiering their apps or they're pushing more data to their cloud for further analytics, or they even use the cloud to test and dev and then production, deployment on edge without having to worry about all of the porting, uh, uh, nonsense we used to have before when we went from different one environment to the other, right? And I see that, uh, you know, in other industries as well. So I think, uh, from that standpoint, from having the, you know, like, uh, the uniformity, um, I would say the industry has matured a lot over the last couple of years, a few years.

Where do you think AI will fit in this equation with platform engineering? We've been talking about AIOps for a while, and now of course you can't wake up without somebody talking about generative ai, but, you know, what is the future of it and ai? Yeah.

Uh, it's a very, uh, it's a relevant question for the times we are in. So, um, I do believe, uh, there is a, uh, there are two ways AI would fit into this. One is, uh, I think we can make developers' life easy, uh, which, uh, you will see some interesting announcements from us in the near future on how to leverage generative AI to, uh, simplify the deployment specs or the database access and kind of kind of, uh, kind of give them like a, a game, a DevOps co-pilot, uh, you know, that kind of works with them, uh, and makes their life easy, right?

On, on, on, on. Like from a, from a, from a, from a, coming from outside in as a customer, as a user. So delivering better product experience and more intuitive product experience and more assistive product experience to our, uh, to our, to our, to our platform engineers and developers, uh, on the, on from coming from inside out, from bottoms up, like the innovation side.

I strongly believe we can leverage AI to, uh, uh, to kind of be a platform engineers assistant. Um, you know, that, uh, that monitors predicts trends, recommends actions, takes actions based on previous, uh, trends of what actions were taken for similar, uh, similar issues or similar, uh, signals. Um, you know, and asking for permission before doing so and reminding, you know, like, you know, kind of like being a, uh, almost live assistant that can, uh, significantly ease the pain of administering large scale, uh, uh, platform, uh, uh, uh, deployments and, you know, kind of like kind of being that, uh, i in the data center or in the cloud that, uh, that assists our platform engineering, uh, customers.

So I do see in both, uh, both ways, uh, AI is going to en enhance, uh, the customer experience, uh, our customers or the platform engineers and platform teams, their experience significantly and is going to help augment our customers as customer experience, which is a developers and application architects and application teams experience significantly and simplify their workflows. So I do believe, uh, we're in the golden age of ai, uh, and I, I do believe strongly that it's only going to deliver richer and richer experiences, and I still believe the threat of Skynet is not there today and likely will never be there. Uh, you know, and like any new technology, everybody's scared, or either they doubt it or they believe in it, and they're almost always on two extremes.

But I think, like anything, we'll find the right middle ground, uh, that advances, uh, our everyday lives much better than before. So you don't seem to envision DevOps roles going away anytime soon, but they clearly are gonna evolve. So what do you think the life of a DevOps engineer is gonna be like in a few years?

Yeah, I think a DevOps engineer will be able to go to a football game without worrying about, uh, their infrastructure blowing up because they have their assisted little ai, uh, helping them out, uh, knowing their calendar schedules and when they're gonna be out and when it needs to be alert, and when it needs to spin up more instances. So it needs to monitor the scale and all of that. Uh, so they're going to get a better life ex richer, richer experience of their lives and better work-life balance.

Um, I don't, I don't think that they're going to be out of a job, because if we are in the knowledge business, and, uh, I think, uh, you know, humans, uh, are, um, needed to be able to, uh, uh, map to, uh, kind of their, kind of what humans have is this, uh, immunity we have developed, uh, or many, many generations and exper of experience and knowledge that they have been transferred over, that we can look at something and map that to, uh, you know, what else can go on and predict how things can, to an extent evolve. Uh, and that kind of experience is hard to build in that's reliable, that you can say, and my AI is going to manage my mission critical payment infrastructure, and I don't need any humans to do it. Uh, will we get there?

Um, you know, I never say never, you know, and I, I will never bet against technology developing there, but I don't think that is immediate threat. Uh, yeah, even if it gets there, I am pretty sure there are hundreds of other higher end roles and high value roles that our DevOps engineers can, uh, will end up doing anyway to add more value to their businesses and to their platforms. So, uh, either way, I see it as a technology that's going to just provide, uh, richer product, customer and life experiences, uh, for everyone around us.

All right, folks, you heard it here. We're all going to get digital DevOps buddies and go from there. Ben Kath, thanks for being on the show.

Thanks, Mike. Great questions. Always happy to, it's always great to talk to you.

Thank you. All right, back to you guys in the studio.