From Layers to Components: IoT Architecture Explained

Feeling overwhelmed by the architecture of IoT? Sensors, actuators, communication protocols — it can feel like a Herculean task, especially for newbies. You might be wondering, “Where do I even start?”

That’s what WebbyLab is here for. We’ll share a guide to the Internet of Things (IoT) architecture, backed by our 5-year expertise. If you’re tired of scrolling through endless guides without finding clear answers, consider this article your ultimate handbook.

Before designing an IoT product, it’s critical to understand how devices will interact with it. It’s necessary to decide on the communication protocols the platform should provide or include the possibility of expanding communication protocols within the IoT architecture.

Kostiantyn Oliynyk, Head of IoT at WebbyLab

As experts in various IoT niches like HVAC systems, consumer electronics, access control solutions, and smart homes, we’ve tackled different types of IoT architecture. We’ve successfully implemented them in projects like the Propuskator ACS and 2Smart Standalone automation platform, along with many others.

The industries WebbyLab works with

Drawing on our profound experience as an IoT development company, we’ll break down the IoT architecture, covering:

• The four main layers of an architecture of IoT products;
• The essential components of an IoT platform;
• Practical examples of IoT architecture implementation;
• Key strategies to ensure security and scalability.

The 2Smart Standalone automation platform developed by WebbyLab

Decoding IoT Architecture Layers

The four stages of the IoT architecture

While all IoT solutions are unique, their architecture can typically be broken down into four fundamental layers. Let’s explore each in greater detail.

Sensing and Perception Layer

This layer is the foundation of an IoT system. It’s where physical environment data is captured.

The perception layer comprises sensors responsible for measuring everything from temperature and humidity to motion and light. Actuators, another part of this layer, are used to translate digital signals into physical actions. For example, turn on the light or the air conditioning system in response to the certain data obtained.

The IoT device architecture essentially bridges the physical and digital worlds, collecting raw data.

Network and Connectivity Layer

The IoT network architecture layer enables the connection and communication between IoT devices and the platform. It’s possible owing to communication protocols like Wi-Fi, Bluetooth, MQTT, HTTP, Zigbee, and cellular networks. To effectively implement these protocols, businesses often rely on custom IoT software development services.

From WebbyLab’s experience, MQTT and HTTP are the most common network layer protocols. 

• MQTT is perfect for uninterrupted, real-time connection of IoT devices to the internet and the cloud. Yet, it’s not always the most efficient option for battery-powered devices.
• HTTP is ideal for battery-powered IoT devices, as they can’t maintain a constant network connection. For example, those kinds of gadgets that wake up periodically, send data to the platform, and then return to sleep mode, preserving battery life.

Kostiantyn Oliynyk

Head of IoT at Webbylab

Helped dozens of startups create effective IOT products.

Get a Consultation

Data Processing and Analysis Layer

Raw data collected by IoT hardware is just the beginning. The IoT data architecture layer is where the gathered information gets filtered, aggregated, processed, and interpreted.

This layer involves using various tools and techs for data analysis. Those include:

• Analytics platforms;
• Advanced analytics and machine learning algorithms;
• Data management systems.

The above tools let you identify trends, predict future events, or trigger specific actions based on the insights obtained from data. 

The IoT platforms typically provide real-time or historical data analytics capabilities as well. This functionality helps users gain insights into their IoT devices and data for further device/system performance optimizations.

Application and User Interface Layer

This is essentially the IoT software architecture layer that interacts with end-users directly. It typically provides interfaces and features that let users monitor data, manage devices, handle firmware updates, parameter adjustments, and diagnostics.

The IoT software platform architecture layer may include:

• Mobile apps;
• Web apps or dashboards;
• Middleware services for device-to-system connection;
• Data visualization tools.

Main Components of the IoT Platform

An IoT platform is the brain of your entire IoT ecosystem. It collects, processes, analyzes, and visualizes data from your connected devices. But how does it work, and what does it consist of?

See the common IoT platform components that WebbyLab experts typically use on the following IoT architecture diagram:

The diagram of a common IoT architecture

Now, let’s discuss each IoT platform architecture component in greater detail.

1. Load Balancer

The load balancer is the entry point for any web application. It ensures a smooth traffic flow throughout the platform and prevents servers from becoming overloaded.

This part is especially critical for the IoT platform because it connects thousands, tens or hundreds of thousands, even millions of devices simultaneously. Continuous connection is a key consideration here.

2. WAF (Web Application Firewall)

WAF is a specialized type of network hardware or software designed to protect web applications from various types of attacks.

3. Connectivity (MQTT)

MQTT is a transport protocol used for both connecting devices to the platform and transferring data from the devices to the end-user or platform.

