The implementation of application architectures has changed significantly in recent years. A few years ago, monolithic application architectures dominated with the aim of reusing as much code as possible. Today's application architecture looks much more differentiated and offers us new possibilities.
The monolith
In the past, many applications were implemented using a monolithic architecture. However, from a certain size or a certain age, it becomes increasingly difficult to maintain, expand or even modernize such applications.
This is usually the result of the individual components being very strongly tied to this monolith or even other technical restrictions that do not allow part of the application to be modernized. Even the smallest interventions, such as the renewal of a library, can often not be generated without side effects in other parts of the application. It is precisely this problem that places new demands on future application architectures.
We are responding to these new, increased requirements with the implementation of MicroServices and the separation of the core system (monolith) and the new functionalities.
The MicroService
Due to the increasing requirements in terms of scalability and speed in the technologies, in terms of appearing and disappearing again, more and more applications are now being implemented using a network of loosely coupled (micro) services. The availability of inexpensive cloud resources and the general acceptance of container technologies such as LXC, Docker and Rkt are also favoring this development.
This is because these services no longer focus on the reuse of code, but on the reuse of infrastructure components. These can also be represented by generally available (micro) services.
In order to create such modular applications quickly and with a high level of quality, we have developed a toolbox that contains and bundles frequently required services. It defines a rough application architecture based on MicroServices as well as Docker, Kubernetes and OpenShift.
MicroService Toolbox
Our MicroService Toolbox consists of reusable infrastructure components, such as a templating service that renders emails or forms, a mail service that transfers emails to an SMTP queue and updates a protocol. The components were either taken directly from corresponding projects or extended. The transfer always takes place as a source artifact in order to be able to react directly to any changes in the requirements.
Our toolbox also includes abstract artifacts, such as legacy systems or monoliths, which can be connected as a core system. This also includes, for example, the connection of SAP systems as a system of records using ODATA.
We use a message broker for communication between the services. This enables us to achieve genuine asynchronous communication between the services and activate reliable messaging if required. The "stateless" design of our services allows us to optimize our MicroService Toolbox, as each service can be scaled as required. The architecture of the toolbox is consistently designed for the creation of cloud-native or container-native applications.
Container application
We took a cloud-native approach to our architecture using containers so that we can use our toolbox almost independently of the cloud provider. This means that our toolbox and the application based on it can be scaled, monitored and distributed almost freely at any time. This also makes multi-cloud and hybrid scenarios conceivable. This approach also means that the applications we create are completely detached from the underlying infrastructure. It is therefore no longer relevant for the application if an operating system update changes a library, as this library always remains the same in the container image.
This also applies to scaling the application. Previously, complex load balancer configurations were necessary. These tasks are now performed by the container runtime.
The use of containers also favors the use of continuous delivery or continuous deployment approaches, as the container is fully configured and available within seconds. Once these hurdles have been overcome and the application is packaged in the container, the step to a general DevOps approach is no longer a big one. More on this in one of the next articles.
by Thorsten Gawantka
