How developer platforms, Wasm and sovereign cloud can help build a more effective organization

Transcript

Olimpiu Pop: Hello everybody. I’m Olimpiu Pop an InfoQ editor, and I had the pleasure of intersecting with Max at KubeCon the other day, and we said that we’ll stay for a chat to understand better what happens in the platform space because he’s so focused on multiple things. Max Koerbaecher, please introduce yourself.

Max Koerbaecher: Sure, thank you very much, Olimpiu. My name is Max Koerbaecher I’m the founder of Liquid Reply and what I’ve done the last years, it’s actually a lot of different stuff. Right now, primarily working around platform, platform engineering, how to build internal development platforms, but also going into sovereign cloud and how with open source and other technologies you can provide data sovereignty for your end users. But around that, I founded some years ago the technical advisory group for environmental sustainability in the Cloud Native Computing Foundation, today just the emeritus advisor. So, I stepped down to give the more energetic people space and keep pushing on the topic, as it requires a lot of energy.

I’m also part of the Linux Foundation Europe Advisory Board. Take a look at different initiatives and see how the organization can support the European open-source ecosystem better and give it some room to develop its landscape. And yes, I have a little bit of background in the Kubernetes release team. I was involved for three years in two different roles on the organizational side, and I’m hosting now the fourth year in a row the Cloud Native Summit Munich, which was formerly known as KCD Munich and organized also organised some meetups around all the Kubernetes and cloud native platform engineering and so on and so forth. Long, long story.

Olimpiu Pop: I’m remembering now all the encounters that we had in the last four years since I’m attending Kubernetes or KubeCon, mainly in Europe. And then I remember that we met also in DevOps, and it seems that we are always riding with the wave before that. As you mentioned, green technology was a subject, and I remember a lot of the graphs that you had that remained in my mind. Last year, I don’t recall the presentation, to be honest, but I know that your company had something to do with spin and wasn’t as connected there. So I’ll leave that for later. But mainly, you always seem to be focused on community-urgent issues and cloud-native, so that’s pretty much the topic you’re looking into. And this year somehow, you try to push all those things in one basket because you spoke about how a platform can bring a company together. Please tell me more about that. You also wrote a book about it, right?

Do you need a platform? [03:13]

Max Koerbaecher: Exactly. So I wrote last year, together with Andreas Grabner from Dynatrace and Hilliary Lipsig from Red Hat, a book about it called Platform Engineering for Architects. And it’s trying to do what you explain. Platform engineering is not always about the technology. The technology itself is solvable, it’s manageable, and if you cannot fix it, then give it one or two additional months since someone else will do so. So I think we are in an inspiring time, seeing the change in the technologies used and the approaches taken, but what is always missing is the missing clue between all of that. And I’m not talking about CI/CD pipelines and bash scripts and whatnot. Here, really, it’s the people and sometimes even the processes, the communication, and how we come to the point of building a platform.

And in our book, we question pretty often, do we need the platform? Do we need to go to the cloud? How to build it the right way? If so, are you sure, sure about it, that it is doing the right thing for you? And we help throughout the book to find the relevant decision points so that in the end, you know process-wise, precisely what you are doing and come to the fact that you integrate the different technologies. But our key conclusion is that you need to find a purpose for the platform. If you know what the purpose of the platform, is then you’re good to go. If you cannot define it, if you just say, “I was at the last KubeCon and it was filled with many cool, fantastic talks about platform engineering and how they change the world”. Yes, it might be like that; this is true for many organisations. However, just because this approach has worked for other organisations, it doesn’t mean it will work for you too. And yes, this is what we aim to bring together and provide more experience around.

Olimpiu Pop: That’s very interesting, because it’s usually a discussion of that kind. I mean, now we’re discussing platforms. Before that, we spoke about frameworks, different cloud providers, and so on and  so forth. And it’s always the discussion. Well, it’s a very shallow discussion compared to what you mentioned, buy versus build and the other stuff. So, what you said is that we need a platform with a purpose. When do you feel that, first of all, a platform is needed? What’s the most common goal for having a platform?

