Microservices introduction
Microservices are characterized by highly decoupled, but cohesive sets of self-contained services each running in its process. Having this level of encapsulation has clear value in design and implementation routines such as testability and individual scalability of such services. It also has some challenges that are not as commonplace in monoliths.
Most startups begin with a small set of functionality(see The Pareto principle/80-20 rule). At this scale, it is easy(and often wise) to select a monolithic architecture. It appears straightforward to add features to and most importantly has clear deployment costs.
As startups begin to grow, the ease of adding features to the monolith becomes the very cause of its deterioration. As more and more endpoints are added, they tend to create a dependency map that would be most reminiscent of our favorite Italian dish.
It is usually at this point, that a well-meaning member of the team recommends that the startup adopt a microservices approach. It sounds reasonable. However, there are a few challenges to consider.
The expense! Consider the following components of the cost:
Extraction of existing functionality into microservices(migration and development)
Cost of managing a distributed architecture (all the components that make microservices manageable)
Cost of managing a diversely skilled team (it sounds fun that everyone can write code in their favorite language, however, startup CTOs tend to favor their ability to still read code they understand)
Also, it would be wise to consider these risks:
Loss of existing staff who might not prefer the move. Tons of legacy features are dependent on existing staff members who have very intimate knowledge of the codebase. Admittedly, it’s not a nice place to be in.
An initial loss of velocity/productivity. This could be fatal(often a catch-22 when you must break the monolith but your business can’t afford the loss of velocity) if your business is not properly informed or configured to allow for such an initial loss.
Components of a microservices architecture
You could always deploy your services individually and be done at that. However, this would not account for one important factor. ‘The fallacies of distributed computing’(https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
To account for and solve these challenges, microservices usually require the following set of tools and techniques:
Versioned Configuration management
Service registration and discovery
Client-side load balancing
Managing Service to service calls
Circuit breakers
Routing
Some of these techniques have their roots in 12-factor apps(https://12factor.net/). It would be worth to look them up.
Migration Roadmap
Considering the challenges and associated costs I propose that such a migration be managed carefully and often in a staged manner. A rough roadmap might look as follows:
Design improvements to the monolith: Make incremental improvements to reduce dependency between structural elements of your code.
Componentization of the monolith: If your language/toolchain permits make components that can be developed and modularized.
Using a uniform toolset(language/platform) to develop individual service projects: Break out your services into individual code projects that may or may not use the same frameworks, but have similar runtime requirements. Suppose you have a legacy monolith that uses obsolete technology. In that case, it might be better to use new language versions to develop these services, while having strict endpoint contracts with your monolith.
Deploying these individual services to an architectural monolith(design as microservice, deploy as a monolith): This might seem counterintuitive, however, a large cost of having a monolith is deployment. It would be wise to technology to deploy your services in the same environment, although, it comes at the cost of losing some independence testability.
Moving to individual service deployments: This is the final stage before moving to a true microservices architecture. At this stage, your services are independently deployed however, they are not tied together by tools for service registration and discovery.
Moving to a ‘managed’ microservice architecture: This is where the architecture employs tools and techniques discussed earlier.