So, I'm going to talk about the architecture.
All right.
Are we ready for the next session?
So my name is Wim Hendricks.
I work in Nokia.
I'm heading the technology and architecture.
In this talk, I'm going to talk about nephew.
Nephils are about thousands of sites that potentially have to be working together to
actually make this service happen to all of you who are using smartphones or tablets
and what have you.
So that's kind of the problem space that we are trying to work upon in nephew.
And so there is basically a set of issues.
One is the scale.
The second is the heterogeneous environments of all these network connections and making
them work seamlessly together.
And then, of course, we are working into an environment where there is just not one single
person in an organization involved.
There is multiple roles within an organization who are actually involved.
So that is what we call infra people.
And that is the application side of people.
There will be security people and so on and so forth.
So we have to deal with all the roles and responsibilities in an organization who actually
take care of certain aspects of that deployment that has to happen to make this service work.
All right.
Moreover, what you see is that if you look to, let's say, a mobile network, right, so
we are talking sometimes about terabits of capacity.
So that means that we are also, me being part of a vendor, right?
So we used to basically own and control every piece of that stack, right?
But because we are moving into this cloud-native environment, we have now desegregated stuff,
right?
The problem that we also face is that we are trying to have very tight control over the
infra and we want to basically work in that cloud-native space, right?
So the question is, how do you do that?
Because you have to basically give away some of that control to other people, right?
So if you can see, we are looking at this is a quite challenging space, right?
And what has happened so far in the past is that every vendor, including ourselves, we
basically said, okay, we control our own pace and then we have a bit of different vendors
involved.
And so what you will see is that you will end up being, connecting multiple components
and components and components and it's actually quite challenging to do that in a cloud-native
way.
So we basically said, okay, can we do better, right?
And this is where Nefio was born, in a sense, because we said, okay, all of these workloads,
they are moving inside of a cloud-native space, meaning they are moving into a Kubernetes
environment, right?
And it's nice to basically do this aggregation.
We can do microservices.
We can basically put all these components onto a Kubernetes environment.
Why don't we leverage that same framework to basically automate and orchestrate the configuration
and the setup of that whole stack, right?
And that's kind of, right?
Now in Nefio, we basically do two things.
We basically look at, on one hand, the application itself, right, which is 5G.
And then we also look at a set of primitives that are not yet available to us that we would
like to have to solve this problem, right?
So we basically do two things.
One is we are basically defining the use case that we are using to actually figure out what
are the primitives that we are missing.
And then we are basically adding those missing components inside of a Kubernetes framework
to be able to address those problem spaces.
And as such, I mean, we leverage KRM.
So I haven't asked, so Kubernetes is probably a lot of people familiar with that.
If you want to show hands, Kubernetes, I think we should be fairly familiar.
Okay, pretty good.
So we leverage, so you are familiar with the term of KRM, right?
So KRM is the Kubernetes resource model, and we leverage that all the way, right?
So that means we have a clearly defined API.
We have the set of metadata.
We leverage the desired versus observed state to basically figure out a declarative base
of operation.
We leverage the event-driven ecosystem and stuff like that.
So we leverage that to the full extent.
Now what we have seen in order to solve that problem at scale, we were missing a few primitives,
right?
And one of those primitives that we have been added to the component is what we call configuration
as data, right?
Because if you look to how Kubernetes works as its basis, you actually have a CRD or a
Kubernetes resource that is basically triggering something, right?
Now because we are dealing with this massively complex environment, right, we said, okay,
a single unit is probably not sufficient for us.
So we defined the concept of a package, right?
So rather than having a single CRD, we actually built a package, and a package is a collection
of KRM resources that you are going to use as a kind of what we call a blueprint or a
service catalog, right?
So it's basically think of it as a collection of KRM resources that do things together,
right?
The second thing that we did is today in order to use Kubernetes, you typically have to build
a controller in code and stuff like that, right?
So we added the capability better.
You basically say I want to create a deployment and then there will be a replica set controller
which basically says, okay, I'm going to select this node and I'm going to scale this out
and I'm going to deploy a set of POTS over a number of resources, right?
That's what typically happens today inside of Kubernetes and you have different methods
to do so.
You have deployment, you have replica sets and so on and so forth, or stateful sets,
and you pick and choose the one that's familiar with you.
Even that we work above a cluster level, what we do in nephew, we call it a term, what
we call a package variant or a package variant set which basically says I want to have my
package which I was talking about and I want to deploy that on these sites, right?
And each of these sites will then be what we call specialized within their own context
where the relative parameters, for example, this site needs this VLAN, this site needs
this IP address, this size needs these PLM and ID's and stuff like that.
So they will be specialized based on their specific context on where they get deployed
and as a result, that's then being deployed on that particular cluster, right?
So you see that if you look to the analogy of Kubernetes, we are working at the level,
at the cluster level versus where as Kubernetes works at the node level scheduling type of
level.
So we work a level above but you see a lot of concepts that were born or that were basically
derived from Kubernetes.
We are leveraging within the framework that we are deploying within nephew in order to
stay as close as possible to it so that we can leverage the benefits of that whole ecosystem.
Now to put that into perspective, I try to explain that a little bit.
So we have a concept of management clusters.
So this is a regular Kubernetes cluster but we use it typically for our control engines,
right?
This is where our, what we call the configuration as data server which is ported in our implementation
is used upon and then we schedule work, network functions onto those specific workloads, right?
And how we do that is we basically have this concept of a package on the right hand side
which is our blueprint.
So think about someone as a vendor or as an operator, someone basically put that together,
right?
So we have the KRM resources that are needed for that particular environment and then we
say, okay, I want to deploy that on 10,000 sites, right?
When we do this, when we try to make variations of that package for a particular context,
we also said, okay, let's divide and conquer, right?
So because you could basically build a pipeline that is very narrow and very strict, right?
But typically what we see is that you need flexibility, right?
So you want to have a flexible system.
And so we developed a concept, what we call the conditional dance of the choreography which
is a set of primitives, I think of functions here that each do a specific thing.
So for example, IP address, VLANs and so on and so forth.
And each of them basically make sure that if those things are needed, they are basically
being called upon and specialized those packages with a specific context for that type of environment.
And that's how we can make this work in a very scalable and flexible and pluggable play
and it's easily to extend that within a specific environment.
So what did we do so far within Nefuse?
We are a very early pro yet.
So and it would be good if people would like to join us.
So we have done, so we are just about to release release two, right?
So what we have shown so far is basically the concept that I showed in the beginning.
We have basically proven that with Free5GC.
So Free5GC is an open source project that basically deploys the core side of a 5G type
of network.
So we have basically proven that we can use the machinery to actually deploy and show
what I'm presenting here in the slides is actually working up to setting up a call, right?
So we are using the whole network setup that actually connects all of these functions together.
So all of that using the primitives that I was showing.
And in release two we added OII which is another open source project mainly focused on the
radio but also as the core so that we prove that we can do this not across one vendor
but across multiple vendors, right?
And so we are extending this whole framework with more primitives as we go along.
As I said, we are a very young project, right?
And so we seek for a lot of help.
So if you are interested to join us, we would welcome.
So please contact me or please look at one of those resources that are available here
because this is all the information which you can have a look at to the operation.
And what you see is that you can actually move rather more quickly than in an on-up
type of approach but we are actually trying to solve a different level.
So what we call the domain level whereas on-up is working at the orchestration level.
Okay.
And so is the same if we say the advantage of NetEar over VMware, orchestrator or other
vendors?
Yeah.
So I think, see, okay, I'm of course trying to advocate it but personally I see the following.
Kubernetes has been the orchestration for containers, right?
That was where it is born.
If you ask me, it has the right primitives to be an automation and orchestration platform
for anything.
So I see Kubernetes as an operating system to actually do any automation, right?
That doesn't mean.
And what is the advantage of that in my view is that, so when you have all of these different
components, first of all, you have a huge ecosystem in open source that is developing
and extending Kubernetes for lots of use cases, right?
So you can deploy AWS resources, Google resources, you can deploy clusters, you can set up servers.
So you first leverage a huge ecosystem that is being developed in open source which we
should all love in this room, right?
Secondly, that doesn't mean that you can as a vendor not benefit or do things specifically
but the big advantage for you as a consumer when we do that is today when you do VMware
orchestration, you build your own VMware orchestration server with your own database
with your own and then you see it's not only VMware orchestration, you need a bit of this
component and a bit of that component and a bit of this component and all of a sudden
you have more servers to serve the network than actually the network.
I'm exaggerating, right?
But the advantage what I see personally is that you look at automation from these, the
use case still will be specific to you and there will be a VMware specific controller,
right?
But if you build it on the same platform, you as a consumer, we benefit from not having
to deploy another platform but leverage what we already have if that suits you.
That doesn't mean you cannot deploy another Kubernetes instance for that specific environment,
right?
But at least the integration.