Max Koerbaecher: That’s a difficult question because there is no generic answer to it. Many companies find this point for themselves for different reasons. There are a few public resources around it, like how Expedia measures the success of a platform, how GitHub measures the success of a platform or how Toyota measures the success of a platform. And all three do it differently. So one is looking into the development speed and how many contributions happen. So, most likely  how they end up building a platform or thought it’s a good idea to create a platform is maybe because they had a problem in the delivery speed of their software, while the others are looking into numbers, right? Just running on an IDP saves us 5 million euros per year. So maybe it was a cost problem in the past, or perhaps the software development cycle cost too much money. And so, you’re looking for ways to improve it or increase its performance.

Therefore, again, it’s not a  generic answer available for it. But let’s see, the most interesting part to really find this point is to go through a lot of questions and identify, like, okay, do I have problems in my software development process, or do I believe I have too many bottlenecks in my organization while producing digital products? I may have different hosting requirements, and I cannot force the whole organization to understand five different hosting providers, so I need to find a way to do that, and so on and so forth. We have one customer at the moment who’s focusing a lot on a very, very complex regulation. They have to fulfill a lot of compliance rules, and there’s two ways to do it. Still, the only way I believe there will be a long-term success is to build a platform around it because it’s easier to provide through one single endpoint all the compliance rules and ensure that in the development of the software and the delivery of the software and the operations of the software, this is always already there.

The other way around this, you have to enforce for every application that this customer is going to migrate to the cloud, and there will be thousands of applications somewhere that the compliance rules fit. Now, some people will say, “Hey, it’s the same if I push it to the cloud or if I push it to, let’s say, Kubernetes as a platform”. Absolutely. But from our experience in the past, it’s easier and faster to build a compliance framework around Kubernetes than to build a compliance framework around a cloud provider or to be precise, within a cloud provider. And that’s so because a cloud provider has tons of limitations and tons of things that do not work the way you would like to have them, and at some point, you very often need to fall back to the good old engineering path and build it by yourself.

Olimpiu Pop: Thank you for that. Let me confirm that I understand it correctly. So, what you’re saying is that most of the technology we face doesn’t have a one-size-fits-all solution, and it’s essential to examine what we have in our courtyard and ensure that we’re solving the problem. Even if the problem is viewed from a business or technological perspective, you should establish a metric in place and ensure that building the platform will enable us to address it effectively. Okay, that sounds good.

Signs that the Kubernetes ecosystem is getting more mature [08:55]

I was just counting the editions of KubeCon that I’ve attended, and this was the fourth one. And I know that I was thinking that technology should have another purpose, as you said, some goal, some primary goal. And in the end, each business we work with, regardless of what they’re building, should have the ultimate goal of helping our customers make their work better through our software. And this year, it was the first time I heard about this at KubeCon during a keynote. The guys from eBay were saying that they are thinking at the SRE level, specifically about the cyber reliability and engineering aspects of user experience. And it was as if I heard the angels sing, and I listened to the fireworks going off, and I said, “Finally, we are getting there”. And would that be a sign of the platform’s coming of age? People are finally realising how they should use it.

Max Koerbaecher: Well, it’s a sign that Kubernetes is becoming mature. And then platforms on top of that are just representing this majority now, and how rigid it can be. Earlier this year, I was discussing with someone about how boring Kubernetes have become. So, there isn’t much to talk about, but that’s not entirely true, because there are tons of changes happening continuously. But where in the past you were always like, it was every release, you were sitting in the evening and waiting that the release notes going on and you’re looking into and like, “Oh, my God, do I need to kill all my Kubernetes cluster I’ve deployed in the last months or can I just seamlessly upgrade?” That time is over.

The community, as well as the end users and the people who deliver additional services around it, such as myself, are trying to find a way to explain that now, Kubernetes is no longer the problem. It’s a little overhead, but it’s not a significant problem or headache. If you spend weeks fixing your Kubernetes, you’re doing something wrong. You should focus on delivering something that helps your organization create value. And this slowly comes together one-to-one into a platform.

