Composable Platforms Evolve with Pankaj Gupta | Platform Engineering 2.0 Ep 6

0. You're about to see our episode six, which is our final chapter in this series. It's been a great series though.

tv, the Techstrong TV YouTube channel, the Techstrong TV app, which is available for iOS, Android, Apple TV, Amazon Fire Stick, and even Roku, so wherever you'd like to watch your videos. My co-host for this whole series, and I thank him for sitting through it with me, and really, quite frankly, he did a lot of the heavy lifting here, so I appreciate it, Pankaj Gupta of Broadcom VMware. Pankaj, welcome back.

It's great to have you here. Thank you. 0 thesis whitepaper.

org through there. Before we jump into pillar five, which is composable by design, Pankaj, would you mind giving people a quick recap, kind of what they missed so far? Sure.

In the previous episodes, we talk about that platform engineering adoption is almost near universal, but challenges remain ahead in terms of the maturity of platform engineering in every organization today. 0 has a great objective, and they achieve extremely well for increasing the developer productivity and simplifying the processes and streamlining the taking code to the production. In last few years, market has evolved significantly, mostly driven by the AI and agentic AI growth for that.

That is also creating new challenges for stronger security, multi-persona experience, as well as for a stronger FinOps requirement for that. 0, which is a evolution, not a reset or a refresh over here. So it's just a evolution.

We covered the four pillars of AI native platform, the multi-persona experience, embedded FinOps, and security shift down to complement the security shift left. And the last pillar, which is also very critical, how the platforms evolve into the future, is the composable by design. Excellent.

Great lead-up, Pankaj. So let's look at this word composable. It has become a bit of a buzzword, right?

" Right? Because it's like one of these AI tells, if you will. But what do we really mean when we say composable, beyond the buzz, right?

What does it mean? You are absolutely right, Alan. The composability is not a new concept.

It has been very long time, at least for two decade in the industry. What it basically means is that you should be able to mix and match the best-of-the-breed building blocks of any infrastructure for that. These building blocks layers are connected with a very well-defined contracts.

Those contracts could be policy, that could be the SLAs connected through APIs for that. And organizations like CNCF is doing a tremendous help to have the standard APIs versus in various building blocks for that. Talking about the CNCF, you have also seen the number of projects which they had 10 years back from 50.

Now there are 250 plus for that. There are multiple choices for CI/CD too. There is a multiple choices even for CNI for that.

So developer should be able to change or evolve independently each layer of the platform without affecting or cascading the change across the other layers for that. If you look at the platform engineering today, they are kind of a simplest way, there are five layers for that. One is the infrastructure layer, integration layer, capabilities layer, the orchestration layer, the experience layer for that.

Let's take a case in example for that. In integration layer, we have seen the new integration parts to be evolved and integrated, like MCP servers, MCP gateways, AI gateways. So that's what we mean about the composability.

But more important part also over here, that you should be able to change one component to another component, like moving-- We want to be able to change Jenkins with the Harness CI/CD tool, I'm just making this example for that, without cascading the changes for that. 0 has to deliver to the customer or the IT organization, is repavability. When you change one component to another component, you should be able to rebuild your platform confidently and quickly, and you should be able to run pretty quickly for that, with lot of confidence for that.

You should have a mechanisms to measure the performance or the satisfaction if I choose one component versus another component. How do I shift traffic from the one component to the newer component or the building block more seamlessly? So that's what the repavability really means into that.

How I see for composability that there is two choices today in the market. Most of the time, just many times customers or IT organization build their platform. Many times they just buy the platform, which is very highly curated and opinionated.

And both will continue, but very advanced customer, very progressive customer, they will compose their platforms as you move forward, and their state of platform will continue to evolve with newer component as new tools, new technologies come together. My finest example is if, Allen, you and me talked same time last year, we were not talking about the MCP servers. Now they are such a critical part of the- No, and more, just every day they're getting more and more embedded Yeah.

So this is a very simple concept has been there, but the need for composability is continue to evolve, but the bigger ask is going to be repavability. Yeah. So let me see if I could sum this up a little, Pankaj, and come back to you, Heidi.

First of all, you're right, 250 projects plus at CNCF. We'll see you more at KubeCon. I think we'll see you there.

We might do something special around this at KubeCon. But it is complex. Choosing, as you said, whether I'm picking a service mesh or I'm picking the CI/CD or observability tools or any of it, it's complex.

You're 100% right. This whole area, though, of genuine, not just mouth talking, saying repavable, but genuinely repavable, it's easier said than done, right? It's easy to say it.

