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