by: General

The difference between Snap, Docker, and Multipass can be easily understood through one example:

Let’s suppose you need a LAMP stack to run code and possibly share content on the Internet. There are four ways to do it:

1st – The conventional way (reference) involves manually installing Apache, PHP, and MySQL on the host OS. The services use all the libraries, kernel, and resources from the host OS. The software merges into your system, sharing files, permissions, etc. If one service crashes, the whole host OS can become inoperative, and if one service has a vulnerability, all data becomes vulnerable.

2nd – The Snap way downloads and installs a self-contained package called a ‘snap’ on the OS. With minimal effort, Snap downloads and installs one capsule (an isolated app) containing all the needed services (Apache + PHP + MySQL), along with all dependencies and libraries (which is why it runs on multiple platforms). Snap starts and stops all services at once, as a single ‘block’ application running on the OS. It carries the same crash risk as The conventional way (1st).

3rd – The Docker way pulls (downloads) an image. This image shares the host OS kernel but creates a fully independent environment with its own users, permissions, file system, etc. This environment is called a Container and does not require a boot, so starting and stopping processes is very fast. It feels like a lightweight VM, but it is not. There is a shell to access the container, and if a service crashes inside, it will most likely not affect the host OS. The same applies to vulnerabilities: they are kept inside the container.

4th – The Multipass way launches (downloads and runs) a pre-installed Ubuntu image. This creates a brand new Virtual Machine that shares nothing with the host OS, with no shared vulnerabilities or crash risk. Multipass is not a hypervisor; it is a tool to quickly and easily spin up a fresh VM in just one command using the native hypervisor, useful when you frequently need disposable VMs for testing. Inside the VM, you still need to follow The conventional way (1st) to install all software and services.

Conventional Snap Docker Multipass
Real Machine (Host). Self-Contained Software. Container. Virtual Machine.
Any Host OS. Cross Linux Distributions. Cross Linux Distributions. Linux, Windows, or Mac.
Single Environment. Runs on the Host Single Environment. Multiple Environments. Multiple (Ubuntu Only) Environments.
Software is installed on the host OS. Software is installed in a snap. The image is run in containers. The chosen Ubuntu version is installed in a VM.
Usually, a new version replaces the old one. It can keep different versions side by side. Multiple containers can run different versions. Different images can be different versions.
Start/Stop real services. Start/Stop like services. Start/Stop like services. Boot the whole VM.
Software size. Software size + libraries size. Software size + image size (from 64 to 104MB). Software size + full OS (from 55 to 1002MB).
Host file system. .snap (Squashfs). N/A (OverlayFS). .img (on KVM Hypervisor).
Uses all hardware. Uses all hardware. Uses all hardware. Uses what was allocated: RAM, CPU, Disk, etc.
Manual deletion, possible leftovers. Clean deletion, no leftovers. Clean deletion, no leftovers. Clean deletion, no leftovers.
N/A Very lightweight. Lightweight. Heavyweight.
N/A Loads in approx. 2 seconds. Loads in approx. 2 seconds. Loads in approx. 10 seconds.

My opinions on which applications fit best with each approach:

Conventional Snap Docker Multipass
If you have a physical machine dedicated to a single purpose, this is the best option. It has full hardware access and best performance with no overhead. Easy and clean installation of full software packages. It can deploy complex systems with all supporting services, such as database servers, and everything comes pre-configured and ready to use. Excellent for keeping all services isolated and protecting the whole system and data, without running many VMs in parallel, which would cause significant overhead. For production servers, this is the most powerful and reliable way to keep services isolated, reducing vulnerabilities and protecting data and the system. It requires capable hardware with sufficient CPU, RAM, disk, etc.
How to Use How to Use How to Use

REFLECTION NOTES

The use case will define which method best fits the need, but a few key decision points are worth mentioning:

  • What is the scope? A system or an application?
    • If a system:
      • Does it require direct hardware access and minimal overhead? Like a high-throughput NAS, for example?
        • Conventional – Bare-metal server
      • Does it tolerate some overhead and benefit from features like snapshots, high availability, or live migration?
        • Multipass – Virtual Machine
    • If an application:
      • Can it be classified as a microservice, fully decoupled from the underlying system?
        • Docker – Containerization with Orchestration
      • Is it a monolithic application that can benefit from AppArmor and Seccomp security policies plus delta updates?
        • Snap – Application Packages

BONUS

Containerization is the direction the industry is heading these days. The full decoupling of the application from the underlying system makes it easy to migrate workloads across different hosts, scale in and out quickly, and spin up ephemeral workers that are created and destroyed in no time.

Check out the Open Container Initiative (OCI) for more information about what makes containers so versatile [Link].

And definitely read more about Container Orchestration in the following posts:

MicroK8s on Ubuntu 22.04 [Link].

Minikube on Ubuntu 22.04 [Link].

K3s on Ubuntu 22.04 [Link].

K8s Persistent Volumes [Link].

K8s Cheat Sheet [Link].

K8s Dashboard [Link].