Agree with the author that Microservices are harder to operate in certain aspects. For example latency tracing with Microservices is harder when you have many services to check latency through, what service call caused the latency. Doing error tracing with Microservices is also harder because now you have to follow a web request through many different Microservices. Microservices in some cases may have worse performance than a monolith. With Microservices data no longer does in local memory or local cache, you have to traverse the network through an API calls to fetch data. Imagine that you have a monolith that can look up data in a hash table that is one memory/cache access versus a micro service network call. In the micro service you have to make a network call for a memory lookup. A memory access may take between 0.5ns-100ns versus a network call may take 10000ns. That Microservices may be between 20000 times to a 100 times slower accessing remote memory in another Microservice than accessing it locally in the same monoliths memory. Thus one could argue that in some cases performance are worse with Microservices than a monolith. You can still scale stateless monoliths buy putting a load balancer in front of the monolith. There is also increased overhead of running Microservices, instead of having one Java process/NodeJS process for a monolith you may have several hundred nodeJS processes Microservices running in Docker containers. Each NodeJS process takes memory for NodeJS itself. An important aspect of Microservices which are good is that they allow a part of the system to be restarted independently instead of restarting a whole monolith. https://radlab.cs.berkeley.edu/people/fox/static/pubs/pdf/j0.... Sometimes you may want to rewrite a component that is also much easier to rewrite with Micro services. Compare a Mainframe from the 60s-80s running a monotlith without unit testing / integration testing versus modern micro services with testing. Replacing parts or the whole main frame monolith will be very very scary.
However I would argue Microservices has been done before the idea is not new. Microservices is a realization of the same principle as that of UNIX/Linux. This is called the UNIX philosophy, Write one program that do one thing well.
Make the output of one program the input of the other one.
Microservices are not a new idea, its the reimplementation of the UNIX philosophy for the web.
"Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features"."
compare with
Microservice definition by wikipedia
"The services are small - fine-grained to perform a single function."
Latency Numbers Every Programmer Should Know https://gist.github.com/jboner/2841832
However I would argue Microservices has been done before the idea is not new. Microservices is a realization of the same principle as that of UNIX/Linux. This is called the UNIX philosophy, Write one program that do one thing well. Make the output of one program the input of the other one.
Microservices are not a new idea, its the reimplementation of the UNIX philosophy for the web.
The UNIX philosophy https://en.wikipedia.org/wiki/Unix_philosophy
"Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features"." compare with Microservice definition by wikipedia "The services are small - fine-grained to perform a single function."
Improving reliaility with recursive reboots, Microservices on Kubernetes are at least implementing micro reboots in case of component failure. https://radlab.cs.berkeley.edu/people/fox/static/pubs/pdf/j0...
Like most tech Micro services probably follow the Hype cycle https://en.wikipedia.org/wiki/Hype_cycle