Microservices are not hype. Anything that lets you scale your code without having to rethink how you write code and while reducing cost is pretty amazing. If anything, I'd say microservices are underutilized these days, because it is often easier to start a new holistic system and architecture it for microservices than to convert aging systems to use a new model.
Look at their example:
Example 3: Microservices
Step 1: Big monolith application scales hard. There is a point when we can break them down into services. It will be easier to scale in terms of req/sec and easier to scale across multiple teams.
Step 2: Hype keywords: scalability, loose coupling, monolith.
Okay...sure. Req/sec and infinite scalability are a great reason to use microservices. Definitely worth having your brand new codebase use a microservice architecture. Whether your older codebase could benefit requires a cost/benefit analysis.
Step 3: Let’s rewrite all to services! We have a ‘spaghetti code’ because we have a monolith architecture! We need to rewrite everything to microservices!
You need a Step 2.5 with a cost/benefit analysis. How much time will it take to convert the code base? Do we really care about scaling to infinity? Where do we think we actually need to scale to in practice and how much benefit will we see from the architecture change? Etc...
Step 4: Shit! It is now way slower to develop the app, difficult to deploy and we spend a lot of time tracking bugs across multiple systems.
This step is kind of just wrong. Once converted most microarchitectures are actually faster to develop for if you've done things right, because you don't have to worry as much about scaling. The first question they ask you as a developer in your first job interview as a developer is probably about Big-O and time complexity. However, this has always mattered more for server-side operations than for client-side operations. If a server does something 1000 times slightly inefficiently, that inefficiency ads up. If an iPhone does something 1 times slightly inefficiently, it likely matters a lot less. In a microarchitecture model, the server is more like the client in the previous example, as each individual instance spawns and does its thing 1 time. Big-O still matters, but not as much.
Beyond this, problems deploying and problems tracking bugs across multiple systems likely have little to do with the microarchitecture itself. In my experience, microarchitectures can be as easy and are often easier to deploy than existing physical-hardware-based systems. For example, if you have many servers or many shards to deploy to, you may only have one deploy point in a microarchitecture or one production and one integration deploy point instead of a system of many servers. It's often easier!
Step 5: Microservices require a lot of devops skills in the team and with right investment might pay off as a way to scale the system and team. Before you reach serious scale issues it’s an overinvestment. Microservices are extracted not written. You must be this tall to use microservices.
Any new thing requires some learning or skill.
"Before you reach serious scale issues it’s an overinvestment." That sentence is wrong though. When you have no code yet it is often a great choice to use a microservice-based architecture, requires very little investment and can both save money and allow easy scaling. When you have existing code, but scaling and cost are huge priorities, it often is a smart investment of time. It's only in the middle stages where you have a large code-base you have to convert and don't actually need the scaling where it could be an overinvestment.