Overview of the microservice framework

Microservices architecture is a variant of Service Oriented Architecture (SOA). The wikipedia article explains well the how and why for the general concepts.

In order to ensure identity of applications and services (services and applications are almost the same thing, and for redpesk security framework, exactly the same thing) redpesk OS requires them to run on processes that can be clearly identified by the Mandatory Access Control (MAC) module of Linux. This requires applications to be split at least to the level needed for security checks.

The consequence of microservice design is the increased role of communications.

During development stages of redpesk OS, it became clear that a framework able to manage communications for applications would be of great benefit for developers that could focus on the logic of their application.

The microservice framework is currently able to provide communication between applications on top of the following communication protocols:

  • HTTP
  • WebSocket
  • WSAPI
  • RPCAPI
  • DBUS
  • DDS
  • when in same process, direct memory without serialisation

This allows interconnection of processes together. But it also allows connection to services from the network.

For some of the given communication protocol, the microservice framework is able to transport binary data at low serialisation cost. A specific component of the framework leverages that feature to allow designing application as Flatbuffer services, using interface description language of Flatbuffer. In that case, transport and deserialisation of complex binary data is cheap and secure because type is also transported through a short hash tag.

The microservice framework also provides a tight integration with the security framework. It provides permission check in a declarative way, based on name of accessed verbs of services. It also allows one to keep track of client sessions.

One of the benefits of using the microservice framework is the flexibility of distributing services across processes. This ability improves the scalabitlity of development, allowing the redistribution of applications on several cores or, the extreme opposite, in a single process.

In practice, the microservice framework is made of the program afb-binder, also known as The Binder. The binder is a program that loads its applications as services. It reverts a more common known logic of making applications, where the application is linked to a library that implement the framework. The benefit is that it breaks the process boundary of applications, allowing two applications to run in the same processes, which improves flexibility. Also because the binder takes care of not being a link dependency but controls its exposed interface, it is possible to run the same application on top of an other but compatible binder, which can be used for audit, test or refit.