We plan to sell devices using balenaCloud platform to manage them. I’m asking how I can grant our customers to manage their own code for the devices they bought?
We would like to offer recurrent fee and support for our device.
As far as I know, I can imagine we could have divided our code via multiple Docker instances and offering our customer an access our internal device API so they can bring there own container to perform their custom code on the device, right?
My plan would be to setup a multiple Docker images application as a base, and the customer could add their own, so they could have a local access to the data the device would gather and perform edge computing on the device.
Is it possible to grant our customer an access to BalenaCloud so they can benefit the device management offered here?
What would be the recommended way to to share the device management in the scenario I describe?
Hi,
This is a very interesting use case. I would guess that you would like to have your application code and your customers application code isolated from one another, with a well defined API between them. We didn’t only recently think about such a use case and have some ideas in the pipeline, but nothing implemented yet. It would be great to get much more details about your use case so that we can factor it in when we are planning upcoming features, that would support such a use case it. It would be great if you could share this here, or if you prefer you could also get into contact with our customer success team if you don’t want to specify your use case publicly. I’m happy to ping our customer success team if you want and ask them to contact you?
One way I could imagine how this could work now (which has a lot of workarounds), would be, that you create an application per customer and grant them collaborator access (of some level) to the application. You would then provide an interface to your customers to specify a docker image (which would be your customers application code), in your back end and push for every update of a user application a new release of your application with the linked user application image to the application that is specific to the customer. I think this solution is far from ideal, but the only way I can think about what you could do with the system as it is.
I’m just starting using Docker and I’m not yet enough experimented to describe exactly how it could be. That’s why I’m asking on both topic: structuring the container code + granting delegated permissions. (may be you could add a grant or user or permission keyword on the discussion).
Our company starts producing physical devices which are collecting many external sensors. Our code mainly collect data and bring them in normalized form on the device. The data can then be sent to remote cloud database for storage and analyze, on a low bandwidth network.
In this scenario, our software container would be protected by Docker isolation, I guess. As our company focus most on hardware and sensor, we plan to let our customer and partner to develop the software they want, so they can manipulate the data in the way they want.
If our customer damage some of our default container by mistake, we expect that BalenaOS should allow us the restore our default container structure, as part of our support service.
I need to experiment on this direction and gain more Docker knowledge to provide more concrete example.
What I imagine for now, to is to have a container for collecting hardware sensor and sign + timestamp each measure. Then the collected data are queued for post treatment on the device.
As we also have a video camera on the device, some treatment are already performed on Edge computing by analyzing the video stream by a neuron network stick. So we will probably containerize the camera sensor, and provide an internal API to exchange with the computed result, and also queue those results.
And so on, by spiting some sensor treatment via API call on a specific container or queuing results globally on the device.
We also provide some default network delivering function, so the data are send encrypted to remote storage.
We also have a local monitoring software which role is to collect internal device metric such as: voltages, temperatures, fans speed, hardware status, etc.
And I imagine, that much of this process above, could be divided in container, or exposed through internal API between containers or with a queue manager internally on the device itself.
Thanks, this is an interesting approach on BalenaCloud. It would be easier for us to manage, if I could trigger our customer account creation on BalenaCloud. The process could initialize a user registration and setup the wanted privileges. BalenaCloud will send the email to the customer account and the registration will end when the new user effectively connect or validate its account. The customer account need to be one per user of course, and may be in a group dedicated for them.
I also would like be able to suspend a device for a customer in case of missing payment of our support fee.
On the embedded application design, for a starting point, we could imagine to share a docker-compose file (or any top level definition) in a git repository in our company, with a configured commit workflow for both the manufacturer (us) and the customer.
When the workflow is validated on our CI, the build request is sent to BalenaCloud, and the current deploying process is triggered.
I don’t know yet about the Docker registry and where the containers involved in the build could be stored or copied from our company, our customer company and then to BalenaCloud registry for building all together?
Thanks for your suggestion, may be a wiki page, editing the proposed workflow could be useful here. And with some extra diagram.
Sorry about my missing Docker knowledge, some part of this merging process may already exists, don’t hesitate to send me documentation and example link I can follow.
There’s some extremely interesting thoughts here, I’ll try and go through the main points and let you know what our plans are and how you might be able to go about some of these problems.
On the subdivision of services, I think you’re absolutely right in separating out services for your software and duties and the customer. From what you’ve said, it sounds like a set of API endpoints in a service that allows the fetching of data to be processed, and then to push it back to that service for encryption and remote storage is the way to go. So customer service containers use your service containers for all information flow, without having to do any network processing of their own (unless required).
On the subject of service container damage, as a user of an application has full rights to look at any container in the dashboard/CLI, it’s possible a customer could get into your code. However, you could mitigate this by not giving a user collaboration directly to balena but by implementing your own gateway which then limits the access they could get (essentially you could proxy calls into services, limiting it to their own). This does require a lot of extra work on your part, however. There are some potential ways around this, ensuring that services ‘self-heal’, but this would also require some monitoring and healthcheck code.
On user account creation, the balena API and SDKs allow you to carry out everything you can using the dashboard and balena CLI, so this is easy to automate, and to make them collaborators on your project.
The freezing of devices on non-payment is an interesting question and I think we’d need to consider how to go about this.
I think the most sensible thing here is to bring one of our customer success team members in, because they’ll be able to have a far more involved conversation with you about your specific needs. I’m going to ping a couple to ensure we follow up with you.
The freezing of devices on non-payment is an interesting question and I think we’d need to consider how to go about this.
You said the account creation is possible via API, so it should possible to remove temporally permission or moving to a “payment-missing” deadend group without privilege or something. I didn’t try any technical implementation yet. Nor on Docker neither on BalenaCloud API.
I’m not much worrying about protecting code spy for now, because of the bunch of hardware needed. In case of corruption I expect for now, to have a safe point of restore, that will bring us back to stable state.
My problem is more on building the container architecture and the related API between containers. Next I will allow one or more container to be added from our customer. I will explore Docker’s mechanisms to take a foreign container and to start it on the side of the other.
I guess, there’s also some Registry mechanism for signed container or something. I didn’t have spare time to explore it yet.
Thank you very much for the hint. I’ll continue to post here for my progress.
This topic is of great interest to us as well, since we are also exploring the possibilities of selling devices with “managed Balena” support. As a toy example, consider the use case of IoT computer vision in a store, with two AI start-ups (our customers) that would like to tackle distinct challenges:
Customer A’s service detects dangerous situations (fire, robbery, …) and forwards the results to a security center.
Customer B’s service counts the number of unique customers and forwards the results to a loyalty platform.
Ideally, we would give the developers of these companies access to a tool that allows them to push updates to their service (and their service only) and service variables, without access to the device or application. For example, they could run hwky push and on the backend, we translate it to an appropriate call to balena push with their allocated API key.
For this situation, one option would be to add an additional Balena application member type:
Service developer: service developers are given, in contrast to the access provided to developers, only the ability to manage a specified set of services on each device in the application. This includes pushing new code, modifying service environment variables and downloading service images.
As you can see, this role is quite similar to the existing developer role, which could make it relatively easy to implement on Balena’s side (correct me if I’m wrong!). I would love to hear any other updates from Balena’s side on sharing device code updates with customers, or what would be the best way forward.