Extracting Microservices from a Ports-and-Adapters Architecture

A typical application controlling a machine interfaces with users, with the actuators and sensors of the machine, with cameras, with the IoT cloud, with local and remote databases, with a fleet management server, and with other system parts. The application core, which implements the business rules, must not know which technology components are used to communicate with the user, machine, cloud, or database. Well-defined ports (interfaces) hide the implementation of the adapters (components) from the core. This is the ports-and-adapters architecture in a nutshell.

The ports-and-adapters architecture leads to loosely coupled and cohesive components with well-defined interfaces. This sounds a lot like a microservice architecture, doesn’t it? It does, indeed—with one difference. Microservices run in their own processes (often on different computers) and talk to each other over a lightweight protocol. In contrast, the ports-and-adapters architecture is mostly implemented in a monolithic application running in a single process. The core and adapters communicate through function calls.

We can find good reasons to extract adapters from the monolithic application as services. The application keeps a proxy for the extracted service. The proxy and the service implement the same port. The proxy and service are very much like the two USB ports connected by a USB cable. Here are two examples.

These days, the main HMI application should have a component performing OTA updates of the embedded Linux system. OTA updates require root privileges. For security reasons, user applications should not have root privileges. If we extract an update service from the application, the application can run with user privileges and the service with root privileges. Only a properly authenticated application may use the service.

HMIs of agricultural and construction machines provide functionality for normal operation by the driver and for diagnosis by a support technician. When we split the monolith into two applications accordingly, we face a resource-sharing problem. If one application reads a message from the CAN bus, the other application will never see this message. The solution is the introduction of a service doing all the CAN message processing and replicating the messages for all the interested applications.

As long as it makes sense, we can transform the adapters from our applications into services. As the services will most likely implement the ports-and-adapters architecture, we may be able to identify even more services. The operating-system and hardware-abstraction layers are fertile ground for more services. The applications and services use inter-process communication like DBus or gRPC to talk to each other.

We have transformed a few monolithic applications into several smaller applications and services talking to each other over a lightweight protocol. In short, we end up with a microservice architecture, where each microservice (including applications) implements the ports-and-adapters architecture.

Go to Session

The Ports-and-Adapters Architecture for Embedded HMIs

The ports-and-adapters architecture (a.k.a. hexagonal architecture) is based on the same idea as USB ports and adapters. USB adapters enable PCs to communicate with embedded devices over CAN, RS232, (W)LAN or BLE. The USB port hides from the PC which technology is used for the communication - as a good interface should do. Different companies can manufacture the adapters as long as they comply with the USB interface.

A typical machine HMI has a UI, machine, accounting and monitoring port. These ports are the interface between the application core implementing the business rules and the adapters connecting the HMI to the user, the cloud, databases and the rest of the machine. Ports lift the abstraction level from concrete technologies like SQL, J1939, Qt and MQTT to the business domain.

The machine port, for example, hides from the core whether the machine adapter uses the J1939 or OpenCAN protocol over CAN bus or Ethernet. If the manufacturer decides in 5 years to switch from CAN to Ethernet, it can do so without impacting the core and the other adapters. The architecture becomes loosely coupled, cohesive and easy to extend.

Each port has at least two adapters: one for production and one for testing. Test adapters are either test cases or mocks. As the core, they are technology agnostic and I/O-free. We can write I/O-free tests for the core. Such tests are ideally suited for TDD or BDD.

Conway’s law tells us that the software architecture mirrors the organisation structure. So, it is not surprising that the architecture more often than not resembles a big ball of mud. We can avoid this by inverting Conway’s law. We map the core and adapters to separate teams. The ports become the team APIs. Some teams can be merged - especially if too small. Other teams should not be merged.

The ports-and-adapters architecture has gained a lot of traction in enterprise software, but is little known in the embedded world. This is unfortunate, because it is an excellent architecture not only for embedded HMIs but also for firmware.

Go to Session

Live Q&A - The Ports-and-Adapters Architecture for Embedded HMIs

Live Q&A with Burkhard Stubert for the talk titled The Ports-and-Adapters Architecture for Embedded HMIs

Go to Session