Okay, if I can ask for your attention, we have another talk coming up.
It's by Razvan, who is somebody who also does not need a lot of introduction.
He's the unfun terrible of Unicornals.
And his talk is about the fact that Unicornals are here.
The stage is yours.
All righty, thank you so much.
Hi everyone, I'm Razvan.
I'm from the Unicraft Projects.
We were also part of FOSDEM last year.
Our Unicornal projects are now part of what we call Unicornal Alliance.
So Andrea, Valdez, Jonathan, Martin, and the others are kind of in this umbrella term.
So my talk is going to be about Unicornals finally being here.
I saw you saw a bit of highlights from Andrea, given her talks.
You're going to see more about that here.
Let's get started.
So I'm talking about application workflows.
Typically we think about, let's call them consumers and producers of software, right?
The first workflow is for people producing software.
The second one is for people using software.
If I were to make an analogy to Andrea's presentation, what she was talking about was actually users
that, I mean people that produce software.
People that produce software don't care about the underlying things.
They don't care about operating system specifics, about how they just want it to work.
Well, so do we.
Users as well, right?
There are, imagine that what you do is you're going to build the application, get the package,
push it, or then you do something like app install or that pulls it and unpacks it.
You have typically a pack, a software package.
If you imagine a dev or RPM, that's kind of it.
However, this has glitches and anyone who has done some sort of development work or even
worse, sorry, Gaby, about that doing DevOps work.
Yeah, there are nasty jobs out there, even nastier than current development.
You're going to bump into issues.
Issues such as that runs there, that doesn't run over here.
I'm using that, you're using Fedora.
You don't have those packages being compiled.
Dependency cell, I can't tell you about that.
Anyone with their right mind had to deal with OpenSS cell and OpenSS cell 1.03.03.1.
All those versions knows about that.
Also when you run a piece of software, that's generally not isolated.
If there's a glitch with that, that will affect others, supply, software, chain attacks,
all those items.
What do we do about that?
Well, generally what people have been doing nowadays is using VMs and containers.
These are trying to tackle those issues.
You want to have containers and VMs because you're going to be able to run them everywhere.
If you're using Docker, even if it's behind the scenes using Hyperview or something, you're
going to be able to run that particular image on Windows, on Mac, on different Windows,
on different Linux distros, sorry for that, all of those items.
There are no dependency issues.
You have your VM configuration, vagrant file, profile, you name it.
You're going to know that's going to work.
I'm not going to lie, I need this particular version of Node or out of the 10,000 millions
or gazillions libraries that Node has, I need to have the proper version.
You just grab that and it works.
Also, they provide isolation, which is very important to make sure they are only using
what you require that may also impact the memory footprint and they're isolated from
each other.
Of course, each of these two approaches has their issues.
Let's talk about VMs.
VMs have very good two items.
They're also mentioned, I'm going to measure next then because of the frequent mentioning,
about resource control, this is a very important feature of VMs.
You are able to allocate CPUs, memory, hard disk, you name it.
Also, you have good isolation.
For sure, there are attacks out there, hypervisor attacks, VM escapes, but they're not so common
as container escapes.
However, they have overhead.
You need a lot of time to start the VM, boot it up.
We talked about cold boots.
You have large memory size and it's also quite difficult to create recipes.
Particularly when you compare it to container size.
We have vagrant files, but even with that, it's not that easy.
On the other hand, we have containers.
Containers tend to compensate the disadvantage of virtual machines.
We have recipes, we have Docker files.
Everything is there.
You just grab it, it runs everywhere.
You have registries of application, Docker Hub, Google Container Registry.
You just do a Docker pull, something, it works.
You have a run, you pass the name, it works.
You have tooling with Docker, with Podman.
You have good performance.
You don't have that much overhead as you have with VMs.
Also, Dandrea showed what comparisons between unicunnels and containers.
But there are isolation issues.
There are a bunch of container-based attacks out there.
You don't have, you are sharing the same kernel.
If the kernel gets screwed, then that's over.
And you have imperfect disk-on-conference control.
We know we have C-groups, but it's not that level you have with virtual machines for sure.
So what we want is we want a blend of those.
And that blend is getting good isolation, good research control, recipes, registries.
We want tooling.
We got good performance.
That means that in the end, if I'm an application developer, I want all of this.
I want you to deploy my application and then users are going to just benefit.
They're going to be able to run quick, fast-booting, good, well-deserved, well-deserved, well-deserved,
well-isolated, high-performance, pre-built application packages.
And in our opinion, that solution is using unicunnels that has this combination of items here.
So this is, sorry, this is a VM to continue to unicunnel.
So kind of blend of this.
My talk is mostly focused on unicraft, as I mentioned, part of unicunnel lives.
So basically what we wanted is this.
Let's just take a tour of the items I just mentioned here as we want and see how we can achieve it.
So because unicunnels are virtual machines, the advantages of virtual machines,
meaning good isolation and good research control, are here.
Right, so you have this.
Also, we want to have recipes.
Bobby's mentioned about bunny files.
We are using, when you're using unicraft, we are using docker files.
We're using something that's called a craft file that has kind of this level of recipe.
Three set ingredients and steps to undertake to make this happen.
We have a registry of pre-built applications.
Just go there, you're going to use craft run, craft pull.
It will just work.
You're going to see the demo.
We have tooling.
It, bunny is not yet implemented.
However, it craft it.
Craft it works.
It's there, it's running.
You're going to see it for your own.
Right, and we have good performance.
That comes from the inherent design of unicunnels.
You don't have the main separation, but also it's because the way unicraft has been designed.
We aim to have extreme performance.
That was the kind of the rationale behind my question to Andre and
Vali regarding the optimization with unicunnels.
Because the way unicraft is being created is highly configurable, highly customizable.
We can specialize it for every particular load to get the best performance we can.
That means allocator schedulers, you name it.
Right, so why am I saying unicunnels are here?
If it asked me this one year ago when we had the talk in Fosden, I couldn't have said that.
But now I can.
We have a catalog of applications ready.
We have profkit well prepared.
There's also on the commercials at the platform that provides commercial support for this.
You can see it happen.
What did you have before?
And you're going to see the demo.
We had to configure the kernel.
Go to a lot of different steps.
It actually, because I tend to like to do things, but like everyone, I don't get to do them.
I spent an inordinate amount of time last night, Martin knows, because I sent his slides quite late at 2 a.m.,
something like this, which is 3 a.m. in Romania.
And I spent, I think, three hours recalling how do I build from scratch and GNEX.
I cursed Simone a little because there was a recent change with the way we are mounting file systems.
I had to squeeze a lot of items, but I managed to do it and it's now prerecorded.
You're going to see it as well.
But you have to go to a lot of steps here, configuration, build steps.
It's an awful, awful, painstaking time that I, as an app developer, not as a kernel developer, shouldn't look into.
I have to have, you're going to see a huge QMU command line.
I didn't do a demo because I don't want to scare you and ruin your dreams.
But if you go to a firecracker, you have a huge JSON file, you have to write the command line for it.
Once again, really nasty if you're just an application developer.
The application has to be porting on your craft that takes time.
I mean, on any unique kernel, actually, you have to link it properly, it takes time.
What do you have now?
We have a set of pre-built kernels.
You just do craft pooling works.
That's it.
I have an application.
I write a small Docker file.
I have my Python application.
I use craft running just for you.
You're going to see it.
There's a single command build.
Actually, there is a single one.
For running, there are two of them because I'm using a bridge interface.
I have to use two commands.
I have to use one command to create the bridge interface.
Maybe in the future, we're going to do it with one command.
But one command is to create the bridge interface.
The other command is to run the unique kernel.
On top of that, and this is something that Simone, three talks from now, I mean, 6 p.m.,
is going to show the internals of running native Linux applications.
We are basically getting pre-building applications already out there in Docker Hub, and we're running them.
So there's no need actually for you to do anything.
You just grab them and you run them.
It's that easy.
That being said, let me show you the demos.
That was the kind of the deletree part.
Let's look at the demos.
For starters, I'm going to show you the demo of the before part.
This is the way it happened before, the way we were building and running kernels before.
It's kind of a three-minute one, so let's just take a quick look.
I'm starting a T-max screen.
This is a native one.
I'm doing configuration now, and just take a look at what I do.
I select the platform.
I'm selecting the library.
There's a huge palette of them.
I'm going to engine X.
I'm using a main function.
I'm going to VFS score.
I'm selecting a pile file system and embed the initial grand disk.
You don't know what to do, but that's how complicated it was.
Going back, I need to use a new version that Simone introduced.
I'm going to dev.
I have to mount dev.
Save. This is the configuration.
I have to know all the steps.
I have those steps.
What I'm trying to do, I need to create the initial grand disk.
There's a command that I need to create.
There's a makeMKCpIO command.
I'm packing the file system inside the initial grand disk.
That's packed. I'm now building it.
It's going to take about one minute to build.
They're just going to look a bit about that.
All of these items, of course, can be automated in some source,
but you have to know them.
Every time I was testing,
I was trying to build something,
I get this option.
I'm doing a lot of community interaction.
It's painful to see people constantly bumping into the same kind of issues.
Are you sure you're using staging?
Are you sure you're mounting 9PFS?
Did you select that particular weird,
maybe you don't think that option there?
These items were things that people were constantly bumping into.
Now, this is now going to get built.
It's the final linking step.
And in the end, we're going to end up with the final kernel image.
I'm now adding an interesting command to create the final link.
It's an interesting command to create the bridge interface.
And now I have even a larger command.
I know, baby, it's amazing.
And it's going to run.
I'm opening a second console.
It's running, so it's okay.
But you can imagine how much time and effort
you can see that the huge command there for Kimu was to make this happen.
So this was the before part.
This was the thing that I would say unicunals are not there.
However, let's look at something else.
So what I'm now doing is I'm using craft.
There are two commands.
I'm using a bridge interface just to make it more realistic.
So I'm using a bridge interface.
And now I'm running on that bridge interface.
I'm running the same engine X image that's now pre-packaged, pre-built,
pre-deployed inside the registry.
It started.
I'm going to query.
It's start behind the scenes.
I'm going to query it.
That's it.
So I can now just say, okay, that's the VM.
It started.
If I want to not use it anymore, I can simply remove it.
And that's it.
It's just on screen, right?
That's what happened.
Let's look at something else.
Let's look at what we do with Python.
Let me say, I think this could be it.
Let me see if this is it.
No, this is not it.
Sorry.
How do I close this?
Q.
Okay.
I think it's this one.
Yeah.
So Python is also there.
Once again, two commands.
One command to create the bridge interface.
And one command to run it.
So I'm using craft run minus, minus net or for the network interface.
Yeah, a bit more memory because it's Python.
It could be worse.
It could be it could be node.
Yeah.
Oh, they'll go there.
Okay.
So I'm using Python.
I'm using the latest version.
It's pulling it from our registry.
And it's already there.
I'm just curling it.
It's port 8080.
And it's running.
Of course, now the similar using craft PS to make sure I have the virtual machine and
I'm now able to remove it.
And that's going to be it.
Right.
Once again, two commands.
One for the network.
The other for starting this.
How can I make this so?
Okay.
You saw someone starting Python.
How can I do it myself?
Well, I have this here.
I have another server.
I have some craft file.
If you see here, there's a different Docker.
I'm using this command.
I'm saying, let's create the network.
Right.
And I'm going to just copy the new server.
So this is the way I'm customizing the build.
It's similar to the new file system.
This is the new file system.
And now I'm going to run this.
I need to have that export because we're using build kit from Docker behind the scenes.
Right.
And now it's going to grab that image.
It's going to grab it.
That's the kernel.
It's going to copy the Docker file.
It's now building the Docker file.
It's from scratch.
It's just copying that information.
Similar to what you do in a Linux environment.
And I'm running.
And that's it.
And it works.
Right.
So it's now saying buy world.
And finally, let me show you something a bit more complicated.
Let's run flash with Python.
Right.
So let's do it.
I have a simple flash server.
I have the Docker file, which says, okay, you need to...
This is similar to having a Docker installment.
Right.
So I have the Docker file from Python, install the requirements.
Then you're going to copy the implementation on it together with the libraries.
And that's it.
So I have the server.
I have a Docker file similar to the Docker environment.
And I'm saying, hey, grab the Python image, grab the Python kernel, run this from the Docker
file, and then copy the...
And then execute the...
My server here.
Right.
I'm doing this to craft this build kit export from Docker.
And I'm running it.
And this will end up pulling the image.
So you can check this out.
It's going to pull the Python image, pulling.
It's going to build now via Docker, via build kit the flash item.
And now it's running it.
And I'm just going to just curl the virtual machine.
And everything is there.
Hello from Flask.
Right.
All of this is now possible.
You have the image, node, Python, whatever you want.
You have your application.
Do a Docker file for it.
Use Croft on it just works.
So these were all the items that you saw earlier.
All of these you can check in our catalog.
There is an...
We call it the community catalog.
There is also on the company side of Croft, there's a kind of a more commercial version
of Croft.
There are guides that we just published that are available showing you how you can use
the catalog or add images to the catalog.
And you can simply take care of this.
Just run on command or to command and it works.
Unicolas are here.
All of those items are now in check.
And together with optimizations such as those mentioned by Andrea and Vali,
we are able to truly make use of cloud-based deployments.
There are some other resources, catalog guides, see us on GitHub.
If you're wanting to sit on a commercial side of things, as Maloga says,
there is a platform using Croft Cloud, you can visit that and find more information.
That's it.
Thank you so much.
Thank you.
We have time for one or two quick questions.
Oh, God.
You have to get the mic for the stream.
So you mentioned that Docker isolation, sometimes the resource control, sometimes is it enough?
Can you name some cases where it's not enough?
Not necessarily.
I'm not saying it's not enough.
It's that the VM is, I would say, a better one.
Because when you do a VM, you actually are able to provide different volume.
And I think that also, CPU isolation, I'm not sure if, I don't know much about C group.
It's kind of, I know VM resource control is better.
I'm not saying it's for all these cases.
I'm sure there are cases where Docker containers may be enough,
but maybe there are cases where you want to have VM-based isolation.
And Unicron will provide that.
Final question?
Yeah.
Oh.
Maybe pass it on.
Maybe be asked.
Maybe just ask.
Maybe just, I'm going to repeat the question.
Yeah.
So is that like an underlying kind of road time that would manage these VMs
and how much your container, do you need a doctor to do this?
Would there be a similar kind of Unicron or do you need a problem?
Yeah.
There is actually, I'm not the person to answer that.
It's Alex, he's kind of a tooling guy.
But there is work being done towards that.
There was something that was at some point called RunU for Run Unicron.
And I don't know, actually the Nubificus guys have something that's called UK Run.
So there's work being done for that.
That's planned for Kubernetes integration if it's not already there.
So that's already ongoing.
If it's not yet public, it's because we have focus on getting items going first.
But integration and tooling on all those container-based ecosystem is high priority on the tooling side.
Yeah, yeah, for sure.
It's on the menu.
Thank you, Rosvan.
Thank you.
Time's up.
Thanks for everything.
For anything we can talk in the breaks.
Thanks.