Microservices Architecture - Integration Into Workflow (part 2)
In the previous part, we compared the various architectures and the factors that led us to the decisions we made. Now let’s move to the changes in operations behind it all and how we adapted our workflow.
Division of labor
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, which consists 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 arising 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 must consider a feature from a broader perspective and adopt a safe approach, taking into account 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 process, we Dockerized our solutions and automated deployments to our servers.
Backward compatibility
Changes made in new versions can’t break previous ones. Keeping track of them became even more critical; each version must have detailed release notes. To determine the state of a project at any point in the past, release notes for the product’s version contain information about all microservices included, along with their versions, highlighting any changes made to a version in a release.
Conclusions
The product’s configurability and reusability open up the possibility of saving 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 provides more options for future business growth. Updatability enables a broader range of technology options, as we can update individual components or even change the technology used in one microservice without affecting others. Ultimately, the customer receives a product of higher quality, which was developed more efficiently.
Authors: Dávid Ondruš, Richard Roštecký, Tibor Hanesz
