WEBVTT 00:00.000 --> 00:14.800 Well, thanks for the introduction and thanks for organizing this steproom. 00:14.800 --> 00:19.400 It is a pleasure and an honor to be the first speaker here. 00:19.400 --> 00:23.880 When I saw the title of the steproom, I'm trying to now gain a sticker by saying it's 00:23.880 --> 00:31.360 correctly building Europe's digital public infrastructure. 00:31.360 --> 00:32.360 Really? 00:32.360 --> 00:39.600 Okay, I think I think maybe we use a lot the abbreviation DPI, the digital public infrastructure 00:39.600 --> 00:40.600 and that's also why. 00:40.600 --> 00:42.800 I also have it like this in my title. 00:42.800 --> 00:47.080 Actually, I wanted to provoke you by saying, well, no, it's not just for you, it's really 00:47.080 --> 00:48.080 for everybody. 00:48.080 --> 00:52.640 A global, open source community building, things for the world, but yes, we needed really 00:52.640 --> 00:57.520 badly in Europe right now, I mean, that's no doubt. 00:57.520 --> 01:04.680 I will introduce myself real quick, been doing open source for my all of my professional 01:04.680 --> 01:10.760 life, Linux kernel was actually sort of starting point lots of years ago, spend many years 01:10.760 --> 01:18.440 at Susan and then since 15 years roughly, I've been building open source clouds, I've been 01:18.440 --> 01:25.000 doing this for Deutsche Telecom, I've also, yeah, was like the chief architect for the open 01:25.000 --> 01:31.800 telecom cloud and the last five years more than, actually, 60 years now, sorry cloud stack, 01:31.800 --> 01:36.000 which is like an initiative which I'll talk about a bit so I'm not going to that. 01:36.000 --> 01:39.120 And I do, I have done this for the open source business alliance where we had a fun 01:39.120 --> 01:43.920 the project doing this now within my own company, which is S7N. 01:43.920 --> 01:50.120 And I'll share a bit some of the work we're doing to kind of bring knowledge on technology 01:50.120 --> 01:54.400 into various countries of the world, that's the title of my talk. 01:54.400 --> 01:58.360 And some of that I've done to get together with customers of Mashke, and that's why you 01:58.360 --> 02:01.720 see his face on the slide as well. 02:01.720 --> 02:07.520 And I guess no one of you has been in Paris at the open, in for some of it, at a session 02:07.520 --> 02:13.360 because if you would, you might be a bit disappointed, I think like 50% or so of the content 02:13.440 --> 02:17.240 you would have already seen, but I have some updates, also for those that have been there, 02:17.240 --> 02:20.880 I guess, that's not affecting a lot of you. 02:20.880 --> 02:25.680 And all of the work we've done was possible by support, we have from various organizations, 02:25.680 --> 02:30.760 the German government has been supporting our project when we was a support project. 02:30.760 --> 02:38.480 We did the project within the OSPA and the trainings, we do and the work we do, we do together 02:38.480 --> 02:44.120 with the Goffsteck project which has funding from ITU, also the German government, 02:44.120 --> 02:51.080 G.I.S. and we have some nice work we do together with the United Nations. 02:51.080 --> 02:59.200 Maybe the context and it is something that, well, we cannot ignore the fact that the world 02:59.200 --> 03:06.080 is getting like a more difficult place to be in and a lot of us, I mean, enjoy the freedoms 03:06.160 --> 03:11.760 we have in our liberal democratic systems where we live in, where we have at least in Europe, 03:11.760 --> 03:19.440 we have this privilege still and we may need to defend it in many, many different ways. 03:19.440 --> 03:26.600 Obviously, as a 90 person, I hope that in our IT space we can contribute like the pieces that we can do. 03:26.600 --> 03:35.000 We have strong dependencies in the way we do IT in most European countries, strong dependencies 03:35.080 --> 03:43.440 on typically US platforms and I mean, Mr. Funderland says it really clearly, those are dependencies 03:43.440 --> 03:49.600 which can be weaponized against us and we need to expect that to happen. 03:49.600 --> 03:55.440 I guess we try to be optimistic on these questions for too long and I guess it's become 03:55.440 --> 03:59.680 obviously, cannot longer do that. 03:59.760 --> 04:08.840 So there is a clear understanding that openness and creating digital public goods is something 04:08.840 --> 04:15.000 that actually helps all of the people in the world. 04:15.000 --> 04:21.120 We have like this nice statements from the Ospos for good conference, 2024 in New York, 04:21.120 --> 04:28.760 where the UN Secretary envoy really said openness, of course, but there's democratization. 04:28.840 --> 04:35.640 So he really makes that connection from, we built open technology that allows access to 04:35.640 --> 04:42.680 technology and that helps stabilizing or building democratic cultures and for achieving 04:42.680 --> 04:49.960 that, we need to foster this co-creation and remove barriers between governments and citizens. 04:49.960 --> 04:55.600 So he's kind of very, very officially saying, well, this is how we do this. 04:55.600 --> 05:05.000 Okay, I hope this slides will be on the video later on. 05:05.000 --> 05:09.440 So we've been working with the GovStack Initiative. 05:09.440 --> 05:17.680 The chart that that initiative has is to build, well, no, sorry, to define specifications 05:17.680 --> 05:19.600 for building blocks. 05:19.600 --> 05:27.360 Building blocks that countries, that governments can use to provide services for their citizens. 05:27.360 --> 05:34.080 And if you think about what that could be, there are different layers like this, middleware 05:34.080 --> 05:37.600 in there with API gateway. 05:37.600 --> 05:43.320 There's basic blocks that everybody needs like e-learning or marketplace workflows. 05:43.320 --> 05:48.520 There's a payment module, there's user management modules. 05:48.520 --> 05:54.800 But there's also like foundation of blocks and one of the blocks that has been defined 05:54.800 --> 05:59.480 and added there also is a cloud infrastructure building block where there's like a specification 05:59.480 --> 06:03.480 for how you build open cloud infrastructure. 06:03.480 --> 06:11.240 We have had the privilege to work with that project and contribute to that effort. 06:11.240 --> 06:14.760 And right now, I mean, this is pretty advanced. 06:14.760 --> 06:19.320 The GovStack Initiative has started this a couple of years ago already. 06:19.320 --> 06:26.920 We currently see other initiatives also where stecks are being defined and I do hope 06:26.920 --> 06:31.600 and I still try to foster some collaboration between those initiatives. 06:31.600 --> 06:36.920 Anybody aware of what those logos on the right hand side mean? 06:36.920 --> 06:40.680 Yeah, yeah. 06:40.680 --> 06:47.440 So this is a Dutch landscape and this is the EuroStack. 06:47.440 --> 06:49.920 The second one, EuroStack. 06:49.920 --> 06:55.280 That's not the public sector initiative, but the industry initiative from Kristina Kaffera 06:55.280 --> 07:03.480 and they're also trying to kind of bring the European industry together to build something. 07:03.480 --> 07:10.440 I do hope and I guess open source does allow and make that easy that we can 07:10.440 --> 07:14.960 foster that collaboration so we don't need to do the work twice and three times in the end 07:14.960 --> 07:17.080 end up with too much fragmentation. 07:17.080 --> 07:21.960 We've had a discussion yesterday, fragmentation is not necessarily a bad thing, but if you 07:21.960 --> 07:26.560 fragment too much, you do not, well, it's too wasteful. 07:26.560 --> 07:30.440 We don't have the bandwidth to build 20 rate stecks. 07:30.440 --> 07:35.160 If there's like two or three or four and or maybe we do many particular rates and so 07:35.160 --> 07:39.840 we don't do the work many, many times and that's also, I mean one of the ideas behind 07:39.840 --> 07:47.200 the sobering class, the project a bit more on the building blocks that Gostek has. 07:47.200 --> 07:55.280 So the logic is it doesn't create software modules, but it creates specifications. 07:55.280 --> 08:00.600 Basically saying, well, this is how the functionality that a specific module should be having 08:00.600 --> 08:09.800 and these are the interfaces typically, well, rest interfaces if you talk about APIs. 08:09.800 --> 08:18.040 And then based on these specifications, based on these interfaces, vendors can implement 08:18.040 --> 08:25.640 modules and then actually provide them within the Gostek marketplace, a golf market. 08:25.640 --> 08:31.320 And there's then also a, they have like a methodology that the compatibility with all the 08:31.320 --> 08:36.720 requirements is being tested and you need to kind of pass all the mandatory requirements 08:36.760 --> 08:42.000 to be listed in the marketplace. 08:42.000 --> 08:47.880 And the idea is that for each of the building blocks, there are partners that do implement 08:47.880 --> 08:54.480 those solutions and then those modules together actually can be used to provide services. 08:54.480 --> 09:03.120 And there is some collaboration with the United Nations and to actually provide infrastructure 09:03.160 --> 09:05.400 and to have at least a demo environment up and running. 09:05.400 --> 09:06.720 So countries can see that. 09:06.720 --> 09:12.120 And then of course countries can decide whether they want to build like their own cloud infrastructure. 09:12.120 --> 09:19.200 They can host those services also, most of the hyperscalers, but a lot of actually countries 09:19.200 --> 09:26.560 do not want to do that, specifically in Africa, there's some sensitivity around not feeling 09:26.560 --> 09:30.120 like being a colony of other countries. 09:30.120 --> 09:37.320 So rather, there were other careful not to run into dependencies from China or from the United 09:37.320 --> 09:38.320 States. 09:38.320 --> 09:42.600 So they have a significant interest into having control over the infrastructure. 09:42.600 --> 09:48.440 And that's also the reason why the developing cloud stick initiative that we have been 09:48.440 --> 09:57.760 building for a few years was chosen like as a implementation there that's being used. 09:57.760 --> 10:04.160 Just to kind of show this light, how this came together, because when we saw this 10:04.160 --> 10:11.080 gov stick project, they were kind of asking, well, actually we want participation, but 10:11.080 --> 10:14.160 you need to kind of believe in the same. 10:28.000 --> 10:35.600 Specifications in public, we develop software in public as open source and the open size 10:35.600 --> 10:51.960 licenses with an open development model, we create public documentation and we do automation 10:51.960 --> 10:55.840 and documentation public. 10:55.840 --> 11:03.600 I will share this. 11:03.600 --> 11:09.160 I think you have tried to fix it, your slides are also visible for this tree, just the next 11:09.160 --> 11:10.160 place for your audio. 11:10.160 --> 11:14.480 Yeah, the slides have been good, can be good. 11:14.480 --> 11:22.120 Yeah, all right, I would just continue, I guess, I mean, at least then people that have 11:22.120 --> 11:28.160 made it into this room, have to reward of being here, of being here early enough, which 11:28.160 --> 11:32.800 is how enough it was them. 11:32.800 --> 11:36.400 And that kind of gives me like quickly going into what we did in the software and cloud 11:36.400 --> 11:38.120 stick project. 11:38.120 --> 11:46.400 So the ability to actually have control over your infrastructure is what was driving the 11:46.400 --> 11:47.400 initiative. 11:47.960 --> 11:54.040 When we started, digital sovereignty was not like a topic that everybody was trying to 11:54.040 --> 12:01.360 work towards, that was not yet like a famous word and also it was not abused as much 12:01.360 --> 12:03.320 in marketing as it is these days. 12:03.320 --> 12:09.080 But when we actually started to see that, this is the case that is happening now that 12:09.080 --> 12:12.600 people talk about digital sovereignty without really having a clear understanding what they 12:12.640 --> 12:13.600 mean. 12:13.600 --> 12:19.600 We took the time to kind of write down what we think we want to achieve with it. 12:19.600 --> 12:25.920 And we have kind of published about this in the cloud report and also in a that and 12:25.920 --> 12:32.240 shoots and that and see how it driven almost scientific journal actually to kind of 12:32.240 --> 12:33.240 define this. 12:33.240 --> 12:37.640 And there's, we came up with like four dimensions, that's something that actually came 12:37.640 --> 12:40.240 up from discussions with people they talked to. 12:40.240 --> 12:45.600 So we talked to use an asset, well, what is it you want to achieve to feel sovereign? 12:45.600 --> 12:50.600 Because sovereignty is something that a user of technology has not the technology, it's 12:50.600 --> 12:55.520 not property of the technology, it's actually property of the user of technology. 12:55.520 --> 12:59.200 And then of course that's the obvious one data sovereignty people want to have control 12:59.200 --> 13:02.640 over their data, where it's thought how it's thought who can access it, who has met 13:02.640 --> 13:04.920 a data access. 13:04.920 --> 13:06.920 That's straightforward. 13:06.920 --> 13:10.200 I think most people that claim to be sovereign actually, 13:11.160 --> 13:18.360 have some mechanisms to ensure that maybe you don't believe all of them, but at least 13:18.360 --> 13:21.680 that's most people are inspired to provide a switching. 13:21.680 --> 13:25.720 So I heard very often that a user, they want to have choice. 13:25.720 --> 13:32.080 If I have like only one provider, that's not very helpful. 13:32.080 --> 13:37.120 So I'm then saying, well, okay, but yeah, there is several hyper scaleers. 13:37.120 --> 13:38.560 So I have choice. 13:38.560 --> 13:42.560 It's not really a good choice because the choice is also once you have taken, you've 13:42.560 --> 13:45.960 chosen one and maybe later on still want to switch. 13:45.960 --> 13:50.080 So having the ability to switch out to a different provider, or maybe combine two of 13:50.080 --> 13:53.720 them together is what's really making this more useful. 13:53.720 --> 13:58.840 The technological sovereignty is about the ability to really look into technology, change 13:58.840 --> 14:05.920 it, adapt it to your needs, enhance it, create innovation actually on the technology. 14:05.920 --> 14:12.440 Something that you can do with open source, obviously, that's, I guess, what's connecting 14:12.440 --> 14:13.760 all of us up here. 14:13.760 --> 14:20.640 And then there's a realization that building infrastructure is not easy. 14:20.640 --> 14:25.160 Operating it in a way that works really reliably and you can, you can base your production 14:25.160 --> 14:28.240 on upon it is harder than building it initially. 14:28.240 --> 14:34.320 So making sure we actually also use what we learned from open source, where we collaborate 14:34.320 --> 14:41.240 in development, let's see whether we can also actually create some ways of sharing knowledge, 14:41.240 --> 14:45.200 of sharing experience, good and bad experience. 14:45.200 --> 14:48.200 The good ones are more easy to share than the bad ones, I guess. 14:48.200 --> 14:49.720 How we operate those things. 14:49.720 --> 14:55.320 And that actually provides then an ability also for small organization that may not have 14:55.320 --> 14:59.200 like a ton of great experts to run infrastructure to be successful. 14:59.200 --> 15:02.960 And that's what we're trying to do there. 15:03.440 --> 15:11.960 The way we do it is rather straightforward, so for providing the provider switch capability, 15:11.960 --> 15:13.200 we have certifiable standards. 15:13.200 --> 15:18.240 Those are really technical standards defining how the platform behaves, what the interfaces 15:18.240 --> 15:19.240 are. 15:19.240 --> 15:24.040 So if you move from one platform to another, you find the same behavior the same interfaces 15:24.040 --> 15:31.040 the same APIs, and you don't need to rewrite all your automation or do all the testing 15:31.600 --> 15:36.960 again, the second piece is really the software piece. 15:36.960 --> 15:42.240 So we have an open source ecosystem around us that provides a implementation for those standards. 15:42.240 --> 15:48.720 And they actually can be put together and we have a number of partners that run production, 15:48.720 --> 15:52.640 public clouds, it also some private clouds on that. 15:52.640 --> 15:58.160 And then operational knowledge is really making sure we specifically put an effort into building 15:58.720 --> 16:04.080 documentation and finding it, and making it findable and making it easily accessible, 16:04.080 --> 16:10.480 specifically around operations, because that's where typically the largest gap is. 16:10.480 --> 16:18.560 And the vision then is, well, I mean, there was like idea that we sometimes hear here, 16:18.560 --> 16:24.240 when we said, well, in Europe, we need more IT platforms that, yes, let's build this cloud 16:25.200 --> 16:31.040 I think that was like a few years ago, a rather common idea how we fix the problem. 16:31.040 --> 16:36.240 We don't think that we want to build a cloud airbus. 16:36.240 --> 16:39.520 I think we should be more clever by having this standards, actually. 16:39.520 --> 16:47.680 Let's build a network of providers, and let's make sure users can easily switch or combine 16:47.680 --> 16:51.120 things from that network because they're compatible, thanks to the standards. 16:51.120 --> 16:56.800 And that way, it's not like this centralized idea of providing competition to hyperscalers, 16:56.800 --> 17:03.120 but decentralized. By having providers work together, share the same standards, and that 17:03.120 --> 17:09.120 that way allowing customers to use all of them together. The standards are defined in an 17:09.120 --> 17:16.080 RFC process. We have this on our documentation page. Those standards have a number, they have 17:16.160 --> 17:22.240 a version. There's of course a discussion process before we create a new version. 17:22.240 --> 17:28.880 So it goes from a draft standard to a proof standard. And then some of those can be, 17:30.160 --> 17:38.080 sure what's happening, can be combined into a solidification scope and a solidification scope 17:38.080 --> 17:44.160 means that you fulfill those 20 standards, and that basically gives you like this interoperability 17:44.160 --> 17:49.920 on the virtualization layer, for example, logo or interoperability at the container layer, logo. 17:52.240 --> 17:56.960 Important those standards are being monitored. So for each of the standards, there's a test. 17:56.960 --> 18:01.360 We have like a very small number of exceptions where we need to have some, like some, 18:02.080 --> 18:07.680 some manual documents, but the baseline is still everything should be automatically tested, 18:07.680 --> 18:12.880 and should be testable also by users. So you don't need admin access to do those tests. 18:13.680 --> 18:21.040 They run every night, and we can monitor them in the compliance monitor, and you can basically 18:21.040 --> 18:27.840 see in the compatible ES that's the example here, some of the clouds that fulfill that. Also some 18:27.840 --> 18:33.680 of our partners actually have been sloppy over the last days and failed them. 18:36.080 --> 18:40.800 Now they already have been informed, they need to fix something. 18:41.760 --> 18:46.320 But also users can see this actually. So, I mean, if you for some reasons see, okay, 18:46.320 --> 18:51.840 the cloud I'm using is no longer working the way I, so automation somehow fails. 18:52.400 --> 18:56.160 You could look there and see, well, maybe it's not your fault, maybe it's the providers fault. 18:59.680 --> 19:08.400 Good. This is actually the architecture that we have implemented within the cloud 19:08.720 --> 19:15.120 specification. So you don't see any product names there, you don't see any technology names there. 19:16.240 --> 19:20.000 And it's a rather classical stack way to like hardware management, you have virtualization layer, 19:20.000 --> 19:25.840 you will utilize compute storage networking, and then on top of that you can do container cluster 19:25.840 --> 19:30.720 management. The nice thing about this architecture in a for a public cloud where you lead 19:30.720 --> 19:36.560 like multi-tenancy and you won't like a very agile way of creating container clusters. 19:37.200 --> 19:42.240 That's the standard way of doing that and we've been there and it works well. And also part of 19:42.240 --> 19:46.720 these the software stack is also that you have like the operational tooling in place and the 19:46.720 --> 19:52.720 identity and the access management that allows you to federate. This is one of the things that 19:52.720 --> 19:56.560 I'm really proud of. So we're going back now to the gov stack context. 19:57.200 --> 20:02.320 We have been actually starting to work with the United Nations, the dataset that people 20:02.320 --> 20:08.960 do in ICC. They're currently building up an SCS environment that is used by the gov stack 20:08.960 --> 20:13.920 people and maybe as important as the environment they build, we're building knowledge there 20:13.920 --> 20:19.280 because UNICC has the ability to bring that knowledge into many countries in the world. 20:20.240 --> 20:28.960 And that brings me to like the knowledge skills building as thing. Obviously sovereignty means 20:28.960 --> 20:34.160 you know what you do, you know when you use technology, how to use it and what it does for you. 20:35.600 --> 20:41.600 And so we have invested and I have beyond all of the documentation work that we've already done 20:42.560 --> 20:49.040 inside the SCS project. I have also had the privilege that I to you actually paid for 20:49.040 --> 20:55.520 creating training materials. So we have like five days course for advanced cloud computing 20:56.400 --> 21:04.960 and there's like an 80 something page PDF. And unlike some other technologies or projects 21:04.960 --> 21:10.640 we have published this under Creative Commons license. So it can be used reused and that's the 21:10.640 --> 21:22.640 way it's meant to be. And this is just summarizing how digital sovereignty and digital 21:22.640 --> 21:27.040 public goods belong together. I guess I'll jump over this so I have time for questions. 21:27.040 --> 21:33.600 Just want to report, we did actually go into some countries and did these cloud trainings and 21:33.600 --> 21:39.040 that's also after that we kind of revised the training material quite significantly once more. 21:39.920 --> 21:43.760 The way we structured is really we kind of explained something and then we did really 21:43.760 --> 21:49.360 life work with like a mini cloud there and had everybody kind of tried out and learned it. 21:50.000 --> 21:54.240 And then only then once we've been successful with everybody, jumped to the next sessions. 21:54.240 --> 22:01.040 So this was a session in Kenya where we had people from Somalia, Kenya and Djibouti 22:02.160 --> 22:05.680 that were participating. It was also funny because we did this at English and there was 22:05.680 --> 22:09.760 life translation in French and then sometimes we tried to speak French with the participants but 22:09.760 --> 22:20.160 it was also a funny experience. Work well. I'll just jump to the last slide then. 22:21.120 --> 22:25.840 Slides if you want to download them you can you can get but you can also get them from the first 22:25.840 --> 22:33.040 them page. I just I made this before I was a way that of course the pre-talks also has 22:34.000 --> 22:37.360 has it. I think we have three minutes for questions. 22:40.320 --> 22:40.960 Three. 22:43.840 --> 22:44.960 Are there any questions? Yes. 22:46.960 --> 22:54.400 You're talking about the specifications. Yes. How do you decide how prescriptive to be with 22:54.400 --> 22:59.600 the specification? Because the specification you can be to general and then you get 22:59.600 --> 23:04.160 deviating implementations but you get to prescriptive then no one implements and properly 23:04.160 --> 23:06.800 because then the two details. How do you get the balance right there? 23:06.800 --> 23:11.920 Yeah. Okay. So the question was how to balance like being too tricked to restrict 23:11.920 --> 23:19.600 different specifications and being too general so it doesn't have enough meaning and clarity anymore. 23:20.480 --> 23:26.640 So we did one thing. We did develop the specifications together with the reference implementation. 23:27.600 --> 23:32.400 So we know that the specification can be implemented. They are relevant and it works. 23:32.960 --> 23:37.200 That has one big downside. There's a risk that your reference implementation in the end will be the 23:37.200 --> 23:42.560 only one that implements this. So we kind of specifically reached out to other cloud providers that use 23:42.560 --> 23:49.360 different set of technologies and thought okay can do we have something that those would not be 23:49.360 --> 23:55.360 able to implement and I'm glad to report there's like 240 for the utilization layer which was the 23:55.440 --> 24:00.800 first one we did. We have now two independent implementations of that that also 24:00.800 --> 24:06.720 fulfilled the criteria. So I think we we were successful with doing that but it is something 24:06.720 --> 24:08.960 you need to balance. I mean the question I think is spot on. 24:12.160 --> 24:19.600 Oh sorry are you kind of keeping track of what asks first? Okay. Okay and let's 24:20.320 --> 24:27.360 thanks. Do you have an impact metric in our many empty users and numbers of servers that 24:27.360 --> 24:33.440 implement this data? Do you follow such a framework? Yeah. So the question is whether we track like 24:33.440 --> 24:40.400 this success by having users or servers counted. So I can report we have six public cloud providers 24:40.400 --> 24:45.040 that are using the technology the largest one running for regions with 24:45.040 --> 24:56.080 a large two-ditched number of hosts and also like significant projects running on that. So 24:56.080 --> 25:00.400 we have like one project that we we like to talk about which is the buy-and-cloud truly project. 25:00.720 --> 25:04.720 Yeah. 25:12.880 --> 25:14.560 Thank you.