Here’s a question we answered in the Interrupt Slack channel after the OTA updates panel. We’re sharing the answer on our blog to make it available to a wider audience.
As you mentioned, you think OTA updating is to be developed early in the development stage. Also, it is evident that one needs to think about a lot of different things. Do you make sure that you implement all of these things in the beginning or what do you develop in that early project stage?
For context, everyone on the panel agreed that OTA updates should be implemented as early as possible in the product development lifecycle – ideally, first. In fact, the panelists agreed that should be the key takeaway from the discussion.
Here’s the gist of the rationale behind this advice, which is described in greater detail in the conversation and the Over-the-Air Update entry:
- OTA updates have significant architectural implications. These are best addressed up front.
- OTA update support is more complex than you expect. It’s not just “can I remotely send an update to the device”, but more involves essential server-side fleet management capabilities like staged rollout support.
- You want to get as much mileage out of your OTA update solution as you can so you can be sure it is reliable enough to not break devices in the field.
Now, back to the question: “Do you make sure that you implement all of these things in the beginning or what do you develop in that early project stage?”
Ideally, if you’re purchasing, you’d get all the essential OTA update and fleet management capabilities that we discussed out-of-the-box. You’d integrate the update mechanism with your device, and you’d use the associated tools for the lifetime of the project. In this case, there is no need to pick-and-choose the pieces that should be implemented early on.
If you’re building a custom OTA and fleet management solution, avoid the trap of “I can run a script to send a build to a device using an OTA mechanism, that’s good enough for us to work on other features.”
It’s a trap because it is, in fact, a reasonable approach that addresses some of the primary concerns. You will start considering the architectural implications on the device side. You also have the opportunity to exercise the update mechanism to ensure the device-side support is reliable.
The problem is exactly the same as we discussed in the live conversation: the temptation is to handle the easy part (OTA updates on device) and punt the complex parts (fleet management, controlled version rollbacks, staged rollouts) until “later” in the project. If your “later” involves scheduling out when, how, and by who these features will be implemented, then that is fine and the reality of how this suite of capabilities will be implemented. But n our experience, “later” is almost always the end of the project, right before releasing to customers.
We cannot emphasize this enough: if you’re building a custom OTA and fleet management solution, you need to give it dedicated engineering time throughout the project lifecycle. The fleet management capabilities we describe are essential, as they significantly reduce the risk of catastrophic failure from sending out a bad update. Don’t leave this stuff for “later.”