So many organizations set out to implement microservices for solving problems. Unfortunately, most have a misconception about what microservices actually solve which leads to an improper implementation. This is a costly mistake with many pitfalls.
The Wrong Name
The name microservices implies that each service is small. While possible to be small, the goal isn’t to minimize the size of the service as much as possible (hence the anti-pattern term nanoservices). Instead, the goal is to minimize the scope of the service while maximizing the services ownership. What does that mean exactly? This means that the service should serve one business purpose (authentication service, analytics service, etc… - though the boundaries can change based on a particular scenario). And it also means that the service should own its tasks from front to back; meaning that it makes as few external requests as possible – and certainly not to any other services that it doesn’t need to. I would even go so far as to say that calling other services of your own could be a potential indication of improper services boundaries which might mean it’s time to rethink your design and reduce latency introduced by http and the (costly) scaling limitations that can introduce.
Allow me to propose a new name: Vertical Services. Perhaps this would mislead far fewer organizations and save many more jobs.
Trending Tech Can’t Save You
The orgs that implement microservices and still choose not to use vertical services usually think they can walk into the issues they are creating and come out on the other side better than others that have gone before them because they are going to use Docker and Kubernetes. Or maybe they are going to go serverless and use Azure Functions or AWS Lambdas. Bad news! This isn’t a problem of pairing the wrong technologies with microservices; it’s a problem of physics. Instead of performing a set of operations in CPU, memory, and maybe reaching out to a DB or disk, you are instead reaching out over HTTP to another service. That is going to be a significant performance hit on each request. And if your services depend on other services, you will end up with a spiderweb of HTTP requests that take several seconds to return at best and an archetecture that doesn’t lend itself to easy debugging or tracing. To scale, you are at the mercy of your Cloud Provider’s network and the size of your wallet for having significantly more machines since your bottleneck is the network connection between each machine.
We know that in terms of latency, cache < memory < disk < network. The speed of an electron isn’t changing anytime soon, so we should embrace this knowledge and avoid compounding bottlenecks caused by chaining services.
There are plenty of great resources out there. Here are some of my favorites that should assist you in launching your microservices journey:
This article describes an effective implementation: https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices
This article gives a deeper dive into the implementation details: https://docs.microsoft.com/en-us/azure/architecture/microservices/index
Jimmy Bogard on what can go wrong and how to avoid it:
Martin Fowler on effective implementations:
If you have come this fare and you are thirsty for more, you can always reach out to me. I love guiding, architecting, and implementing effective microservices!