Although one point I'd like to contest is the first "pro" which is you can use a different language for each service. We tried this approach and it failed fantastically. You're right about the cons, it becomes un-maintable.
We had 3 microservices that we maintained on our team, one in Java, one in Ruby and one in Node. We very quickly realized we needed to stick to one, in order to share code, stop the context switching, logging issues, etc.
The communication piece is something that solid monoliths should practice as well (as is it touched on in the article). Calling an 3rd party API without a timeout is not a great idea (to be it lightly), monolith or microservice.
Thought-provoking nevertheless, thank you for sharing.
Although one point I'd like to contest is the first "pro" which is you can use a different language for each service. We tried this approach and it failed fantastically. You're right about the cons, it becomes un-maintable.
We had 3 microservices that we maintained on our team, one in Java, one in Ruby and one in Node. We very quickly realized we needed to stick to one, in order to share code, stop the context switching, logging issues, etc.
The communication piece is something that solid monoliths should practice as well (as is it touched on in the article). Calling an 3rd party API without a timeout is not a great idea (to be it lightly), monolith or microservice.
Thought-provoking nevertheless, thank you for sharing.