This could be titled "If you do things wrong it won't be good".
A lot of his examples are of people doing things poorly or incorrectly. I could make the same arguments about object oriented programming my saying it's bad because someone makes every function a public function.
For example, microservices are absolutely more scalable if done correctly with bulkheading and proper fallbacks and backoffs, and proper monitoring, altering, and scaling.
But those things are hard to do and hard to get right.
Hi, author here - thanks for taking the time read it.
You're not wrong in that this article is meant to point out the pitfalls of the approach, and to advocate for understanding before diving into a particular architecture.
It's meant to give people things to consider before deciding breaking things into "microservices" is the right thing for their engineering org at that time.
I attempted to note several times that my intention was not to say "Microservices are bad", but rather "Please don't dive in before you consider the trade offs". It's not as simple as some folks might have you believe, so I felt it was valuable to have a "lessons learned" type retrospective coming from someone who has been involved in both approaches.
I think it's more of whether or not you need that scale. If you don't have the resources for it to make sense to optimize everything like that, you're probably wasting your time and making things slower by pursuing microservices.
A lot of his examples are of people doing things poorly or incorrectly. I could make the same arguments about object oriented programming my saying it's bad because someone makes every function a public function.
For example, microservices are absolutely more scalable if done correctly with bulkheading and proper fallbacks and backoffs, and proper monitoring, altering, and scaling.
But those things are hard to do and hard to get right.