Istio Service Mesh Beyond Kubernetes
Nov 17, 2020 • 9 min read
Nov 17, 2020 • 9 min read
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.
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.
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.
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:
There may be multiple root causes for the monolithic release process:
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.
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:
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.
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.