Avoid the monolithic release process when migrating to microservices

The trend of implementing and migrating to microservices isn’t new. The industry is full of war stories where companies invested a lot of time, money, and effort to migrate microservices architectures but were never able to realize the full benefits. Every company’s journey is unique and mistakes that companies make are unique too. However, there are some mistakes that are remarkably common across many organizations and can be avoided with a little key knowledge.

In this article, we will describe one of the biggest mistakes companies make, which is quite subtle and hence often overlooked. The mistake is limiting microservices guidelines to architecture, while leaving the monolithic change management and release process. Technically the microservices architecture is implemented, but the speed to market is still slow. This results in a high cost of infrastructure and a non-scalable development process. What’s worse, teams often don’t even realize they’re making this mistake, which can leave a sour taste following the migration.

How microservices migrations overlook the release process

For the simplest way of describing how and why this mistake is made, let’s take a look at the modernization journey in the technology department of the Acme company. Imagine that one department is responsible for the digital customer experience platform. The platform was built some time ago with a monolithic architecture. It has been reliably serving its needs, helping the company grow an online presence, and delivering stable digital revenue growth. New features and modules have been steadily added to the codebase and both the platform and the team developing it gradually increased.

At some point in time, the cost of continued customization and extension got too high, the speed to market got prohibitively slow, and the team made the decision to re-platform to keep up with business demand. Microservices architecture was chosen as the new standard due to its promise to scale development, facilitate continuous delivery, and increase speed to market.

At this point, it doesn’t matter what approach the team chose to implement the new architecture. It could’ve been strangling the monolith with gradual decoupling of microservices. It could’ve been a big bang re-platforming. It also doesn’t matter whether the platform was built in the cloud or on-premise, or what specific technology stack was chosen.

But in the end, the team followed all the microservices architecture best practices and implemented a new platform:

Each microservice was nicely designed as a bounded context.

• The 12-factor methodology was religiously followed.
• The microservices were communicating only via API or messaging.
• Each service was using its own isolated database and no data sharing was allowed.
• Even front-end UI was split into a number of independent applications.
• Containers and Kubernetes were used for deployment.
• Infrastructure-as-code and immutable infrastructure best practices were used.
• The continuous integration process was fully automated.
• Even the teams were split to take responsibility for their own microservices.

Everything was done right and by the book. And still, every change took days or weeks and required the involvement of most of the teams. Infrastructure costs increased, test environments were unstable, tests were brittle, and development productivity decreased instead of increasing.

How to recognize the monolithic release process

The mistake that is often made is that migration to microservices doesn’t affect the release and change management process. Even if it is fully automated, both requirements are being tested and deployed in production as one monolithic system.

The monolithic release process is easy to identify:

• Every change in any service requires full and lengthy integration testing in non-production environments before deploying to production.
• Continuous integration and delivery pipeline for each service include provisioning integration environments with all upstream and downstream dependencies of the service.
• Many integration environments exist for functional and performance testing of the system as a whole.

There may be multiple root causes for the monolithic release process:

• The migration to microservices is driven by the development team without involving QA, release management, and change management teams.
• There is a single product manager or one QA team that defines requirements for new features and implements tests for the system.
• The majority of tests are implemented as the integration or end-to-end tests on the level of UI and front-end applications.
• Development teams create common or shared libraries, and most microservices and front-end applications depend on these libraries. Typically these libraries introduce hard-to-track build-time dependencies when each change in the library requires rebuilding and releasing all dependent microservices.
• Backward compatibility of APIs is not enforced and development teams frequently introduce breaking changes to APIs.

Even with a microservices architecture, the monolithic release process leads to slow speed to market, a long continuous delivery pipeline, brittle environments and tests, and high non-production infrastructure costs.

How to fix the monolithic release process

Understanding the issue and identifying the root causes behind it are the first steps in fixing the monolithic release process. Improvements will directly follow from dealing with the specific root causes.

Some specific steps that need to be taken are:

• Including product management, release engineering, and quality assurance teams in the effort to redesign the process.
• Breaking business analysts, test engineers, deployment engineers, and operations engineers into service development teams, thus creating self-sufficient cross-functional pods.
• Shifting testing left by implementing most of the functional and performance testing at the levels of individual services and developing stubs and mocks for upstream dependencies.
• Taking API compatibility seriously and implementing proper enforcement and testing procedures.

It is normal however if some level of integration testing still remains. Some end-to-end verification is expected on the level of UI and front-end applications. In order to increase speed to market, minimize the number of environments, and reduce infrastructure costs without sacrificing quality and stability, the lightweight continuous delivery pipeline can be implemented.

The lightweight continuous delivery process can be designed to satisfy all enterprise change management policies. It includes “shifting production left” or “shifting testing right”, depending on your frame of reference. Moving integration and user acceptance testing to the production environment can be implemented in such a way that it will satisfy all enterprise change management policies without disrupting production traffic and sacrificing quality. Techniques like service mesh, test data management, and smart test design should be implemented.

Conclusion

Microservices architecture has its value even with the monolithic change management process. However, moving the release process to microservices continuous delivery when each service or application can be released independently greatly increases speed to market, enables scalability of the development organization while decreasing infrastructure costs, and raises development productivity.

At Grid Dynamics, we’ve helped numerous Fortune-1000 enterprises migrate to a microservices architecture and release process to recognize the maximum value from their microservices migrations. Feel free to reach out to us if you’d like to learn more.