Evaluating Balena on top of another OS

Product support
1

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.

1 Like
5

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.

7

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.

8

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

9

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

11

Hi Jordi, I am one of balenaOS maintainers, and I’d like to clarify some of the points you make above.

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.

balenaOS is also using the BSP support provided by the vendors - there is no other way to provide good production support for these boards. This is done via an initial device bringup that we have done for more than 100 boards (probably many more now). Typically we charge a fee for the service and the maintenance, but some customers decide to do it themselves.

Now, what do you get for this initial friction?

  • Hardware abstraction - by isolating the application in containers with a clean API from the host OS customers can deploy the same application against a variety of hardware, physical or virtual. This helps when updating product lines, testing against virtual devices or fighting component shortages.
  • Continuous device maintenance. BalenaOS is released in an automated CI/CD pipeline - all pull requests are automatically tested in both virtual and physical hardware-in-the-loop, and all device types are automatically updated. Your hostOS is always production tested and state of the art, a need for a secure system.
  • By having a small, lightweight, homogeneous operating system used by hundreds of thousands of devices, Balena can offer operating system support through our support channels. And all of our engineers do support, so you get actual BSP experts looking into your problems.
  • balenaOS is updatable via balenaCloud and supports A/B partitioning and rollbacks.
  • balenaOS is secure by default - it has already solved the tough problems to do with time synchronization, security protocols, provisioning, over the air updates etc.
  • balenaOS provides a specialized engine
  • balenaOS minimizes the bandwidth usage so it can be used in cost constrained cellular deployment

As I see it, balenaOS is light, secure, reliable, robust, and allows our customers to focus to adding value to their product. I see it as something you want to work and get out of the way so you can add features to the application which is where our customers expertise is.

Although balenaOS is ideal for customers that want to dedicate their people to adding value to the product and don’t have a dedicated OS team in-house, it works just as well for customers that need custom modification - balenaCloud supports private device types for this.

Let me know if there is anything else we can help out with.

13

Hi @alexgg,

First thanks for your explanation. It is awesome (and a pain sometimes for sure) that Balena involves everyone in the organization to provide support.

Your explanation touched all the aspects that do Balena interesting. As you said, you add Balena when you don’t want to maintain a state of the art and secure OS with app delivery, I get it. If our product is based on an SBC (full system, not SOM module) is great, if not, as you pointed, then it has to be ported. The effort is big but can be done by an external team (you) but comes with great (and mandatory) features.

As I have you here, I would like to ask you another thing. Maybe @jakogut also has some input.

Balena is about allowing users to deploy apps on top of small linux boxes deployed all over the world. It seems very important to have small updates (hence you implemented the delta on top of Moby). What are the plans for WASM? Are there plans for a WASIX style interface?

And, as I said before, good work. Embedded Linux based systems is not my thing, I’m more on the microcontroller side, I wish there was a proposal as solid as Balena for uC :slight_smile:

Salut!

Jordi