The road to multi-app: transitioning balenaCloud Applications to Fleets

Please use the thread below to discuss the related blog post:

Chris here, hanging out down in the comments - if you’ve got any comments or feedback regarding the changes to fleets let me know!

Absolutely brilliant, no-brainer, fantastic change in the Balena naming hierarchy.

The use of “Applications” to refer to a fleet of devices always drove me a little batty, particularly because we group our devices by customer, so I had to explain to everyone that the Balena name for a customer fleet of devices was, “Application” - which made no sense to anybody.

Renaming the fleet of devices to “Fleets” is the height of product management brilliance. Taking something, sharpening it, and getting it closer to it’s true nature.

Thank you so much.

1 Like

@ghshephard welcome to the forums, thanks for taking the time to sign up and share your feedback - it’s a pleasure to hear this and makes all the thought we put in to this stuff totally worthwhile! Glad we could make things a little easier for you :slight_smile:

I completely agreed with ghshepherd. I came here purely to comment on the product management strategy moves you’re making. Very few product managers / teams are able to combine their vision with execution and clear communication to bring execs, peers, engineering teams and customers along on that journey.

Aside from the name change, the grander vision described in that blog post is spot on for what I expect out of balena as a user and would do if I were in your shoes. .

Well done, keep going.

-Recovering product guy

1 Like

@tideline3d / Josh,

First, welcome to our Forums!

Second, we appreciate the kind words and the feedback. Definitely stay tuned for what @chrisys and our crew have in store. In the meantime, I hope you continue using and enjoying balena. Take care.

Great name change, so I completely agree with @ghshephard!

I’m wondering, as an openBalena user, what are the consequences for openBalena? :slight_smile:
First thing that comes to mind is that I shouldn’t update the Balena CLI and SDK to the new minor version, same goes for the Node.js SDK. And will this mean a new major or minor upgrade of openBalena?

Thanks in advance and keep up the great work! :slight_smile:

1 Like

Thanks for the feedback all!

@bversluijs with regards to openBalena, we of course want to roll the changes out there too in order to make sure the experience is the same. I was chatting with one of our API engineers (and founder!) @_Page about it yesterday and he was explaining that it’s not 100% straightforward as the technology we’re planning on using to ease the transition in balenaCloud is not present in openBalena. It may mean that the openBalena transition is a bit more abrupt and could take longer to implement; for that reason I couldn’t say at the moment if it will end up being a major or minor version bump. As I say though, we’ll definitely be making the same name change there too eventually.

With regards to the balenaCLI, you should be fine using the new release (12.45.0) as the API resources it uses have not yet changed. It should show things as fleets but work with openBalena applications behind the scenes. The SDKs haven’t been updated yet although are in progress, but the same will apply there too - the application models will remain and you can continue to use those, but the new fleet ones will not work with openBalena until that API has been updated. Our approach is always to make additive changes as much as possible and not break existing functionality, but of course at some point we need to deprecate and drop the old stuff.

I hope that helps - let me know if you’ve got any more questions!

1 Like

@chrisys Deleting a fleet pops up this question
“Please type in the number of affected labels.fleet_plural to confirm:”

Also Grant support access asks:
“Allow balena support team access to this application for” (time)


1 Like

@nmaas87 noted! Thank you for highlighting these!

1 Like

Does this mean that you consider allowing to move a device from one fleet to another without loosing the application and/or the configuration?
I have often found myself missing such a feature, but the current behavior is to erase all persistent data when a device is transferred.

Hey there @krix; no it doesn’t mean that unfortunately, as far as functionality is concerned the behavior will be exactly as it was before. The device has to conform to what the fleet dictates, so it wouldn’t make sense to bring any services and data from another fleet into a different fleet.

Could you give any more information about your use case? If you can explain what you’re trying to achieve by moving devices between fleets and having data persist we might be able to find a way to achieve it some other way.

Currently we are migrating some devices from Intel NUC image to Generic X86.
I have not found any other way to do this, than creating a new “application” (now “fleet”), and for each device backup the device data, reinstall the device from scratch, and restore the backed up data.
This is both time consuming and not without risk. Also it creates a new device UUID, which means there are a lot of dead devices and a lot of cleaning up.

@krix you should be able to add Generic X86 devices to your Intel NUC fleet; you can have mixed device types within a single fleet as long as they share the same architecture.

You can also retain the device UUID by moving the config.json file from the old device to the new one. You can even change the device type of the device using the dashboard, but of course that wouldn’t cause the OS to change. If you need help migrating the devices do open a support ticket from the dashboard and we’ll help figure out the most efficient way for you to do this!

Great news! We would currently need to switch between multiple balena-applications to fulfill our requirements. E.g. when customer “X” needs container “A” , but not container “B” and so on, we would need to compose multiple possible applications (app_A_and_B, app_only_A, app_only_B).
We currently circumvent these restrictions by deploying a docker-registry and we put a UI above docker-compose to run our own “applications”.
Does your multi-app approach solve exactly this problem?

s/application/fleet/g your masterclass (and other) docs

@haronaut I think what we’re planning answers your use case in that you’d be able to use the balenaCloud UI to do what you’re currently doing within your own custom UI. You’ll be able to add ‘apps’, one with container A and a second with container B. After these apps have been created you’ll be able to install them on a fleet of devices (even just 1 device if required). New releases of those apps would then be applied to all the fleets where they have been installed.

With this functionality it sounds like you’d need to set up each of your customers or groups of devices you wish to target within their own fleet, and then you’d be able to change what apps are installed on a per-fleet basis but still update each app once from a central location.

I think this would handle what you’re asking but please let me know if not, it’s interesting to hear what use cases there are out there for this technology so we can make sure that we build the thing that people need in the real world.