Now, “platform” is also not a good term, I must say, right? We’ve been discussing different kinds of platforms for 20 years, but a sound, old cloud-native platform, with some container at its core, is where, at least in our community, we feel well and feel good. And to slowly turn away from staring at this tech and look more at the people who are using it, I think that’s just the step we’ve been waiting for a very long time, showing that the technology is rich enough so that we can now focus more on the user. Because open source has always had this perception of, ‘ Hey, it always looks a little bit ugly. ‘ It’s always more complicated to use and so on. However, I think that has changed now, and it now provides enough space, at least in the cloud-native community, to say, “Hey, make it open source, make it sexy and usable, and give it a purpose or allow it to deliver a purpose”.

When to use Kubernetes [12:01]

Olimpiu Pop: That sounds nice. I’m smiling because at the point when I was earlier in my career, I was following the shiniest thing, like pretty much everybody. And then you’re looking for the boring technology, and I don’t know why, but Yoda is speaking in my head like, “Learn you will, you Padawan”. And now I feel that, as you said, the industry or the cloud-native space is becoming more mature, and a lot of other things are building on top of that. However, there is always, at least in my circles, the question of whether to use Kubernetes or not, and that’s a sign of the maturity of the engineers. When will it be feasible for someone to consider Kubernetes? What would be the scale that you have to look into just to say, “We’re going the Kubernetes way?” Regardless of whether it’s through a cloud provider or you’re just implementing it yourself?

Max Koerbaecher: Complicated, to come to the point that Kubernetes makes sense, it’s more like an evolution, right? If you are a large enterprise company, you will likely find numerous use cases to adopt Kubernetes and make it work effectively. Often, you have the other issue that you then have 10 initiatives at the same time, and practically, you’re wasting nine times more money than you want to save. If you are a medium-sized company and the biggest challenge for you is hosting your ERP system, website, and 10 internal tools, Kubernetes may not be the right solution. If you’re a startup and don’t have money, don’t start with Kubernetes. It’s not that Kubernetes itself is drastically more expensive, but you need to spend a decent amount of engineering time, and you need to hire at least one or two people who are in some way good with that tool to make your infrastructure work.

You can focus on going serverless, for example. When you want to create a prototype and are looking to bring up an MVP quickly, it’s fine to go serverless. Still, you can also, at the same point in time, pull out the companies that built everything on serverless in the past and are now migrating back to containers, trying to get into Kubernetes because it has reached such a scale that they have lost control of their system. Because serverless is also not the easiest thing to observe regarding what’s going on. There are, however, numerous cases where it doesn’t make sense to opt for Kubernetes. Earlier in the Kubernetes book club, we also discussed the same question, where we agreed that we should not bring that.

And my co-author brought up an example: if you use embedded systems, you should also avoid using Kubernetes. And it’s like, yes, well, for me, embedded systems are very far from using Kubernetes. Still, Iot itself and the whole edge deployment topic are a very significant aspect of the cloud-native ecosystem. There’s our user group around it, and there’s our telco group around it, which also works with Edge, so it’s reasonable to consider it. Where does it make sense, and where doesn’t it make sense?

So, for me, there are other questions where you can use it. You may want to either build a platform to host thousands or hundreds of random applications that are not very special. In that case, I show you quote unquotes a platform can be a good approach to unify all the different core services which you need: security compliance, make the life for operations easier, unify how you deploy software, how you keep it up and running, blah, blah, blah. All cool, good way. The other way, and this for me, the ideal use case. If I have one large digital product that is built of many different services, many different components, and they all need to in some way wipe together, they need to grow and get smaller, they need to be fault resistant, they need to allow a seamless global upgrade from versions distributed around the world, whatever. Then Kubernetes places its competencies to the best.

