Evaluating Balena on top of another OS

Hi Balena team,

I’m evaluating Balena for future use by doing some trials with on a rpi, but I have some doubts I could not find in the documentation. Maybe you can help :slight_smile:

But first I want to say that yesterday I could deploy a docker compose in minutes without previous knowledge of your platform, so congratulations on your product. Lights ahead of GreenGrass/ECS anywhere.

I have though, as said some doubts.

  1. You asked me to install your balenaOS in my device. What if I want to keep the OS of my device as it is? I see that in your OS there is the balena engine, and that I can install it in my Linux OS. But I don’t have clear, what things I’m not getting by not using your OS? updates? Are all your platform features supported with just the Balena engine service running?

  2. Another key differentiator of Balena is the “binary” delta updates.I read the explanation on how it works, how different is it from “correctly” doing it with Docker? do you have some numbers? By “correctly” I mean only updating the last layer (with the code) of a docker image.

Again, congrats on your product.

Hello Jordi,

Thanks for considering our platform! I work on the OS team here, so maybe I can help with some of your questions.

what things I’m not getting by not using your OS?

You’re certainly able to use our engine in your own Linux OS, but there’s a reason we develop and distribute balenaOS rather than package the individual components, such as the engine, for installation. Developing our own OS allows us to do atomic OS upgrades and fallback with an A/B partition layout, manage how containers are downloaded and run with balena-supervisor, configure device tree overlays and bootloader parameters on platforms where those are relevant, and handle network configuration through cloudlink (essentially a VPN) for easy remote management, among other features.

Essentially, balenaOS is crafted from the ground up to support running containerized applications using balenaEngine, including all the pieces that aren’t provided by the engine itself.

Another key differentiator of Balena is the “binary” delta updates.I read the explanation on how it works, how different is it from “correctly” doing it with Docker?

Delta images are an optimization of container images, how different the downloaded size is compared to a traditional pull depends on the image.

In a traditional pull, modifying a layer requires re-downloading all layers afterwards, even if most of the content hasn’t changed. With a delta image, the worst case download size is the same as a traditional pull, and the best case is only the modified data. Some other team members may have more input on real world numbers and specific examples when using delta images, and I’ll defer to their expertise.

Many of our customers appreciate this optimization when they’re on bandwidth constrained or metered networks, such as with a cellular modem, or when sharing a single internet connection with a large number of devices.

Let us know if this helps.

To add a little bit of information about the efficiency of deltas, we had a blog post that covered specific examples a while back when balenaEngine was first announced. Generally, deltas save quite a bit of space over a non-delta pull when making small changes, especially to layers early in the build process.

Note that the delta implementation has seen changes and improvements since then, and the engine itself has been rebased on the upstream Docker engine several times, along with seeing additional improvements. Some of the numbers are going to vary, especially in relation to the size of the engine binaries themselves, which have grown across the board.

Hi,

Thanks for the quick response.

About the size reduction it looks great. The adding a package via apt-get example it’s very impressive.

About Balena OS, thanks for the explanation, I also read this article Architecture Overview | balenaOS it is clear now what have you packed inside and how you’ve organized everything. I see the advantages you offer, I guess ditching or having to merge your Balena OS with the one provided by NXP or Variscite or Toradex, although doable, seemed like an extra big step, I see the advantages, but I’ll have to wrap my head around it.

See you

Hi again Joseph, @jakogut

I would like to share some info from the talk I had with some engineers, since it could be useful for us and maybe good feedback for Balena.

In short we are kind of “forced” to use the provided OS from our supplier (Qualcomm, NXP, …) since they apply patches and other to the base Yocto. We cannot imagine getting good support by starting from BalenaOS (I’m obviously talking about platforms that you don’t support).

Also another thing that we talked was about the partitions, although they seem to be a good choice, sometimes we have different specifications.

We see Balena engine very interesting, and it seems easy to integrate. But besides that do you think we should port some other part of Balena OS? To me adding just the Balena engine seems that we are not taking advantange of what you can offer, at the end would be just like Greengrass (but with the delta upates).

thanks