When it comes to IoT, there is a lot of complexity and fluidity in the systems. Suddenly, computers can be and do almost anything, including advanced learning. And, like with CoAP and MQTT, this can lead to confusion in the best method to solve problems.
It’s not as simple as: Browser -> Server -> Database — if it ever really was; nor is it: Various Clients -> APIs -> Server(s) –> Data Store(s), like it has been the last few years.
The explosion in IoT devices that need to be built (fitness trackers, thermostats, smart cars, smart lights, smart homes, etc.), combined with the proliferation of tools that can be used to build those things leads to skyrocketing possibilities of solutions to cutting-edge problems. Not only are developers having to deal with the challenges posed by connectivity (security, availability, etc.), but they have to build a cloud architecture that can handle the high-speed, on-demand nature of IoT.
This should lead to immense optimism around the future — both for jobs and for an economy (like the U.S.) driven by creativity.
But, man, it really takes some creativity to devise these solutions. Your bag of tricks needs updating to solve IoT problems on the back end — once you’ve figured out the protocol you need to decide:
- How many different kinds of data storage do I need?
- What will my device do that differentiates it from other devices?
- Do I need natural language processing? How will I do that?
- Do I need a domain-specific language?
- How will I process all the data and where will I store it?
The great news is that there are tools to solve all these problems today. The challenging part is finding the right way to bring all the right tools to bear on your problem.
Sometimes you may be using different programming languages for different parts of the system. Node.js here, Java there, Python for this, C# for that. Even if you have a unified architecture, the pieces aren’t all one flavor anymore.
So, being an architect isn’t about mastering the depths of a single language, it’s about knowing how the parts of the system fit together and being able to do so creatively. And it’s about mastering the depths of at least several things to be able to put together a finished product with your team.
For IoT especially, no two projects are created the same. The form factors, data, sensors, actuators, networks, protocol, people are all different. More and more this implies a need for creative connection of disparate pieces to fit a particular problem.
For instance, we have a client who is doing unique work with specialized actuators in its hardware device. Part of the solution is to provide a power user or administrator a visual tool to send information to the actuators on how they should behave.
In order to do this we’re using ANTLR to define a grammar and parse expressions for a custom language, Google Cloud (including Endpoints, Firebase, BigQuery and Cloud Datastore), Angular and Firebase Crash Reporting for mobile.
On another project we’re partnering with a hardware vendor to use the Azure IoT Hub to process transportation-related messages from a wide variety of sensors on connected vehicles. For this project, we had to define all the sensors and the specialized data payloads that come from each one into a cohesive messaging system.
And this is before we even talk about hardware (which is facing a disruptive evolution in its own right)!
Being a cloud architect for IoT is fun and exciting, but don’t expect to rest on your laurels, and don’t expect to be doing just one thing or programming just one language. You will need multiple skills, in-depth understanding of the cloud tools and a great team around you to rely on when you run up against a tool, language or framework that isn’t in your wheelhouse.
This is an evolutionary process where cloud architecture has been going for some time — understanding the technologies at your fingertips and how to deploy them is the name of the game.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.