1.3 Software architecture

Everything about the fundamental structures of complex software systems

Jeremy Theocharis

There are hundreds of various frameworks for managing complex software systems. In this chapter, we will focus on the most talked about in Industrial IoT:

Monolithic applications vs microservice architecture
Client-server vs event-driven architecture

Monolithic and microservice architecture

Traditional software is written as a monolith. This means, that all required components are bundled together in a single program and “you just need to double-click on the application to start the installer”. As software began to get larger and more complex, the microservice approach established itself. Instead of one large program, multiple smaller programs (so-called microservices) were developed. Each microservice has very small functionalities, but when coupled together as a whole they are able to deliver highly complex business applications. In the following images you can recap how monolithic applications and microservice architectures are built.

The first image shows monolithic software. Monoliths are typically installed and maintained more easily, but struggle in terms of scalability and extensibility.

The second image shows how a microservice architecture is built. It is common to run the same microservice several times in parallel, so that you can easily balance the load and if one microservice fails (e.g., because the server crashed), the other microservices with the exact same functionality on another physical server can take over without any disruption to the end-user.

Typical tools & technologies associated with a monolith

a lot of Java programs
Kepware
Thingworx

Typical tools & technologies associated with microservices

Docker & Kubernetes are tools for creating and managing microservice architectures. Read more here.

Client-server and event-driven architecture

Client-server

In a client-server communication, programs / microservices communicate directly with each other. This is easier to set up, but the system struggles when more components are added on a later stage.

Let’s take the example of a typical vision-based quality control system. You have a camera that sends the data to the image processing algorithm, which then stores the final result in a database. The application works perfectly fine, but now you want to add a new operator dashboard showing the image from the camera together with the classification. Now you need to create two more connections. Now imagine a third or fourth application comes in here, you will very likely start to lose the overview.

Event-driven architecture

From this video we hope you can take away the benefits of event-driven architecture, as well as the design pillars of the reactive manifesto used for its system design.

In an event-driven architecture (also known as “Publish/Subscribe (Pub/Sub)”, “Unified Namespace” or “MQTT”), information is exchanged using a central message broker. This adds complexity at the beginning of the project, but allows easier adding of new microservices.

Coming back to our camera example, you can see that the initial architecture is slightly more complicated as you have a message broker and a database service. But now the integration of a new use-case like the operator dashboard is very easy and quick.