In this chapter, we will start our journey of exploring the Internet of Things, or IoT, by introducing a number of topics, such as the purpose of any technology and the purpose of IoT technologies. We will then cover the three common questions (what, why, and how?) asked in relation to any technology, including IoT technology. We will cover what the IoT is, why the IoT matters, the impact of the IoT on different industries and segments, and finally, how IoT technology works. In other words, we will explain the IoT production-grade solution reference architecture and its solution building blocks.
The chapter will also cover some of the IoT solution design patterns commonly used in any IoT solution and will show a case study of a business problem and how IoT technologies can solve that business problem and deliver the desired business benefits and outcomes.
In this chapter, we will cover the following topics:
Technology exists, and will keep evolving, to help achieve desired business outcomes. This is the ultimate fact. Business owners and investors always look for the following business outcomes when they run a company or invest in any business domain:
These are three common, well-known business outcomes every organization or business aims to achieve. There may be more, but this book does not cover economy or business theories.
Based on those aforementioned outcomes, it is clear now that no one will buy technology just to play with it; rather, they will buy technology that can help them achieve their desired business outcomes, or, in other words, they will buy technology that solves their business problems.
If you have been in business for the last few years, I am sure you've heard the term Digital Transformation a lot. Every organization nowadays is talking about its steps and strategies to transform its existing business into a digital-first business, especially after seeing the massive growth and business disruption of many large, digital, hyperscale companies such as Amazon, Facebook, and other tech companies that were born in the digital era, including Uber, Airbnb, and a host of other successful start-ups.
"Digital transformation marks a radical rethinking of how an organization uses technology, people, and processes to fundamentally change business performance", says George Westerman, MIT principal research scientist and the author of Leading Digital: Turning Technology into Business Transformation.
Many IT and tech companies offer business enterprises and organizations a complete, rich portfolio of services, solutions, and technologies that they provide to assess such enterprises in their digital transformation journey toward becoming digital-first.
Since this book is about technology (not people or processes), the question might be, how will technology help such a great digital transformation initiative? Or, in other words, what are the digital transformation technology enablers that each enterprise could use on such an exciting transformation journey? You might even ask why we are talking about business outcomes and digital transformation when this book is all about the IoT.
Regarding the last question, it is a valid one, and we will answer it soon. One thing to mention here is that we have decided to share with you the practical, or what is called applied, IoT experience that we have gained from being in the IoT field for many years. This experience stemmed from designing, delivering, and operating many large-scale and production-grade IoT solutions for many large enterprises around the globe:
Now, back to the question of what are the key technology enablers and solutions for enterprise digital transformation programs? And to answer this, let's look at the technologies and architecture paradigms that are considered key enablers for digital transformation:
Let's explain these key technology enablers in more detail.
Transforming existing enterprise systems and IT workloads into new and modern cloud-native solutions is a key enabler in the digital transformation journey.
There are many different views on the definition of cloud-native, especially when it is compared with other terms and trends such as cloud-readiness and cloud-enabled. We will cover this in more detail later in the book. However, for now, we will stick to the official definition of cloud-native as per the Cloud Native Computing Foundation (CNCF):
Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
The benefits of transforming organization workloads into cloud-native workloads are as follows:
There are many benefits of migrating and moving enterprise IT workloads and systems to the cloud (especially public clouds). We'll mention a few here:
Traditional analytics and business intelligence technologies and tools have long been used in enterprises and organizations of different sizes. However, the amount, velocity, and different varieties of data generated by business IT (information technology) and business OT (operational technology) systems change the way data and business analytic solutions work. Now, we are talking about big data technologies and real-time or near-real-time data analytics solutions versus historical data analytics.
Artificial Intelligence (AI) and Machine Learning (ML) play a vital role in the digital transformation journey as enterprises in different business segments use different AI and ML models and solutions, including predictive maintenance, product recommendations, personalized marketing and promotions, chatbots, drag discovery, fraud detection, radiology image recognition, video analytics, content commissioning, content creation, auto-subtitling, sentiment analysis, self-driving cars, and many other interesting business cases and solutions besides.
Creating a powerful customer digital experience requires the availability and utilization of a rich set of modern applications and architecture paradigms. For example, in modern apps, the de facto architecture paradigms commonly used nowadays are microservice and two-tier architecture versus the traditional three-tier architecture. When it comes to compute, modern solutions and architecture paradigms will include things such as Serverless Event-Driven Compute (for example, AWS Lambda, Azure, and Google Functions), Containers (for example, Docker), and Container Orchestration (for example, Kubernetes).
When it comes to Middleware and Integration, modern solutions and architecture paradigms will include things such as API Gateway, GraphQL, Service Mesh, Pub-Sub Architecture (queues and Service Bus), and Event Streaming (Kafka). When it comes to Databases, it is not just a question of traditional, well-known relational databases or Relational Database Management Systems (RDBMSs); other database types have emerged recently, including NoSQL, object storage, graph databases, and in-memory databases. When it comes to Mobile Apps and Web Apps, modern frameworks such as React Native, Angular, Vue, and many other frameworks and technologies besides will be used to build such amazing modern customer or consumer apps.
IoT is a key technology enabler for digital transformation. In fact, IoT is the most important technology enabler for the digital transformation process as it is also a key enabler for some other key technology enablers, such as big data and advanced analytics, AI, and machine learning. How? Simply put, such technology enablers depend heavily on collected data and insights from the different data sources of a running business. IoT is one such enterprise or business operational data source.
In the next few sections, we will discuss the different aspects of IoT, in other words, we will discuss the what, why, and how of IoT solutions and technologies.
James Phillips, corporate vice president of Microsoft's Business Applications group, said the following;
It all starts with data; data is coming out of everything. If you can harness that data, make intelligence out of it, and use it to improve your business processes, you're in a position to transform your company and industry.
Have you heard about the Observe, Orient, Decide, Act (OODA) cycle that has been developed by a military strategist and United States Air Force Colonel, John Boyd? As the name suggests, it is a decision-making process based on a loop or series of steps or tasks. It all starts by observing or monitoring the target by collecting data from multiple sources, and then doing orientation by filtering, analyzing, and enriching the collected raw data. Next comes deciding, based on the insights collected and what actions need to be taken, and then finally executing such actions and assessing whether the decision taken was right or wrong. Such a loop continues endlessly.
Enterprises get insights from customer interactions, sales, and connected products to improve the quality of their products, find untouched revenue streams, increase customer satisfaction and retention, and improve the whole business process and operations.
As we can see, there is a strong relationship between IoT and data, so let's dive further into that relationship to understand IoT better.
Imagine converting any physical thing around you into a smart connected thing and getting insights from that physical thing remotely. This would be awesome, wouldn't it?
How can I convert a physical thing into a smart thing, you may ask? The answer is by using IoT technologies and different IoT ecosystems, such as sensors/actuators, microcontrollers, connectivity, and IoT platforms.
Still not clear? Let's take an example. Suppose you run a waste disposal company. The trucks of the company currently travel once a week to different residential areas in the city. After a while, and based on some insights and data analytics, you realize that on some days, the trucks return almost empty as there is not much waste to be collected on those days. That is a business problem as you could save money on the fuel used and employee wages for those days, you could help to save the environment by reducing air pollution and toxic emissions, and so on.
To solve that problem, you need the waste bin to somehow talk to you or notify you whether it is full, halfway there, or empty. Interesting. So how can we do that? We could install in each waste bin a small low-power, constrained IoT device (or a microcontroller in short) equipped with an ultrasonic sensor (such as ultrasonic thru-beam sensors) to detect the level of waste inside the waste bin. You could have another sensor to detect how many times the bin lid has been opened. The microcontroller could have a radio communication module for short-range connectivity options such as Wi-Fi Bluetooth Low Energy or Zigbee, or long-range connectivity options such as cellular (mobile) network connectivity to provide internet or network connectivity to the microcontroller to send the sensor insights or data to the IoT Cloud backend.
Once you have the data in the IoT Cloud, then it becomes just another software or data analytics solution to get insights and act accordingly. Similarly, you could simply convert anything into a smart thing.
The concept of converting any physical thing into an internet-connected thing is really disruptive and has a big impact on the current internet infrastructure. Currently, there are billions of devices already connected to the internet, including laptops, mobiles, tablets, PCs, and other smart connected products, but with such a concept, we have to deal with massive growth in the number of devices connected to the internet network. In a single smart home, for example, you could have 100 devices or more connected to the internet.
The options in terms of dealing with such a massive number of internet-connected devices are either to extend the existing internet infrastructure or to have a dedicated IoT.
Definition of IoT as per Gartner
The IoT is a network of physical objects that contain embedded technology to communicate and sense or interact with their internal states or the external environment.
Now that we have an idea of what the IoT is, let's move on to its impact on different industries.
Over the course of history, there have been different industrial revolutions that occurred in different eras. The first industrial revolution that occurred between the years 1760 and 1840 introduced machine power to replace hand power. At that time, this represented a significant achievement that disrupted and changed many industries, including mining, the iron industry, and agriculture.
Then, between the years 1871 and 1914, the second industrial revolution was enabled and powered by one of the greatest inventions and discoveries of humankind – electricity. Electricity fundamentally changed and disrupted different industries at that time.
In the late 20th century, the third industrial revolution was powered and enabled by the great invention of the computer. Computer systems and networking paved the way for the next and most recent industrial revolution, aka Industry 4.0.
The fourth industrial revolution (Industry 4.0) includes many technology enablers, such as IoT, cloud computing, automation, AI, ML, analytics, and cybersecurity, for disrupting a variety of industries and manufacturing processes.
IoT plays a critical role in shaping Industry 4.0 and impacts and disrupts any current industry and business. Let's learn how!
With IoT technologies, different consumer products and services are not only classified as connected products, but they move to the next level of a business model where the following features can be easily introduced and bring great business value:
Many challenges, such as connectivity issues, asset tracking and monitoring, safety, and security emanated from remote locations such as refineries and oil fields. Those challenges are addressed by leveraging IoT technologies such as IoT device management, IoT connectivity, edge computing, ML, and Analytics @EDGE.
Also, on the consumer side of things, IoT helps a lot in saving energy. Think about smart lights that detect a person's movement in a room and switch on only if there are people in the room. They can also detect brightness levels – whether it is daytime or during the night, and act accordingly. Other examples that employ the same idea are air conditioning systems and heaters. These kinds of solutions save lots of energy resources and reduce consumers' bills as well.
In the utilities sector, things such as smart meters are the first requirement for many utility companies.
The IoT fundamentally impacts and disrupts the transportation industry. IoT technologies play a critical role in the following services and features in that industry:
The IoT fundamentally impacts and disrupts this industry. IoT technologies play a critical role in the following services and features of the industry:
Have you heard about the interesting "Amazon Go" stores that have no staff working in them? Consumers just pop into the store and buy whatever they want and when they leave the store, payment is taken automatically? Interesting, isn't it? IoT and other modern technologies are behind those types of smart stores.
In retail, the IoT supports many use cases, such as the following:
The IoT supports many use cases in the sport and leisure center domain, such as the following:
IoT technologies introduce many benefits to the agriculture and farming sector, such as the following:
One of the interesting use cases in that sector was a case of a farmer complaining about an increase in the newborn cattle death rate (this is the business problem) that occurred because the farmer did not know exactly when cattle would give birth. During labor, human intervention may be required to help female cattle should a problem arise.
So, how could IoT solve that business problem? With a very tiny microcontroller equipped with a vibration sensor and a cellular communication module attached to the tail of the pregnant cattle, at a specific vibration rate (this specific rate indicates that the cattle is giving birth), a video call will be triggered with the farmer and the latter can watch the whole process from their home and intervene if needed. Through this solution, the volume of newly born cattle has increased significantly.
IoT technologies introduce many benefits to the supply chain sector, such as the following:
Resource scarcity, or a lack of resources, occurs when demand for a natural resource exceeds supply. Therefore, in a modern economy, there is always a need for new and sustainable financial and service models.
Smart cities are a business initiative to offer a sustainability model and the best quality of life standards with fewer resources.
IoT technologies help a lot in achieving the vision of smart cities and completely disrupt lots of traditional citizen and council services. Here, we'll mention a few:
And so many more features and services.
With IoT technologies, the concept of a true and complete smart home is possible. Many products and services in homes are powered by IoT technologies. Here, we'll mention a few:
And many other features and services besides.
Without any doubt, and as has already been stated, the IoT is everywhere and disrupts many different business sectors.
Important Note
What is interesting here is the fact that the IoT solution paradigm is very simple and very common. In any sector, you will have things or IoT devices equipped with sensors to sense the physical world and with communication modules to provide connectivity to send the collected generated data from those IoT devices to the IoT backend cloud for further analysis.
To conclude this section, the most important thing is understanding business problems, how IoT can solve these issues, and what benefits businesses will get from using IoT technologies. Let's now move on to understand more about IoT solutions and technologies and see how it all works together.
When an architect, designer, or developer starts thinking about solution architecture for a business problem, they usually start thinking about a standard reference model or reference architecture that has been used and tested, with proof of success, by other experts in solving the same business problem they have in hand.
In traditional IT systems, you go with well-known architecture paradigms such as three-tier architecture, Service-Oriented Architecture (SOA), two-tier architecture, and many more modern paradigms, such as microservice-based architecture and serverless architecture. Even at the software code level, there are software design patterns.
IoT solutions are not unlike traditional IT solutions in the sense of the need to have a standard solution reference architecture or solution building blocks for any IoT solutions. However, IoT solutions are different in the following ways:
In Figure 1.2, we have tried to capture, to some extent, the standard or commonly agreed upon IoT reference architecture, or IoT solution building blocks, that can be used to address IoT solutions for different business problems in different business domains:
Let's examine each layer of the IoT solution reference architecture in some detail.
This layer of the solution focuses on the IoT devices and their ecosystems. IoT devices can be classified into two categories:
a) They act as a communication hub/router, that is, helping IoT endpoint device-to-device communication or IoT endpoint device-to-IoT backend cloud communication.
b) Data caching, cleansing, buffering, and aggregation locally at the edge.
c) IoT endpoint devices go through the gateway to get internet access and don't directly connect to the internet, so such devices manage IoT devices' security.
d) They play a role in the edge computing paradigm as sometimes it is used for local data processing and analytics.
e) The IoT gateway plays a critical role in supporting legacy and protocol conversion. Old IoT devices typically run old IoT connectivity protocols. The IoT gateway can convert those old protocols to modern and supported IoT protocols that run in the IoT edge layer or the IoT Cloud.
We will cover this layer in detail later in the book.
The edge or fog computing paradigm, in short, is running data center workloads very close to the end user or devices. You can move a small data center workload or an entire workload to the edge; it all depends on the edge location facility size and the data center's supported capabilities.
Let's look at the three main drivers behind the need for the edge computing paradigm.
We can't beat the speed of light, right? This is physics. In other words, whatever the quality and strength of a fiber optic cable used for data transmission in a packet data network, the transmission of the data will not be done in zero or fewer milliseconds.
Think about an IoT device running in a car park in the Singapore region, with the IoT analytics and applications running in the IoT backend cloud in the USA region. We should expect – and we can't do anything about it – in the region of a 250 ms latency factor added to the overall application request-response latency. So, a request raised from the IoT device in the car park might take roughly 1 or 2 seconds in total (250 ms latency + application processing time + database processing time, and so on) to get a response, assuming the workload running in the IoT Cloud is well designed and implemented and will not add any further unnecessary latency to the response time.
In some applications, getting an answer or response from the IoT backend cloud in 1 or 2 seconds could be fine, but in other real-time or near-real-time applications, that time could be a big problem. Regarding the example we just discussed, imagine there is a fire in the car park and the drivers need to get out or escape as soon as possible. The car park gate is closed and waiting for a response from the IoT backend cloud to open. Getting the response in 1 or 2 seconds in this case (note: we are not discussing here a no-response scenario as that is a completely different case altogether) might be too late to save people's lives.
In network topology, data traffic goes through multiple nodes or hops till it reaches its destination. Besides the light speed latency that we discussed above, you could also have a number of network issues, such as the cable being torn or some congestion in one of the nodes in the network topology. All such factors could even make the situation worse in terms of latency or getting a response quickly from the IoT backend cloud.
Edge computing solves these issues and challenges by running the IoT Cloud workload required (for example, Apps, Analytics, ML, and Control) locally, that is, as close as possible to IoT devices.
Data is important and, in fact, the goal of any IoT solution is to acquire data, gain some insights, and finally, act upon those insights.
IoT devices generate, or can generate, massive amounts of data. You can have data generated in a very small time resolution, for example, one second or less. Domains such as analytics and ML usually require such big data to give proper analytic outputs or excellent ML model accuracy results, but processing and storing such an amount of data comes at a cost.
Edge computing solves that challenge by processing all (or part of) such IoT-generated data at the edge and storing only the relevant and required data needed for further analysis and applications in the IoT backend cloud.
In the edge cloud, you can do data aggregation first before sending the data or batch of data to the IoT backend cloud. You can run advanced near-real-time or streaming analytics on the edge and might be storing just the results of such real-time analytics in the IoT backend cloud for other historical analytics solutions (for example, trends). For example, running analytics on the last 10 or fewer minutes of usage of smart parking could be done easily on the edge with data stored and processed on the edge for such a time resolution, that is, 10 minutes. After that, data could be deleted or aggregated into a higher time resolution (for example, 1 hour or so) and that aggregated data is then sent to the IoT Cloud for historical analytics.
Edge computing solves the preceding issues and challenges by reducing the cost of storing and processing such massive amounts of generated IoT data in the IoT Cloud.
Due to certain regulations or data privacy compliance requirements, you might have to store sensitive data such as personal data generated from IoT devices within the country or region where those IoT devices are deployed and operating. A problem may arise if you have a kind of centralized IoT backend cloud in one or more regions that differs from the highly regulated regions the IoT devices are deployed and operated in.
Edge computing solves that issue by storing and processing such sensitive data locally and might anonymize such data and push it later to the central IoT Cloud in an anonymized or masked form.
We will cover this layer in further detail later in the book.
This layer is very important in any IoT solution as it covers so many solutions and applications. Let's look at these in detail.
Provisioning, in general, means setting up and configuring backend systems with all the required information and configurations the solution's upstream and downstream systems require to operate as expected.
In IoT solutions, IoT device provisioning can be done in many backend systems depending on the final IoT solution architecture, but here are common systems required in IoT device provisioning:
Also, IoT device identity details such as device credentials and/or X.509 certificates can be securely stored and provisioned in that layer.
In the case of cellular connectivity, for example, you must configure or provision a Subscriber Identification Module (SIM) with the mobile network operator, otherwise such connectivity will not work.
This layer is the front-door layer of backend IoT Cloud solutions and services. In other words, this is the first layer that receives data from the IoT endpoint devices or IoT edge and ingests such data into the proper IoT Cloud storage layer. In that layer, you can have the following components:
A complete IoT solution should have a scalable, reliable, resilient, and secure MQTT message broker, or we can call it an MQTT server since the IoT endpoint, IoT edge devices, and IoT applications usually act as MQTT clients.
A complete IoT solution should have – if needed – a scalable, reliable, resilient, and secure streaming processing engine such as Kafka to support IoT data streams.
This component is critical and crucial in any IoT solution. Why? Because this component is the glue between IoT devices on the ground and the IoT backend cloud. In other words, the component is responsible for directing incoming data from the IoT devices to their destination in the IoT backend cloud. There are so many destinations, such as the database (SQL, NoSQL, and so on), message queue/bus, data lake, or object storage such as Amazon S3, Hadoop, and a streaming engine for further processing or real-time analytics use cases.
In this layer of an IoT solution, there are so many different storage options, as we will discuss later in the book, but the most common one used in large-scale and production-grade IoT solutions is object storage solutions such as the famous Amazon S3 object storage service.
The concept of the data lake – usually built on top of object storage solutions such as Amazon S3 – is the recommended IoT design pattern where all data in whatever format coming from IoT devices will be ingested and stored durably and securely in that data lake storage for subsequent processing.
Further down the line of IoT solutions, you could have another process or system read such raw IoT data from the data lake for further processing and storage. For example, you could perform some data cleansing, preparation, and processing, and store the data in another data store such as a SQL database (for reporting) or a NoSQL database (for a real-time dashboard application).
This layer of the IoT solution covers all systems and components used in building a big data and analytics standard pipeline (collect->process->store->analyze->visualize).
It also contains systems and components used in building an ML pipeline (Data Extraction -> Model Training -> Model Evaluation -> Model Deployment).
This layer is so important because, as explained earlier, IoT is all about getting the data for analytics and insights.
We will cover this layer in further detail later in the book.
In this layer of the solution, there are many components. Let's briefly discuss them.
You will write application code and you will need to deploy or run that code, so you will require compute services to host the application code. These are the typical options:
Virtualization technologies have been a game-changer in the computing service domain in recent decades and are still valuable options in terms of modern application deployment.
Container technologies help a lot in achieving the desired benefits of new application architecture paradigms such as microservice architecture. Microservice architecture concepts were not new, but with container technologies, they become brighter and make much more sense.
Container technology introduces a need for a container orchestration platform to manage container deployment on a large scale. Kubernetes is an open source container orchestration engine designed to deploy and manage containerized services on a large scale.
There are other container orchestration platforms available on the market offered as commercial solutions, such as AWS ECS – Elastic Container Services, or open source, such as Apache Mesos or Docker Swarm. However, Kubernetes has proven to be the best and is the market-leading container orchestration platform with huge technical community support.
In the serverless paradigm, the application developer will focus on the code only, be it Java, Python, C#, and so on. Then, when it comes to deploying that code onto a server-side platform, the developer simply uploads the code artifacts to the serverless provider (whether it is a public cloud provider or a private cloud provider). The serverless provider behind the scenes will deploy that code to a server managed by that provider.
Serverless technologies, also called Function as a Service (FaaS), typically run and manage containers at scale behind the scenes to deploy and run the user's uploaded code.
Serverless usually follows an event-driven architecture paradigm. To execute the uploaded code, an event must be triggered to notify the serverless service to execute your code and return its result, or it can be triggered in a scheduled manner.
Examples of serverless offerings are AWS Lambda, Azure Functions, and Google Cloud Functions.
As part of the IoT solution design phase, you have to choose the compute service you require for your solution. You might prefer containers over virtual machines or vice versa, you might choose both for different applications' requirements, or you may prefer serverless for a quick start and to avoid server maintenance, and so on.
In modern applications, no one database engine or type fits all data and applications' purposes. Currently, there are lots of database engines for different uses and purposes, such as the following:
There are many forms of NoSQL databases, including the following:
a. Key-value databases are commonly used in online gaming apps and high-traffic web apps.
b. Document databases are commonly used in content management systems and user profiles.
c. Graph databases are commonly used in social networking, recommendation, and fraud detection apps.
d. In-memory databases are commonly used in caching, session management, and gaming.
e. Time series databases are commonly used in IoT and industrial telemetry apps.
f. Ledger databases are commonly used in supply chain, registration, and banking transactions.
We will discuss these databases in more detail later and shed light on which one to choose during the design phase of an IoT solution. The IoT solution architect or designer should evaluate the different database options for the IoT solution based on the requirements at hand.
This layer of the solution provides integration or middleware systems to connect IoT solution systems and integrate third-party and external systems as well.
There are many integration systems available, as per the following:
You might need one or two features out of all the included or built-in features of a single middleware platform. This makes decision makers think a lot before choosing between such kinds of platforms or the modern option, that is, an API gateway.
It is worth mentioning that companies behind such legacy middleware platforms have taken serious steps to modernize them to fit with new microservice and cloud-native architecture paradigms.
Pub-sub fits very well with microservice-based applications as microservices are usually developed, deployed, and scaled in standalone mode. Each microservice can trigger or broadcast events related to its operations and, based on the events triggered, the other microservices interested in such events can subscribe and listen to those events and act accordingly; for example, an order-created event triggered by a cart microservice. Then, other microservices, such as payment, inventory, and credit checkers that are interested in, and listening to, those kinds of events (that is, order-created events) can then start their functionality on the created order.
Apache Kafka is the most well-known streaming processing engine used on the market.
This layer hosts IoT applications, visualizations, and dashboards. In other words, this layer is the layer responsible for building what the end user will see and interact with, so it is an important layer in the whole IoT solution.
An E2E IoT solution is complex and requires many systems and solutions in order to be delivered. But if you think about IoT end users or consumers who will use the IoT solution in the end, you'll realize that those end users will interact mainly with the IoT applications of the solution in the form of a mobile or web app. Hence, the excellent customer experience that every enterprise or organization looks for will be driven mainly by that IoT application layer's Key Performance Indicators (KPIs).
To give an example, in your E2E IoT solution, you might have some problems in the connectivity layer, so, for the end user in that case, you could offer what is called a digital twin or device shadow to let the end user keep interacting with the IoT solution as normal, as if the IoT device is still connected. And when the device reconnects, it will read the instructions sent while it was offline from the device shadow service and apply what is needed. Or, let's say you have a problem in the device layer; for example, devices are not reachable at all and no telemetry is received from devices in the configured time.
In this instance, the entire IoT solution shouldn't go into stop or failure mode; you could still offer IoT application layer components to the end user, such as mobile and web apps, until you fix the device issue, but in that case, they will be in read-only mode, that is, the dashboards and reporting could still be offered to the end user. Yes, it will show out-of-date data, but that's better than shutting down the whole solution and losing end user engagement. The user might just want to check some historical reports or something.
In this layer, there are so many solutions and systems to be considered in building and delivering IoT solution applications. Let's briefly go through such components.
There are many solutions when it comes to building IoT solution dashboards and visualization. Here, we'll mention a few:
There are commercial and non-commercial IoT platforms that provide such features as ThingWorx (commercial) and ThingsBoard (open source) and many others.
Usually, the two options above, that is, ready-made dashboards or an application built by a low-code platform, are used to quickly start the development cycle of IoT applications without the need for highly-skilled backend or full stack software developers to build the IoT applications from scratch.
Here, the IoT developers will use different frameworks and solutions to build IoT apps, such as the following:
a) Web and mobile frameworks – frontend.
b) Technologies and frameworks such as JavaScript, React, Angular, Vue, React Native, Ionic, Flutter, and so many others.
c) Microservices and backend APIs.
d) eTechnologies and frameworks such as Spring Boot with Spring Cloud, Flask, NodeJS, .NET, and so many other frameworks and technologies that are available on the market to build microservice-based applications.
e) GraphQL (read-only) works side by side with API gateways (read/write). It makes it easy for applications to get the data they need efficiently without chattiness between a client (for example, the browser) and backend server or backend API.
Now that we've discussed IoT applications and visualizations, let's move on to exploring IoT device management applications.
Managing an IoT device in terms of device provisioning, configuring, maintaining, authenticating, and monitoring is one of the mandatory IoT solution requirements. It is rare to find an IoT solution without a device management component in its architecture and ecosystems.
There are two options for IoT device management solutions:
Without connectivity, there's no IoT solution. Connectivity is everywhere in an IoT solution and it acts as a glue between all IoT solution layers. Let's look at this in the next section.
Solution architects and designers should cover different connectivity options required in the IoT solution and how to connect IoT endpoint devices to edge devices and edge devices to the IoT backend cloud, which should cover which wireless (or wired) technology and communication protocols are to be used.
This layer will be detailed later in the book.
Like connectivity, security and access control is a must-have requirement in any IoT solution. Different IoT solution components must incorporate security requirements into their design and delivery from day 1 or day zero. An IoT security breach is massive and dangerous in its impacts. Think about the hacking of connected cars and what could happen if a hacker has full control of a car while you are driving. What about switching off smart city streetlights or switching off electric grids and so on? It is serious, isn't it? We are now talking about systems that affect people's lives directly, not just traditional websites and online services.
Solution architects, designers, and developers should include all the required security and access controls in all IoT solution components. Topics such as authentication, authorization, malware protection, auditing, access control policies, and data protection in transit and at rest should be fully covered in the IoT solution.
Those are the five layers or the solution building blocks of any IoT solution. There are some other additional technological frameworks and tools used across all those layers, but they are mainly part of, or driven by, the delivery process used in the delivery of the IoT solution. For example, if the organization you are working in follows DevOps or DevSecOps practices, then developers and/or DevOps engineers will use things such as the following.
Infrastructure as code means treating the infrastructure of the IoT solution the same way you treat the solution's source code. In other words, the infrastructure code or scripts are maintained in version control the same as the solution's source code, which will give us lots of benefits, such as faster time to production/faster time to market, improved consistency, less configuration drift, and modern app deployment methods. And finally, it improves the automation of the entire solution deployment.
There are many tools used for infrastructure as code. The most famous infrastructure or cloud-agnostic and open source tool is Hashicorp Terraform.
A solution or project's CI/CD pipeline tools usually include the following:
Usually, unit test scripts and integration scripts run as part of the building stage.
In the next section, we will discuss IoT solution design patterns.
In software coding practices, you should have heard about software design patterns, in particular, those patterns introduced by the famous Gang of Four (GOF) book Design Patterns: Elements of Reusable Object-Oriented Software.
The idea of design patterns, in general in any domain, is to provide a solution that has been tested and proven by different experts to solve specific repeated problems or challenges in the subject domain. For example, in the software domain, you will see a list of design patterns that solve some common coding challenges, such as the Factory pattern, the Singleton pattern, and so many other patterns. In the enterprise integration domain, you will see patterns such as Publish-Subscribe, Event-Driven, Content-Based Router and Message Filter. In the cloud, you will see patterns such as Ambassador, Anti-Corruption Layer, Cache-Aside, and Responsibility Segregation (Command Query Responsibility Segregation (CQRS)).
In the IoT domain, we do have some design patterns and design principles that are commonly used in different IoT solutions. Let's look at some of these.
This is the most famous and common pattern used in IoT solutions. IoT devices sense the physical world and send related data to the IoT Cloud for further processing. Data sent from devices is called data telematics or telemetry.
To send the data to the IoT Cloud, you need connectivity and a communication protocol. Different protocols may be employed, including HTTP(S), WebSocket, and MQTT.
Since we are talking about telemetry, MQTT is the best and most common protocol used in sending IoT device telematics to the IoT Cloud or, to be more specific, to the IoT Cloud Message Broker or Edge Device gateway running the MQTT server.
This telemetry pattern helps many companies to build and offer IoT SaaS solutions or ready-made solutions, where enterprises buy ready-made IoT solutions to have their products connected very quickly and start to gain useful insights from them. The idea is simple: connect the device to an IoT platform and start sending telematics and the IoT platform will provide dashboard, monitoring, alerting, reporting, and analytics features out of the box based on the telematics data collected. Microsoft Azure IoT Central is one of those IoT application platforms that offer such ready-made IoT solutions with no great development skills required.
This pattern is also very common in IoT solutions and usually comes side by side with the telemetry pattern. The command or action pattern means applying or running different commands to a remote IoT device – commands such as reboot, reset, switch on, and switch off device actions, and even upgrading the device firmware, is also considered a command pattern.
It is usually best practice to have control and management of the remote IoT device for monitoring, diagnostics, and security.
IoT devices are not like traditional web or proxy server devices where you can open some inbound ports such as 80
or 443
for incoming traffic from the internet or from a private network. Opening such inbound ports for traditional powerful devices could be acceptable, as usually there are firewalls, Distributed Denial-of-Service (DDoS) protections, and Web Application Firewall (WAF) solutions in place to protect such proxy web servers or the whole server farm from such attacks.
In the IoT, it is slightly different. IoT endpoint devices usually, or in most cases, do not run an IP stack, meaning there's no IP assigned to devices. They do not run an IP stack as they are low-power, constrained, and low-value devices. Even in the case of powerful IoT endpoint devices running an IP stack, it is recommended to not open its inbound ports to mitigate security attacks. Security breaches in IoT solutions are more dangerous than a breach in e-commerce applications or any other IT solutions as the impact of an IoT security breach will be severe on systems and humans as well.
So, the most common IoT device communication mode is the outbound communication mode (aka device to cloud), where the device will make an outbound call to the external network instead of receiving inbound calls (aka cloud to device) from external networks.
You might wonder how the command IoT design pattern we mentioned above works then? As explained before, a command means you send instructions to an IoT device to do some actions. Hence, this means inbound traffic from your application/system toward an IoT device. So how come we say IoT device connectivity is usually, or recommended to be, outbound?
This is a very good question and the answer is simple. The IoT device makes an outbound call to ask about any actions or instructions targeted for it that need to be executed. As we will learn through the book, IoT devices might be in a deep sleep mode most of the time and when they wake up, they communicate with the IoT Cloud or the IoT Edge; Hey, I am up now. Any jobs for me? Then, the IoT device will subscribe to a specific topic for such jobs and retrieve instructions and execute them.
Refer to the next pattern as this is related to that point as well.
For sure, connectivity will be dropped or disconnected at some point in time, and you should always consider that fact when designing an IoT solution. IoT devices might be deployed in very far away locations where there is no network coverage at all, where there is weak network coverage, or where intermittent connectivity occurs due to one of many reasons, such as electronic or radio interference from other surrounding devices or even the IoT device being in deep sleep mode to save the battery, meaning it is not connected all the time.
The solution to that intermittent connectivity challenge is to use an intermediate system or buffer to hold and manage the communication between the IoT devices from one end and the IoT application from the other end. In other words, IoT applications should not talk directly to IoT devices and vice versa. Rather, IoT applications should talk to the intermediate system and instruct it on what needs to be done on the IoT devices, and then that intermediate system will talk to the IoT devices if the IoT devices are on – the best-case scenario. Otherwise, if they are off, then that intermediate system will hold the message until the IoT devices come back to life, wake up, or connect again. Then, they will get the message buffered in the intermediate system when they were off and act accordingly.
Each IoT platform implements the above concept of the intermediate system. AWS calls it the Device Shadow service, Microsoft Azure calls it Device Twin, and so on.
When you buy smart consumer devices, there is usually a common step to configure some device settings before the device works, settings such as the device access point or device connectivity, which Wi-Fi the device should use to connect to the internet in the case of Wi-Fi-enabled devices, which Access Point Name (APN) should be used in the case of cellular LTE connectivity, and which Bluetooth peer should be paired with. This process is called device setup, device provisioning, or device bootstrapping.
In industrial IoT (IIoT), provisioning or bootstrapping IoT devices is different and challengeable. In IIoT, we are talking about a massive number of IoT devices, so how can we have a device bootstrap on such a scale?
To give an example, think about a connected product company that produces thousands or even millions of such connected product devices. They sell devices across the globe. Now, you need a way to streamline the bootstrapping process for all of those IoT devices. If you choose cellular connectivity in your connected products, then how will you bootstrap or provision the SIM inside the device in different countries with different mobile network operators? It is a bit tricky and not a straightforward process.
Usually, two topics emerge in the provisioning and bootstrapping process.
As a manufacturer or owner of IoT devices, how can I make sure that only my IoT devices – not any other IoT or non-IoT devices – talk to my IoT Cloud or my customer's IoT Cloud? There's a need to have some sort of attestation or credentials that are stored securely in IoT devices in order to connect to the IoT Cloud. The device will send such credentials to the IoT Cloud during the connectivity handshake, which can then be validated and authenticated by the IoT Cloud.
IoT device credentials could be in the following forms:
There are pros and cons of each option, which we will cover in detail later in the book. But for now, and regarding bootstrapping, the question is how those credentials are stored and used by the IoT device.
To answer that question, a myriad of options are available, including the following:
We will cover these options later in the book.
Where should the IoT device connect to send the data telematics? Will such an endpoint be statically configured in the device or will it be pushed to the device over the air? Is there a global point an IoT device can and must connect to when it connects for the first time, and then that global point will or might direct the IoT device to the endpoint the IoT device should connect to, for example, a specific region or country's IoT hub or IoT message broker?
All those questions should be answered and clarified as part of the device bootstrapping process.
Now that we have covered IoT solution design patterns in detail, it's time to discuss some use cases to broaden our horizons.
Despite this book being generically about designing and building an IoT solution, we will look at a case study to be used in the book's chapters where applicable.
A smart city initiative is not one IoT project; it is, in fact, so many different IoT projects and it usually has the following cases or modules to be covered:
In this book, we've chosen the smart parking module of the smart city initiative to be used as a reference or case study:
In the upcoming sections, we will go through the requirements or the business problems at hand and the design thought process of an IoT solution to address those business requirements and deliver the desired business benefits.
Usually, in large, bustling cities around the world, finding a parking space (aka slot) is challenging and not an easy task at all. People sometimes avoid outings on account of parking issues. Governments and city council administrations usually look for solutions to address parking availability challenges. There are so many factors behind parking space issues, such as ineffective land planning, insufficient parking spaces, traffic congestion, toxic emissions, and others.
Putting ineffective land planning issues aside, as we can't help with that issue, the congested traffic and toxic emissions issues occur essentially because car drivers lack a real-time parking lot availability solution to enable them to efficiently and quickly find available parking lots in the city.
City administrators started looking into smart parking solution initiatives to gain the following business benefits and solve parking space issues:
As stated earlier, understanding business problems and pain points in full is an important step toward solving such business problems. Sometimes the solution might be a non-technical solution and might not depend on technology at all. The solution might be just enhancing existing business processes or people skills.
In that phase of the project, that is, business requirement clarification, you, as a business or system analyst or solution architect, should put any questions you have to the business stakeholders as answering such questions will have an impact on the solution selected at the end. For example, Is the parking space indoors or outdoors? You might ask, will this matter? And the answer is yes, it will matter, as, based on the answer, you will define which devices, sensors, and connectivity options could be used. For example, if it is indoor parking, then you could have a source of electrical power available in the parking lot or nearby so you might not worry much about low-power, very constrained IoT devices and so on. As regards the sensors, you might not worry much about the external environmental and non-environmental impact on the functionality of the sensors, such as dust and lighting levels. For connectivity, you might choose Wi-Fi and fixed broadband instead of cellular (mobile) connectivity and so on.
The business and system requirement identification process is not an easy task; it would need a book to explain that topic at length. However, here are the general steps used in that process:
Let's dive a bit deeper here and discuss the role of various stakeholders in a smart parking solution.
These individuals will need to manage and monitor the smart parking solution, meaning they might require the following:
Usually, councils do not run smart parking solutions themselves; rather, they make data such as parking space details and other data they can expose through a rich set of APIs available to third-party companies and partners to operate and manage the smart parking solutions.
The operators usually cover the following tasks:
a. Search for available parking lots nearby
b. Book, reserve, and pay for an available parking lot
c. Parking lot management, that is, updates, changes, cancelations, and so on
These are the end users and the target users at the end of the new business model or smart parking solution. Drivers will be provided with the features mentioned above by smart parking operators.
Now let's think about how the smart parking operator will address the requirements we just discussed and come up with a solution.
In networking, network engineers usually do a survey where network nodes such as switches and routers will be placed on the site, which kind of cables will be used, and which kind of network topology will be used (that is, star, mesh, ring).
Cables going through specific routes and even walls is not a haphazard task; there are engineering practices and explanations behind all of that setup.
IoT solutions are no different from traditional networking solutions. In fact, the IoT is sometimes classified as a networking engineering topic. It is called the internet of things, so connectivity and networking are a core part of it.
With any IoT solution, there is a physical world that it needs to sense and then act upon that sensing, which means in an IoT solution, there is always a field or playground where you need to deploy and install IoT devices and sensors.
Step number 1 in any IoT solution is to study very well the field or the ground where the IoT devices will be deployed. In our case, the parking space that we need to study is a field.
We need to know the following about the city's parking spaces:
Given the above IoT solution field planning, the next steps will involve choosing the IoT devices and sensors needed to detect the occupancy status of the parking lot.
There are so many ways in which to detect the occupancy status of a parking lot. Here, we'll mention a few:
Previously, you'd have had to build such services from scratch, using technologies such as image processing and similar, but now, with AI and ML's maturity, hyperscale companies such as Amazon, Microsoft, and Google provide so many ready-to-use cognitive services, such as object detection, image classification, or activity detection (video), that you don't need to build an ML model yourself; it is already done for you. You might only need to feed the model with your data, that is, parking lot images or videos to show when they are occupied and when they are empty. I said might, as detecting a parking lot's occupancy status is becoming a standard, popular use case in that domain, so you might even find a third-party company that offers APIs ready to detect that. You would just need to pass to those APIs images of the parking lot you want to check the occupancy status of and you would get the answer: Occupied or Empty.
You might, as part of smart parking business requirements, need to run some smart parking workloads at the edge, like the example we mentioned before about calculating the number of incoming vehicles versus the outgoing vehicles, or some real-time or near-real-time analytic requirements, and so on.
You must think carefully about such requirements. You need to think about the locations of where you will put the edge computing nodes. Edge units could be as simple as a small Raspberry Pi device or as medium complexity as a small-scale data center, or even as complex as a complete data center hosted at the edge.
In the case of off-street or private parking spaces, edge units could be placed in the parking spaces or nearby, while in the case of on-street parking, it would be a bit challenging to know where you should put the edge units. There are many options for that case, such as renting a nearby facility such as a building or even a room(s) in a shared building. You need, though, to think about the connectivity between the IoT endpoint devices on the field and such edge units, or you could buy managed edge services or hosting facilities from telecommunication companies or public cloud providers who have massive infrastructure footprints to host your units.
We have mentioned telecommunications companies as they have really massive footprint infrastructure coverage for a district or even – with 5G technology – street levels. That is because of their need to host telecommunication radio equipment. Public cloud providers also have edge locations but, for historical reasons, they don't have the level of coverage of telecommunication companies.
Given the preceding IoT solution field planning and based on the parking space type and details, you can, as a solution architect, define what kind of connectivity is required in the solution.
First, you need to ask yourself, I need to connect what to what? You basically need to connect the endpoint IoT devices to the internet or to the backend servers of the smart parking operators or council. Those backend servers are hosted in what is called the IoT Cloud or IoT backend cloud.
There are two options available:
With the first option, that is, directly connecting endpoint IoT devices to the IoT Cloud, you will need the IoT endpoint device to do the following:
Those two conditions make such a connectivity option, that is, connecting to the IoT Cloud directly, not the preferred option due to the following:
The second connectivity option – that is, through the gateway – looks good as you could deploy low-value, low-power, and constrained endpoint IoT devices in the parking spaces. Those devices could communicate between each other and gateway devices using low-power local wireless networking such as Zigbee or Bluetooth Low Energy. Such connectivity technology will help in saving device batteries and it is cheap. The gateway will connect to the internet, meaning the gateway device could use a fixed broadband (wired option) if available or use cellular connectivity (wireless option). The gateway device or edge could or should be a powerful device in terms of computing resources.
We could use the following communication protocols:
From the requirements, we will need to build (or buy) the following backend components for the smart parking solution:
The features or functionality of the smart parking solution might be negotiated with business stakeholders. Usually, the most common statements you will hear at that stage are we can't boil the whole ocean, which feature is a must and which feature is nice to have?, and so on. There are lots of features requested by business stakeholders, but not all such features could be delivered in one release of the IoT project for a myriad of reasons, such as a lack of resources, the pressure of the delivery timeline, or even some features just being fancy features that the solution can work without.
But, when it comes to non-functional requirements, usually there's no negation with the assumption that the business stakeholders agreed with the increasing costs associated with achieving those non-functional requirements. Every business wants its solutions to be highly available (up and running 24x7), highly performant, highly scalable, highly reliable, and highly secure.
As a solution architect, you should consider non-functional requirements from the design stage and provide all the design principles, technical components, and controls required to fulfill such requirements. Also, those design principles should be applied from the device to the cloud, in each layer of the IoT solution.
This section of this chapter is mainly to draw your attention to the philosophy or strategy that we will follow and use throughout this book:
For example, when we discuss the IoT cellular connectivity option, we will not delve deep into how it works in terms of radio access networks, telecommunication core networks, and so on. We will instead explain the concepts to some degree so that you understand at a high level how such types of connectivity work and how you can use them as part of your IoT solution blueprint.
In this chapter, we have learned what the IoT is, why we need the IoT, and what IoT solution architecture looks like at a high level. We covered different IoT solution architecture layers, starting with the IoT devices layer, which hosts IoT endpoint devices, sensors, actuators, microcontrollers, and so on. We also discussed the IoT Edge layer, which hosts IoT Edge computing and platforms, and then the IoT backend cloud, which hosts all IoT applications, platforms, and solutions. We explored the IoT connectivity layer, which is responsible for IoT connectivity across the whole IoT solution, and finally, the IoT security and access management layer, which is responsible for the security controls and access management of the whole IoT solution. We also covered different IoT solution design patterns, including Telemetry, Command, Bootstrapping, Device Twin/Shadow, and IoT device outbound connectivity. At the end of the chapter, we talked about a smart parking case study, which we will use throughout the book's chapters when needed.
In the next chapter, we will start with the anatomy of the word IoT. We will start with the letter I in IoT, which refers to the internet or, in other words, IoT connectivity.
Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.
If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.
Please Note: Packt eBooks are non-returnable and non-refundable.
Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:
If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:
Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.
You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.
Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.
When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.
For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.