I remember the early days of hacking small devices with a single purpose. Many of them lived unconnected and provided one bit of functionality. Maybe you remember that day too. Perhaps you were a professional working on a sprinkler controller or a hobbyist that wanted to have an animated pumpkin for Halloween. Either way, you likely used C or Python as your device language. Those days were great. I spent them exploring and learning. As I grew, the world changed.
Now, our companies rely on data. Data is more valuable than gold. Even our hobby projects live connected. Our consumers assume devices are always connected, and products keep up with constant data streams. We need devices to be constantly connected. We need them to process data quickly and move it to remote storage. We need systems to be fault-tolerant to reduce the loss of any of this precious data. Can we use better tools to accomplish these new goals? Sometimes, you have to have the Nerves to try something new.
One of the scariest moments in any embedded team's history is updating the hardware. The numerous variables during an upgrade only increase when devices are no longer in the hands of our team. Don't worry, digital-slinger-of-bits-and-solder! Nerves has us covered. Nerves systems ship with the ability to send over-the-air updates and an A/B partition. When we first send our devices to the field, they are sent with firmware safely running in the A partition.
Let's examine a scenario: One day, a feature request is made. We diligently do our updates and test the deployment of the updated system to multiple devices. Nerves prepares our devices for the unexpected scenarios that our testing doesn't cover. When we deploy the update to the devices in the fields, the new version of the firmware gets loaded onto the B partition. The system restarts using the B partition to load the firmware. B becomes the primary partition when the firmware starts and passes health checks. Unfortunately, one of the devices is in a state that never occurred in our lab. The system restarts using the B partition, but an error occurs during our health checks. The device then reboots into the previous A partition, running the previous version of our firmware. It will happily run the old version of the firmware until we can make a fix and push an updated version. We didn't have to write extra code or worry about our user's device turning into a new paperweight. Nerves came to the rescue with a well-thought-out deployment strategy.
Systems deployed outside the lab often run into unexpected scenarios, triggering a reboot. The reboot times on resource-constrained devices can take an eternity. This delay is not ideal in mission-critical applications or when users are waiting. Nerves, built on Elixir, provides tools that simplify the process of monitoring and restarting subsystems. Our system can continue to run while subsystems restart within milliseconds, saving valuable time and ensuring that our products remain usable. With these tools and focusing on recovering from errors, our devices are more fault-tolerant without extended work efforts.
Devices are more connected than ever. Ericsson built OTP in 1995 for distributed application management, resource monitoring, servers, and event handling. With more than two battle-tested decades of ensuring networks continue to function, OTP has the developer tools to keep communication lines open and operating under real-world conditions without putting strain on the development team. Building on those tools, Nerves has a host of libraries and tools that interface with many of today's popular networking options.
When using traditional embedded languages, your company often maintains two development teams (embedded and server teams) instead of one. We want to build a seamless experience for our customers between the two systems. Creating a seamless system becomes difficult with the teams' differing concerns and tools. Conway's law states, "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." One development team builds a system that behaves as one cohesive entity. Elixir allows both devices and servers to use the same technology, vocabulary, and thought processes, reducing the friction of communication and context-switching among the team members.
Choosing Nerves over other tools provides fault tolerance, high availability, deployment confidence, and network communication tools, allowing our teams to focus on business solutions instead of stability. We can reduce our communication overhead and budgets by having a single, cohesive team working on the server and the devices.
Amos King is the founder and CEO of Binary Noggin. A leading expert in emerging software languages, Amos is also a frequent speaker at conferences like ElixirConf and Lonestar Elixir and co-host of the popular Elixir Outlaws and This Agile Life podcasts.
Founded in 2007, Binary Noggin is a team of software engineers and architects who serve as a trusted extension of your team, helping your company succeed through collaboration. We forge customizable solutions using Agile methodologies and our mastery of Elixir, Ruby and other open source technologies. Share your ideas with us on Facebook and Twitter.
