Microservices Architecture – Into The Detail Of R&D Activities (part 3)

Over several years, we have gained extensive experience with microservices, encountering numerous challenges. How to ensure continuous knowledge sharing within the team? What’s the process behind choosing the programming language, framework or database that best suits our needs? Is it still possible to build a monolithic application from our services?

Knowledge share

In the microservices world, the need for information within the team is even greater than in the monolithic world because, unlike monolithic applications, microservices-based applications are indirectly bound to each other as they share the same services. Major and minor changes are discussed in regular weekly meetings and also in the R&D communication channel, which helps to keep all team members informed. Hindsight is also essential, so the end-of-year summary meeting is where the accomplishments of the past year are discussed, and the plan for the next year is also developed.

Cooperation

A developer implementing a change must ensure its backward compatibility to avoid negatively affecting any other application using the service. If a new major version of the module is released, a migration guide is written. Should another project be upgraded, the developer who made the change either passes the migration guide to the project team or prepares merge requests with modifications to be reviewed by the project team. These situations, caused by the use of microservices across multiple projects, are the reason for a significant difference in effort, which is not observed in a monolithic architecture.

Development decisions

Since it’s almost a rule that functionality implemented in a microservice will be used by multiple applications, thorough research is conducted behind every central feature, the integration of a new technology, or cooperation with a third-party service. What we take into consideration are business requirements coming from multiple projects. That way, we can develop a more generic solution that not only meets our current needs but also opens up possibilities for future enhancements.

Have we eliminated monolithic applications entirely? Not. For some products, there is no need for 10 Docker containers running and wasting hardware resources when the final application doesn’t have high-performance requirements coming from its business subject or future growth vision. Some applications have been developed as monolithic, but they still utilize services from our microservices. This is only possible because of sticking to a single framework across the microservices. Services are then imported individually using Git submodules, which help us manage reusability.

Conclusions

Involving more brains in the process leads to a greater number of aspects and ideas being considered on the path to selecting the right tailor-made product. That way, we can provide not only large information systems, but also smaller applications, still benefiting from the reusability of already existing features, and at the same time being more lightweight so that customers don’t have to pay increased costs for hosting and maintenance.

Authors: David Ondrus, Richard Rostecky