This past October, our team went to Gig City Elixir, a programming conference with sessions focused on how great programmers solve problems using Elixir and other languages.
Full disclosure — Very sponsors the event, and we have done so since the conference started, so we expected to enjoy ourselves. 2019 was no slouch. We had a blast both onstage and off!
Whether it was our VP of Marketing, Emily Maxie, speaking on the Better Allies - Approaching Equality Together panel, hacking on Harald with Frank from the Nerves Project, or just enjoying the local cocktail scene, Bruce and Maggie put on a great conference in a great location. Evidence of good times in the Slack screenshot below:
Nerves Training at Gig City Elixir
Conferences aren’t only about having fun, though. They’re also one of the best ways to hone your craft. While we were there, several of our developers went to the pre-conference Nerves Training session put on by Frank Hunleth, director of hardware engineering at SmartRent, and Justin Schneck, embedded systems architect and engineer for Le Tote. As frequent users of and believers in the Nerves Project, we jumped at the chance to get our newer-to-Nerves developers some hands-on time with the framework.
Frank and Justin have put together a really spectacular course. The training feels complete, is very fun, and is somehow still accessible. The range of developers at the training was broad, from seasoned graphics driver developers to teenagers trying out Nerves for the first time.
No matter what experience you bring to the table, there are plenty of takeaways — though probably a few more if you’ve worked with hardware or firmware before. For our developers, not only did we walk away with a more complete survey of the project, but we heard first-hand the motivations and inspirations for the project — something that can often be quite difficult to glean from READMEs alone.
As an engineering manager or business owner, you might be wondering: as an add-on to a conference or something your company might invest in, is the training worth it?
My answer is yes, absolutely.
I learn best by doing, and your team probably does too. The project that the course offered is compelling. For our training, we worked on a multiplayer internet-connected social game complete with a display, buttons, and yelling!
The workshop also covers a broad array of topics — from UIs with Scenic, Websockets, GenServers, and more. Your team will have first-hand experience with many common patterns and libraries in the Nerves ecosystem. A brief overview of what the training covers:
- Interacting with hardware using Elixir Circuits
- How to deploy using NervesHub
- How to render a UI with Scenic
- Connecting to a Phoenix App with WebSockets
Why Nerves Works for the IoT Development Process
So, why do we like Nerves so much? On Day 1 of the conference, Justin Schneck gave a presentation on adopting Nerves as your IoT development framework, and even though we’re already huge fans, we took notes.
Hardware can be hard, and even after you’ve figured out all of your wire diagrams and integration points to connect your “thing” to the internet, you’re still left with the question: how do I actually ship this product to production and make sure that it keeps working? You’ll need to think about cellular networking, firmware updates, and security.
Luckily for us, this is the core question that Nerves answers, providing a solution for building maintainable embedded systems.
Nerves is Resilient
Nerves runtime is resilient because it’s built within the Erlang runtime system, which follows the “let it crash” or “let it fail” philosophy. If something crashes, Erlang will just restart it back to a known state, based on the supervision trees that have been set up.
Nerves runtime also allows you to monitor and control your devices remotely, which is a big deal for an IoT product once you’ve tearfully hugged it goodbye and sent it off into the world to go make a difference.
Additionally, with Nerves, you ship your product with two firmware slots, so that you always have a second working copy of your firmware as a backup. This is also what allows OTA updates. You push your new firmware to the currently unused slot, and if the update is successful, you reboot into the new firmware. Handily, this leaves the old firmware slot now open for future updates, toggling between slots A & B.
Nerves is Reproducible
Nerves is also reproducible because it boots up the same way every time. Nerves runtime mounts everything as read-only in root file systems — except for the application data partition, where read-write is enabled — which means that it’s going to look the same every time you boot it up because there was no modification made to the root file system.
Additionally, with Nerves, you’ll get the same benefits that you get from the immutable data structures made possible with Elixir. You don’t have to worry about your state getting mutated in the ways it might with other languages.
Nerves is Reasonable
When it comes to access control for IoT, there are two primary methods you can use — the blacklist approach or the whitelist approach.
The blacklist approach works really well when you know exactly what you don’t want in your system. But in IoT, there might be a lot of things that you don’t know you don’t want. If you choose the blacklist approach, therefore, you could end up with CVEs in your system that you didn’t patch because you didn’t realize they were there in the first place.
Nerves, by contrast, is reasonable for IoT because it has a whitelist, or build-up, approach, meaning you’re only inputting the things that you know you need. You have minimal output runtimes and fewer unknowns, creating leaner, more efficient systems.
How Do You Start Using Nerves for IoT Development?
So, say you’re as sold as we are on the value of Nerves for IoT. What do you need to be aware of before you get started?
Considerations for Choosing a Platform (The Device You’re Building On)
The device you choose to build on for your Nerves IoT project will differ based on the specific needs of your project. A few things you should consider that may affect your choice include:
- Production volume
- Prototype or POC
- Operating environment temperature/humidity
- Input/Output (I/O)
- Third-party software requirements
- Regulatory considerations (FCC/ISO/cellular carrier)
These are the platforms supported by Nerves today:
- Every Raspberry Pi ever made
- Beaglebone Black, Green, Blue, and Pocket Beagle
- Custom systems (Buildroot)
Building a Development Team
Finally, how do you need to structure your IoT development team for a project that uses Nerves?
Here’s a little secret: Nerves is actually a fun way to trick Elixir developers into working on your embedded systems. For new IoT development projects, you can hire multiple Elixir developers and have them use Nerves to manage device drivers, business logic, and web communications.
For existing projects, where you might have a lot of components written in C, for example, you can have the majority of your developers working on what you’ve already built, dealing with business logic and device drivers.
Meanwhile, you can employ just a few developers to work on device initialization, process supervision, and web communications with Nerves. Managing embedded Linux can also be handled on a consultation basis.
Ready to Learn More?
The Nerves Project website offers a lot of resources beyond this blog if you have in-depth questions about working with the framework. Because we’re so invested in the project, we also have quite a bit of Nerves-related content too, like this white paper (#humblebrag).
And of course, if you’re looking for a team with Nerves experience to help you bring your IoT vision to life, you can reach out to us today.