4. Services

Services is a set of functionalities that make up the IoT platform. These include typical front-end/back-end services as well as any additional services that expand the platform’s capabilities or functionality.

Some of the most helpful services include the following ones:

• TimeSeries collector — a vital tool for collecting historical device data, enabling further sampling, aggregation, and data analysis;
• Device management — a set of tools for managing and configuring devices, facilitating firmware updates (OTA updates), and access control to the platform (credential management);
• Notifications — a service or API that allows devices to send messages to clients about malfunctions or any other events;
• Backups — an essential aspect of any system, and IoT platforms are no exception. Loss of historical device data, if collected, could significantly set back business optimization plans for several months. Therefore, it is crucial to back up both user data and device data, including their access parameters to the platform and historical data.

It’s better to collect historical data from the very outset of the platform, even if there are no plans for analysis. When it becomes necessary to conduct an analysis, there will already be a sufficient sample of historical device data.

Kostiantyn Oliynyk, Head of IoT at WebbyLab

5. Monitoring System

A monitoring system is a set of services for monitoring the system’s status. Given the continuous connection of a large number of devices, configuring failure alerts is critical to ensuring system stability.

The IoT platform monitoring system

IoT Architectures with MQTT in Action

While not every IoT architecture relies on MQTT, WebbyLab frequently leverages this protocol for its lightweight design, efficiency, and reliability. Let’s consider several examples of MQTT-based projects implemented by our experts.

Propuskator Access Control System

The IoT architecture of the Propuskator ACS

If we compare our access control system, Propuskator, with the IoT architecture diagram above, they are nearly identical. Our Propuskator devices connect to the platform via an MQTT broker and use HTTP to synchronize access schedules/rules and access logs. 

The only distinction is the absence of historical device data collection and storage, as ACS doesn’t require it. It serves a different business task.

2Smart Standalone Automation Platform

The IoT architecture of the 2Smart Standalone automation platform

Let’s now look at our other project with a slightly different architecture. 2Smart Standalone isn’t inherently an IoT platform but a BAS (Building Automation System). Yet, it can also be considered an IoT device management solution.

The primary distinction lies in its ability to integrate devices from various manufacturers and communication protocols through bridges. The bridge is a service that internally converts one protocol into another, facilitating connectivity between the device and the platform.

For example, Modbus devices communicate with each other via the RS485 protocol using cables. The bridge converts this communication from cables to MQTT and vice versa. Consequently, the platform’s end-user can send a command through the platform; the bridge will receive it, convert it into RS485, and transmit it to the device.

Let’s recap!

While the above diagrams are different, their core element remains the same — the MQTT broker (connectivity). Thus, the connectivity component can be considered the cornerstone of the IoT platform architecture.

IoT Architecture Without MQTT

Now that we’ve explored the IoT architecture our team usually uses, let’s consider an alternative approach. Here’s an example of the architecture based on Google Cloud Platform that doesn’t rely on an MQTT broker:

An IoT architecture without MQTT

In this  IoT network architecture setup, devices use the back-end’s REST API for sending and receiving necessary information.

The distinctive feature of these types of IoT architecture is the lack of real-time device management. Users can input certain settings, which the device will receive upon contacting the back-end, but only when it initiates a request.

In this example, devices are typically in the sleep mode to conserve battery power. They wake up according to a schedule, communicate with the back-end to receive parameters for their tasks, send reports, and then return to sleep mode.

This GCP-based architecture uses various ready-made tools from Google Cloud. This greatly facilitates development but increases monthly infrastructure costs.

GCP is an excellent tool and definitely worth the money for IoT solutions. However, it should be used in cases where there is a real prospect of production and high loads that GCP can easily handle. Startups may end up spending a large amount just on the infrastructure even before reaching the production stage.

Kostiantyn Oliynyk, Head of IoT at WebbyLab

The application we developed consists of the following:

• A web admin panel for system administrators with access to all the necessary information;
• A web and mobile application for end-users;
• An API used by all devices for provisioning, receiving settings, and reporting.

Hence, users interact with the system via web browsers or a mobile application, administrators access it through the web admin panel, while devices communicate directly with the back-end via the provided API. To ensure seamless integration of all components and optimal system performance, many companies engage custom IoT consulting to design and implement tailored architectures.

GCP-Based IoT Architecture Components We Used

Let’s examine the components of this IoT cloud architecture in greater detail. Here’s the breakdown of each Google Cloud service you can see in the diagram above:

