Platform Engineering 2.0: Just-Enough Kubernetes and AI-Native DevOps - Shweta Vohra, Booking.com

In this session, Shweta Bora discusses the evolving concept of platform engineering, emphasizing the need for clarity and purpose in its application. She shares her insights from her role at Booking.com, where she builds scalable platform ecosystems for global travelers. The speaker highlights the common misconceptions surrounding platform engineering and explains why many organizations struggle with it. She introduces the idea of platform engineering 2.0, which focuses on creating platforms that provide stability, integration, and consistency, moving away from merely assembling tools. Shweta presents the V Arise model, outlining five essential parameters of successful platform design: adaptability, repeatability, integratability, self-sufficiency, and ecosystem enabling. The talk culminates in a discussion of architectural shifts needed to enhance developer experiences, advocating for a system where developers express intent rather than manage complexity.

Platform engineering is everywhere right now. Everyone has a platform and everyone seems to be building one. But the most uncomfortable question is are we all really talking about the same thing? As they say the map is not your territory. Just because we call something as it doesn't mean it'll start working behaving like one the other day. And that's why today I want to talk with what platform

engineering really means why do so many uh organizations struggle with the and what platform engineering 2.0 looks like. Hi everyone. I'm Shweta Bora. I'm lead architect with booking.com where I build and scale platform ecosystem that works on highly distributed and real-world environment. And the best part of my job is that it really enables millions of travelers across the world. Now, over the years I have seen and

worked with platform teams where they have poured their hearts into building platforms but still users and developers find it difficult to use. I have felt that frustration because when something is meant to be simplifying things but it adds to the complexity. On other hand I have also worked with platform teams where platform just works. And suddenly teams move faster and take better decisions. And this talk is

actually coming from those moments of building, breaking, and rebuilding platforms. Now, let me share with you something which I have seen coming over and over again. A few months ago, I was working with four different teams. Each of them told me that they have a platform, but when I looked underneath, I found that they all of them are talking about entirely different things. While none of them

were wrong, but let's test it together because I'm sure you must have also be seen that. So, tell me how many of you have seen this. We are using 80 plus open source tools. We have a platform. Anybody who has seen this? Okay. Let's test this. We built a developer portal. We are platform engineering team. Okay, more hands going up. Nice. How about this? Kubernetes is our

Or we renamed DevOps to platform engineering, the classic Wow. And the interesting thing is none of them are entirely wrong, but none of these even help us telling that what platform engineering really means for them or what it is. what we need to do is before we go to platform engineering 2.0, we need to establish a baseline. Because platform is certainly not collection of tools. Then what

is? To establish that by baseline, I would say if platform is something which elevates you with stability, clear integration, and consistency. If it does that, it's a platform. If it doesn't do that, it's just another piece of technology often unfinished. Now, let's make it real with two examples. Take Netflix. Over the years, Netflix given on one side their viewers the experience of movies, um series, or various

other content what they release. On other side, they have enabled through internal capabilities the creators and the partners vendors who hook up their content on their platforms without knowing the underlying complexities. Definitely over the period of time they would have just scaled from movies to much broader ecosystem, but you'll never hear them saying that we have 100 plus tools. Rather, you'll hear them saying we have experience

and we have capabilities. Now, because we are technical audience, let's take another example. Take Linux or any other operating system which you appreciate, which is one of the oldest and most foundational platforms we have. over the years has consistently worked for the vendors, be it cloud providers or um enterprise ecosystem or any other new platforms who build on top of it. Because it is so much integratable,

that's why people were able to build on top of it and it just worked. Not because that it is fancy or complex or has many many tools underlying it. we are using it even till date as the core for many many things. As simple as my platform, uh my laptop which is showing this presentation and it's working. Unless until I jinx it. So, the big question in

the room what platform engineering is? Platform engineering is the discipline of building that platform which starts with core business domain. At the bottom of this image, you see that one where core business need. Because without having a goal or without having a purpose, you may build something useful but may not be platform or may not be of value to anyone. Once you have that need defined, then

you need to go and have your platform strategy uh business models, which is very important because same thing these days you can serve through various business models. You need to really decide that whom you're going to expose it to, how much you're going to expose it for, what the government's governance will look like and how would it evolve. Once you have that clarity, then comes the experience

and economization, which is the third part of this. Now, I might be very much interested in giving my user base rocket science experience, but that may not be affordable, operationable, evolvable, so I cannot give that. So, that's the place where you decide that what kind of experience is right for developers, what kind of of experience is right for other users. And based on that, you decide your

technology strategy, then the tools come. Then the things come that how this whole tools will work together and integrate. And on top of that, you do your with that all base, you do your design and architecture. And that then it comes to the whole circle of development and operations, which is only part is understood as platform engineering. Now, these are the six sides of the success blueprint.

And you need all of them to come together to build really useful And if you don't do that, you might still make something useful, but not a now I want to give you something really powerful. It's the V Arise model. It's a lens. Once you see it, you will never be able to unsee it. And we will have a use case and a demo use case with