Olimpiu Pop: Okay, fair enough. To summarise, if you have minimal applications, consider an alternative solution. There are better ways to do it than this. But if you need to normalize your deployments and you have massive operations, it’ll help you. And this reminds me of the talk I attended last year from Mercedes-Benz. They were discussing having thousands, I don’t remember exactly, in the lower thousands, so 2,000 to 4,000 developers. They had a team of six platform engineers who were able to build the platform and deliver all of those features because they had a very proper and disciplined way of doing things. So that was eye-opening for me. However, I’ll return with a challenging yet interesting perspective.

Can WebAssembly and Kubernetes work together? [16:49]

You mentioned IoT, and it’s growing. I have a piece of that pie on my plate as well. And as you said, telco is, well, a longer edge because it’s big, they have other resources, and it has more different types of scenarios. However, I am involved in the smaller-scale Iot, where devices are deployed throughout various locations, and similar applications are utilised. However, I’m still considering a platform that can handle heterogeneous ecosystems, as they often involve multiple embedded software components and various versions. There is also an intersection point that is occurring more frequently now, and that’s the combination of WebAssembly and Kubernetes. You were on the SpinKube, if I remember correctly, as a connector.

Max Koerbaecher: Yes, partially. So initially, my team developed something called the Spin Operator. The idea was to make it super simple to get started with WebAssembly on Kubernetes. And in the end, the guys did such a fantastic job that it was even too boring to create a demo, as it was essentially just two CLI calls, and you were simply running on your Kubernetes cluster. The thing is, it wasn’t production-ready; it was lean, simple, and easy, but as often is the case, it was an experimental thing. My team collaborated with Fermyon, Microsoft, and SUSE to take it to the next level, making it production-ready and incorporating their reliability to ensure it’s robust enough for even production use cases. And in the end, I do not want to say we developed Spin or SpinKube; that would be incorrect, but my team contributed to a small, minor portion of making that happen.

Olimpiu Pop: Nice. Well, it’s a good company to be in. SUSE, Microsoft and Fermyon have a cloud focused on WebAssembly. So what’s your thought? Will WebAssembly make your footprint smaller? How much difference would it make?

Max Koerbaecher: First of all, I believe it would make our lives easier in some way because it removes all the things that can go wrong and the dirty tasks that you may not want to do as a developer or sys admin, right? So it’s for me, not about the size of the container. It’s also interesting, but it’s more about the security factor that you have their compiled binary format, which you can modify. Practically, it cannot do much if you do not grant it explicit rights. That’s one of the most significant parts that I love about it. In terms of size, performance, or sustainability, we also examined this aspect. WebAssembly doesn’t need to be more resource-efficient or more sustainable because, on the one hand, the execution time of the software remains relatively constant.

There’s no speed or improvement just because you run a WebAssembly. The only difference is that a WebAssembly container can start in 110 to 150 milliseconds. So in the blink of an eye, you can start a container. But does it allow us, that a container doesn’t need to run continuously, where a regular Docker container is also swift. Let’s say it takes a second, sometimes less, sometimes more, but it’s significantly larger in the amount of data that needs to be stored. For a container, yes, you can create a Docker container or a standard container, which can be tiny, a couple of megabytes, or 100 megabytes, depending on your needs. That would be best practice. The reality for almost everything, as seen in large and medium-sized companies, is even more alarming: the container has several hundred megabytes or gigabytes. It sometimes takes dozens of seconds to start up, or even minutes to prepare.

And so that’s where, on the other hand, WebAssembly boils it down to like, “There’s your code, execute it”. There’s no bullshit going around. There are no unusual scripts triggered in our other container, and we have preheated something. No, you are forced to make your software start and run. That’s it. And through that, yes, the container of WebAssembly is comparatively small. Some say you can go down to kilobytes. If you megabyte one, two, three, four, five megabytes, it is a good medium. Sometimes it can also become bigger. That’s not the thing. But it becomes very, very small in this regard. The technology itself is impressive. I like it because it eliminates all the headaches of maintaining, patching, and hardening the operating system in a container, leaving you to simply “Here’s your software”. You can use it everywhere. You can run it alongside every other container, but the platforms, cloud providers, and your local platforms do not support the speed of starting a WebAssembly container.

