This is what I'm getting at though. If you work inside a MANGA company or something, then I imagine your life is probably dominated by navigating a huge byzanti

This is what I'm getting at though. If you work inside a MANGA company or something, then I imagine your life is probably dominated by navigating a huge byzantine ecosystem of services with uptime demands and tons of legacy code. Presumably there's lots of $$ riding on evolving those systems incrementally. In this frothing, roiling context where the only constant is change, I can see how it will often make sense to expand components beyond their original scope. Ergo, your services should be named whimsically. Fine. But many software projects are. not. that. That's really all I'm getting at. This web service developer bubble annoys me because they never feel any onus to introduce themselves in their blogposts and caveat their opinionated recommendations with the context they're coming from. In my world of robotics, just making a random family of services with non-descript names is a bad idea. The services in the system should have roles, and if the temptation arises to add functionality beyond that role, it probably means you need to step back and do some thinking about why that happened. Also: I know you were just making a rhetorical point, but notice that your example is still clearly some web service that we're assumed to be running :)