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 judgment 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 let's 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 other's 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, leaving it unable to move quickly or react to the market. It can also prevent a company from truly solving for the customer because tightly coupled/shared code between subsystems can be a huge benefit to one subsystem while preventing another subsystem from behaving differently, which 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.