Accelerate IoT Applications With Microservices: A Use Case

Shift From Mono To Micro For High Agility

Digital transformation is an ever-evolving process. If you want your business to be on the fast track to digital change, it needs to adapt and be ready for future improvements continuously. When you have to get practical and translate this into IoT applications, the architecture choice becomes of great importance.

For software development the challenge lies in connecting a broad ecosystem of devices and communication protocols that vary from one device to another to a central platform, where data is monitored and analyzed. In many cases, software engineers have to develop custom adapters to retrieve the data and send it to the cloud. The best way to tackle this challenge is to choose the architecture in terms of feasibility.

Simply put, the monolithic architecture is about dividing functionalities into methods and classes, but inside the same single unit which is deployed as a process. Such architecture allows proper testing of the application, as well as usage of the deployment pipeline. However, this approach shows severe limitations when considering systems scaling to multiple users and rapid deployment cycles. The impact is significant as each change requires the entire application to be re-deployed. Furthermore, while scaling up, the entire application is duplicated onto servers instead of just scaling the functions which are facing a higher load.

These drawbacks determined companies like Netflix and Spotify to popularize the use of a new style of software development based on microservices, which are a way of breaking down large applications. Instead of in-memory function calls, each service runs as a separate process. Another benefit is that they use lightweight mechanisms to communicate with each other. Being small, highly decoupled and task-specific they pave the way to agility and resilience.

Microservices In Action: An IoT Use Case

Below is a proposed IoT microservices-driven architecture that best presents how benefits fall into place. The architecture is based on Microsoft Azure, using several components that allow us to implement the desired functionalities.

The IoT application collects data from the factory floor, from different machines and PLC supporting various industrial protocols like TCP/Modbus, OPC-UA or other legacy protocols. Data is then sent to the cloud, where real-time processing occurs (data sanitization, anomalies detection, data storage). A user interface is used to view data, manage devices, define data rules. A BI tool like Power BI can be used for reporting.

In a nutshell, it all boils down to three keywords: microservices, containers and scalability.

Microsoft Azure components are employed. Microsoft IoT Edge, which is a runtime based on container technologies like Docker, is used on the factory floor. Components are developed using different programming languages (C#, C++, Java) packed into containers, using the docker development toolbox and then deployed to a container registry like Docker Hub or Azure Container Registry Service. Afterwards, the containers are deployed on the edge device through Azure Web Interface or the Azure API. This enables new modules to be added on the fly, making the rollout phase easy.

In our example, we have the following modules:

- ModBus Module -a module which uses libraries that communicate with a machine/PLC (programmable logic controller) over TCP or the serial port and assures a bidirectional communication between cloud and devices.

- OPC/UA Module -a module which uses libraries that communicate with a machine/PLC (programmable logic controller) over OPC/UA protocol.

- Legacy Module -other custom modules which can implement connection mechanism to legacy devices. Here we can also include devices that send data directly to the cloud.

In the cloud, all the back-end and front-end components are deployed as containers in Azure Kubernetes Service. It provides almost all the functionalities of the native Kubernetes application, but with some advantages:

· The environment is managed by Azure, so this removes the complexity of implementing, installing, maintaining and securing Kubernetes

· It’s still Kubernetes, so no vendor locking (the same instruction set as for native Kubernetes)

As an entry point for the data and the device management, Azure IoT Hub is used.

Here is a brief description of the components deployed in the AKS:

- Reverse proxy -is a server based on NGINX, placed between internal applications and external clients, forwarding client requests to the appropriate server. It has many advanced load, balancing security, and acceleration features that most specialized applications lack. Using NGINX as a reverse proxy enables you to add these features to any application. In our solution it is used to expose the user interface to external clients and the device Manager Service to the Edge Module.

- User Interface -web application that exposes the functionalities to the end user, such as:

· User management (integrated with Azure Active Directory)

· Device management (used to add, modify or delete a device)

· Edge management (manages the modules deployed on the edge device, adds or removes modules)

· Devices real-time telemetry display

· Business rules definition (the rules that are defined based on the collected data)

· Alerts management

· Reports (integrated with Power BI)

- Storage Adapter-the service that stores incoming telemetry data into the desired storage. Also, it is used to store all the configurations related to the solution. It uses two types of storage:

· Hot Storage like Cosmos DB to store device and system configuration and also telemetry data for a short period

· Cold storage like Blobs or Azure Tables for long-time archiving of data

This service can be modified to support any type of storage, but by keeping the signature the same, it enables compatibilities with the other services. BI Solution (such as power BI) can be implemented on top for historical reports.

- Telemetry Service -the service that retrieves the telemetry data from the Hot Storage and sends it to the user interface ready to be displayed.

- Auth Service-a service used for authentication between the services of the solution. Using Azure active directory, a token-based authentication can be implemented between services. For example, if Service A wants to access Services B, it sends a JWT Token. Service B checks the JWT Token to determine whether service A has the right credentials, therefore increasing the internal security.

- Config Service -the service that retrieves the configuration of the application, like the defined rules and the device configuration.

- IoT Manager/Device Manager -a service used for device management and device communication from the user interface using the Azure IoT Hub.

- Stream Processor Service -the service that reads the data stream that is sent by the devices from the IoT hub, analyzes it and sends it to the storage adapter. Also, alerts can be created based on the rules defined in the user interface.

As a conclusion, microservices architecture offers excellent scalability and the possibilities of adding new components independently, greatly increasing the release cycle. Also, Kubernetes allows new versions of services to be deployed and tested, with the possibility of a rollback, decreasing the risk of bugs in production. Each service can be scaled independently, thus leading to resource optimization.