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

During a few years long experience with microservices, we came across multiple 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 possible to still be able to build 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, applications using microservices are indirectly bound to each other since they use the same services. Major and minor changes discussed in regular weekly meetings and also in the R&D communication channel help to keep all team members informed. Hindsight is also important, so the end-of-year summary meeting is where things done in the past year are discussed and where the plan for the next year is also developed. 

Cooperation 

A developer implementing a change has to ensure its backward compatibility to not negatively affect any other application using the service. If a new major version of module is released, a migration guide is written down. 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 microservices being used in multiple projects, are the reason of a significant difference in effort which is not seen in a monolithic architecture. 

Development decisions 

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

Did we cut off monolithic applications entirely? Definitely 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 still use 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 that are helping us with reusability management. 

Conclusions 

Involving more brains in the process leads to more aspects and ideas being processed on the path to the right choice for each tailor-made product. That way, we are able to 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 light-weight so that customers don’t have to pay increased costs for hosting and maintenance. 

Authors: David Ondrus, Richard Rostecky