 Hello and welcome to this very short talk that is provided by Kurt Galloff and me, Marius Feldman. Doing this talk that is titled Digital Serenity Why Open Infrastructure Matters, we would like to shed some light on the term digital serenity, which is currently intensively discussed in IT industry in Europe. And on the other hand, we would like to interlink the goal of digital serenity with open infrastructure projects. But before we do this, let's have a clear differentiation of terms. And while we want to use this differentiation to clearly point out that digital serenity is not about digital autarchy. Sometimes these terms are confused and are mixed up. However, it's very important to differentiate this. So it's not about building up a wall, for example, around Europe, and to keep all the nice interesting ideas, nice concepts, and specifically also existing nice technology outside of Europe, and do everything on our own here. But it's about integrating these things into an overall ecosystem. So digital serenity, then in the end, is integrating these things, but adding also own solutions, for example, in order to have really the freedom of choice among different options that exist. The core question here is, if while digital serenity means having the freedom of choice, what are essential preconditions to achieve this? Preconditions obviously are there should be alternatives available. Well, actually, if you do not have alternatives, you have no freedom of choice. That's quite obvious. Apart from this, the alternatives really have to differ, which means while they have some functional and non functional properties that are different. So that differ from each other. And apart from this, this is the last aspect that is absolutely fundamental. We need some means and possibilities to discover the digital services that are offered based on the properties to give a simple example. Well, for example, somebody offers a super secure digital service or a very sustainable economically, as well as ecologically or sustainable service, then it should be possible to discover it for sure. So these aspects, among others, have gained momentum in Europe and are currently intensively discussed. Specifically, they are also discussed in an overall interesting project scope, which is named GaiaX. GaiaX is a project that has been initiated by the German Ministry for Economy and Energy back in 2019. And currently, hundreds of companies, not only European ones, but companies from all around the world, work actually on that project in order to push forward the overall vision of digital serenity. In the next step, I would like to give a short insight, a very short overview of this GaiaX project. In order to do so, I've taken this image from the so-called Technical Architecture Documents that has been published in June 2020 by the German Ministry for Economy and Energy. On this image, you'll find the broad spectrum that GaiaX covers. So on one hand, the goal is to establish a data ecosystem, and on the other hand, infrastructure ecosystem. Both of these ecosystems should be heavily interlinked and centered around different technical and non-technical solutions that fall to different categories, such as identity and trust, sovereign data exchange, compliance, as well as a so-called federated catalog. If you would like to get any details on that, I recommend to read the Technical Architecture document. However, we want to focus very briefly on this federated catalog. So this catalog is exactly one of the solutions in order to achieve digital sovereignty as this federated catalog intends to hold so-called self-descriptions. So self-descriptions are descriptions of functional and non-functional properties apart from other aspects that are provided, for example, for digital services or for data, and that are published via this federated catalog. And then users have the possibility to search for services, for example, via this federated catalog and consume them in the next step. So as I've mentioned, this is one of the core components that address the digital sovereignty in regards to the definitions that we have discussed beforehand. So with this, I want to leave the GAIAX project behind with, well, one central aspect that I still want to point out. And this is a quote from page 25 that you find in this Technical Architecture document. The quote is, a strong open infrastructure ecosystem is a foundation of digital sovereignty. The interesting part is that there's absolutely no explanation for this statement within the Technical Architecture document. So, well, it's on the reader's side to give an interpretation. And this is exactly what we will do during the next minutes. However, before we start to really inter-relate open infrastructure and digital sovereignty, let's have a brief look at the current situation and the overall future situation that we predict. So here on this slide, you see on top a single cloud provider. So we are over-exaggerating a little bit the current situation. You see a single cloud provider that is operating a set of services. And this single cloud provider has some specific on provider properties. So some characteristics such as, well, it's energy efficiency, if this cloud provider is GDPR compliant or if it is not GDPR compliant and all such things. Actually, these properties are the foundation for several such properties also on the service level, which means that these properties are partially or completely reflected on the service level as well. Which means in the end, if you only have one cloud provider, well, then there is also no diversity on the service side in regards to these properties. This can be only achieved if you have several cloud providers and have several, well, private or also public infrastructure providers underneath these services having different urban properties in place. So this means that these provider properties, as we have just called them here, have a huge impact on the properties that the services that are offered have got. So specifically, for example, centered around GDPR compliance, energy efficiency or the used hardware, maybe to add some additional things, for example, also specific security means or something like this, this that a specific provider has in place, these things are then reflected on the service level. What does it mean? Well, this means if we do not have several providers, if we do not have a decentralized setup where there exists different providers, well, then we will not have digital sovereignty based on what we have discussed before. Actually, we have mentioned that in order to achieve digital sovereignty, meaning to have the freedom of choice, you need alternatives that really differ. So if there is not a specific threshold reached in regards to how we think differ, well, then there is no digital sovereignty in place. And this as a consequence means we need also heterogeneous decentralized infrastructures where the providers, the private infrastructures have properties in place that really make a difference. So only then you have really a freedom of choice, thus you have then only an option for digital sovereignty. This means we can formulate a thesis here. Future digital infrastructures are not monolithic and centralized, but highly distributed and heterogeneous regarding their properties. And this exactly based on the definition that we have provided before forms the fundament in order to achieve digital sovereignty. So on this slide you see how this may look like. So for example, here we assume a highly synergetic digital infrastructure that consists of several digital infrastructure units of different sites that are in a synergetic relation to their environments, more specifically to assets that are available already. So for example, it may be that there's a district heating system, it may be that there are renewable energy sites and the digital infrastructure units, they are in synergy with these existing assets. And on top of these digital infrastructure units, then a cloud infrastructure is for example operated, that is leveraged. And these different sites then have quite unique characteristics in this specific example, for example, in regards to their energy efficiency. This may look like the pictures that you see here, so just some sketches to point out how this may be materialized. For example, well, the digital infrastructure unit directly next door to a wind park or to a solar farm in order to well then have cheap and renewable energy available in order to operate these digital infrastructure units. To sum up, this means that we are thinking digital infrastructures of the future as decentralized infrastructures with several sites where there are also several providers behind this that operate these infrastructures. And for sure all of them will have their own solutions in the first place for setting up this infrastructure and for operating this infrastructure. So where's the downside of this perspective? So we can identify two general drawbacks here. First of all, the first drawback is related to the APIs. So it may be for sure that each of these providers offers different APIs in future. So if we have, for example, as here, three different providers, then we have three different APIs that are handed over to those that want to run services on top. And again, we end up in a vendor login situation. So the situation has not improved at all. The other aspect is related to the platform that is used. So it may be that while each of these providers leverages a different platform, even if these platforms that are used in order to operate this cloud infrastructure or digital infrastructure may be based on an open infrastructure project, this may still be an issue as, for example, this open infrastructure project may be adapted or changed a little bit. So that again, it's a sort of own solution. And this is the reason why I have mentioned in order to over-exaggerate things a little bit on that slide, that these providers have a proprietary cloud platform in place. So in the end, what we can see here is that having this future perspective means also, if we do not, well, change anything, that we have three times the development effort for creating an operational system, even if it's based on an open infrastructure project or a set of projects. Plus we also have, as we have just discussed with regards to the API, a vendor login situation. So in order to solve this issue, we could just easily claim that there should be a standardized API for all of these providers on one hand. And on the other hand, we should just request a single platform that should be used or demand a single platform that is used in order to operate the different provider infrastructures. Well, this sounds like a slight contradiction, right? On one hand, we are saying that future digital infrastructures should be heterogeneous in order to really have alternatives available due to the different properties. And on the other hand, we are requesting standards, standards for the API as well as for the platform itself. So does it make sense? Well, actually, we should not mix up things. We should really take care about what we are talking. And when talking about standardizing things, we are actually talking about a specific layer. This specific layer is providing virtual machines, virtual block devices, virtual networks and all these things. But in the end, this layer is providing commodity. And actually, it does not make sense to have many alternatives on this layer. Thus, well, standardizing things pretty much makes sense to really demonstrate this with reference to the image that we have used before. So here in this image, you see this commodity layer visualized between the services and the infrastructure itself. And if we have a look at the provider properties or infrastructure properties again that affect as well the service properties, as explained before, well, the commodity layer doesn't make any difference in regard to these properties. So for example, if you have a very energy efficient provider, or if you have a provider that leverages specific hardware, or if you have a provider that is located in a specific country, all these things are directly reflected on the service layer without any impact from the commodity layer. For sure, this is a slight simplification. So it may be that some specific adaptations to this commodity layer may be made that then have definitely an impact on the properties on the service layer. However, in general, this commodity layer should have as little impact on the properties as possible. And due to this, this commodity layer is a perfect area, a perfect field in order to have generic projects in place that solve actually the technical issues on this layer. So in the end, the commodity layer should leverage open infrastructure projects to render possible possible collaborative development and to avoid API fragmentation. So to sum that up, we can point out that open infrastructure is bridging the chasm on the commodity layer. Thus, well, the wheel should not be reinvented actually. And to point out the core findings now, well, on the path towards digital serenity is absolutely crucial to provide a modular open infrastructure solution that renders it possible to enable various actors to set up an operational platform for hosting services quickly on one hand. And on the other hand, open infrastructure projects should reduce development overhead and should ensure API interoperability in order to avoid specifically vendor login, which would contradict the freedom of choice. With this short summary of the first part of the talk, I would like to hand over to Kurt Galloff, who now will introduce a very concrete project, the so-called sovereign cloud stack, that materializes actually these findings that we have just pointed out. Thanks, Marius. My name's Kurt Galloff, and I'm going to share a bit of information on the sovereign cloud stack. So what is it sovereign cloud stack is a project in GaiaX, and it provides what Marius just referred to as the commodity layer. So we are all about providing infrastructure software to ensure their sovereign infrastructure in GaiaX. We provide a complete open source cloud software stack. When I say open, we really subscribe to the four opens of the open infrastructure community. We do provide a lot of infrastructure software, such as virtualization of storage using SEV, virtualization of networking, compute virtualization, obviously, based on open source technology. We have significant amount of operations tooling, tools for doing CI, for automating deployments, for automating updates, monitoring. On top, we put an infrastructure as a service layer using open stack for that. We have a Kubernetes as a service layer on top of that. And when I say Kubernetes as a service, I do that on purpose. It's not just containers as a service, but we do provide customers the ability to provision themselves via an API, a standard interface, Kubernetes cluster, and then control the lifecycle of that. We have some tooling around the containers, which you expect in the container space, as well as identity and access management solution in place that allows you to federate with other clouds of similar nature. The stack is complete, but it's also modular. That means if you're an existing provider and you don't want to use the complete full SCS stack, but want to stay on tools that you already have deployed on pieces that you already have, you can do so and only consume some of the SCS modules. To make sure that we deliver on interoperability, that we really are compatible at this commodity layer, we do have strong standards, so stronger than what you are used to see from the open stack community. We really want to make sure that if you're using several SCS-based clouds, you will have no trouble at all to move applications from one to the other or to use several at the same time and not even notice the difference. Those standards really do not end at the API layer, but we really want to define also the behavior and also certain aspects of how those clouds are being operated. Those standards are being certifiable, so you can actually prove as a provider to your customers that you adhere to those standards. We have federation built in by design and compatibility that just talked about is just one aspect of that. Identity federation is an important one because you don't want to manage your users and the access rights that go along with that on each cloud separately. You want to be able to do it once and then define this for all of your clouds that you're using. Of course, you do need a network connectivity between those clouds. You want to have the ability to create secure tunnels or secure connections with the bandwidths and latency requirements that you have. Finally, we're spending a significant effort to actually work with the operators, support them, to really build an ecosystem out of them. We want to make sure that we extend the idea of working together according to the four opens in building software, also in sharing operational knowledge and really make sure that providers open up and learn from each other and don't need to solve those same hard and difficult problems that you really see in day-to-day operations independently of them. We really want to make sure there's a network of providers also working together at this base commodity layer that Marius was talking about. This helps to improve the quality and also to make the quality more transparent to users. This is a slightly different picture than Marius showed that gives you an idea how the GAIA-X ecosystem is being looked at. At the bottom layer you see the infrastructure ecosystem and this is where the sovereign cloud stack provides an option for providers to have sovereign infrastructure. Talking about where we are with our project, it's a really young project. We only started somewhat less than a year ago when we first came together and had this idea. It was initially initiated by a group of members of the open source business alliance. This is an alliance of German speaking countries, open source companies that really work together there to kind of define their common interest. We have built a very small team based on this idea and that team really consisting out of a handful of people is now coordinating and orchestrating a much larger community of contributors, contributors for companies where IT departments work with us because they're interested but also existing and new cloud providers that are interested and contributing to this effort. We have been lucky to receive some funding from the agency for disruptive innovation in Germany for this year and we're also currently working towards a larger funding proposal that we are trying to get funding for the next years and I'm very optimistic this works out. Very importantly we have a significant number of companies and partners that are supporting us not just from the open source business alliance but also various companies from the industry as well as cloud providers. We have companies from Sweden and France that have joined us and are supporting us. We do have a trademark, we have a logo, we have a web page, we have open source code available on github. We're part of the GaiaX community. We're also working with supporting the foundation that's being built up in the GaiaX ecosystem and SCS is established as an official word package in GaiaX. We do talk a lot to people in the industry but we also received some very positive feedback from actually companies that support IT in the public sector and we've also recently had quite a bit of coverage from press mostly in Germany and I have to say that was really motivating and positive because people seem to have the impression that what we are doing is really something that needs to be done so we are happy to be there. On the technical side we have worked quite a bit on already providing technology so we have code out there and that code can be used already so we can do deployments fully automated with the available code so we have been successful integrating all these existing open source projects in an automated way, validating them and making them available. We can do bare metal installations, obviously there's a few steps in the bare metal installation that are not fully automated because you need to do the cabling and put those machines in the rack but once you've done all that you can actually do it fully automatically but also very nice for testing, for validation, also for demos is that we can actually deploy on top of an existing infrastructure as a service solution using Terraform so we can actually put the server cloud stack which includes OpenStack on top of an existing OpenStack deployment and that takes between one hour or maybe 90 minutes depends a bit on the network connection and performance of your environment. That is very useful, we have that running at more than half a dozen cloud providers, we also have to where we actually have already physical installations. Finally the container layer, the Kubernetes layer is something we're currently still working on, we're struggling a bit with it to be very honest because the Kubernetes cluster API does not seem to have adopted and mature as much as we would like and this is kind of preventing us from coming up with a final standardized solution in that space so we're working with the SAP Gardener folks, with the Kubernetes folks, with Rancher, we have been talking to Giant Swarm to see that we can work together but we still need to kind of define this common standard to really get a breakthrough in that area. This is a short look at the architecture which I will basically skip to avoid running out of time. That being said, let me summarize, Mars I think has very well explained that serenity is important that it matters. In order to achieve it you need to have choice, you need to have control so we need to make sure we have a diverse decentralized ecosystem for providing open cloud infrastructure. Right now we have somewhat of a fragmentation that really is not helpful if solutions that are open are incompatible to each other that does not help and the second observation we have is that it's very hard to provide a high quality operations of cloud infrastructure so SCS is trying to help this with standardizing making sure we make the operations a lot easier and with also making sure that all these infrastructures that are based on SCS are compatible to each other. That's it, I want to invite you to join the two SCS sessions that we have today, there's one at a quarter past noon and there's one on Wednesday morning 9.15 a central European time. I have provided three links to that you can go to to get further information and I would be happy if you join our team and supporters developing this project. Thanks for your attention, if you have any questions to Mars or myself please ask.