Comparing Habitat and (Ubuntu) Snappy


#1

I posted this as a slack post in the #iot channel but figured I’d post it here too for search-ability / different eyes. In my original version there were several links, but I am a new Discourse user, so it wouldn’t let me post with them - so I’ve inserted [1]-style numbers and the corresponding links are here: https://gist.github.com/donaldguy/40965bac2105929ad6097576ba80ffdf

Habitat vs (Ubuntu) Snappy

I haven't gotten tons of experience with either yet - but based on my doc skimming ( both Snapcraft docs[1] and Ubuntu Core docs[2]) and initial experiments heres a quick comparison, Let me know if you notice something I am saying is wrong.

`snapcraft` vs `hab build`:

more to explore, but the major weakness seems to be in the structuring of the dependency story:

  • you are largely expected to build a monolithic/"docker-style" file system image each time;
    • you can leverage the below, and
    • there is seemingly sugar for slurping in duplicates of whole apt trees from upstream "classic" ubuntu,
    • but its still much closer to "from scratch" each time than hab plans
  • there are plugins[3] (vaguely like scaffolding) for build dependencies (and interpreted language runtimes?)
  • there are parts[4] for runtime dependencies (e.g. dynamic libs, side cars, shellouts) but:
    • they are totally separate & distinct from snaps
    • they are maintained/published outside of normal stores (depots) here: https://wiki.ubuntu.com/snapcraft/parts
    • there are not that many available: I count 60 total and none or almost none maintained by upstream
    • I don't quite understand this bit, but they have a direct tie to plugins? its like you couldn't have a plan without a scaffold? - maybe the nil plugin makes this untrue

Builder

this brokering style and strict separation of dependencies from normal snaps seems to mean their version of builder[5] is necessarily much less compelling with non of the intelligent rebuilds that I've seen pitched in e.g. @reset 's ChefConf talk.

`snapd` vs `hab sub`

snapd takes on some similar responsibilities to hab sup but but it all seems to be just for single machines

  • snap set and configure hooks[6] do similar to some of hab sup's config loading and reconfigure hook (it seems like it could do something like hab's other hooks too but it doesn't yet)
  • the plugs/slots system, collectively "interfaces"[7] looks kinda like hab runtime bindings but also with file system mounts?
  • autorefresh stands in decently for at-once update strategy I guess; (edited)

Runtime Sandboxing

The biggest difference perhaps though is that while classic and devmode confinement[8] settings can weaken it, snaps are always executed in a sandbox.

On the habitat side, though a hart can be pkg exported into one or another container format, the hab supervisor itself does not enforce any runtime sandboxing

Scope Differences

The runtime component of snapcraft is not as flexible, nor relevant apparently to distributed systems. A large part of the appeal of using habitat for IoT to me is that coworkers and I could have common tools and use common workflows between IoT devices on the one hand and (e.g. and specifically) kubernetes-hosted backend containers on the other.

Snappy does, unlike Habitat, aim to get all the way to the metal/manage the whole system via the kernel-snap[9]/loopback-mount + readonly file system.

(At my job, we probably are gonna manage that base layer via yocto & update it with mender.io[10], regardless of if we also add something like snap or hab as an app supervision and soft-update layer on top )

Ecosystem

snap & snapd's major advantage vs hab and hab sup for IoT use however is it that is written in Go and already shipping various flavors of arm binaries.

(I'd consider Rust's safety + runtime memory properties a mark in hab's favor if the cross-compilation story was already as good for Rust and the arm targetting studio was ready to go)

Canonical's Builder and Depot analogues ("stores"[11]) aren't open source at all, best as I can tell :disappointed: . There is one[12] alternative minimal snap store pointed to in docs but it does not appear to be what upstream uses at all, and doesn't support hosting parts at all, just full snaps(?).

Edit: short afterthoughts
There are package & store / depot features that are pretty similar, semver + revision (though habitat uses datetime where snap uses index); channels

Snap stores are (at least potentially) set up to host snap’s for purchase, whereas habitat, to my knowledge, is only looking to distribute gratis harts

Snappy is linux only, Habitat seeks to be cross platform

Habitat uses bash and powershell, snapcraft uses yaml


#2

Additionally, I think a plugin could be written for snapcraft and contributed here: https://github.com/snapcore/snapcraft/tree/master/snapcraft/plugins and thus be usable to use hab as a scaffold to make snap packages by installing files with hab pkg install

This would reduce a hab pkg export snap to basically just generating a simply snap .yml using that plugin for the filesystem and setting up a command with daemon: true as a hab supervisor systemd unit and then invoke snapcraft cleanbuild or so.

and if one wanted to go even further:

  • expose hab hooks as non-daemon commands that could be snap runed?
  • hook up hab bindings to snap interfaces somehow?