The Evolution of the Internet of Things

The Internet of Things (IoT) consists of sensors, devices, and/or actuators that are networked in order to gather data for processing and trigger actions or alerts enabling appropriate responses to be made. IoT architecture solutions are frequently deployed to enable intelligent and automated equipment that is deployed in homes, businesses, factories, vehicles, and outdoor locations. The products and solutions are designed to help solve industry specific problems and needs.

Intelligent devices at the edge of the architecture can both transmit and respond to data, sometimes by controlling other components or equipment present. Networking of the devices enables data sharing among them and transmission of data to a data center through a gateway for further processing and analysis. Today’s IoT footprint can respond in real time and perform analysis on massive numbers of incoming events. This footprint represents the latest stage in the evolution of the key components in IoT.

The first device that many define as a sensor was the thermostat, invented in 1883. Motion sensors and infrared sensors first began to appear in the 1940s and the early 1950s. In the 1960s, sensors and associated computing devices were greatly reduced in size to meet the demands of the space program and were key in the development of spacecraft capable of landing men on the moon.

Networking software began to appear during this same time period to be used in linking computers and devices. The ARPANET was introduced in 1969 to transmit messages from computers and devices across wide distances, and it eventually evolved into the Internet. Early adopters of these networks included the oil and gas companies that needed to transmit exploration data gathered from sensors in drilling equipment to powerful backend computers used in performing analytics on the data.

RFID tags and UPC codes began to appear in the early 1970s, and widespread usage occurred in the following decade. By the late 1990s, RFID tags were linked to the Internet at MIT. Kevin Ashton referred to this work in a 1999 speech at Procter & Gamble as the “Internet of Things.”

This was an era in which relational databases were commonly used to store and analyze all data. Data historians built upon relational database management systems became popular for analyzing time series data coming from sensors, programmable logic controllers (PLCs), and other similar devices.

In the early 2000s, new alternatives to relational databases began to gain wider adoption. Companies that built Internet search engines found that the data they needed for analysis arrived in streams and contained delimiters and other miscellaneous data intermixed with the data of value. The data streams required pre-processing to fit into relational databases since relational databases store data in tables neatly formatted into rows and columns. This data conversion introduced latency and complexity that soon became unacceptable to the search engine companies.

New database management systems were introduced to handle such semi-structured data streams. Often referred to as NoSQL databases, Hadoop clusters became especially popular initially for rapidly loading and analyzing large amounts of semi-structured data. Since data coming from many of the devices at the edge also was generated in a semi-structured form, IoT architectures began to include these new data management engines in the backend infrastructure. A “Lambda architecture,” described in a subsequent section of this chapter, became popular in IoT deployment for handling streaming data and traditional batch data feeds.

Sensors continued to evolve, becoming smaller and cheaper, requiring less energy, and providing more functionality. The number of sensors and intelligent devices deployed experienced explosive growth throughout the 2010s.

New IoT use cases and growing data volumes drove a need to apply analytics and machine learning in real time at the location where the data was being gathered. Microsoft was among the first to refer to the devices containing sensors and featuring local compute capabilities as the intelligent edge.

Figure 1-1 illustrates the timeline of IoT evolution that we just described.

Before we look at how these technologies come together to form modern IoT architecture patterns, let’s look at some of the IoT business solutions that leverage these patterns.

Typical IoT-Based Business Solutions

IoT architectures are used to solve a variety of business problems. The types of problems solved are often industry-dependent. Just as form follows function in classic architecture, one should first understand the kinds of problems that IoT solutions can solve and relevant business problems present in your company or organization before pursuing an IoT project.

In this section, we provide examples in agribusiness, automotive, aviation, communications and media transmission, construction, consumer packaged goods, education and research, environmental controls, financial banking and trading, healthcare payers and providers, high-tech and industrial manufacturing, insurance, law enforcement and emergency services, media content and entertainment, oil and gas, pharmaceutical and medical devices, retail, transportation and logistics, and utility companies. As you can see from this list, IoT-based solutions can be applicable to almost every industry.

We suspect that if you work in one of these industries, you might immediately want to jump to that subsection in this chapter. However, many companies that grow adept at building IoT solutions begin to look beyond their industry for expanded business opportunities. So, you might find value in understanding what is top of mind in industries outside of where you work today.

IoT Reference Architectures

A variety of IoT reference architectures are widely promoted by standards organizations, the open-source community, and vendors that provide components and platforms. While we’ll focus on the Microsoft Azure architecture in this book, gaining an understanding of other reference architectures is useful, especially when we use them to assess functional capabilities that are required in any IoT architecture.

