Unikernels Can Fulfill the DevOps Promise
See how unikernels can fulfill the promise of DevOps and see how this alleviates some of the pressure on the Ops team.
Join the DZone community and get the full member experience.Join For Free
One of the core promises of DevOps was breaking down silos and having developers actively manage their own applications in production versus throwing it over the wall to Ops and making them respond to PagerDuty at 3AM on a Sunday morning.
That was the promise — the reality was slight different.
Largely speaking, when someone says they are a "DevOps" or a company is hiring for "DevOps" it really means that the person is deploying, configuring, managing, and babysitting servers.
The promise of DevOps is a really enticing one but I'd argue that one of the reasons why we haven't gotten to the land of milk and honey yet is because systems administration (Linux administration) is still very much a niche skillset that a lot of developers simply don't have. There's a reason why DevOps salaries are so high and yet most of the developers in San Francisco work on MacBooks. (Protip: if you're hiring and someone asks if they are going to be forced to use a Mac that's a good sign they might have those skills you are in need of.)
So instead of trying to find more talented, expensive sysadmins maybe we can reduce the need on to rely on said systems? Is that possible in this day and age of ever-increasing cloud bills and microservices? I'd say we can certainly try.
You may also enjoy: Easily Build and Run Unikernels With OPS
Unikernels are an emerging software infrastructure pattern that combine the operating system and a single individual application into one discrete unit. Unikernels fully embrace the original DevOps manifesto as it removes so many of the underlying system administration tasks that it forces the developers that wrote the apps to manage them in prod (or at least makes it easy enough to).
Unlike containers that still demarcate between those who manage applications (SREs) and those who code, unikernels remove a lot of the friction that organizations have with enabling developers to manage the applications they actually write. Or, to quote Tim Bray, it makes the same engineers who write the code live by the dashboards and alarms and metrics.
Unikernels Avoid Vendor Serverless Lock-In
How? For starters, unikernels get rid of the notion of the "server" and embrace a serverless mindset. That is not to say there is no server, but it's not one you can ssh into and install a bunch of crap. It's not one that an engineer is expected to sit and babysit, either. It's either working or it's not. If it's not working, shoot it in the head and deploy one that is working otherwise —fix the app. Instead of "fighting the machine" there's a certain symbiosis that is formed.
However, unlike most serverless offerings that are entirely proprietary to each individual public cloud provider, unikernels stand apart because instead of some half-baked CGI process that is different from provider to provider, they assume the basic unit of compute is a VM that can be shuttled from one cloud to the next and the cloud provider is only responsible from the virtual machine down.
Another thing that sets unikernels apart from traditional serverless offerings like Lambda is that they are not by definition or by default transient. If you want traditional serverless workloads to be persistent you turn on "provisioned concurrency" and cough up some of that sweet greenback. There's, of course, nothing stopping one from having a transient unikernel workload.
Unikernels Avoid Kubernetes Complexity
Containers and their current application du jour, Kubernetes have a lot of problems which is why they won't be around forever and we are already hearing abodut companies "de-containerizing".
Containers are notorious for eating databases alive. With unikernels, you can pause, stop, restart, and even live migrate with ease with no need to use external software to do any of this because, at the end of the day, they are still just plain old VMs, albeit specially-crafted ones.
This is why we keep on seeing articles like the one from AirBnb complaining that kubernetes has serious performance problems.
One of the contentions if you read this article is that, by and large, most JVM applications, don't fit neatly inside of a container. Engineers have had to go out of their way and use those sysadmins— I mean, DevOps, skillsets to size it appropriately and modify certain settings that they might not realize beforehand. However, deploying a Scala unikernel to Google Cloud today via ops is merely 2 commands in 2 minutes and then it is running.
Container architecture via Docker and Kubernetes are not just completely insecure (best practices dictate using an anti-virus scanner a.k.a. "container image scanning") they also exact serious performance issues because of their inane duplication of networking/storage layers on top of existing vm architecture.
One could say they are "web scale".
Unikernels Enforce DevOps
Unikernels force the developer to bundle everything they want into their deployment unit. Want to hit the deploy button? You can't just build a new instance with Terraform and then use Jenkins to scp your app into place. No, the entire VM gets completely rebuilt — although that's not as bad as it seems because it could be a whopping 10 MB. Google Cloud can do this in less than a few minutes, AWS takes slightly longer.
Want to know what how much memory your application is consuming or how long GC is running for or if the disk is running out of space cause of rampant logging? You have to bake in your observability and configure your logs to the appropriate service.
An instance is acting up? You can't just ask your DevOps cough sysadmin cough to ssh in and debug your application for you. There is no ssh, no usernames/passwords, and no way to pop into an instance. There is no text editor or shell and no
sudo apt-get install . No, you need to instrument your own application and fix it locally like the highly paid software engineer you are — no more shifting the responsibility to ops.
This Cloud was Built on Virtualization
The cloud was built on virtualization — not containers. Unikernels are truly cloud-native. The base unit of the cloud is the venerable virtual machine. Cloud providers have gone out of their way to utilize hardware like ASICs and FPGAs to accelerate network and disk access and then expose them to the vm layer.
Unikernels are a perfect fit for cloud architecture as they already assume they are deployed as virtual machines — they simply strip away the excess of legacy that is not needed.
Unikernels can fulfill the promise of DevOps.
Opinions expressed by DZone contributors are their own.