As they say... when all you have is a hammer, every problem starts looking like a nail.
Nowadays, software engineers barely finish learning basics of their first programming language and they jump in on scaling their first applications they developed while following a tutorial.
It is always better to first exhaust other options like improving basic efficiency and performance of your applications. A single server can do hundreds of thousands or even millions of transactions per second. I have many times seen vast farms of servers doing each at most hundreds or thousands of very simple transactions per second.
A problem is almost always easier to solve and faster to deliver when it is only expected to run on a single server.
And don't start arguing on the need of having multiple servers for redundancy. Properly automated, new service node can spawn within seconds -- maybe couple of your users will see a slight hiccup if you handle it correctly.
The goal here is not to say those practices are bad. What I am trying to say is that engineering is about understanding tradeoffs and making informed decisions.
--
I worked for a large bank which had internal automation platform. It consisted of about 140 "microservices" (apostrophes appropriate here...), 20 servers running those services and about 40 developers.
When I left 3 years later we had 3 servers (bank required hot backups, one within same primary DC and one in secondary DC), just one monolithic app and only 5 developers.
Our job was easier and we were happier than ever before. Reliability improved vastly. And our internal clients started getting the functionality they needed.
Previously, any service call from a client had to jump through multiple layers of "microservices". Vast majority of the application was devoted to communication between nodes, error handling, recovery from strange situations, etc. Once everything rolled into a single service those vanished because there were no longer network calls but method invacations.
And we no longer had to release 140 components and maintain versioning and dependencies between all of them. We only had one component to take core of.
I made a "new component checklist". Whenever somebody wanted to spawn a new component they had to first go through team review and prove the requirement would benefit from being separate component rather than part of existing monolith. No new component was ever created after this was instituted.
Nowadays, software engineers barely finish learning basics of their first programming language and they jump in on scaling their first applications they developed while following a tutorial.
It is always better to first exhaust other options like improving basic efficiency and performance of your applications. A single server can do hundreds of thousands or even millions of transactions per second. I have many times seen vast farms of servers doing each at most hundreds or thousands of very simple transactions per second.
A problem is almost always easier to solve and faster to deliver when it is only expected to run on a single server.
And don't start arguing on the need of having multiple servers for redundancy. Properly automated, new service node can spawn within seconds -- maybe couple of your users will see a slight hiccup if you handle it correctly.
The goal here is not to say those practices are bad. What I am trying to say is that engineering is about understanding tradeoffs and making informed decisions.
--
I worked for a large bank which had internal automation platform. It consisted of about 140 "microservices" (apostrophes appropriate here...), 20 servers running those services and about 40 developers.
When I left 3 years later we had 3 servers (bank required hot backups, one within same primary DC and one in secondary DC), just one monolithic app and only 5 developers.
Our job was easier and we were happier than ever before. Reliability improved vastly. And our internal clients started getting the functionality they needed.
Previously, any service call from a client had to jump through multiple layers of "microservices". Vast majority of the application was devoted to communication between nodes, error handling, recovery from strange situations, etc. Once everything rolled into a single service those vanished because there were no longer network calls but method invacations.
And we no longer had to release 140 components and maintain versioning and dependencies between all of them. We only had one component to take core of.
I made a "new component checklist". Whenever somebody wanted to spawn a new component they had to first go through team review and prove the requirement would benefit from being separate component rather than part of existing monolith. No new component was ever created after this was instituted.
Yep, they def did not need microservices...