Microservices Architecture - Integration Into Workflow (part 2)

In the previous part we compared the various architectures and 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 of labour

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 maintainer whose role is to 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. Prevention is 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 to implement a solution generic enough to 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 solutions and 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 to deliver solutions faster and focus more on business requirements than 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