The Internet of Things (IoT) is real, and it’s here. As described at a recent IoT conference, IoT is like plastic: Eventually it will become part of everything. The great IoT system build-out is on. In response, organizations are enabling all sorts of devices to externalize data, and they are enabling most of those devices so each can be controlled by external processes.
Consider the IoT process that can “summon” your Tesla all-electric car on your smartphone, causing it to pull out of a parking space as if a ghost were driving it, or the IoT machine learning process can control your home thermostat by monitoring motion within your home to determine whether you are there.
If you've been tasked with building an IoT system, you're probably excited by the possibilities, but you also should beware of the many ways things can go terribly wrong....so wrong that you could lose your job. What could be worse than getting fired? Failing with an IoT system could result in a catastrophe that makes national news, rather than just an annoying software bug that you fix during the next sprint. A hacked IoT devices could down a plane, crash a car, send an industrial robot off calibration, or turn up a thermostat to 105 degrees.
To avoid career suicide, there are five things that every IoT project leader must understand. You could be looking at a career disaster if you:
1. Fail to understand that IoT security is systemic
National Security Agency deputy director Richard Ledgett spoke at a military technology conference in Washington, D.C., recently. When asked whether the entire IoT would be a boon for the NSA or just a whole lot of digital noise to sift through, Ledgett replied, "Both." Clearly, the NSA plans on using IoT-enabled devices to fight the war on terror, but the greater threat is from the army of hackers who constantly try to penetrate private systems.
The common pattern is that someone unfriendly will continuously push at your IoT systems. Hacked IoT devices can down a plane, crash a car, send an industrial robot off calibration, or turn up your thermostat to 105 degrees. Hackers understand that devices are easy to break into, while the systems that control them are not.
The reality is that IoT devices are “edge” devices, meaning that they provide an entry point into the network. If they are not secured to that network or, to a higher degree, to the central systems, they can provide an access point to the core system and to any other connected devices.
So, what do you do?
- Consider security at all points, not just those surrounding your central control processes. This means that data needs to be encrypted, the APIs monitored for misuse, and the entire system chain, including devices, must participate in a proactive security model using the appropriate security tools.
The general belief is that we’re bound to encounter some massive IoT security breach at some point, one that not only allows secure data to be abstracted, but could also result in scenarios we are just beginning to imagine. Some pretty awful things can happen around the penetration of devices. If that breach is a foregone conclusion, just make sure it’s not you who will be held responsible due to a lack of holistic planning or outdated security protocols.
2. Fail to understand that the API design is critical
APIs are fine-grained services that may be called by other systems, applications, or people to provide access to IoT services. Problems arise when the APIs are not properly defined and designed. The number one complaint from those who leverage IoT devices programmatically is that the APIs often fall short of expectations. So programmers bind "fix-it" code to those APIs and are forced to change the code when new and better versions of the APIs are released. This is a lose/lose for those doing IoT development and those who are standing up those APIs.
Two things to remember:
- Fine-grained APIs are better than coarse-grained. The idea here is to give more granular control to those who use APIs to build IoT systems. Although this approach means you may need to invoke many primitive APIs at the same time to get the desired behavior, having more fine-grained APIs provides better control over IoT devices, and developers like that. The guidance should be “when in doubt, break it out.”
- Error processing and recovery should be designed into the system. Guess what: IoT-based applications may leverage more than 100 APIs at any given time, and if a single API takes a dirt nap, then the system is hosed until the issue can be addressed by a human. To avoid this problem, IoT API developers need to design in error-handling mechanisms to deal with all possible failure scenarios, including restarting network services, backing out bad data, etc.
3. Fail to produce documentation
While most IoT projects overlook the need to document the system’s capabilities and API usage, or even provide sample code for device access and control, it’s now a best practice to take the time to write user and developer documentation for IoT-based systems. The same requirement exists if you build a system around the use of IoT or if you build an IoT-based product.
IoT-based applications may leverage more than 100 APIs at any given time, and if a single API takes a dirt nap, then the system is hosed until the issue can be addressed by a human.
Documentation has fallen off the radar screen within most development projects, even within product development organizations.
Take note:
- Failure to provide the documentation that your developers and users need means that you’re open to all sort of trouble, since you did not provide a standard for proper use.
In other words, someone is bound to do something unintended with your IoT system, and you may well get sued because you don’t have a paper trail that shows they were told what to do and what not to do.
4. Fail to provide for testing
When building IoT systems, testing is critical to verify the correct function of those systems. You need to provide platforms to test the IoT systems, no matter if you build on somebody else’s IoT platform or your own.
Most IoT performance issues can be traced back to insufficient testing, bad engineering, bad API design, or all of these.
Best practices here include:
- Provide device simulators that basically function with software and don’t do anything physical. This ensures that, if you do drive the smart car into a pole, it’s done virtually. The actual devices are leveraged in certain cases, but there are failsafes in place to stop unintended things from happening.
- Provide DevOps testing processes that can be integrated with popular DevOps tools that support continuous testing.
- Test for security issues as part of the DevOps pipelines, including spotting new problems that are introduced by software changes.
5. Fail to consider performance
IoT systems are very sensitive to performance issues, because any latency is reflected in the behavior of the device. Industrial robots can slow down an assembly line, and that could cost thousands of dollars per hour. Far worse, your car takes 3 seconds instead of 0.000001 seconds to recognize that a car is cutting you off and the brakes need to be deployed.
Performance is really about layers. There is the software layer that needs to execute faster than the devices can respond. Most IoT performance issues can be traced to insufficient testing, bad engineering, bad API design, or all of these. This problem is solved by sound coding practices, testing, and integration into a DevOps process that ensures consistency.
"Software-defined everything" leads to a few basic problems that need to be addressed. Security leads the way, followed by bad software...
Of course, there are those cases where device performance itself is the problem. Typically, these are the same engineering problems that need to be fixed with better software or firmware. Most IoT devices are “software-defined” and thus they should be easy to update to correct the problem. Again, testing is critical here to ensure that the performance issues are addressed.
Get proactive when building your IoT systems
There are many ways that IoT-based development can get you the old heave-ho, no matter if you’re using an IoT device and software systems or building one. Your best bet is to understand that IoT is really about software systems development with the added complexity of leveraging a physical device. The device must respond properly to the commands of the software and to the infrastructure that supports the software.
IoT is often considered a form of traditional embedded programming, which is the way we controlled devices in the past and still do today. However, IoT is software- and data-driven. While there will be some embedded programming, devices are now software-defined, for the most part, and thus can become much different as software is updated on the device.
The power of "software-defined everything" leads to a few basic problems that need to be addressed. Security leads the way, followed by bad software that can drive huge problems around the use of those devices. Indeed, many of these issues can lead to failing the concept of mission-critical, or, worse, life-critical. Both of which will get you fired.
If you like your job, the best way to protect it is to be proactive when building your IoT systems. In other words, don’t wait for trouble to find your IoT system. Put the known processes and protections in place that avoid trouble. Do that, and you’re in for a long and happy career in IoT.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
