Microservices are not Micro; They are Vertical

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.

More Resources

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!