DZone Research: IoT #Fails
So many use cases, so many opportunities for failure.
Join the DZone community and get the full member experience.Join For Free
To understand the current and future state of IoT, we spoke to more than a dozen IT executives active in the space. Here's what they told us when we asked, "What are the most common failures you see with IoT initiatives?":
- 1) Lack of focus on security — security has never been more important, and companies are realizing just how vulnerable their products really are. 2) Choosing the wrong protocols — when it comes to building IoT apps, it’s not one size fits all. Depending on use case, protocol matters. For example, for low-powered simple deployments of thousands of sensors in a field, you’d want to choose something like MQTT, which is optimized for that use case. 3) Not focusing on battery or bandwidth consumption — When it comes to bandwidth management in building IoT apps, it's important to recognize that IoT users and devices won’t always be connected to a reliable WIFI connection or even 4G. In fact, devices will often still need to function in unreliable or varying network environments. If your application is built to perform only on the strongest internet connections, the app will start to underperform when put to the test. For battery consumption, it’s imperative to look at where and how energy is being used. Some common battery drainers include unnecessary background activity, inefficient refreshing, and location-heavy deployments. When choosing any infrastructure or platform to power your IoT deployment, battery consumption should in mind and see what features your service provider has to reduce it. Does the platform utilize efficient data transfer protocols? Does it include things like message caching? Does it allow you to use a microservices-oriented architecture? How that platform provider architects their product determines how well your product will perform.
- 1) Many IoT devices are run on Windows platform. Run as Windows embedded device. Cornered into a single vendor environment. Now Kubernetes, Docker, GPU-based devices much faster. Get environment of containers managed by K8s. IoT is one item where the languages being used s changing on a daily basis. Pick something that will be supported in the future.
- If hardware and software developed at the same time, companies may not spend time on user testing – UX and visual design. If you just test software, you’re making assumptions that the hardware will work. Test prototype hardware with people.
- With limited resources supporting the whole ecosystem of technology is hard – Android and iOS. Getting the basic foundations to work for the user – device, environment. Fundamentals need to be right – Wi-Fi connections, UX. Get the basics right.
- We all want to go immediately to AI/ML without going through the discipline of building out the fundamentals – data ingestion, visualization. We learn as we move up the analytic stack. Iterative steps need to build skills at each. Each project gives the related ecosystem of projects a boost. One motor project that will help all others.
- Put in an innovation lab to test and validate hypotheses. Arm them with the right foundation. Do not assume things, test. Get started, people don’t know how to start because they’re afraid of failing. The link between technology and business is broken — get developers, operations, business, and security together to figure out. You need an executive sponsor and a business driver, as well as a clear go-to-market strategy. Follow a partner-first approach. Identify your own gaps. Be open. And be willing to share challenges.
- OCF has a best practices checklist, part of security specification, you need to look at the whole product design beyond OCF. We offer recommendations. Mirai virus worm was based on devices using default passwords — don’t use default passwords. Make sure encryption keys are held in a secure location.
- Reliable communication/data exchange between devices and lack of management platform to administer and manage are common issues for IoT. Data privacy is also another major issue for IoT. No standards for such yet, since the space is still young.
- Easy-to-install hardware and rely on customers to do have to help install, regardless of how easy to make it. If buying off the shelf products and not getting your hands dirty in the hardware and software, you will not be able to provide the best use case for your customers. Every new deployment is easier with a full stack solution. Integrate at the cloud level with the API. Need to own the full stack don’t depend on a third paid. Own your data.
- 1) Not having a clear and discrete business case or reason for implementing IoT. Without this, a company can’t assess the value of IoT or the methods of implementing it. 2) In the other direction, companies can also look to IoT to solve too many problems at once. If there isn’t clear prioritization of which problems need addressing first, they run into the same issue of not having a defined way to value and measure IoT. 3) All this can lead to wasted effort with no real business benefits, with the final outcome perhaps being no more than an internal report.
- 1) IoT initiatives are incredibly complex and difficult to build, so you run into a lot of failures. When it comes to managing your own IoT initiative, you are constructing a software and hardware ecosystem that is far more complicated than a standard web application. You must first understand the complexities of such a system. Some of these key complexities include Designing, building and testing hardware; Infrastructure setup and costs; Not having the domain expertise; Flexibility/scalability; IoT sensors and networking, and, Privacy and security. 2) To overcome these complexities, companies, and developers must research, plan, and consult domain experts to properly scope an IoT project. Depending on the scale of the project, they should partner with an IoT provider who can help them build their IoT product from prototype to production.
- The most common failure is a lack of planning for the volume of data, which will be created when an application goes into production. High volume applications must be designed from the start to support the ingest, processing, analysis and response of massive amounts of data. If that is not done, then a solution such as our in-memory data grid may be the best option to speed up and scale out an application, which is reaching its performance limits.
Here’s who we spoke to:
- Mike Donovan, V.P. of Product, Aquicore
- Adam Fingerman, CEO, ArcTouch
- Dave Schuman, Mobility Leader, Cloudera
- OJ Ngo, CTO and Co-founder, DH2i
- Nikita Ivanov, Founder and CTO, GridGain Systems
- Suzy Visvanathan, Director of Product Management, MapR
- Uri Sarid, CTO, MuleSoft
- David McCall, President, and Clarke Stevens, Chair, Data Model Tools Task Group and Vice Chair, Data Modeling Work Group, Open Connectivity Foundation
- Zach Supalla, Founder and CEO, Particle
- Stephen Blum, CTO, PubNub
- David Bericat, Global Technical Lead, Industrial IoT and Edge Computing, Red Hat
- Vaughn Shinall, Head of Product Outreach, Temboo
- Ray Wu, CEO, Wynd
Opinions expressed by DZone contributors are their own.
Knowing and Valuing Apache Kafka’s ISR (In-Sync Replicas)
Front-End: Cache Strategies You Should Know
A Deep Dive Into the Differences Between Kafka and Pulsar
Strategies for Reducing Total Cost of Ownership (TCO) For Integration Solutions