What Can Containers and Unikernels Learn from Raspberry Pi and Arduino?

Unikernels, Rump kernels, and mini Linux distributions are operating systems built for specific purposes. These specialized operating systems are somewhat like custom circuit boards. They require upfront investment and design, but when deployed at scale, they can deliver powerful performance.

— Scott McCarty

Compiled from: https://opensource.com/business/16/5/containers-unikernels-learn-arduino-raspberry-pi Author: Scott McCartyTranslator: MikeCoder

One day, I was chatting with a friend who is a mechanical engineer. He was recently working on an electronic brake assistance system for semi-trucks, and he mentioned that their office is filled with Arduinos[1]. This is mainly to allow employees to quickly experiment with new ideas. He also mentioned that Arduinos are actually more expensive than making your own circuit boards. I was shocked by this because my impression from the software industry was that Arduinos are cheaper than custom circuit boards.

I often see Arduinos[2] and Raspberry Pis[3] as small, cool, special components that can be used to create very interesting devices. I primarily work in the software industry and have always felt that Linux running on x86 and x86-64 devices is considered ‘general purpose.’ The reality is that Arduinos are not specialized; they are actually quite general-purpose. They are small, cheap, and very flexible. This is why they have become popular like wildfire. They have a full range of input/output devices and expansion cards. They allow makers to quickly build very cool devices. They even enable companies to rapidly develop products.

The unit price of an Arduino is much higher than that of mass-produced circuit boards, but the unseen time cost is significantly lower. When circuit boards are mass-produced, the price can be kept very low, but the prior R&D costs are much higher. So, in summary, the answer is that using Arduino is worth it.

Unikernels, Rump kernels, and container hosts

Mini operating systems, such as Red Hat Enterprise Atomic or CoreOS, are built to run containers. They are small, fast, easy to configure at boot time, and well-suited for running containers. The downside is that they require additional engineering work to add third-party plugins, such as monitoring clients or virtualization tools. The side effect is that the loaded tools also need to be redesigned as superuser containers. If you are building a massive container environment, this extra workload is worthwhile. However, if you just want to try out containers, it may not be necessary.

Containers provide the ability to run standardized workflows (such as using glibc[4] compiled). One benefit is that you can build and test this unit of work (Docker image) on your computer and deploy it very smoothly on completely different hardware or in the cloud while maintaining the same characteristics. In production environments, the container host is still managed by the operations team, but the applications are controlled by the development team. This is the best collaboration for both parties.

Unikernels and Rump kernels are still built for specific goals but take it a step further. The entire operating system is configured by developers or architects during the build process. This brings benefits as well as challenges.

One benefit is that developers can control how the workflow operates. Theoretically, a developer can try different TCP stacks[5] for different features and choose the best one. When the operating system starts, the developer can also configure the IP address rather than using DHCP. Developers can also trim any parts that are unnecessary for the application. This is also a guarantee of performance improvement because it reduces unnecessary context switching[6].

At the same time, Unikernels also bring challenges. Currently, many tools are still missing. Now, similar to the world of drawing circuit boards, developers need to spend a lot of time and effort checking for the existence of complete library files; otherwise, they must change how their applications execute. There are also challenges in how to configure this ’embedded’ operating system at runtime. Finally, every major change to the operating system requires feedback to developers[7] for modifications. There is no clear boundary between development and operations, so I can imagine that for some organizations or companies to accept this development process, they must change.

Conclusion

There are also some interesting rumors about specialized container hosts like Rump kernels and Unikernels, as they may bring a potential transformation to specific workflows (embedded, cloud, etc.). Please stay tuned in this exciting and fast-evolving field, but also be cautious.

Currently, Unikernels look very much like custom circuit boards. They both require upfront R&D investment and are very unique, bringing benefits to specific workflows. At the same time, containers are even interesting in conventional workflows and do not require as much investment. A simple example is that operations teams can easily deploy an application on a container, but deploying an application on a Unikernel requires redesigning and recoding, and the industry cannot fully guarantee that this workflow can be deployed on a Unikernel.

Containers, Rump kernels, and Unikernels have a bright future!

via: https://opensource.com/business/16/5/containers-unikernels-learn-arduino-raspberry-pi

Author: Scott McCarty[8] Translator: MikeCoder Proofreader: wxy

This article was originally translated by LCTT[9] and is proudly presented by Linux China