Polyglot architecture - Create fewer dependencies

Higher interface independence, flexibly acting teams and greater freedom of choice when choosing programming languages and technology stacks: The use of a polyglot architecture in connection with messaging/event sourcing for asynchronous communication between several microservices (bounded contexts) or external systems/applications has to offer many advantages. Here you can find out what is behind the pattern, when it makes sense to use it and what challenges can arise.‍

How does a polyglot architecture work?

One usually speaks of a polyglot architecture in the context of a microservice architecture. It is determined in advance independently and depending on the requirements, which programming language and which technology stack is used in the microservice. Different languages and stacks can thus be used within an ecosystem and operated in parallel. Instead of limiting, entropy is actively promoted in a polyglot architecture. The ability to largely determine the framework conditions independently is one of the major advantages of a polyglot architecture.

Tight coupling Problem

Microservices can be built in different ways. With a polyglot approach, it is pursued that each service should act autonomously and the database is also selected specifically for the service and the use case. In this case, it therefore makes little sense to choose REST interfaces as the standardized communication path. If a microservice architecture is based too heavily on REST interfaces, strong dependencies automatically arise (tight coupling).

If several REST-based microservices are linked one after the other and one part of the chain shows an error, this affects all consuming services. Finding the source of the error is tedious and the cascade means that each supporting team has to contact the next team from which it consumes the service. This additional effort means time costs from which customers suffer and sometimes losses arise when employees are forced to interrupt their activities and have to wait for feedback before they can be productive again.

With REST interfaces, the data is obtained from the integrated service. This means that the data structure is not structured for the use case of the microservice, but for the general use case of several consumers. In the History Service listed above, this can quickly become a scaling issue once the service needs to search through and display a little more data.‍

The better way: loose coupling

If such sham microservices, more precisely monolithic architectures, are broken up by events, this tight coupling can be broken. This gives each microservice its autonomy and dependencies can be almost entirely avoided in this way. In order to achieve this, those that are required for the implementation of the service are consumed from various event streams. The REST services used are taken over by deliberate replication and integrated into your own service. This means that instead of REST services, libraries are increasingly used to bring shared modules into several microservices. This creates an architecture with a flat structure of microservices that are able to act autonomously. In addition to an independent structure, the development teams also benefit from a polyglot environment, as they can organize the project more flexibly and independently.

The benefits of loosely coupled polyglot architectures

From the combination of different programming languages to the acceleration of development phases to the promotion of IT talent: loosely coupled polyglot architectures have many advantages to offer.

Release cycles independent of other teams

Missing functionality for the use case can be implemented by teams in the libraries used by multiple microservices instead of requiring it from other teams. The communication and planning overhead within the entire company is minimized and the release cycles are independent of other teams.

Safety in the event of a fault: Fault tolerance

In a polyglot architecture it is possible to consume different services individually. If one system fails due to a fault, the other systems remain unaffected and are therefore still able to act. The independence of the individual databases from each other increases security at the same time and the systems can continue to be used without too much damage or loss.

Reduce dependencies

Monolithic applications, or above all microservice architectures built on REST, can quickly gain dependencies if existing microservices are supplemented by other REST services. Each additional REST service promotes a strong dependency on the levels of error handling, release planning and interface maintenance. With a polyglot architecture, on the other hand, the dependencies remain in the team. This is particularly important if an entire ecosystem of REST services is to be used.

Scalability and flexibility

When using REST services, you have to trust that the REST service can keep up with the scaling requirements of your own application. However, these details are usually not given in API documentation for the REST services used. This therefore requires clarification and always costs the teams time. If the options offered are not sufficient, they cannot mitigate within the team without great effort. Therefore, the entire consumed service must be re-implemented or waited until the consumed service has implemented these scaling measures. Under certain circumstances, however, this takes too long and causes your own application to come to a standstill. By consuming events and using libraries instead of a REST service, this can be scaled by the teams themselves for the current traffic.

The right programming language and database

The decision as to which programming languages are used in a polyglot architecture is made by the team itself, because they determine the technical conditions. By consuming and processing events, each microservice can be built independently, allowing efficient use of the advantages of different databases, programming languages, frameworks and tools.

Working speed and motivation

The possibility of being able to actively influence the course of the project also increases the speed and motivation with which solutions can be pursued and the result achieved. Existing skills and abilities are sensibly exploited in this way instead of being limited. Existing resources can be used directly instead of being trained first and then used. In addition, several teams can work on different solutions at the same time and do not have to consider the respective development status or wait for handovers.

Sharing of know-how

By adopting and leveraging libraries, which are typically team-driven, internal expertise is better distributed across the organization.‍

Are there also disadvantages of polyglot architectures?

Polyglot architecture offers many advantages and potential. However, there are also some points that should be considered when considering whether polyglot ways of working are suitable for a project.

• Know-how sharing: By eliminating dependencies on other teams and integrating libraries whose maintenance is mostly driven by team requirements, know-how sharing can also turn out to be a disadvantage if the libraries become too complex. However, this can be mitigated by a “library team”.
• Silos: The company must be willing to move away from the silos. Since further development of the libraries used is now carried out by the teams, the responsibility is distributed among several teams. This is sometimes difficult to reconcile with strongly hierarchical structures within the company.
• Scaling: Because the teams have to do the scaling themselves, it requires know-how on how to do this. This can be mitigated, for example by using standardized platforms such as Kafka, which relieve the teams of sharding problems and their complexity. The team can thus continue to take care of the effective requirements of the company.
• Entropy: If each microservice is written in a different programming language, a version in this language must exist for each library used. Once there is too much entropy, it can become difficult to manage. This can be mitigated, for example, by the widespread Intermediate Language WebAssembly.

If the advantages and disadvantages are carefully weighed up in advance and included in the planning, the necessary steps can be taken at an early stage and the course set for successful implementation.‍

Conclusion: Effective solutions for complex requirements

The digital world has developed enormously in recent years and presents companies with new tasks every day. The digital transformation is quickly creating a microservice ecosystem in companies: many domain-specific services are beginning to integrate with each other. If the dependencies are not transparent when working with REST-based microservices or if too many dependencies are created that can lead to error cascades, a polyglot architecture is a recommended solution.

📝 Like what you read?

Then let’s get in touch! Our engineering team will get back to you as soon as possible.