Why you don't always need a general-purpose operating system
A purpose-built, or real-time, operating system could be more useful for applications that require a lot of data processing. Several options for this type of system exist today.
Applications that require high CPU performance or fast scale-out capabilities could benefit from eliminating the general-purpose operating system and using something purpose-built instead.
The most common operating systems today are Microsoft Windows, Apple iOS and macOS, Google Android and Linux. These are all examples of general-purpose operating systems, which are developed to support a variety of independently developed applications and provide support for a wide range of functions.
Applications, on the other hand, are typically written in a way that ties them to the operating system type that IT will deploy them on. Even web applications running in Docker containers still generally end up being tied to a specific OS, web server and/or database. Cross-platform application development is an option, but it is often more efficient to build an application using the OS and library stack that IT will ultimately deploy it on instead. Building applications on a general-purpose operating system usually leads to higher programming productivity due to better-developed tooling, and there is a potentially lower development cost due to the larger pool of talent available.
Production productivity is reduced, however, because a general-purpose operating system is very inefficient and wastes massive resources for things the application does not need or use.
There are other choices out there for the IT industry to consider when it comes to OS support.
The case against a general-purpose OS
I have spent most of my career developing and working with applications on general-purpose operating systems, but I also spent about 15 years working on communications equipment with applications designed with a purpose-built OS that matched the application's specific requirements.
These terminals were generally small to medium-sized boxes that had minimal hardware due to cost restrictions. To develop the application, I used a hand-crafted OS with just what was needed and nothing more. The OS and application were stored in programmable read-only memory, and I had no need even for a file system. I allocated memory in fixed-sized chunks only, allowing for very simple memory management by eliminating the need for garbage collection.
When the concept of virtual machines became popular, I started to question how many VMs could fit on the hardware. Having individual applications hosted on a purpose-built OS would be very efficient, but that thought was abandoned as we all focused on taking the simplest path -- putting the web-services-based applications, and maybe desktops, in the cloud. Containers -- introduced as a faster and lower overhead alternative to separate VMs -- in reality are more important for the security aspects of sharing infrastructure than for performance.
But what happens when we have applications that use significantly more compute resources than storage? Or require the ability to have new instances start as instantaneously as possible? Or what if the cost model of cloud services becomes more CPU-oriented? With all the interest in machine learning, which handles more data than ever before, these questions become more important.
Options for purpose-built OSes
Alternatives to a general-purpose operating system include some open source and commercial products, which break down into three camps:
Unikernel. The idea behind the Unikernel, sometimes referred to as MirageOS architecture, is that it avoids the overhead of virtual memory and user and kernel mode transitions. It also allows the application developer to select from libraries that provide the functionality required. These libraries are then built with the application as a single image, suitable for fast booting. If the application must run on a hypervisor, the developer must build in support for interfacing with the hypervisor in lieu of a hardware device driver. These systems tend to be used in Linux or Xen-based hypervisors.
I used a hand-crafted OS with just what was needed and nothing more.
Unikernel-based VMs can be quite small, as small as 5-10 MB, and can boot in as little as 20 milliseconds. But once they are running, the application can make full use of the CPU, network and file systems. In addition to the OS having lower overhead because full system compiler optimization is possible, the code that does run will be extremely efficient.
Examples of Unikernel implementations include Mirage, Drawbridge, ClickOS, HalVM and OSv.
Microkernel. The concept of the Microkernel, while also based on libraries, relies more on the traditional protection ring-based security architecture that general-purpose OSes use. The difference is that the kernel directly supports only minimal functionality, and it pushes functionality into optional user-mode libraries. For example, hardware device drivers are user-mode code in this architecture. For single-application usage, these libraries are implemented as direct user-mode function calls -- improving performance over traditional kernels by avoiding both context-switching and ring traversals.
The concept of the Microkernel has been around for quite some time, but some of the early implementations failed to demonstrate the expected performance gains. They are, however, quite popular on single-purpose applications on small physical devices, such as communications equipment, where they are often referred to as real-time operating systems.
Exokernel. The concept of the Exokernel is to build the OS in a fairly traditional manner, but to focus on efficiency by reducing the levels of abstraction between the application and the hardware. The Exokernel concepts of pass-through support without abstraction are very similar to those of paravirtualization in hypervisors.
The Exokernel is mostly a research concept, and it does not have known commercial implementations at this point.
As machine learning and IoT applications grow in the enterprise, organizations and IT departments should consider the potential operating cost savings of purpose-built OSes over containers on a general-purpose operating system.
