Platform Mesh: Breaking API Lock-In for True Multi-Cloud Service... Mirza Kopic & Mangirdas Judeikis

In this talk, Mirza Copić and MJ discuss the challenges faced by platform engineers when building and integrating various platforms, specifically through the lens of Platform Mesh. They explore the complexities of dealing with multiple service providers and their unique opinionated management APIs, which often leads to vendor lock-in and fragmentation. The speakers introduce the concept of a resource broker within the Platform Mesh framework, designed to simplify the management of services across different cloud providers. This resource broker automates the migration of resources, handling underlying details to improve user experience. They emphasize the importance of Kubernetes in orchestrating APIs and propose using existing Cloud Native Computing Foundation (CNCF) tools to build effective solutions. The session concludes with insights into creating a cohesive architecture that transcends individual provider boundaries.

Thank you all for being here. We really appreciate that your time that you've come today. My name is Mirza Copić. I'm from SAP. With me here today, I have MJ from Klaisso. We are both developers that work on Platform Mesh and we want to tell you a little bit about Platform Mesh and some of the problems that we have when building, you know, platforms. I mean, a

lot of you are already platforms engineers and you probably have already have faced these issues as well. Now, one thing we wanted to say also is that we do realize this is an advanced track. We are going to talk about advanced problems, but we do want to present them in a way that are actually useful and so we will go over it in very simple terms, but

we hope that they actually see that this will also help us and be useful in for the future as well. Another thing that we want to mention also is that Platform Mesh itself is a project in the New Native Foundation. So, if you have questions, please stop by at the New Native booth. We also use other projects in CNCF and we are also at the KCP Pavilion

as well. Now, with that said, there's the elephant in the room, of course. Yes, we are building yet another platform. As a matter of fact, we are building a toolkit for building your own creating your own platforms. We are aware even AI says that it's one of the synergy words of the 2020s, you know, a platform that literally means everything and nothing at the same time. It's

one of those keywords. But ultimately, the tooling is important. You are platform engineers, we are platform engineers. We need to get around it. We have to solve some problems and the way we do this is through platforms. Platform Mesh itself uses and builds on existing toolings that are in CNCF. So, I mentioned Platform Mesh is part of the New Native organization, but we work also and contribute

heavily into KCP. We also work with Kubind as another project for integrating Kubernetes APIs and of course multi-cluster runtime that came out of KCP itself. So, if you have operators, you want to target multiple clusters, you use the multi-cluster runtime, and there's a new thing for that as well. But what we do, of course, is we take all of these tools, these KPI this Kubernetes API machinery,

and try to solve the problems that we have in platform as a service with them. Oops, it's a little bit too fast. Before we go into a little bit about the problem space that we have within the platforms themselves, a little bit of an introduction about what we tried to do, and we presented the platform as a service last year as And it primarily goes into this

heterogeneous landscape that it currently exists, where you have many different administrative domains of APIs and services. So, what do I mean by that? You have this continuum, where you have a lot of different software providers and hardware providers, infrastructure providers essentially, um and they build services on top of that. But every one of those services is an opinionated management API. So, we're not talking about, you know,

an S3 bucket that it has in a common API, we're talking about the management API for that bucket. How do I get this original bucket in the first place? If you go from one provider to another provider, you essentially have vendor lock-in. You have an API lock-in, you're tied to that, and it's very difficult to do this. So, ultimately then, for you as the platform engineers, um

even as the consumers of those services in your platforms, the responsibility and the heavy burden of the complexity lies with you. You ultimately have to implement You're the one who has to know an opinionated management API from one platform provider, and understand an opinionated management API from another platform provider, and you have to bring your team up to speed on that. If you add another platform and

another service from a different provider, yet again, you have a third flavor in there as well. And it's very complicated to do Because it creates essentially fragmentation. It also creates lock-ins for you. It also creates snowflakes that are there and ultimately difficult to work with. And that's really where platform as a service tries to come into that. We're saying that there is a problem in this space.

We're trying to solve this. We see that when you look at the existing landscapes, there is already some paradigms from cloud native and open source engineering where a lot of it is using Kubernetes. So, why not use the Kubernetes API not just for workload orchestration, but for orchestrating those APIs themselves, those services that can be represented using Kubernetes resource model. Those orders themselves then can be fulfilled

by those providers. The management of those APIs, the APIs export and import. And of course, before we go into how we do that, there is obviously a very important question in today's age. The question is that, well, if you have so many different APIs in the age of AI, does it still really matter? Yes, it does in my opinion. I mean, it is just my humble opinion,

