Microservices- instead of a monolithic architecture


Microservices- instead of a monolithic architecture


Microservices Architecture Reduces Complexity

The development of AssetSec was deliberately based on a microservices architecture. The strategic approach that we pursue with AssetSec was decisive.

During the preparation phase of the project, emphasis was placed on a strong separation between front end (Javascript -React.js) and back end. Previous test phases have shown that the requirement and use of several external interfaces adds more complexity to the architecture of the backend. To keep this to a minimum, we decided to use a distributed backend infrastructure, also called Microservices architecture.

Monolithic Architecture
(previous architectural style)

Microservices Architecture
(new architectural style)

This architectural style requires the incorporation of the latest technologies. In addition to security mechanisms, communication structures and various application details of the services, (Netflix is a pioneer of microservices architectures and a main source for open source packages: See Netflix OSS), new development principles and content must be taken into account. This content can be divided into two different subject areas.


(Decisions and definition of the individual service contents):

  • Which language:
    Java, Python, Javascript?
  • Which libraries?
  • Which programming patterns?
  • Data management: What kind of database?

macro architecture

(Decisions and definition of rules within the infrastructure):

  • Process and technique of software publishing
  • Communication between the individual services
  • Storage of the occurring program messages
  • Safety criteria within the infrastructure

This graphic illustrates this distinction. Here, each module represents an application/service. Each green element within a block for a service content (database, library, etc.):

macro architecture

  • Decision of the tools of the system
  • Objective: Cooperation and stability

macro architecture

  • Decision per application/service
  • Objective: Flexibility and freedom of development


Once this basic framework is defined, strong benefits can be derived from the architectural style. For example, each feature in the backend can be implemented using its own microarchitecture. So any development pattern, any language or data storage can be used. This means that for each service, the microarchitecture can be chosen to best suit its requirements.

In addition, the manageable size of the individual application means that complexity is greatly reduced: Each application defines features with different visibility on the processes and associated data. Each application concentrates on a specific part of the domain. The lean software is thus understood more quickly and can be further developed at a lower cost.

Service A accepts a request, sends a message and returns "Request accepted" as an answer. Service B assigns this message to itself, takes the necessary information from the message, and does the necessary work. In this case, the work to be done is a complex arithmetic operation and an additional call to an external application. As soon as this work is done, another message is sent to Service A to receive it.

The strong advantage: What exactly happens in the background is not important for Service A. Which language the message was returned in the background is also irrelevant. Only the rules of the macro architecture must be observed.


The implementation of a microservices architecture poses a number of challenges, but also exciting opportunities. Developers are able to live their freedom within their microarchitecture and still provide a common application with a common goal. Modern technologies and languages can thus be easily integrated into existing systems.

Any further questions?

Contact us by e-mail or messenger. We will be happy to answer any questions you may have. You can test AssetSec free of charge for 7 days. We are happy to answer your questions. We look forward to hearing from you!