 Hello, everyone, and thanks for coming. I'm Matias Fara, and I work at Huawei France. In this presentation, I'm going to talk about the deployment of microservice as micro-VM total guess. I hope you enjoyed the presentation. Before I go deeply into the presentation, I would like to picture what is a microservice. Usually speaking, a microservice is a way to decompose a monolithic application into a simpler component, namely service. Each service provides a functionality. One possible way to deploy microservice is by using virtual machines. This pattern is called a service instant per VM. The deployment of microservice as virtual machines has many true benefits. First, it allows to isolate microservice. This means that they can interface one each other. Second, you can leverage on cloud infrastructure like Amazon web service or Google Cloud Engine. So let's see how is the actual deployment of a microservice by following this pattern. I'm going to describe the picture from button to top. We have a bare metal host which contains an operating system and the hypervisor. In the context of each virtual machines, we have the device model which is created by the virtual machine monitor, which could be QMU or Firecracker. And the microservice run as a user application on top of a general proposed OS. Let's see what are the features that a general proposed OS provides. Generally speaking, our operating system has a scheduler, file system, networking, and some drivers. There is a separation between user and current space. And the microservice is secured as a user process with on-memory space. And the communication between user and kernel is based on these calls. However, a general proposed OS consumes a lot of resources like memory, CPU, and in this mesh. Also, the creation and storage of this sort of VM is complicated. For example, if a mesh is deployed in different cloud providers, different drivers should be back it. The reason is that, for example, the device model for Amazon web service is not the same as the Google Cloud Engine. Also, the VM stayed too long to be up and running, which makes it hard to implement continuous integration and deployment of microservice. So the result of consuming so much resources makes that we can only host a few virtual machines per host, and in addition, the maintenance of these VMs is high. So to reduce the complexity of a general proposed OS for a dedicated task as microservice, and at the same time leverage on the strong installation that virtual machines provide, some approaches propose to use a unique kernel to host microservice. A unique kernel is when you compile the kernel with the user applications. Currently, there are different unique kernels which are used in different scenarios like OSV, MiraschOS, Unicraft, Nine of the Ends, et cetera. In these approaches, the kernel and the application share the memory space. The kernel code and user code are combined into a single binary. And in most of these approaches, there is no separation between user space and kernel space, no context switching, no paging, and the CSCAL shows calls to kernel code. However, the port of an application takes time and effort. So sometimes, a unique kernel must be redone for each new application that needs to be ported. So in this context, TORO is a unique kernel that provides a minimalistic API to develop microservice. I'm going to present TORO in the following slides. So TORO is an application-oriented kernel which provides a minimalistic API to write applications. The unique kernel is mainly made of five models. So for example, the threads unit allows the manipulation of threads. The memory unit allows the allocation of memory. The whole kernel is about 18 kilolines of code. So to get a better performance on KVM, TORO focus on built-in devices and the networking support both blocking and no blocking so-called interface. So in TORO, the usual application and the kernel compile together, and the user application has to explicitly define what are the components that must be included. To define this, the developer must specifically specify the unit that must be added by using the keyword use. So the result in your binary contains both the kernel and the application. This binary is immutable in the sense that you can use the same binary in different hypervisals without modifying it that simplifies the maintenance of the microservice. Then we use a script called Clioly to create events in different hypervisals. But let's see how much work is needed to deploy an appliance like a web server by using TORO and how much work is needed. To illustrate the amount of work to deploy an appliance, I'm going to use as a real example the web server appliance, which is a simple microservice that serves a file by using HTTP. This appliance currently used to host the TORO website. So in term of code, this appliance needs to get connection from the internet and be able to read files. So it needs to include a network driver and a block driver. And in addition, the appliance needs to include a file system like FAT or Extend. And also the TCP IPS tag. So the microservice has to be compiled with this code. In terms of device model, we need to set up the devices that the appliance is going to use. So for example, in this case, the device model must include a built-in network core and a built-in block for block devices. To deploy the appliance, two of these files are needed. First, the binary that contains Hekutauwe code, which is an ELF64 binary, and the files that appliance hosts. Generally speaking, the binary is about 250 kilobyte, but the files could be in the order of megabyte or gigabyte. And finally, to provide that working for the VM, we need to set up, for example, the IP of the VM, but also the IP of the host. In addition to expose the VM to internet, we have to set up some sort of IP for warding, for example. So let's summarize the main drawbacks of this configuration. First, this image consumes memory and on this space. For example, each guest has its own image. This image has to be written in all nodes. And the use of a TCP IPS tag requires configuration like bridge and IP bar per guest, guest drivers, devices. Also, the use of more devices increase the tag surface. Sharing of files between guest and host is most of the time hard and complicated. And relying on a specific file system in the guest is not good for MLW image. So the question was, can we do better? And when I said, can we do better, I mean, can we simplify the configuration steps? Can we reduce the tag surface? Can we still provide a reliable shared files system? Can we reduce the VM CPU consumption and footprints? So we propose to title this issue by providing a cloud infrastructure in which VMs are micro VMs. Networking on file system in the guest is implemented by using build IOV socket and build IOFS. And a distributed files system is implemented by using CF. In the following, I'm going to briefly present these technologies and explain how they were implemented in Toro. So build IOFS and build IOV socket are both build IOV devices. Different than other devices that are in kernel devices, so they are more performant than emulated devices. I'm not sure about build IOV socket, but in the case of build IOFS, it is in KMU since 5.0. In the case of micro VM, it is a minimalistic KMU machine, which is inspired by Firecracker. It provides several benefits, like reduced device model based on build IO, improved booting time and reduced footprint. So let's talk about a bit build IOFS and build IOV socket in the context of Toro. Build IOFS is a build IO device that allows to share a directory between the guest and the host. In the guest side, you only need a build IOFS drive. The device is supported by micro VM. Machine, the only requirement is to support, is that the driver has to support the build IOV transport layer. In the host side, you need a demo name in build IOFS, D, in which you have to set up what is the directory to share and a tag that is afterward used by the guest. The use of build IOFS has several benefits. For example, we don't need to base on a specific file system. This means that the binary can be immutable. The configuration for build IOFS is minimal, so you don't need image anymore. The unicolonial source code and architecture can be drastically reduced. For example, the virtual file system becomes a driver for build IOFS. You can remove buffer cache, file system driver, and block driver, for example. In the case of build IOV sockets, it allows to establish a positive socket-based communication between the host and the guest, in which each guest has a context ID to be identified. So the use of build IOV sockets has several benefits, like simple configuration on the guest, no need of TCP IPS tag, no need of build IO net, et cetera. In case of you want to expose the virtual machine to internet, you need some sort of proxy to forward traffic from internet to the guest. And the last piece in this architecture is the share file system. Follow all nodes to access to a common file system. We build a CFFS cluster, and we use it to provide the binaries of the VMs and the files. I'm going to talk a bit about this cluster and how it has been developed. So to try this architecture, I build a three nodes CF cluster. Each node participates with 10 gigabytes of disk to the cluster, and I use the public cloud OVH. Each cluster is a true core with eight gigabytes of memory, and the cost of each node is about 16 euros. To deploy the virtual machines, I ran in two cheaper nodes. These are one core and two share of memory hosts that cost about three euros per month. In this machine, I mounted the CFFS file system, and the cluster has been used to store binaries for the VMs and the files that are servered by the microservice. The hosts client one and client two are easy to deploy the microservice. To ease the creation of virtual machines, I started an open source project on these machines, named XMLRAP, which allows to automate the launching of VMs. So for example, to ease the forwarding of ports, to launch the CFFS and so on. So I have some results about evaluation of the architecture. So the binary side, which is the binary includes the kernel and the user application has about 235 kilobytes. The time to review the microservice is about 500 millisecond, which is the compilation times. And it's just the time that's going to impact the ability to do continuous deployment and integration of microservice. And the boot cycle, which is turning off and on of the microservice is about 80 milliseconds. And just to have in mind that an echo hello world takes about two and a half milliseconds. And other important factor I was interested in was the CPU sash. In this case, the VM comes in 90% of the CPU, what is answering a request. And then when it's completely asleep, means that the core is halt or the VM is halt. And it is taking about 100% of CPU. And the memory footprint per VM is around 2.9% of memory, which is about 60 megabytes or 35 VMs per host. In this case, I have compiled the key and moved all the configuration enable. And it shows to have in mind that the whole cluster, it goes about 58 euros a month. So it makes that it's spent about 85 symptoms euros per month per VM. And I have also uploaded all the scripts and the tutorial to create your own cloud based on the configuration that's just presented. So in the follow way, I'm going to show a video that a present the implementation of these architecture. So what we see here is first is the dashboard of CF. We can see we have three nodes. And as I said, each one contrued with 10 gigabytes with me would make 30 gigabytes of total of the of the whole cluster. Then we have XML route, which is the tool that's going to, we are using to ease the deployment of the VM. So for example, here we have the two nodes and the static web server microservice. We have some parameters like the binary and the file system that is shared to the host and also the forwarding of the port between the host and the guest. And we can also have the output of the e-screen if we click on the web socket. So this is the screen of the of the VM. And it could be completed by using headless, but in this case, I just combine with the screen. And this is the total website and I'm going to refresh shows to show that the VM is and total is currently answering. And so for example, if now I'm refresh, and we're going to see that the screen screw up, I'm going to do it again, since it's not really evident. We can see that the screen move up. And now I'm going to just get a picture and see that this quality output in the VM. So yeah, well, this is sort of the challenges that I face and I'm continually facing at the moment in order to improve the deployment of this architecture. First, I would like to improve the support for live migration, which is not currently supported by micro VM machine. Also, I see that we have a sort of bottleneck when we have to forward traffic from the internet to the guests. So we have to improve the way we do it in that case. And I think we have, we can improve the overall performance by using set of copy when we use built AFS and built IOV socket. This is more in the guest site in the drivers, in the total drivers. And I think current evaluation of this architecture should be improved by comparing with approaches like unique kernels, containers, and also general proposed OS. And all these challenge remain as a future word. So, well, I finished the presentation. So if you have any question, feel free to ask. Thank you very much.