Intro to the Internet of Things

According to a 2014 Forbes article (actually, the autoplay video on the article), 87% of people had never heard the term “the Internet of things.” That has changed rapidly in the last two years (research firm 451 Research pegs 2016 as the year that the Internet of Things goes mainstream). Still, as with many cloud computing concepts, IoT is a vague term.

A Simple Description of the Internet of Things

Consumer-centric devices have emerged over the last forty years, from ATMs to inventory tracking in vending machines. Smart phones were a massive jolt, introducing a new means to connect to and interact with both consumers and physical objects. That networked, digitized environment of physical objects is the Internet of Things. 451 Research had a fantastic term for it: the Internet of things “virtualizes the physical world.”

That is a slightly consumer-centric perspective, though, looking at how one interacts with that IoT environment. The Internet of Things means something a little different from a business perspective, where a company actually defines that IoT environment.

In this sense, there are kind of two realms. There is the centralized, internal data systems environment. This is a more traditional IT environment, like data center servers or cloud instances, running enterprise-wide systems like data processing, enterprise applications, and analytics. Then there is the outer realm, the variegated sets of devices that interacts directly with users and customers -- sensors, actuators, applications.

In this perspective, IoT is not a technology -- it is a series of use cases (noted by James Kirkland, the chief IoT architect here at Red Hat). It is the way your company uses its connected devices and (big point here) the data they collect.

A Three Tier Architecture

Red Hat defines a three-tier architecture for IoT: a data center / cloud level, a gateway (control) level, and a device level.

These tiers map neatly to those internal / external realm of IoT.

That external realm has a two tiers:

• Device tier. This is the outer tier, the devices at the edge of your infrastructure. From the perspective of consumers, these are any devices, like self-service kiosks. From the infrastructure perspective, these are data points. These are a new data stream that can deliver very detailed, real-time information.
• Gateway tier. This is also called a control tier, because it provides a closer access point for devices to be able to interact with the business intelligence in the centralized core services, only outside of the IT environment, closer to the edge. This communicates with devices, both receiving their data and sending forward business logic, event processing, and other automated responses to make the device tier more reactive.

The inner realm has single level:

• Data center (or cloud) tier. These are the core data services within the organization, and is more within a traditional IT environment. These include databases and storage servers, business rules engines, and real-time and historic analytics.

Technically, dual gateway and data center / cloud tiers are not required. Devices can communicate directly with services in a data center. However, that runs into potential issues with scalability, security, and resilience, not to mention basic performance. Pushing more data processing logic closer to the devices can help that device tier be more responsive to customer or system issues, which improves overall customer satisfaction.

Middleware within an IoT Environment

There are two key phrases that jump out to me when describing the three-tier model: data and communication. IoT is based on bidirectional communication, and in this sense it is very similar to social media. It’s not just pushing information at users; it’s about consuming and responding to information from your users.

IDC’s FurtureScape report on the Internet of Things noted that the Internet of Things, from an architectural or planning perspective, should be considered “beyond just the end-user interface, but in terms of the data and information that your IoT project wants to collect and act on.” (Emphasis added.)

Recognizing what data are valuable is key to an effective IoT design. This is a middleware blog, so my primary concern is not the entire IoT infrastructure -- it is the role of middleware in developing and sustaining that infrastructure. For middleware, that comes down to the data center / cloud and gateway tiers, specifically in how they process and respond to data.

The two key functions of IoT are data and communication, plus James Kirkland’s observation that this is less about technology and more about workflow. At a really high level, you can break down IoT design into three steps:

• Identify what types of data you can receive and, of that, what data you want.
• Identify data formats for more effective storage and aggregation.
• Define workflows and develop business logic or actions that can be taken in response to common scenarios.

IoT introduces a potentially overwhelming stream of data (both figuratively in the amount of information and literally in the IT resources required to process it). Once you identify what data you need and what you want to do with it, middleware provides the services that support that business plan:

• Communications (messaging and transaction management) for every tier
• Data integration and virtualization, across many different data formats and protocols
• Automated business processes

Learn More

IoT isn’t a single application or even a stack. It is a way of using data from new sources, physical devices. And you can decide on how and what you need to do within your environment to do that effectively. Red Hat has some interesting whitepapers on different approaches to IoT:

• BPM and IoT: Transformation to the physical world
• Making the Case for Converging Enterprise Mobility and IoT Initiatives
• Simplify IoT implementation with Eurotech and Red Hat
• Mobile and IoT track at Red Hat Summit 2016