Microservices Pitfalls — How Advantages Can End Up Making Your Life Harder | by Ivelina Yordanova | May, 2022

Each fashionable expertise ought to be applied cautiously

Photograph by T.H. Chia on Unsplash

Microservices have been the way in which to go for some time now and so they supply some plain advantages. I’m not right here to inform you this mannequin is unsuitable.. no, that might be wild. Nonetheless, I’ve been on a kick of studying about exceptions to the principles, in regards to the limitations of what we name “finest practices” in coding and software program structure. One factor that got here up, time and again, was the monolith vs the microservices debate.

It’s probably not an enormous dialogue, most individuals acknowledge some great benefits of the microservices strategy, however I did come throughout some fascinating factors towards it or somewhat dangers in the way in which these are applied. I’ve additionally witnessed a whole lot of these dangers flip into actuality and develop into a burden for the engineers. Like every little thing in life, the mannequin ought to be taken with a grain of salt and balanced towards the real-world context and limitations in addition to the enterprise specifics and targets. So, I wished to sum up a number of the key pitfalls I discovered and noticed myself.

Let’s first take a look at what are the explanations to maneuver away from a monolith and all of the “marketed” advantages of the microservices structure.

A monolithic utility is one the place all of the code, even when cut up into logical modules, is taken into account a single challenge, typically the code lives in a single repository and the construct additionally produces a single deployable, executable artefact. Normally, when speaking about this sort of utility folks consider enterprise functions with these 3 elements — a database, a consumer interface, and a server-side utility, though that’s not crucial.

Nicely, that sounds good, doesn’t it? There are some apparent benefits to this:

  • ease of growth and deployment — you could have all of the code in a single place so reusing the code is straightforward, testing end-to-end is straightforward and deploying method much less hustle
  • efficiency — that is typically quoted as a bonus of monoliths and it’s true that communication between the entrance finish and again finish is extra environment friendly if it doesn’t have to contain calls over the community by HTTP API or every other method. Nonetheless, for functions the place that’s probably not essential the argument will get weaker.

Then again, there have to be a whole lot of disadvantages to a monolithic utility if that’s not the go-to anymore, proper?

  • tight coupling — irrespective of how exhausting you attempt to hold some type of logical separation in your code, it’s inevitable that you find yourself with at the very least considerably coupled modules.
  • increased complexity — typically the monolith repositories flip right into a labyrinth for brand spanking new and even skilled builders. That makes it exhausting to make adjustments as a result of the influence of these adjustments is unclear. Even when the code base is properly examined and it prevents most bugs from leaking into manufacturing, the time an engineer would take to implement the change and debug any potential check failures can be doubled
  • bug influence — each time your protected internet of assessments fails you and a bug does find yourself in a launch, then that might have an effect on the entire utility and render an essential enterprise service unusable
  • slower construct and startup occasions — since all of your code is in a single place it’s fairly slower to construct and sometimes additionally slower to startup the appliance
  • scaling is tough — the structure sort of pushes you in direction of vertical scaling since horizontal one requires syncing up situations’ knowledge and that defeats the purpose of a monolith
  • innovation is difficult, borderline not possible — having a single code base normally means a restricted variety of appropriate languages and frameworks, so experimentation and innovation is a nightmare that nobody desires to cope with

Discover the distinction within the variety of cons vs execs? Nicely, that’s the explanation folks have moved away from this mannequin.

So, now you can preempt what a number of the advantages of microservices now are, however let’s sum it up.

The objective of microservices is to have smaller, single-purpose providers which talk with one another by a REST, RPC or message-based API. Every microservice makes use of its personal database and the uncovered API can truly serve a number of different providers. This brings a whole lot of advantages to the event crew and the enterprise:

  • free coupling — every service is a separate code base, that hides the enterprise logic and solely exposes an API. Modifications within the microservice don’t have an effect on every other that communicates with it (if finished proper and backward compatibility is taken into account)
  • diminished complexity — for a developer to make a change in a single microservice they don’t essentially must be accustomed to the entire system, which consequently reduces dev time
  • bug influence — any problem in manufacturing is confined to the precise microservice and all the remaining speaking with it may well implement mechanisms to cope with that in an inexpensive method
  • sooner construct and startup time — simply by lowering the quantity of code and complexity
  • simpler and extra environment friendly scaling — as a result of each microservice has it’s personal database and obligations, it may be scaled horizontally method simpler. What’s extra, with the separation in place you’ll be able to solely scale the bits that flip into bottlenecks as a substitute of the entire system
  • simple to innovate and experiment — following up on the primary level — adjustments are clear for the opposite microservices — it’s simple emigrate one microservice to a brand new framework or language with out having to think about compatibility and impact on different modules

That each one sounds good, however microservices are usually not all rainbows and roses, it’s not a magic bullet. There may be nonetheless loads to be taken into consideration if you go within the path — each technical and non-technical elements ought to be thought of as a result of in any other case, you’ll be able to find yourself with dozens and dozens of very tiny microservices that make your life as a developer a hell.

Let’s see what are a few of these.