And then I call it paralysis by analysis, right? When a platform team, how do they decide what to prioritize, what to modernize first, where to go? How do they do that?

I think that's a huge question for that. This is the question at C-suite today. This is the question for platform engineering.

But I think that every board, every CIO is really asking that what is the next AI milestone for any organization for that. I think it's the simplest way to start there for every C-suite is that set a 12 months AI native platform milestone for that. Once you have milestone, they will note that do I need it?

The bigger requirement right now is it the AI native platform? Which personas have a bigger or prioritized needs for that? Is FinOps is more critical on day one versus the security requirement for that?

Or is it the composability? I think this answer will vary from each organization. 0 has to be implemented now.

And that cascades from there to the platform engineers. I think many of the modern organization for platform engineering is really looking how do they prepare their platform for agentic infrastructure for the future for that. And it is also a huge culture, the skill gap requirement, which every CIO, CTO absolutely knows about, even the board require for that.

Many of the AI and the agentic, it's learning for everyone. Yeah. Absolutely.

So I think you've made a good segue into our wrap-up, Pankaj, which is the call to action, right? How does a platform team prioritize, right? 0?

We laid it out, five pillars, right? And we're not saying any one, which one is more important. Well, that may be up to your particular organization and your needs.

But as far as what you've seen, because you're out here, you talk to real people. Which of the five pillars tends to unlock the most value the fastest? Where's the most bang for the buck for people out here looking to make a splash?

It's hard to answer, and it's a very tough question. I think the power of these five pillars is collectively. Where do you start?

Which is a bigger priority? That's a individual organization's call for that. Like some organizations have already moved very significantly for AI workloads already.

For them, tokenomics is, or FinOps is very critical. If they have been recently breached or seen that, then the security shift down becomes a bigger requirement. But overall for bulk of the organization, I see if they address the AI native platform requirement Identifying which personas are more critical for them to support.

We have now six personas, five human and one non-human. The developers, the platform engineer themself, the business and FinOps leaders, the ML or AI engineers who is going to develop the applications for that, and also the security or SecOps and compliance team. Those are the five human personas, and the fifth persona is this agentic AI.

So that will depend what the company's priority is and which persona they have to address first. Absolutely. It's again, evolution.

It's not a snapshot in time. No. And evolution's not necessarily linear, right?

Sometimes it's a cha-cha, two steps forward, one step back, right? Back and forth. But when you look at it over the arc of time, you see the progress.

I've got to ask you, though, the counter question. Has the remit for platform engineering gone too far? " Now we're talking about, well, do we run it at the hypervisor level with a cloud native, AI native on top of that?

And now we're talking about these five pillars with FinOps and security, because security always needs to be in there. But all of these things, this looks like mission creep, scope creep, right? The way I used to call it when I was running my own companies, building product.

How do you answer that, Pankaj? You are absolutely right. I think the biggest challenge with CIOs, CTOs, and IT leaders is the phase three is, one is the cultural shift, the second one is complexity, and third is the cost.

Yeah. Wherever you go, these are the top three requirements: the cost, complexity, compliance. Yeah.

And compliance is governance. Yes. Yeah.

Agreed. Hey, I got one last question for you and we're going to wrap this up. Take out your crystal ball.

What do the next 12 months look like for teams that act now versus those that wait? I think the next 12 months is going to be fundamental shift on two parts. One is the stronger FinOps and a stronger security for AI and agentic AI workloads.

0? Don't know yet. Well, that's a good place to end this.

Pankaj, I want to thank you so much. Look, this took a lot of time, and you did a lot of the homework and a lot of the heavy lifting. Appreciate it.

We hope you've enjoyed this as much as Pankaj and I have enjoyed having these discussions. Again, go check out all six episodes. There's a lot to digest there.

They're on demand. You can read, you listen and watch at your own speed and take it in as you can, but do take them all in. They're all good.

Pankaj, again, thank you to you and to Broadcom VMware for working with us on this. Stay tuned. 0 stuff coming out.

We're actually doing a survey right now. com, you'll see the survey as a pop-up there. We could always use more input as we continue our research there.

We will be at KubeCon, right? And we will be discussing this at KubeCon. So if you're going to Salt Lake City, please stay tuned for that and we'll be making some announcements.

But I think that's it for now. Pankaj, I'm going to give you the last word. Thank you for having us.

And it's a evolution, and every platform engineering should read the white paper and figure out what is next for their platform evolution inside their organization and how they can be the catalyst of change. Thank you. You're watching Techstrong TV.