• Cloud Run and Cloud Tasks. These are the services that let us deploy an app from a Docker image, set the configuration for a single instance, and automate tasks of horizontal scaling (increasing the number of identical instances) to handle increased loads.
• Load Balancer. That’s a service for evenly distributing the load between cloud instances (in our case). It’s needed to get one IP address as an entry point to instances that are automatically scaled.
• Cloud Armor. It’s a network protection service guarding against DDoS and other cyber attacks.
• Cloud SQL. It is a cloud database (we typically use MySQL) with the option to configure read-only replicas.
• Cloud Storage. That’s a service for storing static files like images, videos, and firmware.
• Secret Manager. It’s a service for securely storing passwords, API keys, and other sensitive data.
• Cloud Monitoring. This service works well for metrics collection and setting up alerts/alarms to trigger when thresholds are exceeded. Notifications can be sent via various channels, including email and Slack.
• Cloud Tasks. It’s a service for scheduling and executing tasks at specific times.
• Cloud Pub/Sub. It is a pub/sub service that makes it possible to send messages to subscribers in a certain order.
• Cloud Scheduler. It’s equivalent to cron jobs for scheduling tasks.

And here’s an in-depth explanation of some of the Google Cloud services we leverage:

• Cloud Tasks. We use Cloud Tasks for sending reminders to clients about certain events initiated by the device or system. These reminders are sent at a set time in a delayed manner.
• Cloud Scheduler. To use this service effectively, we manage tasks like data rotation, device checks, connections at specified intervals, and so on. These tasks operate within the worker framework but are triggered by Cloud Scheduler. The main difference between this service and Cloud Tasks is that Cloud Tasks handles tasks for individual devices (including payloads), while Cloud Scheduler executes them on a fixed schedule.
• Cloud Pub/Sub. We use this service to process events sent by the device. An event comprises information about the result of an action. The device sends these events to the back-end, which then puts them in the “queue” in the Pub/Sub service. Subsequently, the worker executes them.

Custom Services We Used

The WebbyLab team used bespoke services as part of this IoT system architecture based on GCP. Here’s what we added:

• Client application. It’s deployed on Cloud Run, accessible via the load balancer (used by clients to interact with the client API).
• Admin panel. It is also deployed on Cloud Run, accessible via the load balancer for admin use.
• Back-end. It comprises API groups for different users.
• Worker-back-end. It’s a service designed for executing tasks.

All services deployed on Cloud Run are secured behind load balancers, which are further protected by Cloud Armor and its policies.

Wonder how to put those IoT architecture ideas to good use? Check out the top 10 IoT use cases.

Ensuring Security and Scalability

Building a secure and scalable IoT architecture is key to your project’s long-term success. Here’s how to make your system stronger:

Strategies for Securing IoT Ecosystems

A decent IoT security architecture ensures protection layer by layer. The methods you may leverage include:

• Secure your devices by implementing strong authentication protocols, encrypting sensitive data, and keeping firmware updated.
• Protect your network with firewalls and intrusion detection systems.
• Treat your data with care by encrypting sensitive information at rest and in transit.
• Regularly scan and fix vulnerabilities in devices, platforms, and applications.
• Develop an incident response plan for your IoT reference architecture to address any issues quickly.

Implementing End-to-End Encryption and Access Control Measures

Encryption makes your data unreadable to unauthorized parties. Implement it to protect your data throughout its entire journey, from device to cloud and back.

Plus, don’t forget about access control measures. These make sure that only authorized users and devices can access/read/modify specific data within your Internet Things system.

Scalability Considerations for Accommodating Future Growth

If you aim to develop a future-proof IoT architecture, leaving room for scaling is mandatory. To do so:

• Adopt a modular design that lets you add new devices and features effortlessly.
• Prefer standardized communication protocols like MQTT, as they allow for easier integration of new devices and services into your existing IoT architecture.

Webbylab Experience in IoT Architecture

WebbyLab has been delivering robust IoT architectures for over five years. During this time, our expert team has tackled 10+ projects and developed three IoT products of our own, including 2Smart Standalone and Propuskator.

A mobile app of the Propuskator ACS

We can handle a range of services to facilitate your IoT platform architecture:

• Consulting. Get expert guidance on architecture, programming languages for IoT, and more.
• Acceleration. Speed up development and get to market faster.
• Enhancement. Optimize and add features to your existing IoT software.
• Full-cycle development. Rely on us to handle it all, from concept to deployment.
• Analytics. Extract valuable insights from your IoT data.
• Integrations. Connect your IoT system with other platforms or services.

But less words, more action. See how we implement successful IoT solutions in our portfolio.

Implement IoT Architecture with Ease

IoT architecture might seem complex, but with the right foundation and partner, you can achieve success. Our article has just covered the basics — the possible IoT applications are truly limitless.

Have further questions on the architecture of IoT? Contact our experienced specialists at WebbyLab to turn your project idea into a robust, viable ecosystem.