it which we with which we'll prove it also. This lens gives you these five parameters, which is adaptable because your platform has to be continuously evolving around your requirements, teams, and changing technology. It has to be repeatable because this needs to be stability stability giving the stability and consumable in the same way for different contexts. It needs to be integratable because without that, how will your teams,

tools, workflows will hook up to that without getting that friction? It needs to have be self-sufficient because that's where you will provision, operate, and provide that value which should not require your platform engineers or platform teams to be present there to give that value. Otherwise, that becomes a bottleneck. So, it needs to be self-sufficient without having the platform teams being around. And it should be uh uh

ecosystem enabling. Because platforms are meant to be foundation. These are not just systems. These are ecosystem enablers where all things you do on top of it becomes another pattern innovation or many more things which come out of it. Now, the catch-22 here is you will see and you need to have all five of these parameters to say that this is the Otherwise, if you get one, two,

or three of these aspects and not all five, then something is missing. Now, let's move on to platform engineering 1.0. Platform engineering was born out of a need when organizations realized that they need to standardize infrastructure. And that's where a lot of sophisticated stacks were built on top top of Kubernetes or along with Kubernetes. Each of these tools or open-source projects brought something useful, but together they

have created something different. more tools we adopted, more the complexity curve go grows because operational complexity grows with time. And that's why platform teams became those teams who are just stitching all the time things around. Because they have so much to stitch. And that's where it lost somewhere in between. And the problem is the exposure model because everyone has exposure to Kubernetes and all the underlying details.

Now, in platform engineering 1.0 workflow looks like this. Developers write the configuration, the infrastructure configuration. Platform translates it into cluster language and then Kubernetes gives you those capabilities and Kubernetes becomes the interface for developer. Which is a problem. Because you're exposing too much, which is not required. Now, the shift in the platform engineering two comes is developer expresses the intent and platform translates it into actions automatically.

And Kubernetes is still there as an engine, but it's not the interface. And that's the shift we are talking about. Just enough Kubernetes. Which means you are deliberately choosing how much of Kubernetes you need to so that developers get to see as much as needed for their work. Whereas platform engineer may work on various other layers. Now, this is the Kubernetes exposure gradient which further tells us

that things start at level one. Now, at level one you are we have full control. We are giving the full power of Kubernetes to everyone. More work, more complexity exposed. Then we standardized more. We said templates. And templates solved the problem of knowing what to follow, but it was still too much of exposure. But then golden paths, we said, which further reduce the complexity because you said

that these are the treated paths, these are the safe known paths which developers should take. And then comes the level of automation where it is at capabilities. Level four is about where capabilities where most developers should sit. Because they need to be exposed to as much as they need for their role or their work to be done. They should not be worried about how does things happen

in your engine below. They should be expressing the intent and they should get what they want. So that's how the exposure model looks And quickly the platform engineering 2.0 architecture where developer speaks developer's language on the first layer. Platform control plane translates it to infrastructure language and does those automations and workflows for you. And infrastructure engine gives you those facilities which is required. Again, the exposure model.

You're not exposing everything. You are giving developer what they want, what they speak, the capabilities. Now, let's take a use case, platform engineering 2.0. Let's put it into action. Let's say a developer needs a API inference service. Now, what they should do is they should express the intent. They should get all that workflow underneath prepared for you, prepared for them, sorry. And then you create the lean

infrastructure what they need. That's how you can give them quickly. But how do you achieve it? I'm proposing here one particular stack, but actually this is not fixed. You can do your own permutation combinations and better than this. If you come up, please let me know also. We are using here Okay, before I tell about those four Now, this is something um we all have scars from.

50 plus name spaces, 20 plus CRDs, hundreds of services, all in one cluster or multi-tenants cluster in various forms, shared tenancy we have one runaway sidecar, one bad rollout, or one bad config map brings uh down the experience of developer experience for How many of you have seen that with your work? Right? I've seen it. So can feel you. Plus so platform 1.0 scaled the cluster. In

platform 2.0, we focused the how do we achieve it? Instead of putting everything into one big messy cluster, give lean infrastructure by using KAS K3S. K3S gives you those capabilities in form of cells. Those cells can themselves be those clusters which are spinned up by your control plane. And because these clusters are disposable, if anything goes wrong, you can replace and bring up the other one. Or

if you need to patch anything, you need to upgrade anything, you can do those replacements easily because you have that lean infrastructure now. that's how you can also achieve the resiliency which otherwise becomes a problem with those uh heavy clusters. Next comes the ambient mesh. Now, service mesh solved real problem, but it came with heavy tax. Tax of those sidecar injections, which with every pod you need

a sidecar. means that you need high CPU, more latency, and more complexity operational overhead again. Which ambient mesh, or you can pick up your favorite replacement of ambient mesh, but it solves it by replacing it with a different layers. This still gives the same developers observability, routing possibilities, and scaling possibilities, but at a different layer. So, developer is is doing just enough Kubernetes what it needs. And

the third piece of this puzzle is gateway API. if my developer needs to have a canary deployment, 10% of traffic routed, it just needs to express that intent. gateway API and your control plane platform control plane take cares of that what below this pyramid, what all lies your gateway, gateway class configuration, and how it gets set up so that you offer that uh thing to the developer.

