Imagine you are interviewing for an IT role at a company, and you sit down with the manager. You’ve tried researching what the company does, but you are still a little fuzzy on the details, so you ask what the IT environment is like. “So, we own the servers, but they aren’t on-premises.” That’s not unheard of, you think, they could be in a data center somewhere. “They aren’t in a data center. In fact, they are deployed in all sorts of remote locations. We have thousands of them, actually, some are a few years old and some are brand new. We’ll probably upgrade them every five or ten years. And sometimes the connections are slow. And the internet goes out from time to time. And the power isn’t super reliable. And anyone can access them, so managing security risks is a challenge. Also, there’s no one around to reset or update them.”
You thank her for the interview, and try to decide if you should just walk quickly out of the building or run. What a nightmare! How could you stay sane in an environment like that? How can you stay agile, respond to business pressures, make decisions and implement them quickly when you can’t know for sure that your servers are even connected to the internet? How do you reliably send updates, how do you even deploy new servers, and what do you do about security?
Using DevOps To Tame The IoT Nightmare
In many ways, IoT devices are like little servers at the edge. Configuring these devices, updating their operating systems or firmware, figuring out if they are up or down, getting analytics about how they are doing, and updating your software that runs on top of them, all of these activities are shared by both servers and IoT devices.
When it comes to applying DevOps to IoT, those similarities can be leveraged. Like web apps, mobile apps, internal desktop apps, and databases, many of the concepts remain the same. It’s about getting code out quickly and reliably, and keeping those services up and running, and learning from how they are used so the next time an update is pushed out you’ve made some improvements from real-life experience. However, with apps and databases, figuring out orchestration and management is often a matter of piecing together what set of established tools, processes, and roles you want to have in place in your particular organization.
At about this point, the similarities stop and the many differences begin.
IoT devices often don’t have a human nearby to reset them. They often endure extreme weather conditions outdoors, they can get wet and muddy, and it sometimes can’t be taken for granted that they will have access to power or the internet at any given time. In many cases, they are expected to have a lifetime of five, ten, or even more years without failure. After all, especially in the consumer space, people don’t want to replace their dryer just because the computer inside is a bit long in the tooth.
All of these are challenges to traditional thinking when it comes to applying DevOps practices in an organization.
When first dipping your toes into IoT, the thought of working on the process may seem like a distraction. I implore you, that piece is absolutely vital.
In comparison, the scene of IoT is that of the Wild West (albeit quickly becoming civilized). It’s difficult enough to put code out to a device. When first dipping your toes into IoT, the thought of working on the process of delivering value rather than the code or the hardware may seem like a distraction. I implore you, that piece is absolutely vital.
At the core of DevOps is the belief that change is inevitable and should be embraced with open arms. In the embedded space, in the past, much of the concern wasn’t with change, it was with ensuring whatever was released was iron clad. Without connectivity to the internet, that methodology makes some sense. I don’t think much about my regular old microwave because whatever hardware and firmware it left the factory with will run the exact same way, every time, for as long as electricity runs through it’s veins.
Once something touches the internet, that all changes. At a bare minimum, updates are the only way to protect oneself against the constant barrage of security concerns. On a more positive and forward-thinking note, being able to update your software in the wild can allow additional functionality and bug fixes in ways that were completely unfeasible before. It creates an environment of constant improvement within all of our connected things that we’ve enjoyed as computer and smartphone users for years.
So with that new environment in mind, combining DevOps with IoT isn’t just a nice to have. It’s essential.
It can be surprising how much can be accomplished with a tiny team, especially in the proof-of-concept phase. Accomplish as much as you can with only a few key players and then only scale when there is significant pain. A smaller team might include a key stakeholder with an idea and a full-stack developer with cloud development experience. That’s it.
And that’s where I’d start, the software side. There’s a surprising amount that can be done with off-the-shelf hardware, like a Raspberry Pi 3 and the Seeed Grove Starter Kit for IoT. Seeed’s Grove technology allows you to use common off-the-shelf hardware like Arduino and Raspberry Pi and connect them to sensors without getting your hands dirty with soldering irons, breadboards, and transistors – all scary and bizarre artifacts to the average software developer. It can be very tempting to focus on how you’ll make the device power-efficient, small, and easy to use. Save those problems for another day and focus on how you’ll solve the problem at hand first.
At this point in the process, it is easy to be lulled into a sense of DevOps complacency. It’s very easy to want to just develop locally, put code on the device, and never worry too much about how you’ll scale to other developers, or how you’ll deploy to the cloud, how you’ll put code on many devices, and how you’ll update them once they are out in the wild.
I would argue that at this point in the process is the perfect opportunity to figure out the basics of how to do those things, when you don’t have too many cooks in the kitchen or too many users.
Deploying To The Device
There are different tools and processes for pushing code out to your IoT devices, and for most, the tradeoff comes between ease-of-use and control. For example, it can be relatively easy to set up a hardware device with Microsoft 10 IoT Core, preinstall a UWP app on it, and then update it through the Windows App store. When you create your own image of IoT Core to put on the device, you can specify the device to auto-update the operating system as well as the app you are pre-installing.
The end result is you have a device in the wild that abstracts away the issues with updating (like what happens when the internet cuts out in the middle of an update), at the cost of exacting control over when that update happens.
So how do you get code from the developer machine to the store? Well, it is possible to directly do that from a local machine. Still, to embrace DevOps, getting a CI/CD pipeline in early will make you a hero when other developers get on board with the project. Thankfully, Visual Studio Team Services makes it easy by offering tasks that can push code directly to the Microsoft Store.
If that’s not enough control (directly pushing to the Microsoft Store, and therefore every device), Microsoft’s new Visual Studio App Center is build a more lightweight way to build, test, deploy, and get analytics for Apple, Google, and Microsoft apps. While it is geared toward traditional user apps, it works just as well for your Windows Store app that will live on a desktop as much as one that will live on an IoT device.
Beyond Proof of Concept
Once the idea is proven, and maybe deployed to a few test devices, it’s time to consider how to move beyond the proof of concept phase. At this point, all sorts of questions will come up. What if I need control over when deployments happen? How do I measure how these devices are being used? Will I know if a device has been compromised? How do I configure everything for manufacturing? Will my cloud back end handle scaling? I will cover these topics (and more) in upcoming blog posts, so stay tuned!