The way in which these domains and IoT devices operate together in an implementation is illustrated in Figure 1-2.

There are many other reference architectures from other standards bodies and consortiums, such as the Open Software Foundation, that you might find are worth further investigation. Of course, these architectures continue to evolve as the capabilities in IoT solutions grow. But next, we start to look at how you might incorporate these concepts in your existing IT architecture.

How IoT Fits in Your IT Architecture

If you are new to IoT but have worked with IT architecture for years, you are likely familiar with traditional batch-oriented infrastructure patterns. Data in online transaction processing systems service business areas such as financial operations, supply chain and distribution, human resources, and customer relationship management. Such systems can also include unique solutions required in the industry that the company operates within. The data is structured and fits neatly into rows and columns; hence, it is stored and accessed in relational databases.

For analysis of data that crosses lines of business and requires history dating back months or years, data warehouses and/or data marts provide a place to access such data within relational databases using business intelligence tools or directly using SQL. These data warehouses and data marts are populated with data using batch extraction, transformation, and loading processes (ETL) in systems between the sources and targeted systems. They are sometimes populated using batch extraction, loading, and then transformation processes executed within the targeted data warehouses and marts (ELT). Figure 1-3 represents this architecture.

These requirements are very different from the requirements that drove the creation of data warehouses that are deployed using relational databases. The new architecture that emerged is often described as a Lambda architecture and consists of both real-time data feeds (a speed layer) and batch data feeds. Figure 1-4 illustrates a conceptual view of the processing and data management systems present in the architecture.

Figure 1-5 illustrates in more detail the components that are typical in an IoT Lambda architecture. There can be many variations in the components and patterns present. The existence of legacy components, such as the presence of historians or limited networking options, can be a factor in the components that are included in this architecture. Certain functionality requirements and skills of frontline workers, developers, data scientists, and IT also influence the components selected in deployment strategies.

In Figure 1-5, we show a bidirectional exchange of data between the data lake and the data warehouse. This is typical where data from one of the data management systems is needed in the other for query and reporting or machine learning training. In Chapter 2, we’ll describe Microsoft’s products that align to this architecture footprint.

All the new backend components are typically deployed as cloud-based services. Components you are likely to find deployed in the cloud include the IoT Hub/Event Hub, streaming analytics engine, in-memory data preparation and training solution, and the data lake. Other traditional backend components, such as the data warehouses and data marts, are sometimes relocated to the cloud, especially when replacements for a previous generation of components are sought. Dashboard and reporting business intelligence tools are also frequently cloud based.

Why Cloud Computing and IoT

When cloud computing was first introduced, the primary justification to move infrastructure to the cloud often cited was reduced cost in comparison to on-premises deployment. The cost of storage of large amounts of data is very low in most cloud-based solutions, and processing is charged for only when applications and tools utilize processing resources. However, many organizations now mention other primary motivators in moving away from considering an on-premises backend IoT infrastructure deployment.

For organizations deploying IoT in order to innovate and provide business solutions like those that we previously described, shortening the time to solution implementation can be of critical importance. On-premises deployment involves acquisition of servers and storage, software components, and networking resources. Once acquired, these resources must be installed, configured, and tested. IT must also be properly trained to manage, support, and optimize these resources. After meeting these prerequisites, development of the solutions can begin on the eventual production platforms.

In most organizations, getting the needed components in place to begin development can take 6 months or more. Utilizing cloud-based resources eliminates much of this preparation work as the new backend components can be easily spun up in minutes.

In IaaS deployment scenarios, the cloud vendor is responsible for the data center environment, networking, servers and storage, and virtualization. You remain responsible for updating and managing software and managing data in the data center above the virtualization layer. Multi-vendor software components are typically deployed, and integration among software components must be carefully considered.

In PaaS deployment, the cloud provider additionally takes on updating and management of data center operating systems, middleware, and data management platforms. Much of the focus of Microsoft’s IoT reference architectures is on PaaS components, as you will see in Chapter 2.

SaaS solutions are typically sold by cloud provider partners who built their offerings upon the cloud vendor’s IoT reference architectures. Examples of such offerings today come from producers of vehicles, controls, manufacturing equipment, manufactured products, and healthcare monitors. Many these products are bundled with appropriate embedded software for operating and managing the vehicle or device. Increasingly, the companies that produce these products also offer maintenance services that rely on data gathered from the equipment.

