> Apart from the fact that not everyone uses Visual Studio, "connected services" appears to be something by which you can connect to existing cloud-based services.

Yes. That's the point.

> How does that solve the problem of a mess of interconnected services (...)

I don't think you got the point.

The whole point is that you only need to connect your local deployment to services that are up and running. There is absolutely no need to launch a set of ad-hoc self-contained services to run a service locally and work on it. That is the whole point.

Your whole argument boils down to "don't write shit software" which yeah, fair, but in the real world, the company that you just joined has shit code that evolved over 10 years and has accumulated all sorts of legacy cruft. The idea that there is "absolutely no need to launch a set of ad-hoc self-contained services to run a service locally and work on it" just doesn't match the reality of most places I've worked at. You either got very lucky or you didn't work on complex enough systems.

> Your whole argument boils down to "don't write shit software" (...)

No. My whole argument is open your eyes, and look at what you're doing. Make it make sense.

Does it make sense to launch 50 instances locally to be able do work on a service? No. That's a stupid way of going about a problem.

What would make sense? Launch the services you need to change, of course. Whatever you need to debug, that's what you need to run locally. Everything else you consume it from a cloud environment that's up and running.

That's it. Simple.

If there's something preventing you from doing just that then that's an artiicifal constraint that you created for yourself, and thus that you need to fix. We're talking about things like auth. Once you fix that, go back to square one.

Just FYI, you come across as extremely antagonistic in the way you're conveying your message. The underlying tone seems to be "you're stupid".