Well, thanks for the introduction and thanks for organizing this steproom.
It is a pleasure and an honor to be the first speaker here.
When I saw the title of the steproom, I'm trying to now gain a sticker by saying it's
correctly building Europe's digital public infrastructure.
Really?
Okay, I think I think maybe we use a lot the abbreviation DPI, the digital public infrastructure
and that's also why.
I also have it like this in my title.
Actually, I wanted to provoke you by saying, well, no, it's not just for you, it's really
for everybody.
A global, open source community building, things for the world, but yes, we needed really
badly in Europe right now, I mean, that's no doubt.
I will introduce myself real quick, been doing open source for my all of my professional
life, Linux kernel was actually sort of starting point lots of years ago, spend many years
at Susan and then since 15 years roughly, I've been building open source clouds, I've been
doing this for Deutsche Telecom, I've also, yeah, was like the chief architect for the open
telecom cloud and the last five years more than, actually, 60 years now, sorry cloud stack,
which is like an initiative which I'll talk about a bit so I'm not going to that.
And I do, I have done this for the open source business alliance where we had a fun
the project doing this now within my own company, which is S7N.
And I'll share a bit some of the work we're doing to kind of bring knowledge on technology
into various countries of the world, that's the title of my talk.
And some of that I've done to get together with customers of Mashke, and that's why you
see his face on the slide as well.
And I guess no one of you has been in Paris at the open, in for some of it, at a session
because if you would, you might be a bit disappointed, I think like 50% or so of the content
you would have already seen, but I have some updates, also for those that have been there,
I guess, that's not affecting a lot of you.
And all of the work we've done was possible by support, we have from various organizations,
the German government has been supporting our project when we was a support project.
We did the project within the OSPA and the trainings, we do and the work we do, we do together
with the Goffsteck project which has funding from ITU, also the German government,
G.I.S. and we have some nice work we do together with the United Nations.
Maybe the context and it is something that, well, we cannot ignore the fact that the world
is getting like a more difficult place to be in and a lot of us, I mean, enjoy the freedoms
we have in our liberal democratic systems where we live in, where we have at least in Europe,
we have this privilege still and we may need to defend it in many, many different ways.
Obviously, as a 90 person, I hope that in our IT space we can contribute like the pieces that we can do.
We have strong dependencies in the way we do IT in most European countries, strong dependencies
on typically US platforms and I mean, Mr. Funderland says it really clearly, those are dependencies
which can be weaponized against us and we need to expect that to happen.
I guess we try to be optimistic on these questions for too long and I guess it's become
obviously, cannot longer do that.
So there is a clear understanding that openness and creating digital public goods is something
that actually helps all of the people in the world.
We have like this nice statements from the Ospos for good conference, 2024 in New York,
where the UN Secretary envoy really said openness, of course, but there's democratization.
So he really makes that connection from, we built open technology that allows access to
technology and that helps stabilizing or building democratic cultures and for achieving
that, we need to foster this co-creation and remove barriers between governments and citizens.
So he's kind of very, very officially saying, well, this is how we do this.
Okay, I hope this slides will be on the video later on.
So we've been working with the GovStack Initiative.
The chart that that initiative has is to build, well, no, sorry, to define specifications
for building blocks.
Building blocks that countries, that governments can use to provide services for their citizens.
And if you think about what that could be, there are different layers like this, middleware
in there with API gateway.
There's basic blocks that everybody needs like e-learning or marketplace workflows.
There's a payment module, there's user management modules.
But there's also like foundation of blocks and one of the blocks that has been defined
and added there also is a cloud infrastructure building block where there's like a specification
for how you build open cloud infrastructure.
We have had the privilege to work with that project and contribute to that effort.
And right now, I mean, this is pretty advanced.
The GovStack Initiative has started this a couple of years ago already.
We currently see other initiatives also where stecks are being defined and I do hope
and I still try to foster some collaboration between those initiatives.
Anybody aware of what those logos on the right hand side mean?
Yeah, yeah.
So this is a Dutch landscape and this is the EuroStack.
The second one, EuroStack.
That's not the public sector initiative, but the industry initiative from Kristina Kaffera
and they're also trying to kind of bring the European industry together to build something.
I do hope and I guess open source does allow and make that easy that we can
foster that collaboration so we don't need to do the work twice and three times in the end
end up with too much fragmentation.
We've had a discussion yesterday, fragmentation is not necessarily a bad thing, but if you
fragment too much, you do not, well, it's too wasteful.
We don't have the bandwidth to build 20 rate stecks.
If there's like two or three or four and or maybe we do many particular rates and so
we don't do the work many, many times and that's also, I mean one of the ideas behind
the sobering class, the project a bit more on the building blocks that Gostek has.
So the logic is it doesn't create software modules, but it creates specifications.
Basically saying, well, this is how the functionality that a specific module should be having
and these are the interfaces typically, well, rest interfaces if you talk about APIs.
And then based on these specifications, based on these interfaces, vendors can implement
modules and then actually provide them within the Gostek marketplace, a golf market.
And there's then also a, they have like a methodology that the compatibility with all the
requirements is being tested and you need to kind of pass all the mandatory requirements
to be listed in the marketplace.
And the idea is that for each of the building blocks, there are partners that do implement
those solutions and then those modules together actually can be used to provide services.
And there is some collaboration with the United Nations and to actually provide infrastructure
and to have at least a demo environment up and running.
So countries can see that.
And then of course countries can decide whether they want to build like their own cloud infrastructure.
They can host those services also, most of the hyperscalers, but a lot of actually countries
do not want to do that, specifically in Africa, there's some sensitivity around not feeling
like being a colony of other countries.
So rather, there were other careful not to run into dependencies from China or from the United
States.
So they have a significant interest into having control over the infrastructure.
And that's also the reason why the developing cloud stick initiative that we have been
building for a few years was chosen like as a implementation there that's being used.
Just to kind of show this light, how this came together, because when we saw this
gov stick project, they were kind of asking, well, actually we want participation, but
you need to kind of believe in the same.
Specifications in public, we develop software in public as open source and the open size
licenses with an open development model, we create public documentation and we do automation
and documentation public.
I will share this.
I think you have tried to fix it, your slides are also visible for this tree, just the next
place for your audio.
Yeah, the slides have been good, can be good.
Yeah, all right, I would just continue, I guess, I mean, at least then people that have
made it into this room, have to reward of being here, of being here early enough, which
is how enough it was them.
And that kind of gives me like quickly going into what we did in the software and cloud
stick project.
So the ability to actually have control over your infrastructure is what was driving the
initiative.
When we started, digital sovereignty was not like a topic that everybody was trying to
work towards, that was not yet like a famous word and also it was not abused as much
in marketing as it is these days.
But when we actually started to see that, this is the case that is happening now that
people talk about digital sovereignty without really having a clear understanding what they
mean.
We took the time to kind of write down what we think we want to achieve with it.
And we have kind of published about this in the cloud report and also in a that and
shoots and that and see how it driven almost scientific journal actually to kind of
define this.
And there's, we came up with like four dimensions, that's something that actually came
up from discussions with people they talked to.
So we talked to use an asset, well, what is it you want to achieve to feel sovereign?
Because sovereignty is something that a user of technology has not the technology, it's
not property of the technology, it's actually property of the user of technology.
And then of course that's the obvious one data sovereignty people want to have control
over their data, where it's thought how it's thought who can access it, who has met
a data access.
That's straightforward.
I think most people that claim to be sovereign actually,
have some mechanisms to ensure that maybe you don't believe all of them, but at least
that's most people are inspired to provide a switching.
So I heard very often that a user, they want to have choice.
If I have like only one provider, that's not very helpful.
So I'm then saying, well, okay, but yeah, there is several hyper scaleers.
So I have choice.
It's not really a good choice because the choice is also once you have taken, you've
chosen one and maybe later on still want to switch.
So having the ability to switch out to a different provider, or maybe combine two of
them together is what's really making this more useful.
The technological sovereignty is about the ability to really look into technology, change
it, adapt it to your needs, enhance it, create innovation actually on the technology.
Something that you can do with open source, obviously, that's, I guess, what's connecting
all of us up here.
And then there's a realization that building infrastructure is not easy.
Operating it in a way that works really reliably and you can, you can base your production
on upon it is harder than building it initially.
So making sure we actually also use what we learned from open source, where we collaborate
in development, let's see whether we can also actually create some ways of sharing knowledge,
of sharing experience, good and bad experience.
The good ones are more easy to share than the bad ones, I guess.
How we operate those things.
And that actually provides then an ability also for small organization that may not have
like a ton of great experts to run infrastructure to be successful.
And that's what we're trying to do there.
The way we do it is rather straightforward, so for providing the provider switch capability,
we have certifiable standards.
Those are really technical standards defining how the platform behaves, what the interfaces
are.
So if you move from one platform to another, you find the same behavior the same interfaces
the same APIs, and you don't need to rewrite all your automation or do all the testing
again, the second piece is really the software piece.
So we have an open source ecosystem around us that provides a implementation for those standards.
And they actually can be put together and we have a number of partners that run production,
public clouds, it also some private clouds on that.
And then operational knowledge is really making sure we specifically put an effort into building
documentation and finding it, and making it findable and making it easily accessible,
specifically around operations, because that's where typically the largest gap is.
And the vision then is, well, I mean, there was like idea that we sometimes hear here,
when we said, well, in Europe, we need more IT platforms that, yes, let's build this cloud
I think that was like a few years ago, a rather common idea how we fix the problem.
We don't think that we want to build a cloud airbus.
I think we should be more clever by having this standards, actually.
Let's build a network of providers, and let's make sure users can easily switch or combine
things from that network because they're compatible, thanks to the standards.
And that way, it's not like this centralized idea of providing competition to hyperscalers,
but decentralized. By having providers work together, share the same standards, and that
that way allowing customers to use all of them together. The standards are defined in an
RFC process. We have this on our documentation page. Those standards have a number, they have
a version. There's of course a discussion process before we create a new version.
So it goes from a draft standard to a proof standard. And then some of those can be,
sure what's happening, can be combined into a solidification scope and a solidification scope
means that you fulfill those 20 standards, and that basically gives you like this interoperability
on the virtualization layer, for example, logo or interoperability at the container layer, logo.
Important those standards are being monitored. So for each of the standards, there's a test.
We have like a very small number of exceptions where we need to have some, like some,
some manual documents, but the baseline is still everything should be automatically tested,
and should be testable also by users. So you don't need admin access to do those tests.
They run every night, and we can monitor them in the compliance monitor, and you can basically
see in the compatible ES that's the example here, some of the clouds that fulfill that. Also some
of our partners actually have been sloppy over the last days and failed them.
Now they already have been informed, they need to fix something.
But also users can see this actually. So, I mean, if you for some reasons see, okay,
the cloud I'm using is no longer working the way I, so automation somehow fails.
You could look there and see, well, maybe it's not your fault, maybe it's the providers fault.
Good. This is actually the architecture that we have implemented within the cloud
specification. So you don't see any product names there, you don't see any technology names there.
And it's a rather classical stack way to like hardware management, you have virtualization layer,
you will utilize compute storage networking, and then on top of that you can do container cluster
management. The nice thing about this architecture in a for a public cloud where you lead
like multi-tenancy and you won't like a very agile way of creating container clusters.
That's the standard way of doing that and we've been there and it works well. And also part of
these the software stack is also that you have like the operational tooling in place and the
identity and the access management that allows you to federate. This is one of the things that
I'm really proud of. So we're going back now to the gov stack context.
We have been actually starting to work with the United Nations, the dataset that people
do in ICC. They're currently building up an SCS environment that is used by the gov stack
people and maybe as important as the environment they build, we're building knowledge there
because UNICC has the ability to bring that knowledge into many countries in the world.
And that brings me to like the knowledge skills building as thing. Obviously sovereignty means
you know what you do, you know when you use technology, how to use it and what it does for you.
And so we have invested and I have beyond all of the documentation work that we've already done
inside the SCS project. I have also had the privilege that I to you actually paid for
creating training materials. So we have like five days course for advanced cloud computing
and there's like an 80 something page PDF. And unlike some other technologies or projects
we have published this under Creative Commons license. So it can be used reused and that's the
way it's meant to be. And this is just summarizing how digital sovereignty and digital
public goods belong together. I guess I'll jump over this so I have time for questions.
Just want to report, we did actually go into some countries and did these cloud trainings and
that's also after that we kind of revised the training material quite significantly once more.
The way we structured is really we kind of explained something and then we did really
life work with like a mini cloud there and had everybody kind of tried out and learned it.
And then only then once we've been successful with everybody, jumped to the next sessions.
So this was a session in Kenya where we had people from Somalia, Kenya and Djibouti
that were participating. It was also funny because we did this at English and there was
life translation in French and then sometimes we tried to speak French with the participants but
it was also a funny experience. Work well. I'll just jump to the last slide then.
Slides if you want to download them you can you can get but you can also get them from the first
them page. I just I made this before I was a way that of course the pre-talks also has
has it. I think we have three minutes for questions.
Three.
Are there any questions? Yes.
You're talking about the specifications. Yes. How do you decide how prescriptive to be with
the specification? Because the specification you can be to general and then you get
deviating implementations but you get to prescriptive then no one implements and properly
because then the two details. How do you get the balance right there?
Yeah. Okay. So the question was how to balance like being too tricked to restrict
different specifications and being too general so it doesn't have enough meaning and clarity anymore.
So we did one thing. We did develop the specifications together with the reference implementation.
So we know that the specification can be implemented. They are relevant and it works.
That has one big downside. There's a risk that your reference implementation in the end will be the
only one that implements this. So we kind of specifically reached out to other cloud providers that use
different set of technologies and thought okay can do we have something that those would not be
able to implement and I'm glad to report there's like 240 for the utilization layer which was the
first one we did. We have now two independent implementations of that that also
fulfilled the criteria. So I think we we were successful with doing that but it is something
you need to balance. I mean the question I think is spot on.
Oh sorry are you kind of keeping track of what asks first? Okay. Okay and let's
thanks. Do you have an impact metric in our many empty users and numbers of servers that
implement this data? Do you follow such a framework? Yeah. So the question is whether we track like
this success by having users or servers counted. So I can report we have six public cloud providers
that are using the technology the largest one running for regions with
a large two-ditched number of hosts and also like significant projects running on that. So
we have like one project that we we like to talk about which is the buy-and-cloud truly project.
Yeah.
Thank you.