It’s great that I can start and stop a WebAssembly container in milliseconds, but it doesn’t help me if a node on AWS takes 7, 8, 9, or 10 minutes to start up, right? So this is the problem in the end. And so, either cloud providers need to start providing services again in the serverless space that can catch up with WebAssembly. And that will happen sooner or later. Or, from my perspective, where my sustainability expert comes in again, especially for a little while, slowly, platforms in an enterprise context, I see it as a possibility to fill in the blanks.

So, the Kubernetes platform is only sustainable or sound in its resource consumption if it utilises almost 100 per cent of the resources; only then is the resource consumption efficient, right? And so you can fill it up; you can have your static workload, with the heavy applications running at the bottom, and then the more flexible applications running on top. And then to fill up the planks, you can include, for example, a WebAssembly container, because you can kill it very quickly and move it somewhere else without even realising it.

How many platform engineers are needed to build your developer portal/platform? [22:49]

Olimpiu Pop: Okay, that’s a nice thought. To summarise those points, you mentioned that WebAssembly can be very fast if used appropriately. Still, companies that simply bloat their WebAssembly binaries or whatever they are called should look for an alternative. And to make things sustainable, I need to mention that sustainability is both financially and environmentally, because they’re interconnected, and it’ll mean that we have to utilise the entire resource that we have. And WebAssembly can be built on top of it because if it starts very, very fast, it allows it just to spin left and right regardless of whether people are seeing it or not. Interesting. However, this is an interesting space, and we can discuss it at length, but ultimately, this is only the runtime, right? It’s the basic stuff, and then we have the application built on top of it. And you mentioned that currently you’re looking more into internal developer portals, and that’s, again, another buzzword because I remember that last year backstage had the most developers allocated for building it.

What’s your experience with developer portals?

Max Koerbaecher: We need to draw a clear line in my wording. It’s always an internal development platform, not a portal, because there are not that many portals. Either you go backstage if you want to go open source; Red Hat has a wrapper around it. All other solutions are commercial. And we need to be aware that, as cool as backstage is, it is a burdensome child. Many organisations are starting with it, failing with it, and I get very, very mad about it.

We were a few weeks ago on a platform engineering executive roundtable. Almost everyone reported they have around three to five people working on their developer portal, and they don’t see any kind of benefit coming out of it. The problem with this standpoint is that it becomes locked into platform engineering and building platforms in the second row. And that’s a massive problem for me. That’s why I always like to take it down; first, we talk about an internal development platform because it’s bigger than just UI. The platform itself can provide you with tons of features and capabilities, and it can be adjusted to whatever you need. And then you are back to the example which you mentioned from Mercedes-Benz tech innovation, where they, with a reasonably small team, can serve a vast number of developers.

And they’re not alone by themselves. Customers we are working with have similar or larger scales, and we can see this practically in this ratio. We always say like five to five. So 5,000 developers require five platform engineers, right? When I look at the organization which we support, we usually come up to the scale of these teams in this regard. And if you need more people, then you have done something wrong with your platform – something like that. For sure, it’s also always complicated, but that’s a little prominent example for me.

But yes, developer portals themselves are a huge buzzword. I think sometimes it’s cooked too hot than what can really, really deliver. For my KubeCon demo from a talk which I gave from KubeCon, the demo, I also spin up an own IDP with the Kanoa project. Everything runs very smoothly. Argo runs smoothly, Argo Workflows comes up like a chime. External DNS, no problem. AWS EKS on an auto mode also, no problem, everything cool. Backstage killed me for weeks. I spent dozens of hours making that little… Sorry, I’m getting angry here. Fill in some bad words that come to mind first to get it up and running. And then when it was up and running, you want to fix something, you want to integrate something else, compile it, push it, proc again, it’s like, man, it can’t be.

So I can understand the pain around it. And that’s why I always like to say an IDP is not backstage. An IDP is a platform that your developers use and love, so you have it. One of our biggest customers runs everything in GitHub, that’s an IDP. They do not have a portal, and the developer portal is developed and maintained by a different team. Although they do not want to imply that no one cares, they are focused on their tasks. But the platform itself runs without it. So it’s not needed for making your organization successful in this space.