but I believe that if you have a Kubernetes resource model as the underlying architecture, you have a structured way for APIs to make sense of. You can use API compositions on top of You can make use of already existing knowledge that you already have. So, you already know kubectl, you already know Kubernetes. There's nothing new there for you. We're just presenting it in that form that you

can then easily consume. And the same thing is true for AI as well. Now, coming back to the actual problem space itself within the platform. So, we've talked about there is the whole continuum, the multi-provider cloud edge environment that we have. When you then start implementing those APIs, there's a smaller problem that's also available within the platform itself. And this is a question that comes from you,

from the community. I got this question last year as a matter of fact at many presentations. And that question is that, if I order a service within platform as, I get a specific API that presents that resource, but I want to switch to a different service provider of that same API, I have a different API version. How do I do that switch? I have to do this

today manually doing the yellow myself or I can get an API to do it for me. But there's a bigger issue of lifecycle management of that resource. And that's what we're getting at today with the resource broker in platform as. And exactly that's what we wanted to discuss with you is how do we make the transition of some of those resources? Imagine you have a resource that

is coming from a sustainable compute provider. You want to switch the next day to a more performant provider because you have the necessity. You've scaled that much, you originally you have sustainable compute because you cared about the ecosystem. You say cared about okay, I don't care so much if it performs as long as it runs. But once the need is there, how do I switch that ephemeral

compute from one provider to another provider? And you can do this through the platform as. You can do this through K R and S essentially. We'll also then talk about more specifically of the scenario when you have multiple services and multiple providers or even multiple platform as. That's the most important one as I think it's most challenging that we're going to go through. And we'll have a

small demo that MJ will show us how we're implementing what we call the resource broker in platform as to try and address these specific issues primarily. So, the first part is that there is no consistent way to consume those services across the continuum. And it reminds me a little bit about the three vendor problem. We've also referred to this one of our previous slides at KCD in

Geneva where it says that the more vendors we have the more problematic it is to maintain. So, we're not saying that we have a perfect solution for this. We're trying to say that we're trying to build tools to make this easier for us to implement and maintain. We have to live with this ultimately. And when you now as developers or as architects, you know, you're giving a

set of tools. There was a previous talk by MJ in 2024 that I essentially went through this also with uh, Stefan and Sebastian where they essentially had a very nice analogy and I think that fits in here very well. And the analogy is that, well, you have as platform engineers a lot of tool sets available to you. You have many different building blocks. You can build all

of those things. So, if I ask two different architects and give them the same tool set and say, "Here is the problem. I want you to build me a platform that does XYZ." and gave them the same uh, tools, they would implement it differently. But the reason for that is that I really want something more of a grown-up approach. I want to have something that has a

goal in mind that says that we are all building towards the same end goal and the path that we take should be similar. It should be predefined. There should be some existing building blocks that come straight off the shelf that makes it easy for us all to get to there the same way. when you look at the landscape that you have, if you try to build a

platform, you know, I'm just using here Kubernetes as an example because we're talking about um, Kubernetes-based platforms, you might end up having many different components. Again, here is the point about different tool sets. You might be using tools like Crossplane, you might be using KubeRow, you might be using Backstage. You have many different providers from external or third-party You also have your own operators that are that

run on this platform as well. But the important thing is that it's not just usually a single cluster. It will be many clusters. You will also have a restrictions on how you interact with the clusters, how you interact with the platform components. And it's largely either GitOps or CLIs or you use UIs or do you manage a platform using ClickOps? I hope not. And then when you

want to think about the platforms themselves, like mentioned also the talk from 2024, I think it's interesting and important to think about the personas that we largely build it from the view either of the platform owner or from the view of the platform user. But we rarely think about the actual service providers themselves. You know, how do we make it easy for them to integrate into the

platforms? Yes, they can all write operators. But we could also offer some tools that we have that may be integrated easy for them as well. We rarely think about this persona. We ignore it. There are other personas as well, but are these are the three primary personas that we have to consider. So, how do we do this in Platform as? Well, the backbone of Platform as essentially

is control planes. And we do this through KCP. KCP has the machinery, the mechanisms that allow us to offer APIs as services. They're lightweight control planes that can be created in less than a second. And I can then have a multi-tenancy on each control plane that allows me to say that this control plane this workspace as it's known in KCP terminology now represents my way to store

my resources and orchestrate them from there. Now, coming to our view, and I say our because it's opinionated and you have many opinions as well, is that we primarily don't look much different than existing platforms that we've seen. It doesn't look that much different from the slides from before that we've had. The major difference is primarily that we have accounts and those accounts themselves are control planes

