Internet of Things is fast evolving and is slated to become one of the largest markets and one of the most expansive industries in the next few years. In a conceivable future, every single aspect of our daily lives will be monitored and control by the billions of devices that will be connected to the internet.
But there are some caveats to using the full potential of this nascent technology and making the best use of the utilities that it offers. The implications of not addressing IoT development issues are more far-reaching than data security and privacy issues. Many industrial resources, including infrastructures such as power grids, and critical devices that regulate and control health, such as drug infusion pumps, are dependent on IoT technology.
The bottom-line is that IoT is becoming so integrated into our lives that it should be taken much more seriously. Yet the concerns are so many that if we do not tackle them separately, we are bound to be met with dead ends, pitfalls and outright disasters.
I first learned of the concept of “abstraction” and “separation of concerns” when I was studying object oriented analysis and design (OOA/D) and software design patterns. This is a tried-and-tested method that has helped deal with the complexities of software development for years. And I truly think that IoT development needs a similar approach, especially while it is still in its infancy and is still undergoing fundamental changes. Here’s why isolation and separation should be the key approach in IoT development.
There are too many diversities and too many moving parts
I’ve already talked about scalability issues in previous blog posts and articles. The varieties of hardware and software that IoT devices cover create challenges for development of solutions. For instance, at one end you have devices that are sporting small-scale 8-bit microprocessors while at the other end you have powerful 64-bit multi-core processors that have extensive computational power. Writing software for these totally different types of architectures is challenging.
The same goes for storage, where some devices have no or little storage capabilities while others have tens and hundreds of gigabytes of storage space. Encryption, networking, operating systems… whatever aspect of IoT you examine, there are just too many diversities.
And with the limitless use cases that IoT has, you’ll be seeing all of these varieties deployed in different settings, different combinations and arrangements, all of them expecting to connect and interact with other devices seamlessly.
One solution would be to create ad-hoc and proprietary software and hardware modules for each possible scenario, which is failed right off the bat because there are virtually infinite number of possibilities, it would take huge amounts of efforts, would be prone to flaws and would be impossible to manage and maintain.
By separating concerns, we can isolate different aspects of IoT development (encryption, storage, functionality, network delivery…). By defining interfaces and contracts, we can create different modules that address the varieties of IoT while being able to interconnect and interact without depending on each other’s underlying implementation details. This could help mix and mingle different technologies in any way you want, given that they respond to the required contracts.
IoT is changing in many directions
IoT is still a nascent technology that is evolving in many different directions at the same time. There are too many competing technologies and trends. For instance, we have a plethora of data delivery mediums, such as Bluetooth, Bluetooth Low Energy (BTLE), ZigBee, Wi-Fi, Thread… Each of these have their own purpose and characteristics in range, battery life, bandwidth… Some of them might not be around in the next few years and be gobbled up by one of the other competitors. On the other hand, we might see the apparition of other hot new technologies (such as the NFMI).
Other verticals are evolving as well. Storage and functionality can be switched to the cloud and back to the device or to some blockchain mechanism, depending on which can better address the changing market and consumer needs.
If we do not plan for our solutions to be able to adapt with alterations, we’ll be doomed to rewrite code and reinvent the wheel for every slight change that overcomes the industry and market. Here’s where separation of concerns and abstraction can again come to the rescue. By having distinct abstractions for each conceptual component of IoT systems, we can allow the underlying technologies to evolve and progress without disrupting each other as long as they conform to the defined set of contracts that connects them together.
The use of structural design patterns such as “pipes and filters” can also help and allow changes in formations and structures to be addressed by using input and output contracts. So for instance, if you want to plug in an IoT device to your ecosystem, yet it doesn’t have the means to encrypt its data or to implement secure communications protocols, you can add an HSM module to your graph, connect the device’s inputs and outputs to the HSM’s interface and conduct communications through the HSM transparently.
The IoT development workforce lacks expertise in many areas
IoT developers usually come from an extensive embedded systems background, yet have little or no experience developing for online (always-online) and cloud-based systems. This means they’re neither able to adequately control the security implications nor take advantage of the benefits such settings provide. They don’t necessarily know how to identify and authenticate devices on a network in a secure and unspoofable manner. They don’t know how to leverage cloud storage for analytics and reporting. There are a lot of different things involved and there’s only so much a developer can master individually.
That is why we’re seeing severe security vulnerabilities pop up in IoT devices everywhere, from HeartBleed exploits to shared private keys across devices, to devices that leave ports open to scrutiny over the internet. IoT security vulnerabilities are making the headlines on a regular basis.
By separating concerns and providing developers with ready-made solutions to deal with the security, storage and messaging facets of their IoT solutions, we can relieve them of the need to implement their own proprietary code and, as previously mentioned, reinvent the wheel.
Everyone’s in a rush to ship to the market
IoT is in its “gold rush” phase, and every manufacturer is in a rush to ship new inventions to the market before competitors, and thus get a bigger piece of the pie. That’s why we’re seeing developers and manufacturers overlook security and adaptability and focus solely on shipping function-complete products.
This is having serious implications. A look at the reports being published about the Shodan search engine shows just how awful the insecurity of IoT is.
While IoT developers’ concerns for rapidly shipping products is understandable, their oversight of security issues is not, because it is spilling tons of private data online, is threatening to open up security holes in places never imagined previously, and can even compromise the health and threaten the lives of consumers in some cases. All of these facts are going hand in hand to create mistrust among consumers, which fires back against the manufacturers’ initial goal, which was to improve sales.
Creating separate, reusable modules for security, authentication, messaging and storage can help manufacturers focus on their area of expertise meet their release deadlines without neglecting the other important aspects of development.
Final thoughts
Separation of concerns is a wonderful concept, and it has applications in many different fields. I’ll be writing about this in my future articles, but I’d also like to hear your thoughts and perspective on how we can deal with the complexities of IoT development.