Certainly there are solid points here, but he doesn't really address the ops side of the equation. I wouldn't write a bunch of microservices on day 1 at a startup with no traffic. I have no doubt it is more complex than a monolith for development & operations. I have no doubt that it introduces a bunch of extra network related overhead..
But what happens when you have serious traffic? One of the main benefits of microservices is splitting the system up for deployment & provisioning. One particular part of the system might be very memory heavy, you can deploy it on a cluster of machines that are spec'ed appropriately. One part of the system might have a relatively constant workload so you can put it on dedicated hardware, while other parts might be cyclical and you can spin up and down instances to match traffic. You can deploy particular components independently which makes releases a much smaller affair.
These things are not impossible with monoliths, but they are easier with microservices. So if the bigger pain point is deployment, scale, etc and not writing new code, then microservices might be a good choice.
In many cases you can do everything you just described by sharding the monolith. Instead of putting 100% of an EmailService on 1 box, put 10% of it on 10 boxes which are also running a web service 10%, an auth service 10%, etc. This will give you logical separation and reduce latency.
Obviously I'm not advocating making a postgres (lots of seeks) server share disks with a hadoop server (lots of spinning). That's silly. I'm advocating sticking with service objects until you have a good reason not to.
Exactly, that seems to be the point of the article. Starting with micro services is plain old over-engineering (reminds me of the original J2EE which I managed to avoid) but using a service object still leaves you free to distribute if and when you need to.
But what happens when you have serious traffic? One of the main benefits of microservices is splitting the system up for deployment & provisioning. One particular part of the system might be very memory heavy, you can deploy it on a cluster of machines that are spec'ed appropriately. One part of the system might have a relatively constant workload so you can put it on dedicated hardware, while other parts might be cyclical and you can spin up and down instances to match traffic. You can deploy particular components independently which makes releases a much smaller affair.
These things are not impossible with monoliths, but they are easier with microservices. So if the bigger pain point is deployment, scale, etc and not writing new code, then microservices might be a good choice.