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

Applications are now Fleets in balenaCloud. Learn why we made this change- what it means to users- and how it impacts our product roadmap.

Applications on balenaCloud are now Fleets. We’ve changed this to progress us towards our long-term vision of disentangling devices from software, allowing you to manage both independently and solve for use cases of ever-increasing complexity.

We want to provide ultimate flexibility for fleet owners and believe that working within the confines of the application scope was limiting what we could offer and causing confusion.

Our team believes in making sense of the world and using accurate terminology, so we can all have conversations and work together without getting confused. It’s an important thing to get right at this point in balena’s journey; we’re making this change to unlock a whole host of other features in the future.

For our current and long-time users, read this post in detail to understand the changes.

For soon-to-be users, welcome to the journey. We hope you sign up and enjoy managing your Fleets in balenaCloud.

Read on to find out:
* What we changed in:
* Dashboard
* CLI
* SDKs
* API
* Why we made those changes
* What’s next?

Blame Chris, your Friendly Neighborhood Product Lead

You can shout at me, Chris, aka chrisys on the Forums, for changing things. But wait! Before you engage caps lock, give me a few minutes to explain what we’re thinking here, and hopefully it will all make sense and be worth the temporary pain as we transition. I’ll be quick, no doctoral-thesis-length documents, I promise.

What have you changed?

Firstly, we’ve not made any breaking changes to functionality. Our focus is to make sure that our changes won’t have an immediate effect on your day-to-day usage of the platform. At this point, any changes we’ve made to functionality are purely additive and won’t cause any existing usage to stop working immediately. We do recommend adopting the new terms as soon as possible, as there will be deprecations in the future.

Dashboard

We’ve updated the balenaCloud dashboard to change all mentions of the term applications to read fleet. These changes are purely visual and do not represent any change in functionality at this point. All the tasks you’re used to carrying out via the dashboard are still present and accessible in the exact same way, but the names and labels on the UI components have been updated. Find out more about how to use fleets in our documentation.

CLI

A new minor version of our CLI tool has been released that deprecates the use of the ‘application’ term, although continues to let it be used interchangeably with ‘fleets’. Although the old commands will continue to work, the CLI will warn you if you’re using it interactively (i.e. non-scripted), and the old commands and terminology will be removed in the next major version of the CLI. You can find more details about this change here.

SDKs

If you’re using our Node SDK or our Python SDK and update to the latest version, you’ll find an additional model for ‘fleet’. This works in exactly the same way as the ‘application’ model you may have used to date. In a future release, we’ll deprecate the application model so recommend that you start to use fleet instead. Find out more in the SDK documentation here.

We’re continuing to roll out updates here, so stay tuned for more information.

API

The balenaCloud API has been updated to add endpoints for fleets. You can effectively regard these as aliases to the application endpoints you may have been using to date, e.g. application becomes fleet. The documentation has been updated to reflect the change and the old endpoints will be deprecated and removed in the future.

Like the SDK, we’re continuing to roll out updates here as well, so stay tuned for more information.

“Why did you do that!?”

If you’re an existing user of balenaCloud, you’re probably used to the term ‘balenaCloud application’ by now. We create applications, balena push to create releases in applications, add devices to applications, and so on.

That made sense, right? Why change that?

This made sense in the past and would continue to make sense going forward — if we were to maintain the status quo and stand still. However, we have big ideas for the platform and simultaneously we hear all the big ideas that you fine folks have about the businesses you want to start, products you want to launch and projects you want to build and share, and so we want to keep moving forward and building.

A few questions that came up as we addressed user feedback of all shapes and sizes:

  • What happens when we also want to configure our device fleet, does it make sense to do that inside an application?
  • What about when we want to create an open fleet on balenaHub, should we change settings on our application even though we’re working with open fleets?
  • What about when we want to install two separate apps? For example my production app alongside a WiFi repeater or Proxy tunnel, or a video capture app alongside a machine-learning analysis app, or something as simple as balenaSound combined with Pi-hole.

We want to be able to support these use cases without requiring you to manually merge multiple apps into a single application; we want to support this use-case natively.

It starts to get a little confusing when we realise we’re referring to an application as something that contains not only devices and releases but app(lication)s as well. It’s operating as a collection of software in one respect, a fleet of devices in another, and in its inherent function as an application with its own releases as well. In this scenario, applications would contain applications, which we think could be presented better.

Let’s start by changing the high-level scope

We believe that if we directly rename the concept of application to fleet, even without changing a single thing functionality-wise, things start to become clearer and make a lot more sense. We can add devices to our fleets, we can make open fleets, we can build functionality to deploy multiple apps to our fleet of devices, we can work to separate out user roles between fleet owner, device owner, and app owner, we can separate fleet software from app software, and so on. What you’re seeing here is the start of the journey down that path.

What’s next?

We’re in the process of continuing to update all of our projects, blog posts, docs, marketing materials, and anything else we find to reflect our changes. We’re appreciative of your patience whilst we carry out fundamental changes such as this, and hope that although it’s a little painful in the short term, the gains in the long run are worth it.

It’s quite likely that we didn’t handle 100% of cases in our first pass, so bear with us, and if you spot anything you think we should know about please let us know via social media (see links below the post), our Forums, or start a support ticket if you’re curious or concerned.

You can also get in touch via email at [email protected] – myself and the rest of the team would love to hear your thoughts (or complaints 🙂 ) either way.

Stay tuned for more updates

I think that’s everything for this episode. Of course, as discussed above, this change paves the way for a lot of powerful functionality that we can’t wait to build and deliver to you. We hope you join us on this journey and enjoy it with us. We’ll be working hard to bring everything we’ve talked about here to life as soon as we can.

You can find out what other features we have in progress, let us know about what you’d like to see us developing and upvote features on our public roadmap.


Posted

in

Tags: