Introduction
Every Azure Sphere device must be associated with an Azure Sphere tenant before it can be used for development or deployed in a product. Azure Sphere tenants allow teams to manage Azure Sphere devices. This may be development activities or managing production Azure Sphere over-the-air (OTA) application deployments. While it's not obvious, these two use cases conflict and it can be confusing for new Azure Sphere teams to define an Azure Sphere tenant strategy that allows development teams to be productive and also provides tight control over production deployments. Additionally, because devices can't be moved from one Azure Sphere tenant to another, the team should consider long term business strategies as well. This blog discusses Azure Sphere tenant constraints/exposures and defines one potential strategy that new Azure Sphere teams should consider when starting their Azure Sphere journey.
Tenant Activities
Microsoft describes the Azure Sphere tenant as "An Azure Sphere tenant provides a secure way for your organization to remotely manage its Azure Sphere devices in isolation from other customers' devices."
You access/leverage the tenant to do things like enable development mode (unlock a device for development) or to manage OTA updates for a fleet of devices. See Avnet's Over-the-Air deployment Lab to learn about setting up and managing products, device groups and OTA updates. There are many other things that you use the tenant for, but when considering a tenant strategy, in my opinion, these are the key activities that should be considered.
Azure Sphere tenant vs. Azure tenants
Don't associate or confuse your Azure Sphere tenant with your Azure tenant. These are two different entities and are not associated or related to each other. Microsoft manages the Azure Sphere tenant deployment and incurs any associated cost with providing this free service for Azure Sphere devices. Your organization owns and manages your Azure tenant and is responsible for all costs incurred.
Things to consider
What are the constraints and activities to consider when defining a Azure Sphere Tenant Strategy?
- Users (who has access to the tenant)
- Production Considerations
- Developer Considerations
Tenant Management (users)
There are currently three different users defined with varying levels of access . . .
- An Administrator has full access to all devices and operations within the tenant, including the permission to add or delete other users. Your organization should have at least two logins with this role, but no more logins than necessary.
- A Contributor can add devices and device groups, as well as create and change deployments, but cannot perform any delete operations. Software and hardware developers who create applications, manage connected devices, and update deployments, but are not responsible for managing tenant access, should have the Contributor role.
- A Reader has access to information about the tenant, including claimed devices, deployments, and when available, any error reporting data from devices. This role is appropriate for maintenance and operations personnel who are responsible for tracking connected device performance at end-user installations.
Production Considerations
Note that the Administrator and Contributor roles can both update deployments. Managing your product's deployments should be considered a privilege that only a few trusted employees are granted. If a tenant user accidently or maliciously deployed bad or misbehaving application(s) to your production devices, there could be huge consequences to the business. Any mature software organization implements a release management process, and that process should ensure that only fully tested and approved applications are deployed to production device groups/products.
This implies that your production Azure Sphere devices/products should all be claimed to an Azure Sphere tenant with limited Administrator/Contributor users.
Developer Considerations
Azure Sphere development teams require access to the Azure Sphere tenant where their development devices are claimed. Developers need to be able to enable development mode (unlock) devices so they can sideload and debug Azure Sphere applications. The minimum required user access for developers is Contributor.
Since developers require Contributor access to perform their job duties and the Contributor role is able to update deployments, they should NOT be users in a production tenant but should have access to a development tenant.
Devices are claimed to a tenant and can't be moved to another tenant
Azure Sphere devices are associated with a single Azure Sphere tenant and once a device is "claimed" to a tenant it's in that tenant for life, it can not be moved to another tenant.
Business Considerations
Consider a scenario where a startup company is developing multiple products that each leverage one of the Azure Sphere MCUs. The company has long term plans to sell off its product lines to other companies. In this scenario it's advantageous for each product line to be managed in separate Azure Sphere tenants.
If all the devices across all product lines are managed by a single Azure Sphere tenant, then it's impossible to pass control of a single product line in the tenant to the new company without exposing the other product lines. Conversely, if each product line is managed by separate tenants then when the product line is sold, the Azure Sphere tenant where all the devices are managed can be transferred to the new company and there won't be any concerns.
Suggested Strategy
My recommendation for new Azure Sphere teams is to create a single Azure Sphere tenant for development, and then as the product matures and production units are manufactured, create a second Azure Sphere tenant for validation and production devices. This strategy allows development teams to move as fast as possible and also allow tight control over validation and production deployments.
Development Tenant
The development tenant could be organized as shown in the graphic down below. Please click on the image to enlarge it. The graphic shows three different products in the tenant. Each product can have separate development activities. Under the "Product1Name" product I'm showing 6 device groups. The first 5 device groups are the standard device groups that are created when you create a new product. The last device group called "Validation Lab" is a custom device group created by a tenant user. You can create as many custom device groups as you need to support your development process.
Users
The users for this group includes the entire development team as Contributors and a couple of managers as Administrators to add/remove users as needed.
Development Device Group
When devices are put into enable-development mode azsphere device enable-development, they are logically moved into this group. Note that this group still receives OS OTA updates, but not application OTA updates.
Validation Lab Device Group
I've also shown a custom device group called "Validation Lab." Since the developers all have access to this tenant, this device group could be used to give the validation team early access to features as they are developed to help flush out use cases and obtain feature feedback before any production builds are available. Devices that have been claimed to this tenant could be deployed to the Validation Lab and builds/applications can be pushed to the devices OTA by uploading them to this device group.
Production tenant
The Production tenant could be organized as shown below. Please click on the image to enlarge it. Each device group can have different builds/applications/deployments so you can manage risk for the devices in each device group as appropriate.
Users
The users for the Production tenant is limited to only the most trusted team members. I'm showing director level Admins and Release Managers with the contributor role. This way only the Admins and Release Managers have the ability/access to push new builds to the validation team or production devices as builds pass through the organization's release process. With great power comes great responsibility!
Development Device Group
This device group still exists in this product and if a production device needs to be moved into this group for troubleshooting or debugging, any of the defined users can enable development for the device then pass it to a developer/engineer.
Validation Lab Device Group
The Validation Lab could have production units claimed to this tenant and defined in this device group. The Release Manager can push release candidate builds to the device group for each test pass.
The release process should be tightly controlled. Once a build/application has been pushed to the tenant then deployed to the Validation Device group, it can be moved/associated to other device groups in the tenant. So the build that the Validation team tested is the exact same build that gets deployed to the Field Test or Production device group. This is the proper way to promote builds through the process and guarantees that the build that was tested is the build that gets deployed.
Field Test Device Group
This group could be used for your Beta customers that are willing to accept early releases and provide early feedback to the product team.
Production Device Group
This group is used to manage all your production devices. You could have multiple Production device groups. For example maybe you want to manage devices by region so you could have ProductionAsia, ProductionUS, and so on. Maybe your product has multiple hardware revisions that require different application builds, you could create separate Production device groups for each, for example ProductionRev1, ProductionRev2 and so on.
OS Evaluation Device Groups
Your validation plan should always include testing new OS releases before they are released into the retail feed. Microsoft will push new OS builds to the OS Evaluation feed 2-3 weeks before they are moved to the retail feed. These device groups facilitate testing new OS releases as early as possible.
Creating a new Azure Sphere Tenant
To create a new Azure Sphere tenant you need a user account and an unclaimed Azure Sphere device.
User Accounts
See the Microsoft Documentation here for details. Basically you need to confirm that your email address is associated with a Microsoft Account, and then add yourself as a new user: azsphere register-user --new-user <email-address>
Create a new Tenant
See the Microsoft Documentation here for details.
- Install the Azure Sphere SDK, if not already installed
- The SDK will install the tools needed to communicate with the Azure Sphere device
- Connect an unclaimed Azure Sphere device to your PC
- Login using your user email: azsphere login
- Create the tenant: azsphere tenant create --name <tenant-name>
Add additional users to the Tenant
See the Microsoft Documentation herehttps://docs.microsoft.com/en-us/azure-sphere/deployment/manage-tenantsfor details. By default when you create a new tenant you're automatically assigned the administrator user privileges. You can add as many additional users as you need.
- Register new users as you did above: azsphere register-user --new-user <email-address>
- Add the new user: azsphere role add --role <Administrator|Contributor|Reader> --user <email-address>
- List all the users in the tenant and their roles: azsphere role list
Conclusion
I hope this blog gave you a better understanding of Azure Sphere tenants and how you can use them to manage development and production activities. I got into the weeds a little talking about device groups, but I think it helped support my recommendation for multiple tenants.
It's feasible that you could have a single Azure Sphere tenant and have trusted users enable development mode for the development team's devices. This will likely slow the development team down sooner or later; but it's a feasible scenario. I was a release manager in the past, and controlling the software that gets released is critical to a products quality and reputation; I prefer tighter control.
Keep in mind that the recommendation in this blog is my opinion. There are lots of reasons for managing tenants in different ways and the nice thing is that the system is flexible so that you can define multiple tenants or just use a single tenant, it's 100% your decision.
Please feel free to post questions or comments below, I love to hear different viewpoints on these topics.
Enjoy,
Brian