WEBVTT 00:00.000 --> 00:07.000 Thank you. 00:07.000 --> 00:12.000 Thank you. 00:12.000 --> 00:16.000 Thank you. 00:16.000 --> 00:26.000 Thank you. 00:26.000 --> 00:31.000 Thank you. 00:31.000 --> 00:38.000 Sorry. 00:38.000 --> 00:41.000 How do we do one side? 00:41.000 --> 00:43.000 I'll send also. 00:43.000 --> 00:45.000 Yes. How do I... 00:45.000 --> 00:48.000 First aid. 00:48.000 --> 00:50.000 The best is today. 00:50.000 --> 00:55.000 That's it. 00:55.000 --> 00:57.000 Yes. 00:57.000 --> 01:07.000 Thank you. 01:07.000 --> 01:14.000 Thank you. 01:14.000 --> 01:17.000 Thank you. 01:17.000 --> 01:20.000 Thank you for attending today's presentation. 01:20.000 --> 01:25.000 My name is Mr. Copic. I'm from SAP and with me I have Marvin Beckers from Kubernetes. 01:25.000 --> 01:29.000 Today we would like to talk to you about building a European platform. 01:29.000 --> 01:33.000 One thing I want to make clear is that this is not a corporate donation. 01:33.000 --> 01:41.000 It is actually supported by European funding. It is at its core open source and you can even say an altruistic approach. 01:41.000 --> 01:44.000 Now, just let's get started at the current issue that we have. 01:44.000 --> 01:48.000 So we see in the current cloud infrastructure a lot of silos. 01:48.000 --> 01:53.000 We have vertical silos that are locked in with APIs and specific toolings. 01:53.000 --> 01:57.000 Each provider builds their own closed environments and we see that a bit of a problem. 01:57.000 --> 02:01.000 But for the mentally there is actually some other conflicts that already exist. 02:01.000 --> 02:06.000 Primarily between the software ecosystems and the infrastructure ecosystems. 02:06.000 --> 02:08.000 They are at a conflict. 02:08.000 --> 02:13.000 The software always wants to be flexible and mobile for consumer needs. 02:13.000 --> 02:16.000 Whereas the infrastructure always aims for specific locking. 02:16.000 --> 02:21.000 You are tied to specific provider. You tied for specific runtime. You are tied to specific control. 02:21.000 --> 02:27.000 However, the vision that we want to pay it forward is that we are looking at a multi provider cloud edge continuum. 02:27.000 --> 02:29.000 A mesh if you like. 02:29.000 --> 02:35.000 Where providers and providers expose the capabilities through initial and unified interfaces. 02:35.000 --> 02:39.000 This allows also a shift of workload between different providers. 02:39.000 --> 02:42.000 Where you can then maintain consistent functionality. 02:42.000 --> 02:50.000 So that is how a quick look at the current picture of how it would be with a consumer and multiple providers. 02:50.000 --> 02:55.000 You are targeting a custom provider integration. 02:55.000 --> 03:00.000 You have complexity that increases exponentially, especially as we add more providers. 03:00.000 --> 03:06.000 And this is because each provider has an opinion that service and platform APIs. 03:06.000 --> 03:10.000 This ultimate results and lock in through those specific opinion APIs. 03:10.000 --> 03:14.000 No common language exists between each provider and these platforms. 03:14.000 --> 03:18.000 In the end, it is down to the consumer through the heavy lifting. 03:19.000 --> 03:23.000 They need to then bridge these gaps between those providers. 03:23.000 --> 03:26.000 Ultimately though, that is not the only problem. 03:26.000 --> 03:30.000 The same old problem also exists inside a platform itself. 03:30.000 --> 03:35.000 You see that more than platforms combine many specialized services vertically. 03:35.000 --> 03:43.000 And then combine these with rest APIs and glue them together to create these different components in the platform. 03:43.000 --> 03:49.000 Generally there is a management interface that binds these diverse components into a cohesive platform. 03:49.000 --> 03:53.000 But there is already a common component in most of those. 03:53.000 --> 03:58.000 And that is that cloud native has already changed the landscape. 03:58.000 --> 04:01.000 And open source foundations are driving that change. 04:01.000 --> 04:06.000 They use paradigms that are driven by open source into these platforms specifically. 04:06.000 --> 04:12.000 Manage service providers, as an example, can use these as well as consumers. 04:12.000 --> 04:17.000 Therefore there is no need to invent something completely new. 04:17.000 --> 04:20.000 We do not want to bring you another thing that you have to do. 04:20.000 --> 04:26.000 It is already in those platforms and exists in your stacks as well. 04:26.000 --> 04:29.000 And this transformation has happened already. 04:29.000 --> 04:34.000 To break down the barriers to enable flexibility with an interconnected mesh. 04:34.000 --> 04:41.000 Using Kubernetes resource model as the standardized interface for digital services and binding them. 04:41.000 --> 04:46.000 This is not about continuous container orchestration. 04:46.000 --> 04:52.000 It focuses on API standardization patterns by building on existing successful patterns. 04:52.000 --> 04:58.000 Using the Kubernetes resource model enables digital twins of these components in the mesh. 04:58.000 --> 05:03.000 You can even provide customer facing controlled planes. 05:03.000 --> 05:07.000 If you are a master service provider that builds bridges between these equal systems. 05:08.000 --> 05:15.000 And this platform mesh adopts a Kubernetes resource model to build a unified language, a link word Francois. 05:15.000 --> 05:18.000 Where the service capability becomes a digital twin. 05:18.000 --> 05:22.000 A life declarative contract between what you get and what you want. 05:22.000 --> 05:28.000 A bridge that, sorry, bridging the gaps between the different cloud providers. 05:28.000 --> 05:31.000 Now looking at today's view. 05:31.000 --> 05:34.000 The business in reality is that there are fragmentations. 05:34.000 --> 05:40.000 There are lockings. There are snowflakes. Teams must master multiple opinionated platform APIs. 05:40.000 --> 05:46.000 Each integration becomes a custom snowflake integration. 05:46.000 --> 05:50.000 Locking specific to the vendor is also a muster. 05:50.000 --> 05:55.000 These existing lockings may to be disrupted. 05:55.000 --> 06:06.000 All right. How do we disrupt them? 06:06.000 --> 06:09.000 And how do we do that in an innovative way? 06:09.000 --> 06:12.000 How do we not bring in, as Melissa said, another standard? 06:12.000 --> 06:18.000 How do we start out with what we have in modern IT architecture already? 06:18.000 --> 06:26.000 So the Kubernetes resource model that Melissa mentioned, it is basically the low level language of how you interact with Kubernetes. 06:26.000 --> 06:33.000 It defines how you interact with it, how you, in a very fundamental sense, order things from Kubernetes. 06:33.000 --> 06:36.000 But do we just want to take this order interface? 06:36.000 --> 06:38.000 And we basically want to work on that. 06:38.000 --> 06:41.000 And in our vision, when we take that. 06:41.000 --> 06:45.000 So providers eliminate this custom layer. 06:45.000 --> 06:48.000 You know, all this glue that was necessary. 06:48.000 --> 06:53.000 And that basically resulted in a very winner takes it all kind of situation. 06:53.000 --> 06:56.000 Because at some point the integration work was just too much. 06:56.000 --> 06:59.000 Or it's just too much for consumer of digital services. 06:59.000 --> 07:06.000 So there's only a top view at the spot at the top spot that can basically be adopted. 07:06.000 --> 07:09.000 And then you run out of capacity to basically work with them. 07:09.000 --> 07:18.000 So now, if you look at this and if providers, if providers of digital services, if they suddenly start to speak the same language, 07:18.000 --> 07:22.000 we eliminate all of that or a lot of that. 07:22.000 --> 07:29.000 And consumers have basically the standard that they know that they can speak to different service providers. 07:29.000 --> 07:38.000 And they have this common language and they can sense basically what we could define as order manifest of digital service instances. 07:38.000 --> 07:41.000 Both to one provider and to another provider. 07:41.000 --> 07:45.000 Now, we have to be honest here, this is only the starting point. 07:45.000 --> 07:49.000 So this is a little bit how it looks on a technical level. 07:49.000 --> 07:54.000 And obviously just speaking the same language doesn't mean that everyone is offering the same services. 07:54.000 --> 08:02.000 So going from a common language, we also in the future, as a basically follow our project, 08:02.000 --> 08:07.000 we need to think about standardizing what kind of digital services are that to offer, 08:07.000 --> 08:13.000 how would you order them, what are the kind of parameters to order such a digital service. 08:13.000 --> 08:17.000 And this will require standardization bodies. 08:17.000 --> 08:21.000 Like, this is a future work, this is something that will need to be worked on. 08:21.000 --> 08:27.000 But our point here is that without a common language, the standardization cannot happen. 08:27.000 --> 08:31.000 So we still, we first need to basically have the same words 08:31.000 --> 08:39.000 to talk about something and then we can define, okay, I want to basically sit down together and we can speak in that common language 08:39.000 --> 08:45.000 and it's offer this kind of standard for ordering digital services. 08:45.000 --> 08:50.000 And only with a common language you have a high fidelity in such standards. 08:50.000 --> 08:59.000 So basically making sure that the order interface that you offer is really something that is useful to consumers and to providers alike. 08:59.000 --> 09:06.000 So basically what we're doing here is we are taking and there was this nice animation earlier. 09:06.000 --> 09:13.000 We basically take a standard that is already there, often buried deep within an IT architecture, 09:13.000 --> 09:17.000 and we bring it to the top. 09:17.000 --> 09:22.000 So, and that allows us to have an intrinsic order interface between providers. 09:22.000 --> 09:26.000 And that also means that we can think about data transfer. 09:26.000 --> 09:35.000 We can think about this kind of regulations that are either already there or up and coming, 09:35.000 --> 09:43.000 and that require providers to have portability and this common language can enable that. 09:43.000 --> 09:48.000 All right, let's walk quickly through some cases. 09:49.000 --> 09:53.000 What the case that we would like to make is that this is already happening. 09:53.000 --> 10:02.000 If in technology there is already this movement called developer, like, yeah, okay, internal developer platforms also called platform engineering. 10:02.000 --> 10:08.000 And this is basically how IT organizations, modern IT organizations are building out their own internal platforms. 10:08.000 --> 10:14.000 So if you look at this and at our proposal how this should look like, an internal IT organization, 10:14.000 --> 10:19.000 where it has users, and in the platform it would get an account. 10:19.000 --> 10:25.000 You can think of that, like, you've seen maybe this already with every kind of multi-tenancy system. 10:25.000 --> 10:34.000 But basically the internal users they would send an order in, and that order would basically go to a specific team of service providers within an organization. 10:34.000 --> 10:42.000 And basically through that, this order is translated to an order from different service providers within the organization, 10:42.000 --> 10:48.000 because there's a higher level service that is being offered that translates to lower level service also offered. 10:48.000 --> 10:51.000 So service providers also become service consumers. 10:51.000 --> 10:57.000 So we're just going to work with this quickly, because I want to show you something else that we don't have that much time. 10:57.000 --> 11:02.000 So now we're getting into buying raises building. 11:02.000 --> 11:08.000 So of course you can build this internally, but how can what we want to propose help you with building, 11:08.000 --> 11:12.000 sorry, we're integrating and we're creating a new kind of market. 11:12.000 --> 11:22.000 So basically, if you think about the scenario, I'm sending in an order, and basically, there is an MSP managed service provider, 11:22.000 --> 11:28.000 and that managed service provider is sitting outside, but it offers the same kind of APIs, the same kind of language. 11:28.000 --> 11:34.000 And because of that, there is ability to bind into that provider to bring that provider in. 11:34.000 --> 11:43.000 And because of that, additional twin model can help us and basically say, okay, I order from the MSP a specialized service, 11:43.000 --> 11:53.000 and that specialized service will allow me to basically order that through the MSP and the MSP can focus on its business objectives. 11:53.000 --> 12:00.000 And we believe that this is good for providers as well, because providers will basically be able to sell to many, 12:00.000 --> 12:04.000 because they have very little overhead when stepping into the markets. 12:04.000 --> 12:10.000 And the open source community, and specifically the cloud native ecosystem, which Kubernetes and many other things are part of, 12:10.000 --> 12:19.000 will provide benefits to service providers and to service consumers, because they allow them to basically have SDKs, 12:19.000 --> 12:26.000 have integrations, all of that for free, and all of that, same for every provider, so providers can focus on their core objectives. 12:27.000 --> 12:33.000 So, to wrap this up, sorry, we think that there's a different market possible. 12:33.000 --> 12:41.000 A market where there's a lateral movement between providers and co-operation, and all of that through a common language and through protocols that can help us, 12:41.000 --> 12:45.000 basically define this multi-prior cloud edge continuum. 12:45.000 --> 12:47.000 And I think I'm out of time. 12:47.000 --> 12:48.000 So. 12:48.000 --> 12:49.000 Just in time. 12:49.000 --> 12:50.000 Yes. 12:50.000 --> 12:51.000 Thank you very much. 12:51.000 --> 12:56.000 We just want to mention also quickly, there's a new foundation that's also being started as part of Linux Foundation, 12:56.000 --> 13:03.000 Europe, New York Needforce, and this is the most of the cooperation and goes into that. Thank you. 13:04.000 --> 13:23.000 Thank you very much. 13:23.000 --> 13:25.000 The next talk. 13:25.000 --> 13:28.000 I'd like to thank you all for the ask for the examples here. 13:33.000 --> 13:35.000 Thank you.