In a previous article I talked about the benefits of Microservices.
While Microservices are a popular choice for many organisations who either work on or are hoping to move to highly distributed systems, there are some important challenges to bear in mind.
Network calls increase
When you move from a monolithic solution to a microservices approach your network calls between services will increase exponentially.
More importantly you will need to move from a synchronous approach to communication to an asynchronous approach. (You cannot rely on services being available, as this breaks the requirement for isolation)
There are a couple of different schools of thought in this area. Some people in the industry believe that direct calls are okay when they help solve a business need. I personally disagree with this, that doesn’t meant that it is never a viable option though.
Either way the network between your services will be more congested and your services need to deal with network latency between them and be prepared to handle situations, where they do not get a response in time or where a service is down.
Services deploying frequently and evolving independently
You need to create an environment where services can update in isolation and evolve in isolation.
This sounds like an easy thing to do in principle, but it is difficult – certainly when moving across from a legacy solution.
Service isolation is paramount here.
Service Discovery, Versioning & Routing
Orchestrators like Kubernetes, Swarm, or Service Fabric can handle some of these areas for you.
Depending on what hosting method you choose for your services you may need to implement some or all of these services yourself though and you need to ensure consistency across your organisation in terms of the approach.
More about the challenges you need to bear in mind when moving to Microservices.