From here in enterprise-land, the advantage of microservices isn't architecture, it's resource contention in development. Team A is much less likely to interfere with the work of Team B. Performance etc claims are nonsense, but keeping teams from breaking each other is real.
Assuming they aren't randomly changing unversioned APIs, of course...
I think OP's point was that if your company provides a service, and runs 10 containers to do it, then each container provides 1/10th of the total functionality of the service and is therefore a "deciservice". The joke being that you then can't say you use "microservices" until you've got 10^6 of them.
I meant division of functionality rather than horizontal scaling. For instance, all of Netflix consumer facing features making up the 'Netflix app' is a full 1.0. If we subdivide the functionality into pieces the number of functional pieces determines the fraction of the whole application it provides.
But.. if you have 10^6 total instances I don't think anyone would object to you calling them micro.
Just thought of a naming convention, how many types of microservices do you run: