12/19/18
Public cloud services -- Amazon AWS, Google Cloud, IBM Cloud, Microsoft Azure offer the simplicity and convenience of CapEx-less buy-as-you-go/as-you-need compute and storage. However, in return, you have to accept some limitations, notably, sacrificing some degrees of control.
So it's not surprising that over 90% of all the server workloads are running on private systems, including on-premises hardware (which may be running cloud environments), and private clouds, plus some mix of hybrid combinations of on-prem, private cloud and public cloud.
Diane Green, CEO of Google Cloud (and before that, founder and CEO of VMware) said in a July 2018 TechCrunch article, "Some people estimate that only 10 percent of workloads are in the big public clouds."
And Urs Hölzle, senior vice president of technical infrastructure and Google Fellow at Google, said in an October 2017 interview, "...95 percent, 98 percent of workloads are not running in any one of those clouds. They're running on premise or in a colo or something like that."
When you are deploying to environments where you have control over the servers -- like in the Outer Limits, "control the horizontal and the vertical" -- it makes sense to pick an approach that lets you take advantage of that opportunity, for reasons including:
- to get the most bang for your buck; that is, get the most performance out of your hardware
- to maximize the security of your applications.
One way to do this is by using a "unikernel" architecture for packaging applications, rather than virtual machines (VMs) or containers or bare-metal. (Quick re-assuring note: this isn't an all-or-nothing approach; unikernels, VMs, and containers can co-exist and interoperate side-by-side.)
Here's a brief look at the why and how of unikernels for your private on-premises servers and your private/hybrid cloud activities.
UNIKERNELS: THEY'RE SMALL, PURPOSE-BUILT VIRTUAL MACHINES
A unikernel is standalone executable capable of running under a hypervisor ("bare metal" or software). A unikernel consists of:
- the application executable -- which can be anything from a web server, database, DNS to your company's internally-developed software
- configuration data
- the specific operating-system-level libraries that the application needs, such as clock, an Ethernet driver or something similar to talk to the network, something to talk to the file system, etc. Specific examples: libxslt and libxml-dev are linked into practically every single interpreted language out there (whether you use them or not).
Unikernels like NanoVMs' Nanos kernel are dedicated to a single application. This means they perform less context switching, make fewer system calls to the OS, and use far fewer server system resources, compared to traditional VMs and other approaches.
The first unikernel systems descended from Exokernel and Nemesis, dating back to the late 1990s. Today, there are roughly a dozen unikernel initiatives, including NanoVMs' own.
Each unikernel application is custom-built -- that is, the unikernel VM for each given application. Since you know what application you are looking to run, and odds are good you also know what hardware (or hypervisor/host) it will be running on, it's not hard to identify which what libraries will be needed.
Because it is compiled with only the OS components needed for a single operation (application), a unikernel version of an application will be significantly smaller than a traditional VM version of that application -- typically only slightly larger than the actual application. For example, NanoVMs' own commercially-available VMs typically run in less than 50MB and can run on any hypervisor.
By comparison, traditional operating systems like Linux distros and Microsoft Windows include gigabytes of drivers and libraries -- most of which a given instance or application will never need (for example, hundreds of drivers for video, USB, audio...) -- plus dozens-to-hundreds of utilities like SSH, which similarly are not needed. That's a lot of not-adding-any-value overhead to application storage, boot-up time, and RAM usage -- not to mention having a lot of "unused appendages" which may have security vulnerabilities.
UNIKERNELS ON YOUR PREMISE AND IN YOUR CLOUD(S) SERVERS
On a server environment that you own (either actually owning it, or you're renting it as a private service, with the greater control that implies), deploying your application instances as unikernels rather than as traditional VMs or containers has important performance, cost-effectiveness and security benefits:
Unikernels can run in much smaller hardware than the same number of traditional VMs. Alternatively, you can run many more instances and other unikernels in the same hardware than VM instances for the application. For comparison, on a 28-core, 32GB RAM test system we use -- far lower-powered than what modern on-premises, data center or cloud provider is running today, OpenStack servers can run only five to six VMs, while we have seen NanoVMs support as many as 1,000 Nanos unikernel VMs.
Unikernels boot faster than regular VMs. For comparison, in OpenStack, VMs are assembled at boot time, and reboots can take minutes, while NanoVMs boot in seconds.
Some companies like NEC are reporting boot times of five milliseconds for their LightVM unikernels, versus 200-20,000 milliseconds for Docker VMs or containers.
Because unikernels are single-process systems, requiring lesss context switching between kernel and user, unikernel applications also run faster than traditional VM'd ones.
Unikernels, because they are single-process VMs and are not using a shell, and don't include SSH or many other components typically present in VMs, are intrinsically much more secure than a VM. A hacker can't try to SSH in -- there's nothing for their attack to connect with. Also, because only a single application is running in a given NanoVMs unikernel, the traditional concerns for ring-0 access don't apply -- because you (or malware or a hacker) can't execute some other program inside it.
YOUR PUBLIC CLOUD ACTIVITIES CAN ALSO BENEFIT FROM UNIKERNELS
While this discussion is primarily about running unikernels on private on-premises servers and on private clouds, unikernels can run on public cloud. The performance and security benefits apply -- but you won't realize the private environments' economies of scale to the same extent.
For example, in Amazon Web Services you have to create EC2 images (in Google Cloud, GCE images), which are typically at least 1GB in size, versus, say, a Go web server unikernel, which can be measure in 10 megabytes -- and it could easily be much smaller if the server were done in C rather than Go, which isn't as tidy as C is.
(Note, as unikernel-like technology comes to public clouds, unikernel efficiencies there may improve.)
TRYING, AND MOVING TO, UNIKERNELS
Because of the need for OS libraries, creating unikernel versions of your applications requires new tools, and also expertise that your current IT staff may not yet have, along with orchestration tools to deploy, monitor and manage your unikernels once you have created them.
A good way to get started is by exploring -- contact NanoVMs for a demo of our Nanos unikernel technologies and tools.
Stop Deploying 50 Year Old Systems
Introducing the future cloud.