in KCP. They are workspaces. But because they are workspaces, we can extend those. We can then bring in APIs from external providers by using something like API sync agent or multi-cluster runtime, those projects that we've mentioned before. Additionally, we could also use Q binds to bring those APIs in. What we also can then do is go one step further and use Q bind and say there is

a control plane this is where I orchestrate all of my resources, but wouldn't it be really nice if I had that um which currently exist in a control plane and there is no existence of pods or deployments in control planes in KCP, if it were actually in my real cluster itself?" And Kube bind can do that. Essentially doing an API as a service or an operator as

a service that makes that API available in your existing cluster. So, when you then create deployments, you can say reference this secret or reference this other CRD, you get the information from there from its status or its dependent resources. All you have to do is have an agent running in your cluster. We do of course have other components in here as well, not just the account, uh

but primarily at the bottom there what we have is the platform edge components like the resource broker which we'll go into a little bit more detail. With that said, now we'll go into the actual domain problem domain itself within the platform and how to offer services with multiple providers and multiple implementations. MJ, over to you, mate. Okay, so thanks for staying for the first half of the

presentation. So, let's see what we have. So, I want to bring it down a bit like why do we think with the current platforms and current platform architectures doesn't fit or doesn't work? Like we have so many talks about platforms, so consider multiple implementation. You have multiple providers and multiple consumers. That's a not new pattern in Kubernetes, we all know it very well. And the best example

is storage. We have a claim, we say, "I want the storage. I don't care what kind of storage this just give me based on my traits and requests." We have a storage class which implements those by choosing it and the drivers act as a providers. It's no different for what this like generic consumable API, some selectors and configurations, and backends routing. So, we have it we have

services. It can be anything, in this case, it's storage. We have some managed providers in the back end based on your storage providers. And we have consumable claims. The claim word is quite buzzword, too, but you get the idea. And it's not the only API in the Kube ecosystem which is does this pattern. We already have it. Like, can we have more of this? This is such

a nice pattern. Like, why I can't have this for virtual machines? Like, I want to put a claim for virtual machine in my Kube cluster or platform. GPU standard, it gets routed to the one of the provisioners. Everything in KRM YAML files, all good and shiny. Or storage buckets. Like, it's so intuitive now, we don't even question these things anymore. And reality check, one can build that

stuff now. If you take existing tools in the ecosystem, I'm not going to do name dropping, we all know those tools, you can do that, but it's brittle. Once you extend to 10, 20 providers, 30, it's very hard to manage and life cycle and keep keep it up to date. And while we're working on this problem, we started thinking, okay, how the good provider looks like? How

the good model And we envision this kind of pseudo four levels where level one as a provider, if you want to move from one provider to another, is reinstalled. This is what we do now. You want to move from AKS to Azure or other way around in a Kubernetes cluster, you reinstall, you migrate your workloads, etc. etc. Data level two is something like data synchronization. Like, we

have Valero and few other operators helping us with these activities, but it's still predominantly manual. Level three is live live migration where we don't care, things happen. And level four is what what AI is promising, AGI. Like, things things move. So, to achieve this, we need to have to talk same language, to be on the same providers, consumers. Mentally, as a community, we are somewhere here. We're

just crossing the boundary. It's like 10 years of ecosystem and we're still here. So, introducing resource broker, yet another resource broker, I know. We bad at naming. So, it's part of platform mesh, but the idea is we want to have a tool to be able to create these claims and providers and backends dynamically. So, one writes their own YAML file, says, "This is how my claim looks

like." It's very similar to what Crossplane and Kube are doing, but in more more code way. And it gets does everything for you, routing, migration, provisioning, deprovisioning, etc. And the important part is these YAML files are not opinionated, like I don't care how you write your file. We don't want to enforce a new standard like other tools, because we think that standards should emerge themselves. We want

them to emerge, but at this point in project life cycle, we don't want to enforce anything. And let's take one step back. If you say hypothetical problem, you're moving from one provider to another Kubernetes cluster, how would you do that now? This is bit of AI slope, but as AI is getting better with code, it's kind of getting better with these tools. It's not far from from

reality. You would need to create a second cluster, you need to migrate your applications, making sure it's consistent, do all the due diligence, switch traffic. This at least months plus project for the DevOps. It's the sole reason most of the DevOps exists as a as a job. So, let's walk why this challenge is complex in a hypothetical scenario. We have claim my cluster Azure. Uh and this

looks to the KRM machinery. What How the KRM Kubernetes machinery works to solving this? You get create, it gets passed through the standard API provisioner provider, I'm scaling this cluster. Same flow, update call, works nice. Now I want to migrate it. I'm dating my claim. there's a problem here. It's already How do you handle finalizers? Kubernetes machinery itself has very strict notations how you handle deletes, finalizers.

