3 Things the Network Must Provide for IoT

The Internet of Things (IoT) continues to be a topic of interest. And while consumer oriented gadgets and gizmos tend to make headlines, it’s the behind the scenes, in the data center prep work being conducted by early adopters that remain more fascinating for me.

Probably because there’s a lot of work to be done to support a large-scale IoT effort. And there’s really no such thing as a small-scale IoT roll out when the “thing” is targeting consumers. Because in case you haven’t noticed, there are a lot of consumers out there. And they dig the shinies.

With that in mind, there’s a lot more happening right now across the technology industry to support those who are integrating IoT with existing offerings (cars, appliances, toys) as well as those who hope to be the next big thing with brand new things you didn’t know you needed until you got one.

Really. While government dominates the industries purchasing for IoT (according to our State of Application Delivery 2016) telecom, technology, and cloud service providers aren’t far behind. Every industry, in fact, had a pretty good purchase rate for the previous twelve months, indicating there’s a lot more work going on with IoT than is obvious if you’re only watching the consumer space. 

Much of what’s going on is in the infrastructure; in the network that’s providing connectivity and immediacy of response by the applications in the back-end that manage, meter, monitor, secure, and interact with those cute little chips embedded in your kid’s favorite teddy bear.

Like any app or client (because that’s really what these remote things are, clients) there are a basic set of services they need to operate consistently, predictably, and reliably. Namely, they need services that enable security, delivery, and visibility.

Security

Security tends to be the last thing we focus on with new technology so I’m going to start with it, because it’s security breaches that tend to get the most attention these days for even a fledgling technology like IoT.

Things need to communicate with back-end apps. Whether it’s to save data, retrieve updates or patches, or change configurations, things must communicate – securely – with back-end apps. That means secure tunnel support, via SSL or TLS. It means using secure HTTP, not plain-text, and it further means not hardcoding keys into your things. I’m serious about this one. Don’t do it.  

Security also means identity validation. Yes, I know this thing is a car, but *whose* car is it? We need services that can quickly and accurately identify things and associate them with their authorized users and owners to mitigate the possibility that my neighbor might decide my radio should be tuned in to something other than a heavy metal station. The horror!

Finally, security also means protocol analysis. That’s important especially given the new protocols being considered for standardization across the IoT universe. Protocol insecurities can be a significant risk (you may remember Heartbleed) and tend to be difficult to address in a timely manner. The ability to detect potential abuse of protocols can redress risk up front.

Delivery

Data, transactional and otherwise, needs to be delivered to things and to back-end apps. Doing so isn’t always just a matter of shoving a bunch of JSON-encoded bits to a REST API somewhere. Many things speak the new languages of IoT: MQTT, CoAP, and AQMP. But their respective back-end apps? They  speak REST because they’re also providing web and mobile app access to the same capabilities and information. Which ultimately means that somewhere in the delivery path lies a gateway; a translator; an intermediary providing for protocol interoperability.

That enables the thing in your car to send data or messages via MQTT that can be understood by the back-end app that speaks REST. The intermediary intercepts and translates (securely) to provide seamless conversations between your thing and its apps. Think of the intermediary like C3PO, and your car (or other thing) is R2D2. This means native protocol support as well as a software-defined approach that provides a scripting platform through which support for other protocols can be quickly developed. Data path scripting is one of the three key components of network programmability, but it’s the least mentioned. When it comes to IoT and supporting what will likely be a wide variety of protocols and languages, the flexibility offered by this often unsung capability will be invaluable.

I mentioned scale as a consideration earlier, and it’s here in delivery where we see that requirement supported. To scale support for a million things, for example, you’re going to probably use a decomposition-based app architecture. Maybe not full-blown microservices, but you’re likely to separate out functional domains, at least, to enable scale of different functions with a more efficient (and cost effective) methodology.

That’s where something like message-based load balancing comes in. You might recall this concept mentioned in the service provider space in conjunction with protocols like Diameter and SIP, where efficacy and cost-effectiveness of scale is imperative.

Message-based load balancing is important because protocols like MQTT are based on messages. They’re a pub-sub (publish – subscribe) model not unlike the message-based middleware one might have heard of existing deep inside the enterprise. Anyway, they’re based on messages, and those messages need to be parsed out and sent to the appropriate service or device. To do that and scale means the load balancing service must be able to parse out the message and determine where to send it, then select an appropriate resource to handle it.

That’s not nearly as easy as sounds, as basic load balancers have limited application parsing capabilities.  But it’s going to be a requirement to support scaling the protocols IoT devices prefer.

Visibility

Finally, the infrastructure has to support visibility. That means the ability to see what’s going on. It’s the visibility into secure transactions (SSL inspection) that enables security to take action and identify bad actors. It’s the visibility into usage patterns that can drive auto-scaling of the appropriate services.

Visibility isn’t just about “big data” providing robust operational analytics but reporting and logging as well. Troubleshooting is going to get really hairy in these complex architectures and logging is going to be critical for tools and people alike to track down the problem. 

Scaling and supporting the IoT isn’t just about the gadgets. There’s a lot of work to be done in the network, in the infrastructure, and in the operational frameworks needed to support it. The good news is that if you’re one of those folks working on the (very important) back-end architectures that will be the support for some cool gadget, you can always make the case that you need one (or three) for testing.