Of course real life is messy and plenty of people realized writing small single purpose services was valuable, and plenty of people build giant "microservices" that have nothing to do with the original term and are just badly constructed monoliths.
You have observed that other services also have that quality. Indeed. Nowhere did I say, "all services with decoupled deployment are microservices".
Yes there is. A service is a very generic concept to the point it's only relevant as a high-level concept.
The concept of a microservice makes all the sense in the world if you look back to where we came from: web services. When compared with all the work and requirements and complications of using SOAP and WSDL and UDDI and everything around, just sending small JSON payloads around, and the ability to peel off smaller services leveraging that architecture approach, was a far lighter and uncomplicated way of doing business.
I mean, the name microservices becomes obvious once you look back and all that you see is macroservices.
I really hate that word when used without further definition.
Which makes the term "microservice" even weirder, given that any microservice is going to be bigger than a single subroutine.
I think they were saying something more aligned with your opinion than you read it as.
Microservices tended towards a single runtime per service, ensuring the deployment lifecycle was tied to the build lifecycle and thus allowing for independent evolution.
At the beginning Microservice was generally viewed as more granular than SOA, though that’s been backed off of.
But then you’d get some that would make bizarre claims like a microservices must be under 100 lines of code. :shrug:
Cockroft’s Rule of Thumb
Can complete a service in two weeks or less Completed = coded, tested, and in production • Fits in “one or two developers’ heads”
At that rate you quickly hit hundreds of services.