Unikernel Cronjobs
Unikernels are single process by nature so there are tools and styles of work that sometimes are implemented differently in unikernels. One of those tools that I've extensively used in the past but never had a direct replacement for in unikernel land was the concept of a cronjob.
Cronjobs are used for many tasks that require recurring work to be done. The most common use-case might be log rotation, however, ETL, database backups and those nightly user-engagement reports that marketing asked you to send out are all common use-cases too.
Cronjobs are executed by the cron daemon and are inherently multi-process and multi-user -- design characteristics that fit well in the 1970s and 1980s when cron was designed but don't fit in the unikernel world-view where everything is ran virtualized in the cloud. So how do you do database backups? How do you implement those one-off reports? Don't you need a daemon to kick off those jobs?
That's where the new Nanos C2 unikernel cronjob feature comes in.
The downloadable Nanos C2 package now features built-in cronjob scheduling. Nanos C2 is an administrative tool to easily manage and deploy unikernels and get a birds eye view of your unikernel infrastructure. It is self-hosted meaning you can download and install it anywhere. It is inherently built to be multi-cloud. We personally run them on AWS and Google Cloud but again, Azure, VSphere, your own custom KVM/Xen platform - whatever works.
Nanos C2 is a go webserver and comes packaged as a unikernel so we thought that's a daemon - let's just use this. You can easily pick your unikernel image as a cronjob to be ran on any recurring schedule of your choice.
The dialog is dead simple and since it's a unikernel there is no way to ssh into this instance or fork off any other programs. This also means that you'll never have that problem where the cronjob stopped working and when you investigate you can't ssh in because the disk is filled up cause you forgot to delete the gigabytes of data you were transferring, etc. (True story - many times over.)
We created a few common default schedules but you can of course implement cron using normal cron expressions too. (Old habits die hard.)
You might be wondering how this actually works because it doesn't work like Paul Vixie's. Instead of spawning a new process for each job like we would in Linux, C2 will spawn a unikernel. What that means is that we actually boot up an instance on demand, let your work run, and do it's job and when it is done we spin down the instance at completion. No instances are idling just waiting for work to happen.
Yes, this means just by moving your existing cronjobs to C2 you'll end up saving a ton of cash.
All the scheduling is done using the underlying cloud primitives that are the same on every cloud provider. There are no special cloud features being used and there is no complex scheduling mess you have to learn and babysit like you find in crappy insecure "orchestration" platforms like kubernetes.
I'm fairly excited about this new feature because not only does this implement a feature that we really needed and wanted but it takes the original concept and makes it ten times better. It also really illustrates the raw unadulterated power of unikernels and how incredibly tuned they are to the cloud. You can't get something that runs this fast and this secure in normal Linux vms and you can't get it in containers. Unikernels are going to make the past 15 years of cloud look like a model T while we are driving in Aston Martins.
For less than the price of some avocado toast you can experience the fastest, safest method of doing ETLs and data dumps and other cronjobs. If you are an existing customer reach out to you rep to ensure you have the latest/greatest or if you are not a customer - Sign up for Nanos C2 today.