Ubuntu Core Should Be the Future of Cloud Native Computing
One of my favourite film quotes, is from the eponymous 80s flick Ferris Bueller’s Day Off. It goes
“Life moves pretty fast. If you don’t stop and look around once in a while, you could miss it.”
Life certainly does move fast; but technology moves even faster still, and today’s hot new tech paradigm is tomorrow’s leftover Xmas nut roast and brussels sprouts.
In “Is ChromeOS the most advanced OS on the market today?”, I disassembled Google’s Chrome OS, and attempted to demonstrate that it’s inner workings are not just 5 years ahead of the rest of the market, but approaching computing in a way that lays the foundations to make it ready to offer a highly secure, future proof, modular solution, ready to run isolated legacy workloads, through a combination of paravirtualization and containerization.
Well now, running hot on the heels of ChromeOS comes Ubuntu Core. Ubuntu Core offers a very similar computing paradigm to ChromeOS, albeit without the embedded paravirtualization and LXC based jails that make ChromeOS what it is.
Instead Ubuntu Core is founded and built on Snap, which is an advanced application containerization solution developed by Canonical (who also develop Ubuntu). Snap is marketed by Canonical as an app store for Linux users, but actually it goes deep — much deeper than Canonical are positioning it at the moment in their marketing material. Snap is really robust, and it implements a myriad of secure computing features — digital signatures, Seccomp restrictions (a system to build whitelists of allowable kernel call subsets that an application may make), AppArmor profiles (AppArmor is an alternative to SELinux that can be used to automatically build and then enforce resource access policies for commands and applications), udev rules, and classical file permissions, in order to build a tightly restricted, sandboxed mandatory access model for every process running on the host.
Snaps can be installed dynamically — or declaratively at Ubuntu Core image build time; the system is flexible, and snaps can be wired up to one another for inter-application communication if needed, although all dependencies (think versioning…) are bundled into the snap, making each application fully self-contained.
There are a few other cool features of snaps —like automatic updates, transactional and atomic updates, and rollback to the previous good state in case of problems. The system is designed so that even the host’s kernel implementation is a snap — how modular is that!
Ubuntu Core is an extremely lightweight operating system: a complete base OS image is not incomparable to many of the base docker container images out there in terms of size on disk. And it’s been designed from the beginning with support for ARM as well as x86_64 architectures, since it is very much oriented toward embedded systems and IoT use cases.
With a highly focused emphasis on secure computing, and no upfront design constraint around how many processes run on the compute node, Ubuntu Core feels quite different to a typical Docker based microservices architecture — regardless of whether that MSA is running in a k8s orchestra or runs on ECS or on Fargate, or some similar such thing. You see, a best practice Kubernetes microservices architecture deployment carves every. single. process. up into a docker container, and has consequently become a subject of endless impassioned debate between the MSA advocates and their oft-pilloried contemporaries who prefer the [generally maligned] monolithic application architecture. With Ubuntu Core, you can have an MSA architecture, or you can have a Monolith. Or you can have a hybrid approach. There is no design constraint; you can do what works the best for you and your users.
So in that sense, Ubuntu Core and Snap make a worthy successor to the eponymous Docker container and image registry: offering a far better security paradigm, better update management, more flexibility, [MO] better software license compliance, and no upfront design constraints (except for obliging those most famously cavalier of animals — software developers — to give upfront thought to application security). I am eagerly awaiting the day Ubuntu Core and Snap usurps Docker’s throne as the containerizer of choice within the court of k8s.
The trouble with Docker
Docker is quite nifty. Spinning up a docker container image is a bit like downloading a live CD .iso and launching it in a VM, except that it only takes a few seconds (or minutes, at the most) to download, and launches instantly. That’s because its not an .iso image, and it doesn’t run in a VM. Instead its a series of compressed “slices”, with slices being shared by multiple container images, and because it runs in a Linux CGroups namespace, sharing your host computer’s kernel. And it has a really easy, declarative build script language that even a total n00b can pick up. That’s really great. Makes it super easy to work with. Docker Incorporated did a great job on user friendliness, which is why its become so popular.
The problems with Docker tend to be about the container images though. Image slices get out of date quite quickly, falling behind on patching, and potentially exposing the container to critical vulnerability exploits (CVEs). And the provenance of the slices is not always very trustworthy or reliable (never heard of Zero Trust Security?). As a result, a whole aftermarket has sprung up to try to solve this —with bandwagon vendors selling container image vulnerability scanners, container security monitoring engines that monitor for bad behaviour, and even total rewrites of docker, like Rkt or the much more radical Kata container engine. But all of these solutions approach the problem like the farmer who closes the gate two Sundays after his prime breeding stallion has bolted.
Another approach is needed here: the host system would be running LXC — which would act both as a resource governance framework and another layer of jailing (or better still, the host would be running QEMU with paravirtualization for proper kernel isolation), with Ubuntu Core instances running inside LXC containers, as a replacement to Docker, and Snap packages as a replacement to OCI images (“open container initiative” — which is IBM and the gang’s effort to standardize the innovation that Docker did). This is the Zero-Trust approach: it is assumed from the very beginning that the Snap containing the application, or perhaps the Ubu Core instance, or both, are gamed, and not to be trusted; and layers of defence and control are applied all the way through the stack. It is quite different to the gumball (hard shell, soft centre aka “castles and moats”) perimeter security approach of the Docker ecosystem. Remember that snaps are minijails with isolated sandboxing, seccomp policy, udev rules and apparmor profiles, and the snap is digitally signed.
Where Snap could improve: well this would be in developer friendliness. Packaging Snaps is quite easy to learn and do, but it is not as noddy as Docker. To be fair, AppArmor profiles, seccomp and udev rules, and fs permissions are automatically generated during snap build; and snaps can import the content of other snaps or packages, so for the power you get, it is pretty peasy-squeezy. But if the Snap system offered a Docker transpiler in order to autotranslate from .docker build scripts to .snapcraft specs it would make it easy for developers to make the jump.
What else
Much more than a credible Docker swapout alone, I believe Ubuntu Core could also offer a credible alternative to the serverless computing functions paradigm — I am referring to systems like AWS Lambda or Azure Functions: this is a newish concept whereby customers need only write a short script in JS, python, Java or some other language, and then upload it to the cloud where it is executed on a trigger (which is usually an HTTP request), thereby eliminating the management of a few servers.
But a few Ubuntu Core hosts running on a bunch of t4g.small AWS Graviton2 instances, for example (these cost $0.44c per 24 hours, per instance in eu-west-1 at the time of writing), could offer far better performance (eg. no cold starts), much more predictable operating cost, complete portability, and actually just as much peace of mind, if not more, from a security and operational management perspective. And before you ask — actually yes, I have known organisations that have racked up some really, really big bills by using AWS Lambda.
So there you have it folks — the future is a loud, bright, freeware, open source, security hardened, Ubuntu signature orange pantone — and the future is already available to experiment with, procrastinate about, or deploy safety critical, classified workloads to - today!
