Changing the game — Strategies for transitioning to micro-services and nano-services

created by nightcafe

In recent years, “microservices” and “nanoservices” have become major buzzwords. I’ve collaborated with many teams who have actively implemented these, breaking down their code from (occasionally monolithic) services into extremely small microservices. Kubernetes and serverless frameworks provided the right infrastructure to do this swiftly, efficiently, and easily. However, this approach has led to an increase in our maintenance and costs.

Imagine running a global company that is spread across numerous digital regions where the same system is replicated.

this is our application

This solution might offer the best performance, but it comes with high costs and complex maintenance. For instance, how would you roll out an update? One region at a time? Conduct tests in different regions? It gets complicated, but we want a uniform experience across all regions. So, what can we modify?

Each region contains two apps (A and B), a database, and static files.

Suggested solution: Push-pull mechanism within a primary region

alternative push\pull mechanism

We still have three regions, but now we have one primary and two non-primary regions. When a non-primary region is deployed, it begins by gathering all necessary data (like configurations, basic assets, and required application tables) from the primary region and caches them locally. This means they won’t need to be collected again until the next environment restart.

The primary region then needs to cache everything and store the changes within the cache. When a new version is deployed, the primary region is responsible for pushing all the changes to the non-primary regions and monitoring both its own deployment and the deployment of changes. As for caching on the primary region, it must be done via a cache server for persistence, while the non-primary region can use a local or remote cache.

Pros:

• Reduced maintenance
• Less traffic
• No single point of failure
• Works well for both push and pull changes

Cons:

• Dependence on primary region
• Each region needs to register at the primary region to receive updates

Suggested solution: SDK or libraries

alternative using SDK or lib

Previously, we had one primary region that we could use for deployment and to change rollout. But what if we could transform Application B from a calculation application to an SDK or library (or most of its logic) and migrate some of it into Application A? Then all static files could be moved into a single cache or file storage under one CDN for fast access and caching, resulting in better resolution and less maintenance.

We could further improve this by using configuration management to decide which SDK is deployed where. If a region fails, we can redirect all traffic from that region to another, maintaining the user experience. As for content stored locally within each region, it’s necessary to replicate it for regional backup and then global backup for permissible data. (Some data is restricted by laws such as tax or privacy regulations.)

Pros:

• No primary failure
• Caching mechanism can be used on a wider scale
• Costs less
• A|B Testing

Cons:

• Need to manage the plugins
• More complex monitoring
• Maintenance of caching is more complex

Choosing a solution

I’ve presented two different ideas here for managing code deployment in a global company. Both have their advantages and disadvantages, and neither is perfect. However, they offer different perspectives and could be adapted or improved upon to best suit your specific needs. The choice is up to you.

Happy coding!