Olimpiu Pop: I zoned out a bit when you mentioned that developers have to be happy, and that’s one of the newest metrics that people are discussing. So we had DORA and then we had space, and then out of a sudden we thought about DevEx, and in the end that’s important. If the people are happy with what they’re having and, as you said, they avoid the frustration that comes from building something that allows them to be very creative and then deliver the value that they want. Ultimately, for me, the platform – the tool we use – regardless of the label we assign, should serve as a connecting bridge between the operational space and the development space. And that allows us to build bridges in the organization and break down the silos. Because, in the end, that’s what we’ve tried for so long to do, and now my feeling is that we’re closer than ever to achieving that.

Okay. We touched on a wide range of topics, and you’re at the forefront of everything. First of all, should I have asked you something else? What would be the topic I should have been keen to ask you?

Max Koerbaecher: I’m glad you didn’t touch AI.

Olimpiu Pop: Well, everybody touches AI. So we can leave it there for now.

Max Koerbaecher: With those few words. It was touched, too.  It’s very complicated to think about what’s next because so many things are happening at the same time right now. What we will see, and that’s what the organizations currently struggle with, is still to adopt the cloud. We are far ahead in the platform engineering community. We treat cloud just like an API that is tame. Yes, I need to know some limits and so forth, but usually we don’t invest so much energy in it and just fix the problem, then focus back on what delivers value to the users. But that’s still one of the most significant problems which we see with our enterprises that they’re working on. Besides that, I think we can do way more better in the space of providing application platforms. So when we talk about an IDP, we usually talk just about infrastructure and CI/CD and security and compliance and whatsoever.If you look in all kinds of reference architecture, they always look into resources and cloud provider and all the infrastructure part. Almost nothing looks the application level.

For this one, I really loved in the past Heroku and I think they are currently back on track. Somehow after the acquisition of Salesforce, they vanished for a few years and now they’re back and shiny and put out their nose and like, “Hey, here we are. We are still a cool platform. Come to me”. And I think you see similar platforms like Versal for example, which focus a hundred percent only on one problem. Give me your application, I put it somewhere and make you happy. And I think in that space we really still miss good solutions that are putting the right perspective into it, but also because it’s complex to make people in that space really happy in the end because they either want to touch the infrastructure or they don’t want to touch the infrastructure or the application becomes so complicated that they need 500 different configurations around it and so on and so forth.

So I can understand that there’s no simple solution to it. On the other hand, we have the same for all the Kubernetes and infrastructure space. We have thousands of config possibilities and millions of compositions that are possible and so on. So I think there will come up something in some time, but at the moment we don’t see anything.

Olimpiu Pop: Okay, so let me see if I understand it correctly. I don’t know if you saw it, but I had a large light bulb on top of my head when you said about internal developer platforms and application space. Because the thing that I just thought about is how cool would that be to have the qualities view on the infrastructure guys, the infrastructure team working together with the enablement team and delivering interesting building blocks that everybody can use in a uniform manner. And then we are just making things fast, secure, compliant because whether we like it or not, compliance is a very important topic. Is that around your thoughts as well?

Max Koerbaecher: Yes, in some way. I mean that’s the promise which we carry around since years and decades of doing cloud, right? But the reality is it really isn’t. We are getting more and more far away from it. We always add layers on the bottom. I don’t know, maybe we hope to fill up the whole thing until we reach the top. Maybe that’s the idea behind it, but we don’t think about what we can add from the top to it. That’s why I like other projects in this space and also WebAssembly because it forces me to reduce some part of the infrastructure. I said even just to take out the operating system of a container, that’s already a big change. It sounds stupid, but how many organizations spend thousands of thousands of euros and build hours and people on building so-called golden images in secure images and then the next developer comes around the corner wants to use, I don’t know, Rust, and suddenly nothing works again, right?