In addition to these cloud-based deployment models, there are emerging solutions that combine PaaS-style deployment with some aspects of SaaS. Microsoft refers to its offerings that cross these boundaries as solution accelerators. The accelerators spin up needed PaaS components and can provide a starting point for deploying solutions that monitor devices, create a connected factory, perform predictive maintenance on equipment, or test IoT solutions on simulated devices.

Cloud-based platforms have other benefits as well. Deploying to the cloud enables flexibility in deployment by offering a variety of reliability and availability options. Backend platforms are secured in ways not easily replicated in an on-premises deployment. And, you can rapidly scale the platforms when needed.

The cloud is also ideal for testing new IoT-based business solutions that might not prove to be justifiable. Cloud resources can easily be shut down if the project doesn’t move forward without a penalty of having made a huge investment in infrastructure prior to the testing.

Other IoT Concepts and Considerations

IoT devices are of varying sophistication and capabilities. Low-power sensors might simply capture and transmit data. Powerful edge devices often contain processing units, memory, and storage and feature the ability to host an operating system and applications. The more sophisticated edge devices can process analytic and machine learning workloads that can drive immediate responses when changing conditions are detected at the source.

When specifying the remote IoT devices that you will be deploying and managing, understanding the networking options available is an important consideration. The IoT devices might communicate directly device to cloud (D2C) and receive feedback and updates from the cloud to device (C2D). More commonly, several devices in a location will transmit to an IoT gateway in a hub-and-spoke fashion as mentioned earlier in this chapter. In some scenarios where IoT devices are widely dispersed, a mesh framework is deployed as some of the devices also store and forward messages from outlying devices. A mesh containing intelligent edge devices capable of performing analytics at the device is sometimes described as a fog computing environment.

IoT devices in a hub-and-spoke or mesh deployment are most often connected using a physical connection such as Ethernet, Bluetooth, or Wi-Fi. Low-cost LP WAN technologies for devices with limited capabilities and battery life provide an alternative in some situations.

As this book was being published, there was much anticipation about the impact of 5G networking. Early Wi-Fi deployment of IoT devices utilized 3G or 4G networks. The 5G networks promise greater speed, capacity, and reliability, enabling more sophisticated exchanges between IoT devices, including intelligent edge devices, as well as communications to cloud-based services.

Communications to cloud-based services historically leveraged the Internet. However, as concern grew regarding the security of the IoT infrastructure, many organizations have chosen to connect devices to the cloud through private networks.

The devices that you choose should support a common protocol so that they can communicate with each other, and that protocol should also be supported in the cloud-based infrastructure of your cloud vendor. Though this might seem to be a trivial point, coordination between IT and the purchasers of the devices is vital to assuring success. In scenarios where this coordination is lacking, the resulting infrastructure can become needlessly more complex or early device investments could be abandoned.

ISA 99 further defines relevant security assurance levels (SALs) designed to measure adherence to security goals. Target SALs are the security-level goals that are to be achieved by the IoT architecture. Design SALs are planned security levels in components and across the proposed architecture. Achieved SALs are actual measured levels of security achieved in deployment. Capability SALs are levels that can be achieved through configuration of security options in components.

As we explore the various Microsoft components that might be deployed in an IoT architecture solution, we’ll also take a closer look at meeting these criteria through capabilities available in Azure and at the edge.

A concept you might encounter as you devise IoT-based architectures that deliver needed business processes and solutions is the notion of a “digital twin.” Organizations often build prototypes of the architecture we’ve described earlier in this chapter and virtually simulate the sort of data that will be gathered from sensors and devices to illustrate what solutions will deliver. Such simulations can be useful in determining which IoT devices should be deployed, or where additional sensors need to be added to devices already in place.

An Evolution in Needed Skills

By now, you likely realize that the skills that are required to successfully create and deploy an IoT-based solution, especially one that you heavily customize, are quite diverse. Possessing an understanding of the business solutions that IoT can enable and the business requirements that align to a need for IoT-based solutions in your company is required.

Defining, designing, and implementing IoT-based solutions often follows a “design thinking” paradigm. We discuss design thinking as an approach in Chapter 8. The paradigm is a rapid cycle of research, problem definition, ideation, prototype building, and testing in an iterative fashion. Such an incremental approach is aligned with popular methodologies used in the cloud-based deployment of solutions and consistent with a modern DevOps approach. Possessing skills related to this approach and cloud-based deployment and management are also needed.

In this chapter, we outlined what these solutions might look like in a generic IoT architecture and some additional considerations. In subsequent chapters, we’ll explore the key Microsoft components that can play a part in an IoT architecture and some of the possible architecture variations in more detail.