There is a difference between "loose coupling" and "tight coupling". Components/modules should be loosely coupled - regardless if they run within the same process or not. Component/module interfaces should be carefully designed so that coupling is loose.
I think this is too strong of a definition because then everything is a monolith.
We need a definition of what it means for two services to communicate while being “uncoupled”. I think “are versioned independently” or “don’t have to be upgraded in parallel” meets the bar.
> I think this is too strong of a definition because then everything is a monolith.
Yes... exactly. More things are monoliths than we want to admit.
> We need a definition of what it means for two services to communicate while being “uncoupled”
Take a dead simple example: an application server that talks to an in-house video encoding micro-service
Even if that video encoding service only has a single really well designed endpoint, there's STILL coupling between the application server and the video encoding service.
Just because we've replaced a method call with an HTTP request doesn't mean things aren't coupled anymore.
Sure -- you may be able to deploy certain changes to your video encoding service without changing your application service. However, you need to be keenly aware of what changes are compatible with existing application servers and which are not and that adds complexity and cognitive load. Maybe it's worth it in some cases. In many cases, it's not.
If we go with your definition then my app is a monolith with S3 and SQS which doesn't help me pinpoint where the potentially bad architecture thing is.
yeah -- your app is coupled to those services. I've definitely written code before that depended on a third party API only to have that API break on me.
Granted, this is not something to worry about with S3 or SQS.
> If we go with your definition then my app is a monolith with S3 and SQS
okay sure, I agree that calling your app a monolith with S3 and SQS is ridiculous.
The point is that we all may think that we're writing another S3 or SQS when we write our own micro-services. However, in practice maintaining a stable, backwards compatible, public API like that is quite costly and we usually end up re-implementing function calls as HTTP requests and then calling it "loosely coupled".
I don't think a monolith is defined by coupling. I think it's defined by being a single deployment of custom code covering many domains/including many kinds of functionalities, rather than many deployments.
Your definition of uncoupled makes some sense. It's a good starting place at the very least.