Once you delete an object, it gets marked for deleting, garbage collection kicks in. So, it doesn't work. What you need to do, you need to have two objects. But again, this is no different from what we have now. It's what we do now actually. Like you as a user, as a platform consumer, cloud API consumer, you don't want to see this. You have a cluster and you

get clusters like, yes, there is some Azure stuff happening. What you want to see is this. So, user experience matters. So, how to achieve that? We shift left shift right. We still maintain the objects, we still maintain them, but they are hidden from the user. They are hidden by the API, the Kubernetes API in a way. We insert some magic. That's where the resource broker, we do

the migration hooks. That's programmable in a way. And for the providers use is the same. But we have a wall two. Meaning Azure or AWS should not care if the if the cluster is being migrated to or from. As much as they care, it just cluster in a life cycle. So, that's our platform boundary. And once the migration happens, we get a different claiming claim backed by

the different provider, it's a happy path. It looks kind of easy, but it isn't. So, what we see in from this short example is that if you want to stay within KRM boundary, like to be compliant KRM you need to have multiple object copies somewhere. But, mostly hidden from the users because you don't want to see the user seeing multiple objects or implementation details. And it's not

easy, else we would have it already. And the main point is that architectures like this is only possible if you have cheap control planes at your disposal. Imagine same architecture being built using Kubernetes clusters or uh containerized API servers. It will really fast goes out of hand how many those things you need to run. So, what you want to have is you have control plane which user

sees. You want to have some staging area where you do the magic and you have a provider area. it's demo time. Let's see how it works. So, consider I have a platform mesh instance. Let me do do do do do So, this is how current platform mesh looks like. Every of these tabs are its own provider, its own microservice. So, example, you can everything is Kubernetes backed,

so you can do things and things happen. So, as a provider, you bring your you bring your own tab in a way. But, that's not the main demo, so let's go here. generic API broker as a microservice which routes between different providers. So, I have two certificates, Bob and Ryker for people who gets the reference. it's always fun typing on live demos. So, on the provider side,

so I'm in a provider view. That certificate is implemented by cert manager. So, you see cert manager ryker.corp.com. On the consumer side, this is what user sees when they interact with our The claim itself is API which we came up. It's a what you come up with. So, spec.corp.com name Bob. two different APIs, resource broker sits in a in between and shuffles between them. But we want

to show the migration. let's add a watch. So, I have two two on a provider side, both that externals, and I have two on a consumer side. Let's go and I create one. Uh let's say demo. internal.corp That goes here. So, you see object popped up. We have some provider references abstracted, but I think magic happens here. We need to walk through what happens. On a consumer

side, I added a demo. It got non-provider signed. At some point, resource broker picked up says like, "Oh, you asking for internal certificate. Let me route to the internal CA backend certificate popped up. All good. So, that's a claim got implemented. Now, I want to move it. I did my development things like that, and I want to change it. So, I'm changing to demo.corp.com. I'm I want

the same certificate, but now be external backed. nothing changed, and let's see here. On the customers on the consumer side, UID is the same means objects stay the same. We didn't do delete, create. Objects never bent away from the API. secret checksum changed. The secret got rooted, certificate got changed, and here events are misordered, but external CA got a new certificate, it got ready, internal got deleted.

Means in a backend, we got things got rerooted from one provider, migrated automatically. that's basically core idea of all this, like dynamically be able to create logic to migrate from vendor to vendor without like creating your own claim claims machinery. That's basically it for demo, and bring it home. Yes. So, as you've pretty much seen, what we really talked about is our polymorphic APIs, and in order

to do that, you need an abstraction layer. You know, you think about it like a USB essentially. You know, we need this because we have many different services across many different providers. You need a simplification model to do this. You don't want to essentially push down all of the complexities to the end users And how do we do this? Well, we use KCP and KRM. It gives

us in the end something like a bus that we can connect to. We can reuse that. We have a generic API then. If you are the provider, you implement that API. The rest is then done by the platform itself. It's like an adapter pattern. With that said, I want to say thank you very much and really appreciate your You can find more information about that on our

website on platform.io as well as KCP. We're also very happily and working on that as well and contributing there too. Also want to mention again, you know, we are in the project, so feel free to stop by the booth there. And if you have any feedback then, let us know. Any questions, please. Cool. We still have few minutes for questions, but just after this, KCP has a

project pavilion booth. So, if you have to chat more about these things in a longer format, visit us there. We'll hang out there and up to the evening. Cool. And with this, Don't be shy. Microphones are there if you have Going once, going twice. Thank you. Thank you. Have a good day.