Wait, wasn’t this one of many execs? Sure, it was..and it’s…to a degree. As a result of the microservices talk by the community, they require a extra advanced setup and depend on the pace of the API they use. This may imply that sooner or later including extra situations of your service doesn’t end result within the anticipated improve in efficiency however finally even the alternative.

Bug influence

One other benefit which may flip towards you. Regardless that a failing app gained’t by definition take down all the remaining with it, this doesn’t all the time imply it gained’t have an effect on the power of the remaining to operate. It is a professional function that closely depends on the design of your system and the goodwill, abilities, or reminiscence of the groups accountable for the microservices speaking with the failing one. What I imply is, if you happen to create microservices only for the sake of claiming you could have a microservice structure with out desirous about how these talk and what’s the influence of every particular person failing, then you definately may as properly hold all of it a monolith.

If service A fails and the remainder of the providers don’t have any method of fairly dealing with a failure in A, then they fail as properly and all of it simply propagates again to the highest. Moreover, even when there’s a method to do this, it’s completely as much as the builders in that crew to recollect to deal with the failure and do it proper. That is nice from an engineering perspective — you care just for the bit you develop, nonetheless, it would lead to extra time and few iterations till it’s finished proper and this may have an effect on the consumer’s expertise.

Code tidiness

Sure, microservices imply much less code in a single repository, however no that doesn’t essentially imply clear and environment friendly code. When you could have completely different providers being developed and maintained by completely different groups, you may find yourself with completely different languages and frameworks which aren’t appropriate, so you find yourself rewriting the identical code. Duplication like this might sound harmless in a few providers however think about having essential bits of code being rewritten in 3–4–5 methods after which having to make a change in all. The coordination between groups that this may require will improve time to manufacturing.. loads.

It’s additionally not preferrred to go too excessive within the different path by making a single widespread lib for each little bit of enterprise logic. It is a good concept, however taken a bit too far may be an issue. You may find yourself with a library that tries to accommodate slight variations within the necessities of a number of providers and with this flip into a very sophisticated and exhausting to take care of challenge, the place the influence of every change isn’t clear and it’s exhausting to check…sounds acquainted huh? Moreover, think about having to replace all microservices dependencies individually with a view to apply a wanted change from the library? It won’t solely take effort and time but additionally a whole lot of coordination and calculations the place it may well go first, then subsequent, what would that imply and so forth…


It looks like including new options in a microservice structure can be simple…and it may be, however not all the time. Typically, a brand new fearure’s necessities may be more durable to attain with microservices — both as a result of it includes a number of providers and groups that have to now put all their different priorities inline and work collectively or as a result of within the microservices context this function would power you to implement workaround and with that add technical debt and pointless complexity.

Syncing states

It’s advisable that every microservice has its personal database with a view to preserve free coupling and independence for the dev groups sustaining it. Nonetheless, what occurs if 2 or extra providers must be in sync about their view of the world? What occurs if A updates its database and B and C don’t?

Investigating points throughout a number of functions and making sense of the timeline is a painful train and requires builders to really know loads if not all in regards to the implementation specifics of the opposite apps concerned, which defeats the aim of separation of obligations.

What’s extra, the destructive influence of spending an excessive amount of effort and time to mitigate these points programmatically may overweigh the advantages of getting these 3 providers as one monolith repo. This comes again to the significance of the design and contemplating the communication and failure dealing with not simply blindly following the pattern for the sake of it.


This one is a sort of amalgamation of some factors talked about already in a couple of locations, particularly — making use of adjustments to all microservices is a effort and time consuming train. It’s boring and repetitive and actually brings down the spirit of the poor developer tasked with this.

Modifications may contain updating dependencies, logical adjustments, migrating to a unique third get together service, deployment, monitoring or alerting mechanism. That is particularly essential and will actually be thought of fastidiously in small corporations/groups, which deserve its personal part.

Firm/Staff dimension

If a person crew of three–4 builders must help and actively prolong greater than 10 microservices, I’d exit on a limb and say this can be a difficulty. That will be an instance the place you as a crew have to weigh good architectural practices and traits vs their sensible day-to-day implications. You’ll must stability your individual bandwidth with doing issues in a advisable method. For those who go forward and resolve to work with 10 microservices, then this may closely cut back your throughput and gradual the enterprise down.

You may have to compromise on some design selections with a view to give your self some respiratory room. That doesn’t essentially imply dangerous code, not when you find yourself making these selections consciously and with a plan for the longer term. You would hold some logically-related bits collectively however preserve free coupling between the modules in a method that can allow you to cut up this up each time the crew and firm broaden.

Ultimately, it’s all about having good reasoning to help your architectural and implementation selections and making that apparent together with your design, code, and documentation. That’s extraordinarily essential for the longer term growth of the providers and can assist information or inspire future selections as a result of it’s too typically true that the folks designing, writing, and sustaining service and all completely different folks at completely different levels of their careers and sometimes too their time within the firm doesn’t overlap. Be sure to can again your selections and don’t simply soar on the present fashionable finest practices prepare with out contemplating your particular context.

Thanks for studying 🙂

More Posts