What on earth is a "large" framework? What does the size of a framework (by whatever metric) has to do with the "micro" which refers to a slice of the domain the service is taking care of.
A group I work with opted for a microservices approach, a few years later they have 47 tightly coupled "microservices" that have to be deployed all together or they break.
"But we can deploy services independently" they say, "we can scale these services independently too!", "We can finally scale our development team!"
Years later: no services are scaled independently. Deployments are a mess. Most deploys end up having to be lock-stop deploys. Issues are incredibly hard to track down because of complex network interactions. For some reason 7 of them are written in Rust and only 1 guy knows Rust. Stack traces become almost worthless. You find yourself having to piece together log files across tons of services to track down issues. You have hundreds of Jenkins jobs for deploying services.
If your business logic is contained in another framework and your microservice just call a subset of those functions, is it really a microservice ?
I entirely agree. The framework jab, along with the gratuitous and entirely unrelated assertion regarding containers, just lower the expectation that the article has any point worth reading, specially considering that afterwards the author decided to include "having tests" as a characteristic of his concept.