by Arthur Correa on 7/15/2015
Share on Twitter or Facebook

Lately everywhere I look I read about the Microservice "tax".  Meaning when you implement microservices there are new dynamics involved that your company may not be accustomed to dealing with such as

  • Additional operations overhead - Rather than just focusing on keeping one or two farms of servers up and running to a reasonable SLA you have to instead worry about as many farms as you have microservices.  
  • Communication between services is slower than in process communications and have a higher risk of failure.
  • Data consistency between services

I completely agree with those problems, my problem isn't with the industry recognizing that there are differences with how your Microservices impact your business.  My problem is using the term "tax" to say that.  I can't think of a single instance where a "tax" is a good thing in any way shape or form.  From the time that we first understand what a tax is, we are conditioned to think that taxes are bad and something to be forced upon us.  So by labeling Microservices as having a "tax" it gives people a snap judgement that Microservices are not worth the trouble they incur.  This is a huge problem as it stops people from considering the benefits of a Microservice architecture.

If we are going to say that Microservices have a tax, then lets consider what the Monolith "tax" is.  

  • The monolith grows until it becomes impractical for any engineer to have the necessary familiarity to work on all of it.  A developer can not understand the full business domain the code is representing.
  • It becomes more likely that developers step on each others work and as a result productivity decreases.
  • The entire body of code needs to be released in lockstep resulting in a large amount of testing effort with every release and a larger process overhead to protect the sanctity of the release.

Over time these things can cripple a company until it completely loses the ability to move quickly and react to the market.  It can also prevent a company from truly solving for the customer because tightly bound/shared code between subsystems can be a huge benefit to the subsystem while preventing flexibility for another subsystem to behave in a different way that may be more appropriate for the target user at the time.  (For example the design of a core data structure such as a product may make allow for great flexibility in how data is stored and allow for multiple types of products, but make it difficulty for an end user to actually configure the product that they wish to purchase because of the complexity, and the fact that the tight coupling between configuration and product model does not allow for enough flexibility to adjust to the users' needs).

So while a Microservice does indeed have a "tax", it is important to recognize that a Monolith isn't a free ride as a result.  It has a tax all its own that only grows and gets more expensive with time.





by {{ comment.AuthorName }} on {{ comment.DefaultDateStringFormat }}
{{ comment.Text }}


name:
*
email:
* This is not a valid email.
url:
This is not a valid url.
comment:

2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678