In 1886 the German engineers Gottlieb Daimler and Wilhelm Maybach unveiled to the public a converted stagecoach. They removed the stagecoach’s drawbar and added a petrol engine to move two of its wheels. Technically, it was still a stagecoach, not an automobile. The Benz Patent-Motorwagen launched that same year had a completely new chassis design. Its rear-mounted engine only had three wheels, however, because its inventor, Karl Benz, wasn’t able to solve the four-wheel steering problem. This would come years later, with the re-invention of the Ackermann steering, also known as axle pivot steering or “A-steering”. Until then, cars would be steered with a tiller.
In the age of steam power, each factory had one engine with a giant driveshaft running through it. When the electric engine came along factories replaced the giant steam engine with a giant electric motor. It took time before people realised it was more efficient to deploy several small motors in different parts of the factory and connect electric cables rather than having one common driveshaft.
History has shown that technological revolutions are full of transition periods during which we come to fully understand the implications and potential of various inventions.
OS – An Anachronism from the Good Old Days of Time Sharing Systems
Looking back on the more recent history of computing, one anachronism that persists to the present day is the operating system (OS). The OS as we know it dates back to the seventies when huge time sharing systems were replacing the old punch card computers. Time sharing systems were a kind of virtualization and were fast and efficient compared to punch cards.
Before modern operating systems, programmers punched codes on cards and fed them into a computer. If the cards were punched incorrectly, the programmer would only discover this after the code was compiled, which took about a day. Systems could only run one program at a time. This was fine at the time, but you couldn’t assign a computer to a person as the cost prohibited this.
Time sharing systems introduced in the seventies had much more processing power and were much faster. Several users shared these huge, expensive systems, which could run multiple programmes at the same time.
This meant they needed an operating system that kept users separate from processing. Operating systems like Unix were born. These OSs took over hardware resource management, allocated memory and provided generic services for the different programmes that ran on the host machines. They shielded the applications from the processing, creating two spaces – user space and kernel space.
Switching between these two spaces requires time (back in the 70s we had plenty) and processing power. This dichotomy of user and kernel space made a lot of sense when applications ran on big shared servers. However this model still persists today even though the multi-user system is long dead. A cloud server today, for example, is typically dedicated to a single task and likely to have one user and one process. This means that in a multi-tenant environment each user’s application exists in a silo but still needs to run its own full OS.
The general purpose OS is heavy (Linux and Windows are about 2GB) and particularly out of time in modern cloud environments. When running applications in the cloud, a traditional OS’ large size requires you to invest in hardware, electricity, cooling and also maintenance. It also means applications take a long time to load and to start up. Their large code bases and the fact that they need continuous updates makes them insecure, prone to bugs and attacks.
Unikernels: A-steering for your App
The first two automobiles mentioned earlier lacked one important thing – a steering system adapted to four-wheel motor vehicles. This came years later with the advent of “A-steering,” which became the launch pad for further innovations like the steering wheel.
For cloud applications, unikernels are can be compared to A-steering.
Unikernels best match the requirements of lightweight applications such as gateways, proxies, load balancing, firewalls and API endpoints running in the newly created virtual cloud environments.
Unikernels dispense with the legacy overhead required for the original time sharing systems. They just inject the kernel functionality needed to run an application into the application itself, merging kernel and user space. A bit like the punch card, both the application and its library share the same “address”. The need for resource-intensive switching between kernel and user space is eliminated. No resources are wasted, apps are lightweight, and can booted up and stopped very fast. Also, their smaller code base makes unikernels less prone to bugs.
A closer look at a unikernel reveals a startup programme (bootloader), application code, some networking drivers and minimal library functionality needed to build and run your application. The code running inside the unikernel doesn’t share any code with that of the virtual machine on which it is running. This makes it very secure compared to traditional operating systems.
The Achilles heel of a general purpose operating system is its ability to modify itself. This means that if you are able to subvert a computer running a classic general purpose operating system you can make it do your bidding. This is what makes these computer such attractive targets. If you can gain control they can do anything.
So unikernels are fast, small, resource efficient, flexible and very secure.
They are ideal for lightweight applications in virtualised cloud infrastructures such as gateways, proxies, load balancing or firewalls.
There is also a place for them where space is limited and security and real-time matters like in CPU-based IoT or ultra low-latency applications like high frequency trading.
Don’t Drive your Car with a Tiller!
To take full advantage of today’s technological possibilities, it’s high time to reconsider the traditional OS and look into unikernels. However for many people it’s still not obvious that we’ve left the seventies and its anachronistic time sharing system behind. Even though many are running all their applications in the cloud and in software defined environment.
If you’re still having doubts, consider this: would you still drive your car with a tiller?