And so I think there’s, for example, wasmCloud, a very cool approach, also an open-source project, also part of the CNCF that can run practically everywhere. If you like Kubernetes, throw it on Kubernetes. If you like VMs, throw it on VMs. If you want to have it somewhere else, it can run somewhere else. There’s no real limit around it. But they have taken out every other complexity and just take your application and make it deployable, make it robust. If some connection drops somewhere, the tool will try to find other connection paths. If it doesn’t happen, it waits until it gets back connection and so on. It almost feels like a serverless platform, but it isn’t a serverless platform and it almost feels like a distributed ledger technology. But it isn’t a DLT, it’s not a blockchain, right? It sits somewhere in the middle. And I think there we can see in the next year, I guess, more development, more interest to try this out.

Would a sovereign cloud make your life easier? [33:17]

Olimpiu Pop: Okay. One of the elephants in the room passed by and that’s AI. We left it passed by us, but there is another one and I wouldn’t have mentioned it if you didn’t have touched on that and that’s over in cloud. Unfortunately the way things are looking, that’s something that probably people will start asking, if they didn’t already, “So what are we doing? Are we cutting the transatlantic cables and building new clouds or are they still already existing?”

Max Koerbaecher: Well, I think we shouldn’t do the China move, and, as we learn, trading relationships are very important. But I think what people slowly come to the point is that it doesn’t make sense to just ride on one horse in the end or just follow one horse. And that we need to find our own strengths back in some way. And that always sounds a little bit political, but it’s really not about they versus us or whoever, it’s more about we have lost in the last years a lot of our capabilities and we run behind the technological innovation. This is for multiple reasons. It’s from the investment structures which are way better in the US and people just give you a couple of million dollars. On the other hand, they have a problem with money. So it’s not good to give us the full hand of money if you do not have enough money in your other hand, right?

Nevertheless, I don’t think we should cut the cables, but we need to be aware of that. That’s the very fascinating, interesting part in the sovereign cloud itself. You have a legal aspect which you cannot fulfill with any solution existing except it is provided by 100% European entity owned organization that has zero connections to the US or China or Russia. Also, all of them want to sneak peek into what you’re doing there. That doesn’t matter so much. And the other part is you need to ensure that you have your data all the time encrypted. And I think this is right now the time not only of sovereign cloud and sovereignty about your data, but also confidential computing. I think that in many discussions, which I see is the second or third thing which comes up is it’s not enough to just legally do the things but we also need to protect it from end to end. And I think that’s the both things which we see at the moment coming up.

Beside that, cloud providers are developing. I’m super glad that we can work with Stack-It together in the German market or Scaleway more international and have tons of other options out there. We also can discuss about what is a cloud provider because we have a lot of providers, infrastructure as a service provider for example, that have almost cloud-like services, but not always someone would take them as a cloud provider.

But I really like to see that there’s a push. I really like to see that people challenge the new infrastructures which are getting built, try to understand how they’re working, how they’re different, maybe getting frustrated about it. That’s also my experience on some part. But I also always say the cloud as we know is broken because it’s just like a digital version of how you have done IT the last 60 years before. So maybe it’s time to really rethink how we are doing it. This will not happen for the large enterprises. They’re stuck in their structures, but everyone else can maybe find a way to do it a little bit better and not spend countless hours networking and firewalling and whatsoever and just find ways to really focus on providing, again, more cool features and spend time in being innovative and create new stuff.

Olimpiu Pop: So for me, how it translated from my personal experience and what we discussed is that the sovereign movement is more about aligning with our values, our European values, and ensuring that the data is safe, it’s computed safe, and it’s stored safe inside the European Union, in each entity of the European Union where you need to have the data, and that’s mainly it. Keep your data close and ensure that it’s used by the people that actually have the right of using it properly. Okay, well I think this is a nice sum up of what we discussed up to now looking to a bright future. [inaudible 00:37:26] Max, thank you for your time and hope to see you soon.

Max Koerbaecher: Thank you for having me. I wish you a nice evening.

Olimpiu Pop: Thank you.

Mentioned: