Service Architecture And Message Broker
Due to the different environments at our customers, we are forced to keep our software architecture as flexible as possible. A single component for pre-processing machine sensor data may have hardly tasks to accomplish for one customer, and be exposed to very high loads for the next. While in the first case, it makes no difference whether it runs in the main process, in the other it can potentially become a bottleneck and can ideally run in parallel to its own process or even on its own machine.
In early development versions, we had initially created a monolithic system that managed multiple processes using its own process runtime. However, we quickly realized that we could accomplish the same thing with less effort by using containers. After all, containers are processes in their own right and provide some additional features that we like to take advantage of (see section “isomorphic builds and infrastructure as code”).
As a result, we switched our entire software to containers and ended up with a modular service architecture. So there are several modules for reading and translating sensor values and machine states, one for managing knowledge modules, several machine learning modules, and so on. We also use this strategy in customer projects to add customer-specific features as needed in the form of our own plugin modules.
The modules communicate with each other via a message broker, i.e. they send and receive messages on a common channel without knowing the dialogue partner. Except for the common message types and the common database, the modules are therefore completely decoupled. In contrast to a point-to-point topology, the additional work involved in distributing the various modules to different systems is thus limited to providing each module with the address of the message broker as a configuration variable.
With the service architecture, we use a bit of the best of both worlds: service-oriented and monolithic architecture. The architecture is very malleable, but that only comes at the price of as much complexity as is absolutely necessary.