Microservices and it’s release management

Here I am supposed to about a discussion that I had with a few industry experts about microservices and it’s release management.

Nowadays, modern software solutions are software-as-a-service (SAAS) or platform-as-a-service(PAAS) and complex distributed systems. Therefore, multiple teams are responsible for their own bounded contexts. Hence, there are facts to think about as a company grows and teams increase in size, however, monolith development becomes more difficult. Soon, the system can no longer fit in a manageable with a single operational team as there are too many moving parts, so things slow down.

Let's look at microservice architecture in high-level

Characteristics of microservice architecture

image from internet

Benefits of microservices?

By looking at the characteristics of the microservice architecture, Choosing a microservice for a new project needs a bit of effort as it needs to design and implement infrastructure and pipelines. But there are benefits of it over the monolith architecture. let's look at the main benefits below.

Scalability: Teams can scale in/out (CPU/Memory) one or a few services of the distributed system based on traffic for a particular service.

Availability: We can isolate one or a few services. Therefore we can avoid single failure points by deploying critical services to multiple availability zones.

Frequent releases: We can release a few or more services as we want without impacting others. Therefore the time to market is less.

Autonomous teams/smaller teams: We can have context bounded smaller teams and make them autonomous. Therefore it benefits with less communication overhead and more collaboration.

Independent Tech selection: Teams are free to use a comfortable tech stack. This leads to avoiding high infrastructure costs over monolith architecture.

Microservice architecture vs monolithic architecture

by looking at the below diagram, you can see how software gets complicated with the microservice architecture. But also easily manageable.

image: https://pintea.net/

Note: You can see, as services are divided into tiny modules but UI is still packed together. the UI modules also can manage with tiny modules via micro-frontend architecture and let's talk about it in a separate article.

Is microservice replace the monolithic?

No, microservice not replaced monolith. Both monolith and microservice are valid approaches. I feel like monolith approach is natural approach to starting a project when we do not know where we don’t know product roadmap or technical roadmap. We can ignore design mistakes and re-design when we have monolith. But monolith will be a bottleneck when you want to scale application, reduce cost of your services and time to market and hotfixes of your large distributed software.

Deployment of microservices

The common approach of the microservices architecture is one microservice, one repository. Why? microservice architecture defined as small, bounded context, loosely coupled, independently deployable autonomous service.

But when you have hundreds of microservices, each services has its own repository (multi-repository), CICD pipeline, versioning scheme and different teams are releasing different versions.

different cicd pipelines for each microservices

Therefore, it is difficult to keep track of release versions and what if you want to track application level release version? But I do not think this is matter since end users are not interested to know module versions behinde the scene of most of the PASS or SASS systems. Also, most release helper tools such as circle ci, gitlab cicd can configure to indicate that which versions deployed to which environment. Therefore, teams can easily managed it behind the scenes.

Manager releases with multiple microservices

when you have multple services and repositories for each of them, you can have artifact repositories to manage them. If you maintain released repository seperately it will help you to release them in custom environment such as on-premises services as well.

release steps of microservice

1. Each microservice build will tag with their own version.
2. Publish the service build to the artifact repository.
3. Build docker image and map the microservice version to docker image.
4. publish the release build to the dev or QA environment. This usually go with integration test, acceptance test and manual test.
5. Publish the release to release repository and production environment.

Note: Changelog and old builds hotfix identification goes after step 4 above.

manage with artifact repositories and release repositories

Why Monorepos?

Monorepo is a antipattern where single shared repository for codebases and assets(libraries). This is breaking “single responsibility principle” in microservice architecture.

With the complexity of the micro-service deployment architecture and the release management, Monorepo concept came into the picture. Mostly, this concept arise from the organizations that they have hundreds of microservices, but they release product periodically and non-continouse deliveries to production. Because they need to keep changelog and deployment in a simplyfied approach.

image: https://jconsoftware.com/

But, I believe monorepo approach leads to microservices to feel like monolith. But, I feel like, we need to forcus on product roadmap and technical roadmap at least for next 5 years also the forcast for the application usage, network traffic and critical services scalability if we are a product company with PAAS or SAAS. Otherwise we are endup with another monolith giant.

But monorepo will lead for:

1. Simple release process as multiple modules share the single CICD pipeline and testing.
2. Release can be simple with managing versions collectively.
3. Collective integration and acceptance test coverage.
4. Single git history and changelog.

But on the other hand, there are some drawbacks as well.

1. Since multiple projects in same repository, tight coupling may slowdown releases.
2. All commits into the one repository may leads to codebase maintainability.
3. CICD pipeline may have some repetitive parts for each modules in the repositiry.
4. If there is any issue in one project, we might need to revert other project features as well as it released together in a same version.

Conclusion

There is no single better answer fit for every software solution. One shared repo and global CICD pipe line would work for some situations like startup or new project. On the other hand, one repo and one CICD pipeline for each service will be the best approach for distributed systems where we need continious deployment independently and scale in/out seperately.

Rather we having monorepo for all modules in a company, my suggession is, The teams can have monorepo approach for their own maintaining modules regardsless of independent or dependent each other and release collectively.

However, selection of the approach is based on our organizational and project needs. Therefore, it will be a long discussion among architects, techleads and devops teams as well.