Microservices Architecture - Integration Into Workflow (part 2)

In the previous partwe compared the various architecturesand what led us to the decisions that we’ve made. Now let’s move to the changes in operations behind it all and how we adapted our workflow.

Division oflabour

Can one person possess the knowledge of all services? It wouldn’t be sustainable in the long-term and it would lead to mistakes. We’ve taken advantage of the system consisting of smaller parts and assigned responsibility for each service to the core team’s developers.All changes and discussions go through the service’s maintainerwhose role isto create a future vision and ensure its following.

Development

Brainstorming and specification before actual implementation are crucial to minimizing risks ensuing from the reusability of microservices between projects. While code changes can improve a feature in one project, they can break something in another.Preventionis our priority and that’s why the developer has to look at a feature from a higher perspective and choose a safe approach taking in mind that code is not used solely on one specific project. The goal is not only to ensure that existing functionality won’t break but also toimplement a solution generic enoughto at least mitigate the need for breaking changes during future improvements.

Deployments

Extra work in microservice architecture comes mostly from deployments. Since deploying each microservice individually would be ineffective, as part of our DevOps,we Dockerized our solutionsand also automated deployments to our servers.

Backward compatibility

Changes made in new versions can’t break previous ones. Keeping a track of them became even more important,each version must have detailed release notes. In order to be able to determine a state of a project in any past moment, release notes of the product’s version contain information about all microservices included together with their versions, highlighted if a version was changed in a release.

Conclusions

The product’s configurability and reusability open the possibility to save customers’ money and our time,allowing us todeliver solutions fasterandfocus more on business requirementsthan on repeating technical challenges across projects. The scalability of these solutions brings more options for the future growth of customers’ businesses. Updatability brings a wider range of technology to choose from since we can update individually or even change the technology used in one microservice while not affecting others. In the end, the customer gets a product of higher quality, which was developed more efficiently.

Authors:Dávid Ondruš,Richard Roštecký, Tibor Hanesz