[jongjong]

We do use docker compose (thank god) but I also need to run a server from source for most of the microservices in order to modify and debug the code. There are around 20 something containers in practice, 6 pods/services. All interdependent and necessary to run the product (it's a legacy codebase 10+ years old, I joined less than 1 year ago and had nothing to do with architecture decisions). Most features touch on at least 3 to 4 repos/microservices all impossible to decouple. The problem is really opening and launching code across 6 bash consoles some of which require an additional manual authentication step with various cloud providers. I need the ability to restart some independently after making code changes. It's just a very complicated system.

I'm sure the launch can be fully automated but it's kind of at the edge of not worth automating because of how relatively infrequently I need to restart everything... Also the CEO doesn't like to make time for work which doesn't yield visible features for end users.

I actually handed my resignation a month ago, without another job lined up. It became too much haha. Good practice though. Very stressful/annoying.

[branko_d]

I remember, at the turn of the century (was is 2001?) when Microsoft was touting "weak coupling" achievable through "web services" and demoing the support for SOAP in Visual Studio.

To me, that was the strangest idea - how could you "decouple" one service from another if it needs to know what to call, and what information to pass and in what format? Distributing the computing - for performance, or redundancy or security or organizational reasons - that I can understand - but "weak coupling" just never made sense to me.

[jongjong]

Yeah it's a case of falling in love with the solution, not with the problem.

The real reason for tight coupling is simply complex interfaces. That means a range of things; complex function signatures which rely on highly specific parameters (e.g. live instances instead of raw primitive values or raw data) or return complex values instead of raw information "here's what I did". It can also mean complex API parameters and response payloads. Ideally, complex processing should be hidden behind simple interfaces which don't encourage micromanaging the module/service. If the interface is as complex as the processing behind it, that's a design failure and will lead to tight coupling.

Separating code into modules and services may be intended as a way to encourage developers to think about separation of concerns so that they may end up designing simpler interfaces but it doesn't seem to help certain people. Some see it as an opportunity to add even more complexity.

[codr7]

Yep, one of the minor details the micro service fan club don't talk about much.

Firing up the whole mess and debugging one or two of them locally is always a major pain, and god help you if you have no idea which services to stub and which to debug.

[auszeph]

Something I've felt is missing is a developer orchestration layer that makes it really easy to define the set of services like a docker-compose but just as easy to switch implementations between container, source, or remote.

Sometimes you need them all from source to debug across the stack, when you don't you might need a local container to avoid pollution from a test env, sometimes it is just fine to port-forward to a test env and save yourself the local resources.