One of the hottest things in tech today is the Internet of Things (IoT). Everything will be connected including every gadget, kitchen appliance, wearable device and vehicle. But one of the biggest areas for IoT are controllers embedded into just about everything. These controllers will report back, generating reports and information that can be analyzed and acted upon. IDC says technology and services revenues rooted in components, processes, and IT support for the IOT will reach US$7.3 trillion by 2017, up from US$4.8 trillion in 2012. When you are throwing around numbers in the trillions that is no small feat.
New IoT implementations require projects (such as application development and backend integration, for example) that many enterprise customers don’t have the resources or custom development experience for. Vendors such as Microsoft and AT&T are responding with IoT consulting services. These vendors must be flexible to meet the needs of enterprise customers whose IoT can include machines and devices from a variety of makers. As such the bigger vendors are generally agnostic towards partnering with otherwise competing vendors in order to pool the necessary resources to complete an IoT project.
When management contracts a vendor / consultant for this kind of engagement, a DevOps mindset really helps to ensure the new IoT ‘glove’ fits the existing IT and information security ‘hand’. As challenges appear, a DevOps approach utilizing best practices is the best way to meet them.
A common challenge with IoT projects is the disconnect between management desires and IT realities. IoT projects often begin because management has a goal to receive specific information. Many IoT projects involve installing controllers in business and manufacturing to retrieve data from their IoT. The controllers themselves are of course hardware. This of course is a challenge to traditional DevOps approaches. By its very nature IoT is dealing with hardware that is difficult to upgrade. Of course more and more it is the software that is driving the innovation
“In many cases, management may hear good things from a competitive company they know who uses a specific controller device that they really like,” says Jerry Irvine, CIO, Prescient Solutions. Management may request that the vendor pull in that maker and product and that IT work with them to make it work. Unfortunately, IT will often find that the device is not compatible with the proprietary systems they use. Then the business will often ask them to find a compatible substitute and may still want it by a given deadline. This is not how anyone should acquire controllers.
The best practice solution is for the enterprise to have an R&D team including IT set up to work in an on-going fashion to provide requirements for the IT environment and the business function. “In this way, IT and executive management can proactively and consistently look for new offerings with compatible features and functionality,” says Irvine.
Another way DevOps can help in IoT projects is to maintain the environment in the least customized way possible. When a vendor puts in a controller, they will certainly be able to customize it to provide the specific reports and functionality that the customer wants. If the customer wants to go beyond the standard reports and capabilities however it now can pose a challenge to automation and further development.
The issue is that when the enterprise needs to apply updates to the hardware, device software, or management application, the vendor must customize that as well, and the updates come at a hefty premium rather than standard (gratis) with the product. The best practice solution, says Irvine, is for the enterprise to take the entire report that the controller can provide standard, and customize the data from the report on the end afterwards. Customize as little as possible.
Security is another challenge for IoT projects. The fact that these devices are connected via the Internet can make them a target for hackers. Companies deploying controllers should ask themsevles “how sensitive is the data that IoT devices and wireless communications will handle, and how dangerous can the IoT machine or device be? ” If developers/IT and operations can say with a certainty that the IoT application will never handle extremely sensitive data such as credit card numbers, and that the IoT device is not a car, dangerous machinery, or a potentially dangerous medical device, for example, then of course security is less of a concern. But part of goal of DevOps should be how do we build security organically into the device, software and process.
John Pescatore, Director of Emerging Security Trends, the SANS Institute. IT and management says we will have to limit what IoT applications can do. If the application must use sensitive data, it has to be encrypted and the end device has to have enough processing power to do encryption or it cannot be part of this application. Likewise, for security of life and death critical applications, there is a part of the DevOps model that does not make sense. That part is the “build a little/fail a little/fix” type model of the evolution and perfection of the device. “Letting your customers find failures in MRI machines or 787 Dreamliners is not a good idea,” says Pescatore.
So how do we reconcile the DevOps model, along with security when building components for the IoT? The challenges are there, but they can be overcome when we are talking about trillions of dollars at stake.
