| Some counter points, especially with fallacy #1: > Fallacy #1: Cleaner Code > “You don’t need to introduce a network boundary as an excuse to write better code.” I see this all the time as the argument against microservices: "but if you are just disciplined you don't need them". It seems pretty clear to me that a large body of programming history has shown that it is incredibly difficult for a whole team to be disciplined all the time. If everyone was perfect drivers we wouldn't need seat belts. Some artificial "barriers" can be very helpful to tackle people working in the real world. > Fallacy #2: It’s Easier > “Distributed transactions are never easy.” This argument I'll buy, but there is a lot of really good work going into orchestration like kubernetes which makes a lot of these concerns much lower. > Fallacy #3: It’s Faster > “You could gain a lot of performance in a monolith by simply applying a little extra discipline.” Again with the discipline...
But another point he makes really misses the mark: > Additionally, many of these stories about performance gains are actually touting the benefits of a new language or technology stack entirely When you have microservices it allows you to use the best tool for the job for each individual service. If you have a Java monolith and you want to add new functionality that say GoLang would be better suited for, chances are you are still going to develop it in Java because it has to fit with the rest of the monolith. His example counters his claim. > Fallacy #4: Simple for Engineers > “A bunch of engineers working in isolated codebases leads to ‘not my problem’ syndrome.” This is pretty subjective and I really think depends on culture and buy-in. Almost all these same things could be said about a well architected SOA monolith. > Fallacy #5: Better for Scalability > “You can scale a microservice outward just as easily as you can scale a monolith.” Again his example, seems to counter his claim. Yes you could segregate the API calls to your monolith but you are still going to have the overhead of those un-used APIs. Unless you are doing some really clever dynamic loading that code is still going to be loaded into your executable package at the very least redundantly increasing RAM load, making for wasted resource utilization (which converts to real dollar and cents in the VM world). Additionally the author completely ignores any potential start-up costs of needing to load a larger monolith over a smaller microservice. |
Can you explain more how kubernetes help with distributed transactions? I was aware they are more of a management system for microservices, not something that handles db transactions.
I've found splitting a monolith into microservices very painful because it prevents you from easily having all-or-nothing db commit semantics. It's a lot easier to wrap your entire RPC/API endpoint in a single db transaction than it is to issue multiple commits (e.g. an RPC to a microservice that writes) and worry about the large number of states that can result if your endpoint crashes mid-way.