Microservices vs The World

“The goal of software architecture is to minimize the human resources required to build and maintain the required system.”

Robert C. Martin

In the last 5 years, before the start of a new project, microservices have been pretty much the topic on every architectural conversation. The idea is great, small, independent, cohesive, services that can be implemented, tested, maintained and released individually without much impact on the rest of the system. Microservices are then the holy grail of architectures all positives and almost zero negatives. If that is the case, why in the last 2-3 years our holy grail is getting bad press? Some engineers even suggest that a monolith is better. I am sensing the anger in you while reading this blog, asking yourselves how can a monolith be better? Well, it all comes down to pros and cons and how the business is structured.

Let’s start with the structure of the business, microservices are independent and cohesive which means that a team can develop services in silos and do not need to coordinate extensively with other teams since there are no dependencies. The teams can pick their programming language, databases, CI/CD process etc. Why I am saying all these? Apart from the word silo everything else sounds great and you have already found solutions for the silo-like documentation, service discovery, controlling what technology to be used etc… Regardless of your solutions, the uniqueness of the service will require the original team to change and maintain it since they will be more effective. You cannot have everyone in a department to be experts in every programming language and database system. If we accept that each service is a silo then each team needs to maintain that service for life, which brings us back to the business model, do you accept the cost that each team will be maintaining a service for life? In a youtube video, the VP of Spotify said they have 500 teams and 750 services which validates what I just described.


So, let’s say that you work for the new Spotify/Netflix and you have the funds to assign up to 2 services per team. What are the pros then?

  • Independent deployments are simple, each service can be built and deployed in isolation and if it has zero dependencies it can be even tested.
  • Fault isolation can be achieved since the services are independent.
  • The focused teams can build domain knowledge and have a good understanding of the codebase since they have specialized in a very specific area.
  • Engineering freedom each team can pick any technology out there.
  • The Code surface area can be expanded easily which means a department can be scaled as the company grows.

But there is no such thing as a free lunch, so what are the cons.

  • Simple Mathematics, if the ratio of services over teams is not balanced then the software development will become unsustainable.
  • Small tasks feel gigantic, let’s assume that you need to change your monitoring/auth provider or add a step in your CI/CD with microservices you will need to repeat the same task multiple times.
  • The Complexity of the system is only kept in control by the number of teams that you have. Which means if the business is not growing as fast the complexity of the system will grow exponentially.
  • Impossible to outsource since the new teams are only for a short time, that means the ownership of their services would need to be absorbed by existing teams, which will add additional load since the outsource teams may have used a brand new tech stack.
  • Impossible refactoring since each service is in its own repository and the modern tools mainly work on a single repository. Which means great news, grep and the  1980’s tools are back.
  • DRY is less likely to be applied.
  • Network latency exists even with the big cloud providers, if a client request, needs lets say 10 internal requests and for every request you will need atleast 100ms then those small delays starts to add up.
  • Team skills will be a challenge since a highly distributed system would be more complex. Be prepared to compete and pay for the best of the best.
  • Security will be hard to apply since the system has a high degree of entropy.

At this point if you still believe microservices are the way forward, here are some Microservices smells so they can be addressed before they become an issue.

  • The teams do not understand and do not own the business domain.
  • There are more services than teams.
  • There are more repos than teams.
  • Services talk to each other extensively (even through a messaging bus).
  • Services share data storages.
  • APIs are not consistent.
  • Failures are not detected in critical systems.
  • Lack of containers.
  • Lack of standards (versions, languages, frameworks etc.)
  • Cross-cutting concerns have to be implemented for every service.
  • Services are not idempotent.

I would love the idea of getting all these smells right from day 1 but unfortunately, microservices are by far the most challenging and costly architecture, my advice at this point is to ask:

  • Do you need a highly distributed system?
  • Can you do a monolith first?
  • Is there a better compromise like microservices architecture?
  • Is N-Tier architecture a better approach?

Microservices architecture on paper sounds amazing but unless the business as a whole is not committed to it, then your department will end up with low morale, low productivity, and tones of code debt.


11 thoughts on “Microservices vs The World

  1. Thanks for the interesting post!
    We are dealing with the microservice architecture a bit different. The overall architecture is still maintained by a single architect. And he is responsible for the code quality, static code analysis, making rules for test coverage, CI/CD. For that we have the same programming language, CI/CD, build system, and code quality for the whole project. Yet within each microservice we have different repos, libraries used, data storages. It becomes easy to switch teams or refactor, or I believe even to outsource (but we haven’t tried it).
    The only concern of your that could apply is network latency or failure detections. But you can always introduce other microservices for caches or load balancers.
    N-tier architecture or a monolith would not be a better approach.

    Liked by 1 person

  2. “Tones of code debt” should be the new corporate line by Dulux 😉

    Excellent article; the list of smells is particularly useful. I think people get a bit myopic around emergent or evolving complexity. There’s a great tendency to favour reducing complexity locally (as that’s often a code problem) without considering the effect on global complexity (like the coordination issues mentioned). You see it everywhere, from fine-grained refactoring to architecture-level decisions.


  3. I could have written this article… nearly 5 years ago… I keep repeating to my colleagues and friends – use microservices only if you don’t have any other choice.

    Liked by 1 person

  4. Of course there are pros and cons in microservices architecture, as there are in almost every technology and software architecture approach. You need one (or more) very skilled architect(s) in order to cut your system in reasonable services. Done right the pros of a microservices architecture will overweight the cons by far. Your system will be much more maintainable, testable and scalable. Besides, you will be much more flexible in releasing new versions of your services.
    As usual, the main point is HOW sth. is done.


  5. We have both, a monolith system, and a distributed system. Speaking of low morale and low productivity, the monolith takes over 1hr in CI/CD to build, test and deploy (with builds occasionally failing for random reasons). Multiple (10+) teams compete for build slots, priorities to push to production etc. Not to mention agony of reverting or fixing changes if team A pushes work of team B to prod by accident. The distributed system has many interdependencies and a known single point of failure so sometimes stirs some commotion but on the other hand allows the teams to be much more independent and agile. However, it is too much distributed – some “micro” services could have been merged with others. From my experience it comes down to things like better planning, architecture, code design and using the correct technologies to solve the correct problem. When done right, it can save a lot of time and improve morale / productivity. Regardless of what the system is.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s