by: General

The difference between Snap, Docker, and Multipass can be easily understood by one example of usage:

Let’s suppose you need to have one LAMP to run codes and possibly share content on the Internet. There come four ways to make it:

1st – The conventional way (reference) would be installing MANUALY the Apache, PHP, MySQL in the Host O.S. The services will use all the libraries, kernel, and any other resource from the Host O.S. The softwares will merge to your system, sharing files, permission, etc. If one of the services crashes the whole Host O.S. can become inoperative, or if one of the services has a vulnerability, all the data becomes vulnerable.

2nd – The Snap way would download and install a self-contained software called ‘snaps’ on the O.S. With absolutely no effort, Snap downloads and install one capsule (app isolation) that contains all the services needed (Apache + PHP + MySQL), all dependencies and libraries (that is why it can run in multiple platforms). The Snap will start and stop all the services at once, as one ‘block’ application that will also run on the O.S. Has the same crash risk as The conventional way (1st).

3rd – The Docker Way would pull (download) one image. This image uses (shares) the host O.S. Kernel, but it creates one whole independent environment, such as users, permissions, file system, etc. This environment is called Container and does not require to boot, so starting/stopping processes are very fast, feel like a light-weight VM, but it is not. There is one shell to get into the container and if one service crashes inside is will most likely not affect the host OS, the same for vulnerabilities, will be kept inside.

4th – The Multipass Way would launch (download and run) one Ubuntu pre-installed image. This will create a bare new Virtual Machine that does not share anything with the host O.S. and does not share any vulnerability or risk in case of a crash. Multipass is not a Hypervisor, it is a tool to quickly and easily start a fresh VM in just one click using the Native hypervisor, in case you need frequently disposable VMs for tests. Inside the VM you have to do The conventional way (1st) to install all softwares and services.

Conventional Snap Docker Multipass
Real Machine (Host). Self-Contained Software. Container. Virtual Machine.
Any Host O.S. Cross Linux Distributions. Cross Linux Distributions. Linux, Windows or Mac.
Single Environment. Runs on the Host Single Environment. Multiple Environments. Multiple (Ubuntu Only) Environments.
Softwares are installed in the Host O.S. Softwares are installed in a ‘snappy’. The image is installed in ‘containers’ The Chosen Ubuntu is installed in V.M.s
Usually, a new version replaces the old one. It can keep different versions side-by-side. Multiple dockers can be different versions. Different images can be different versions.
Start/Stop Real Services. Start/Stop Like Services. Start/Stop Like Services. Boot the whole V.M.s.
Software Size. Software Size + Libraries Size. Software Size + Image Size (from 64 ~ 104MB). Software Size + Full O.S (from 55 ~ 1002MB).
Host File System. .snap (Squashfs). N/A (OverlayFS). .img (on KVM Hypervisor).
Use whole hardware. Uses whole hardware. Uses whole hardware. Uses what was allocated: RAM, CPU, Disk, etc.
Manual deletion, possible remainings. Quick deletion, no remainings. Quick deletion, no remainings. Quick deletion, no remainings.
N/A Very Light Weight. Light Weight. Heavy Weight.
N/A Loads in approx 2 seconds. Loads in approx 2 seconds. Loads in approx 10 seconds.

Opinions and applications that I believe would fit better to each:

Conventional Snap Docker Multipass
If you have one physical machine dedicated to only one thing this is the best option. Has full access to the hardware and best performance with no overhead. Easy and clean installation of full software packages. It can deploy complex systems with all support systems, such as database servers, and everything will be already configured to working perfectly. This tool is excellent for keeping all the services isolated and helps to protect the whole system and data, without running many V.M.s in parallel, which would cause a lot of overhead. For professional servers, this is the most powerful and reliable way to keep isolated services, reducing vulnerabilities and data and system. It requires good hardware with a lot of CPU, RAM, Disk, etc.
How to Use How to Use How to Use

REFLECTION NOTES

The use case will define what method will best fulfill the needs but it is worthy while mention a few decision making key points:

  • What is the infrastructure? A system or an application?
    • If system:
      • Does the system require direct access to the hardware and minimal overhead? Like a high throughput NAS, for example?
        • Conventional – Bare-metal server
      • The system allows some overhead and will benefit from features like snapshots, high-availability, load migration, etc?
        • Multipass – Virtual Machine
    • If application:
      • Is it the type of application that can be classified as best suitable to be a micro-service, fully unaware of the system that it runs on?
        • Docker – Containerization with Orchestration
      • It is a monolithic type of application that can benefit from the security policies of AppArmor and Seccomp plus delta updates?
        • Snap – Application Packages

BONUS

Containerization is the most likely way the industry goes this days because the total detachment of the application and the system it is running on allow to easily migrate loads through different loads, fast scale in and out, and ephemeral workers that started and destroyed within no time.

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

And definitely, read more about Container Orchestration on 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].