[00:00.000 --> 00:15.680] Only one minute late, it's been a long day, so bear with me. [00:15.680 --> 00:22.480] So hello everyone, thanks for joining this talk so late in the day. [00:22.480 --> 00:27.160] My name is Thierry Carras, I work for the Open Infrastructure Foundation, which is the [00:27.160 --> 00:31.920] home for the OpenStack project and Cata containers and a few others. [00:31.920 --> 00:39.760] From the accent, you can probably tell I'm based in France, and so I'm very aware of [00:39.760 --> 00:44.360] the questions around digital sovereignty, and I wanted to use this talk to give you [00:44.360 --> 00:51.360] a sense of why, from our perspective, digital sovereignty really matters, and how can open [00:51.360 --> 00:56.200] infrastructure help in that area. [00:56.200 --> 00:58.640] But first, what do we mean by digital sovereignty? [00:58.640 --> 01:02.080] If you've been in this room for the whole day, I'm pretty sure you've already heard [01:02.080 --> 01:06.600] 10 definitions, I'll just add one. [01:06.600 --> 01:14.480] Obviously, the digital sovereignty is around access to data, and the 21st century is really [01:14.480 --> 01:21.000] global and driven by software, and so in a fast-changing world, whoever adapts the fastest [01:21.000 --> 01:22.500] really wins. [01:22.500 --> 01:25.080] It's really a question of disrupt or be disrupted. [01:25.080 --> 01:30.640] So the ability to adapt fast and ship new features fast and deliver new applications [01:30.640 --> 01:34.040] fast is really critical. [01:34.040 --> 01:38.320] But the way you deliver those applications has really been evolving over the past 20 [01:38.320 --> 01:39.320] years. [01:39.320 --> 01:43.840] 20 years ago, if you started, same time I started, you would procure some physical hardware [01:43.840 --> 01:49.920] and as an application employer, you would install your operating system, your dependencies, [01:49.920 --> 01:52.760] and your application on top of that. [01:52.760 --> 01:56.920] But that was a bit inconvenient, so we added more and more layers. [01:56.920 --> 02:01.680] The first layer we added was hardware virtualization, abstracting the server your application is [02:01.680 --> 02:07.080] running on from the physical hardware that runs it, and you gained a lot of efficiency [02:07.080 --> 02:08.920] doing that. [02:08.920 --> 02:13.960] Then we added another layer, which is cloud APIs, which allows you to programmatically [02:13.960 --> 02:17.880] access those virtualized resources. [02:17.880 --> 02:20.120] And so you have those two concepts. [02:20.120 --> 02:25.040] You have programmable infrastructure on one side, and you have cloud-aware applications [02:25.040 --> 02:28.360] being deployed on top of that. [02:28.360 --> 02:33.800] And this programmable infrastructure is really key to reach the next level of velocity because [02:33.800 --> 02:38.640] machines need to be able to provision the resources that they need by themselves. [02:38.640 --> 02:45.160] And so you really need that programmable infrastructure to reach the next level of velocity and ability [02:45.160 --> 02:47.200] to deliver applications fast. [02:47.200 --> 02:53.520] The building up this programmable infrastructure by yourself is really a challenge. [02:53.520 --> 02:57.800] It's complex to do, and it's difficult to find talent that knows how to do it, because [02:57.800 --> 03:00.000] there is a lot of demand for those skills. [03:00.000 --> 03:04.400] Luckily, you can pay others to do it for you by using public clouds, available public [03:04.400 --> 03:07.160] clouds, or managed private clouds. [03:07.160 --> 03:12.960] But the trick is, the cloud market is really cornered by a couple of internal giants based [03:12.960 --> 03:15.000] in the US or China. [03:15.000 --> 03:20.400] So this really creates a challenge for European governments and companies. [03:20.400 --> 03:26.120] The challenge is that in order to stay competitive, European companies really need access to programmable [03:26.120 --> 03:27.560] infrastructure. [03:27.560 --> 03:33.440] But the most obvious way to get to that programmable infrastructure is to use a hyperscaler cloud [03:33.440 --> 03:36.640] based in the US. [03:36.640 --> 03:41.360] But data is really the basic resource of the 21st century, and which legislation your [03:41.360 --> 03:48.400] data lives under, like Ludovic just said, really ultimately defines who controls it. [03:48.400 --> 03:53.920] Like the US government can't compel any US company to disclose their customer data. [03:53.920 --> 03:58.200] In case of a geopolitical conflict, you can see the US government shutting down access [03:58.200 --> 04:03.640] to vital data that is hosted on a US-based company. [04:03.640 --> 04:09.440] This creates really a significant geopolitical vulnerability, and if the last 10 years are [04:09.440 --> 04:14.680] any guide, this vulnerability, if we don't address it, will only grow. [04:14.680 --> 04:19.280] With the recent pandemic, with the war in Ukraine, we've seen growing willingness by [04:19.280 --> 04:25.400] governments to weaponize their control of the international supply chain. [04:25.400 --> 04:30.760] So really, even assuming good intent from those governments and companies, we are all [04:30.760 --> 04:32.200] friends, right? [04:32.200 --> 04:38.560] Well, the legislation that data lives under actually affects which laws apply to it. [04:38.560 --> 04:44.960] An obvious statement, but Europe has really very progressive privacy laws that protect [04:44.960 --> 04:49.800] individuals from the reach of greedy data aggregation companies. [04:49.800 --> 04:54.880] And so how do we enforce those laws in a world where all of that data actually lives [04:54.880 --> 04:58.400] in a place where those laws do not apply? [04:58.400 --> 05:01.640] So even if you assume good intent, there is the risk there. [05:01.640 --> 05:07.680] The solution is, of course, to build our own European-based public clouds. [05:07.680 --> 05:11.000] But it's easier said than done. [05:11.000 --> 05:17.400] Europe really has a vibrant ecosystem of companies, but it really lacks the giants that can compete [05:17.400 --> 05:20.520] with a Google or a Microsoft or an Amazon. [05:20.520 --> 05:28.680] So how can we turn that vibrant ecosystem of smaller actors from a liability to an asset? [05:28.680 --> 05:34.400] Germany and France have really acknowledged this critical geopolitical vulnerability for [05:34.400 --> 05:35.400] a while. [05:35.400 --> 05:42.360] But I would say that the previous attempts at solving it weren't super successful. [05:42.360 --> 05:49.000] Like for example, we had several attempts at building giant sovereign clouds in the past, [05:49.000 --> 05:54.040] but they were really not adapted to the nature of the European ecosystem. [05:54.040 --> 05:59.280] More recently, they moved towards mandating locally operated systems, which is a great [05:59.280 --> 06:03.920] step, especially as far as government data is concerned. [06:03.920 --> 06:09.840] And for others, it also encouraged cataloging and describing available services through [06:09.840 --> 06:14.800] initiatives like Gaia X, which make it clear which laws and policy really apply to the [06:14.800 --> 06:16.080] data. [06:16.080 --> 06:22.000] But those efforts were really easily, trivially worked around by the hyperscader companies. [06:22.000 --> 06:27.360] Some of them co-opted the requirements through local partnerships, so they would work with [06:27.360 --> 06:31.920] the local EU-based company to help them run locally the thing. [06:31.920 --> 06:37.320] So the problem is, working with EU-based organizations to run the services locally really [06:37.320 --> 06:44.800] maintains this critical technological dependency that Amazon could just shut down access or [06:44.800 --> 06:48.600] weaponize access to information really easily. [06:48.600 --> 06:53.040] In some, I picked on Amazon right now, but it's actually the wrong approach because they [06:53.040 --> 06:55.280] are actually not the ones doing that. [06:55.280 --> 06:58.320] Google and Microsoft have been doing a lot more partnerships. [06:58.320 --> 07:05.280] Amazon just decided to lobby against the law and trying to convince legislators that depriving [07:05.280 --> 07:12.640] EU companies from the amazing Amazon web services would critically impact their ability to [07:12.640 --> 07:15.600] be innovative and competitive on the market. [07:15.600 --> 07:20.600] So they basically tried to convince legislators that if they don't let people access freely [07:20.600 --> 07:26.520] Amazon web services, we're doomed because obviously we can't do that here. [07:26.520 --> 07:28.160] So what do we do now? [07:28.160 --> 07:32.040] In that context, I think open infrastructure can help and I want to explain what we mean [07:32.040 --> 07:35.120] by open infrastructure first. [07:35.120 --> 07:37.720] What is it and why can it help? [07:37.720 --> 07:42.320] So if we go back to our picture from earlier, a programmable infrastructure and cloud-aware [07:42.320 --> 07:47.760] applications being deployed on top of that, open infrastructure is really open-source solutions [07:47.760 --> 07:52.040] that help you provide that programmable infrastructure. [07:52.040 --> 07:58.000] And standard there, used by millions of CPU cores all around the world, is a stack composed [07:58.000 --> 08:03.960] of Linux at the virtualization layer, open stack at the cloud APIs layer, and Kubernetes [08:03.960 --> 08:09.280] at the application orchestration layer, what we call the lucky stack. [08:09.280 --> 08:12.720] But why would you use open source for infrastructure? [08:12.720 --> 08:15.800] Why does it matter? [08:15.800 --> 08:21.760] First, it really gives everyone access to infrastructure providing technology. [08:21.760 --> 08:27.480] All organizations, all countries, it really allows to distribute the future more evenly [08:27.480 --> 08:32.840] and by making those technologies accessible to all, you actually allow everyone to play [08:32.840 --> 08:39.060] and innovate without friction or having to ask for permission, you maximize innovation [08:39.060 --> 08:40.560] as a result. [08:40.560 --> 08:47.080] But beyond those two key benefits, you actually have three properties of open infrastructure [08:47.080 --> 08:54.800] that make it really suitable for using it in a digital sovereignty context. [08:54.800 --> 08:56.560] Independence is one of them. [08:56.560 --> 09:00.920] Open infrastructure is not just open source, it's also openly developed. [09:00.920 --> 09:07.080] So Linux, open stack, Kubernetes, those are all developed not by a single vendor, but [09:07.080 --> 09:10.800] by a massive global open collaboration. [09:10.800 --> 09:16.680] And that means everyone can participate on a level playing field under a neutral governance. [09:16.680 --> 09:18.440] Nobody is owning the keys to the kingdom. [09:18.440 --> 09:22.840] Nobody will pull the rug below you by selling to someone else. [09:22.840 --> 09:27.880] Another benefit of open development is transparency, all technical discussions are happening in [09:27.880 --> 09:32.280] the open, all governance decisions are publicly documented. [09:32.280 --> 09:39.000] Trust is really essential in building a digital sovereign, digitally sovereign cloud system. [09:39.000 --> 09:42.080] And open infrastructure is really naturally transparent. [09:42.080 --> 09:49.640] And finally, being able, giving everyone access to that technology, it allows everyone [09:49.640 --> 09:53.920] to standardize on using the same solutions, which enables interoperability. [09:53.920 --> 10:00.760] Interoperability is really the main challenge for federating a group of smaller actors to [10:00.760 --> 10:06.280] compete with giants because it's really hard to eliminate the differences and present a [10:06.280 --> 10:08.880] coherent user experience. [10:08.880 --> 10:12.440] So you can standardize on available features, that's a good first step. [10:12.440 --> 10:15.880] You can expose the same APIs, which is even better. [10:15.880 --> 10:20.000] Using the same technical stack obviously is one step above that. [10:20.000 --> 10:25.320] And so EU companies that are standardized on the low key stack like Deutsche Telekom, [10:25.320 --> 10:31.800] Chloroise, I've seen a hoodie there, OVH Cloud in France, Orange Business Services, Binaural [10:31.800 --> 10:37.440] Exine, for many a cloud fair in Poland, Elastics in the Nordics, they all give you the same [10:37.440 --> 10:42.840] APIs backed by the same software and showing good interoperability. [10:42.840 --> 10:48.240] And once combined, all of those public cloud providers give you enough points of presence [10:48.240 --> 10:52.840] and capacity to actually rival any of the hyperscaders. [10:52.840 --> 10:59.960] But in order to increase interoperability even further, you can build a common distribution [10:59.960 --> 11:05.520] and share operational practices that will give you the next level, I mean perfect interoperability [11:05.520 --> 11:10.000] because it will be basically the same software running in the same conditions in different [11:10.000 --> 11:11.240] data centers. [11:11.240 --> 11:15.960] And this is what the sovereign cloud stack project is, aims to solve, and we'll have [11:15.960 --> 11:21.080] a presentation later, here you are, by Kurt. [11:21.080 --> 11:27.160] So I suspect it will go into a lot more details, but I'll just summarize for those who will [11:27.160 --> 11:32.680] not stay in the room, sovereign cloud stack as the name implies is an initiative aiming [11:32.680 --> 11:38.280] to build a standard stack for providing sovereign infrastructure. [11:38.280 --> 11:43.320] It's composed of a standard Loki stack, also making use of SEF, another open infrastructure [11:43.320 --> 11:44.960] component. [11:44.960 --> 11:51.440] It's aiming at enabling a federation of highly interoperable infrastructure providers, and [11:51.440 --> 11:58.040] it's going beyond proposing the same features, exposing the same APIs, running the same software [11:58.040 --> 12:04.120] to sharing the operational choices and best practices. [12:04.120 --> 12:09.120] It's also openly developed open source, so anyone can join and participate in the level [12:09.120 --> 12:14.560] playing field, and I'll conclude on that in summary. [12:14.560 --> 12:20.120] Digital sovereignty is a major challenge for Europe in the 21st century, especially around [12:20.120 --> 12:24.240] infrastructure, the infrastructure layers, because if we leave the hyperscalers in full [12:24.240 --> 12:32.440] control of that layer, we are going to be easily cut from our sources of information [12:32.440 --> 12:35.880] in case of any tension. [12:35.880 --> 12:40.120] Open infrastructure is open source solutions for providing infrastructure for applications [12:40.120 --> 12:42.560] and data. [12:42.560 --> 12:47.720] It enables independence, transparency, and interoperability, which are necessary to [12:47.720 --> 12:54.080] really federate a bunch of local actors to compete with the U.S.-based giants. [12:54.080 --> 12:59.760] And so if you care about digital sovereignty, as you should, have a look at the open infrastructure [12:59.760 --> 13:03.480] to power providers that I mentioned, but also at the software and cloud stack and stay in [13:03.480 --> 13:09.400] the room to see the CURTS presentation later today. [13:09.400 --> 13:17.640] Thanks for listening. [13:17.640 --> 13:21.280] And we have plenty of time for questions. [13:21.280 --> 13:33.120] Hi, my name is Michael. [13:33.120 --> 13:37.480] I tried to deploy OpenStack about a decade ago in our internal stuff. [13:37.480 --> 13:38.480] We found it very difficult. [13:38.480 --> 13:44.520] In fact, one of the problems we had were an organization of about 12 people, and OpenStack [13:44.520 --> 13:48.720] was clearly appropriate for an organization of 100 people. [13:48.720 --> 13:55.640] And so we went for both simpler solutions, you know, plain Zen, KVM, and hyperscalar [13:55.640 --> 13:57.240] sides of things. [13:57.240 --> 14:00.640] And my impression is that it hasn't changed much. [14:00.640 --> 14:07.120] That OpenStack has a scaling issue, meaning it's great for large systems and large installations, [14:07.120 --> 14:08.840] but it's not good for small systems. [14:08.840 --> 14:16.640] And so what that means is that I don't develop for the stack that you want to deploy. [14:16.640 --> 14:21.320] I develop for something else because I can't afford to maintain that piece. [14:21.320 --> 14:24.680] One of the annoyances, and I'll just let you answer it, one of the annoyances at the time [14:24.680 --> 14:30.360] was the V6 support was abysmal, and it's better now. [14:30.360 --> 14:35.200] But my impression is still that Kubernetes, for instance, is like, what's an IPv6, they [14:35.200 --> 14:36.680] just don't care. [14:36.680 --> 14:42.440] And I wonder in this common operational choices and carriers stuff that you're talking about, [14:42.440 --> 14:47.240] so this is, you're going to address this issue of, well, I can't really move a cluster [14:47.240 --> 14:51.920] from point A to point B if I have overlapping 1918 dress spaces. [14:51.920 --> 14:56.720] I need V6 and I need it to work natively and well so that I could don't have to think [14:56.720 --> 15:00.200] about this nonsense. [15:00.200 --> 15:06.040] So should I repeat the question for, I hope the question was recorded, it was a long one. [15:06.040 --> 15:13.720] So first on the concern around the size of deployment or the inability to scale down [15:13.720 --> 15:19.560] to simpler deployments, I would say that it has improved a lot. [15:19.560 --> 15:22.760] Providing infrastructure is really a difficult job. [15:22.760 --> 15:26.400] It's not like something you would deploy on your garage. [15:26.400 --> 15:32.120] If you're at a stage where, like you say, a company with 10 people, I don't think there [15:32.120 --> 15:39.480] is much sense in doing it, but the main concern was really keeping up to date with upgrades [15:39.480 --> 15:46.760] and the cycle of six months releases that we had and we made a lot of progress there [15:46.760 --> 15:52.120] in securing the updates, in limiting the amount of changes that are happening over a cycle [15:52.120 --> 15:55.920] of six months, pretty mature and stable now. [15:55.920 --> 16:03.400] And we are seeing teams of relatively small numbers running gigantic systems. [16:03.400 --> 16:09.520] Like Ubisoft, for example, is running a very large open stack private cloud for their game [16:09.520 --> 16:15.920] servers and it's a team of 10 to 12, what they said in the latest webcast. [16:15.920 --> 16:21.720] So obviously, yeah, more for 100 people company than for 10 people company. [16:21.720 --> 16:28.880] In terms of, I think distributions like sovereign cloud stack, others where there is also more [16:28.880 --> 16:34.760] guidance in the type of options that you should be deploying, more partners, you can really [16:34.760 --> 16:40.760] rely on and sharing the same issues will further help, but it's true that it's more targeted [16:40.760 --> 16:50.040] to people that have enough, I would say, the minimum size of the deployment is more like [16:50.040 --> 16:53.400] dozens of servers than three or four servers, for sure. [16:53.400 --> 16:59.040] In terms of the V6 support, I'm actually surprised because open stack had IPv6 support [16:59.040 --> 17:00.040] before Amazon did. [17:00.040 --> 17:02.040] Amazon is totally sorry. [17:02.040 --> 17:03.040] Okay. [17:03.040 --> 17:10.760] Well, maybe that's placing the bar very low. [17:10.760 --> 17:15.920] And I don't necessarily have the dual contact that I'm interested in hearing more about [17:15.920 --> 17:24.600] it if we can do that, but it feels like overall, in terms of updates, and I'm actually very [17:24.600 --> 17:28.600] surprised when I talk to some of the big deployments that we have and see that they're actually [17:28.600 --> 17:32.080] running it with a team of three or four people. [17:32.080 --> 17:37.680] So I would say, I mean, I'm not an operator myself, I'm not running an open stack cloud [17:37.680 --> 17:45.680] myself, so it's difficult to see directly how easy it is or how difficult it is. [17:45.680 --> 17:52.640] But what we are seeing from practical data is that the more we go, the smaller the teams [17:52.640 --> 17:57.440] are, we have clearly a talent shortage, so it's difficult to find talent. [17:57.440 --> 18:03.040] I would say that's the main challenge right now for open stack is really the difficulty [18:03.040 --> 18:06.080] to find people that actually have experience doing it. [18:06.080 --> 18:11.800] So most of the companies that are deploying it today, especially in Western Europe, France [18:11.800 --> 18:19.720] and Germany, there is a lot of training of new people, they will train their own teams [18:19.720 --> 18:24.240] because finding talent on the market is very, very difficult. [18:24.240 --> 18:30.600] I would say that's the main blocker right now if you had to cite one. [18:30.600 --> 18:31.600] Other questions? [18:31.600 --> 18:47.760] I'll be in the room for the rest of the day, so thank you so much.