In platform engineering 2.0, we are not just scaling, as I said, the clusters, we are closing the loop. Because let's take one example. Let's say Prometheus detected that uh one of the memory is having a memory growth in one of your Now, it collects all those signals and feeds it to your AI model or your That control plane detects the anomalies and inefficiencies. Very first thing control

plane does is it separates out your that cell or cluster. And then, it replaces it, brings back the traffic to the newer This is how we are closing the loop of getting the things taken care as well as the newer capabilities being offered without going into all that hell. what is the actual implementation of it where user sits and expresses intent on the top. Your right side

is your shared managed plane, which is giving you the gateway API and the mesh capabilities and all the networking possibilities what you want to place there. These cells are nothing but your mini clusters because these are powered by K3s and K3s is um like your full Kubernetes capability, but without overexposing things to the people. That's why it's lean and lightweight. And if anything goes wrong with one

of these services, you can easily replace them. This is how we are putting it together. in platform engineering 2.0, Kubernetes won the infrastructure war, but it should not be the user interface. What What we need instead What we achieve is composed capabilities and re- reduce cognitive load, lean infrastructure, which is what I'm calling as just enough Again, to reiterate, platform 1.0 scaled the cluster, platform 2.0 scales

the capability. Hope that makes sense. I think with that I'm done. I don't know how much time I I still have 7 minutes I can see. If there are any questions, and before that, if you don't mind, can I click a pic with you all? Thank you. Any questions? Any Yes, please. I have a question regarding storage again. So, I didn't I saw you using CPU or

GPUs as a flexibility, but it you didn't talk about the wanting to have file storage, direct local storage. Is that not part of the equation, or could you add that later? It certainly is, to keep the use case complexity to the level where I've not brought the data databases there. Even K3s can have it, but you would part out those functionalities to those cells which can afford

to be isolated. That's where cell-based architecture works, right? So, that made me not bring that into this use case. But, it's pretty much there. Uh yeah. You want to ask on mic? I have I have another question. Yes, please. >> Um yeah. Uh apparently there is um organizations that don't have a platform, um, if they were here in the room, what would you say to them and

why should they or should they not adapt platform engineering? Thank you. Very good question. I think more people should ask that. It's not necessary that everyone needs a platform. It's a fancy word these days, but the question you should ask is that um, is there anything which can be made foundational which makes people's life easier across the company? If answer is yes, maybe that's an opportunity to

start looking into what is that and then one way of easy way of solving it is that, okay, automate it. But we need not label it as platform. If you really feel that yes, you need something which has to be abstracted out and, um, needs to be built as platform with those five capabilities which I said, then yes, why not? Because platforms, as I said, are not

just for systems. They are for enabling the whole ecosystem. I can give so many examples around it. You use App Store or, um, these Galaxies, right? So, it's it's Apple's way of giving outside to the developers who want to build on top of it. But they would never say that Kubernetes infrastructure cluster is installed in so and so region. So, that's where they are. So, figuring out,

I mean, it's fancy just because it's fancy you want to adopt it, that's not the reason. But if you see that there are certain patterns in the company where you have those opportunity, it is worth looking in. Hi. So, my question is for those of us who use managed Kubernetes, EKS, AKS, that kind of How do you How do you propose dynamically deploying K3S in places. Do

you run that as a pod inside your EKS cluster? Do you have an auto scaling group uh with like some image that already has K3S installed? Like how do you propose doing that? K3S is a is a full cluster on its own. It just that it gives you those capabilities what you need without giving you the bloat. Now, if you are using managed is it a problem

for you working with that stack? Is it like um are you more focusing on those capabilities or are you more focusing on the infrastructure requests and time going more there? If if time is going more and platform is not serving you the then yes, ask them to give you those options. And this this can be achieved through various other ways. I mean, it needn't be K3S in

your case. It could be any other lightweight option. do you see do you see it coming from the problem space or you just want to explore it? No, I'm just I'm just curious. I have never used K3S. Okay. But I am might >> That's why I said K3S is one of the options which I'm saying may not be suitable for everyone. And but yeah, do experiment with

it if if they allow you manage service people. Hello. Hello. Um I'm interested in the S in arise. Um self-sufficiency sounds like it's much more than just um the obvious answer to have self services. So, what else is there? That can be done. Um I I need to know more from you. What do you want to know because you've expressed the arise and you're you're focusing on

self-sufficient, but I'm not getting your question. >> Yes, one of your answers is to have self-services. So, that's so that the users can just do everything on their own. But, what other mechanisms are there to make the system self-sufficient? So, I said self-sufficient, not self-service. Yeah, yeah. So, self-sufficient By self-sufficient, what we mean is See, platform needs to own one functionality really solid. For example, Netflix we

said does the video streaming and is it does that really well. Linux is meant for operating system, device management. It does it really well. So, that's what I meant by that whatever you build the platform for should not be like I cannot work if I don't have this project, this open-source tool, this open-source tool, then that's not platform. Kubernetes in that sense is not a platform, by

the way. I know some people not like it. Any other questions? If not, thanks for listening. Have a good rest of the evening.