[jedberg]

If that's the experience then you're doing services wrong. Each service should have its own datastore and a single API. The interface between services should be a single connection.

There should be maybe one meeting where the caller defines what they need the service to return to them.

[10000truths]

The problem with this is that you have to be really damned careful how you split things up. If your separate data stores end up having to be joined together later on because some new business feature requires them to be cross-referenced, you're painted into one of two corners:

1. Merge the two services (and their data stores) into one and cause havoc downstream of either service

2. Burn through your network latency/throughput budget trying to reinvent a DB join across RPC boundaries (and god forbid if you can't batch multiple lookups in a single API call!)

[dahwolf]

Exactly. Software developers will never learn that the separation of concerns is a myth. In reality, UI, business logic and data are deeply entangled. Hence, moving these things apart makes everything worse.

[ris58h]

> There should be maybe one meeting

Oh sweet summer child

[jedberg]

I do not like appeal to authority either. But based on my experience, most of these issues were resolved in one to two meetings (I said maybe one, after all).

The team that needs data goes to the team that has that data and says "can you make an API that vends the data that I need?". Then they make it. And then maybe there is another meeting with a follow up, or perhaps an email asking for the data to be presented slightly differently.

But if you come to a team with a good use case and some examples, it shouldn't be too hard for them to create an API that vends the data appropriately.

This of course is all predicated on a good microservices architecture where you already have systems in place to handle API discovery and communication between services and proper data separation.

[sethammons]

I'm willing to bet you do not know who you replied to. Their resume is more impressive than most.

[ris58h]

https://en.wikipedia.org/wiki/Argument_from_authority

[RugnirViking]

your "argument" was literally just telling the person that they were naive for thinking things could ever be handled by one meeting.

turns out, they inarguably have a whole lot of experience at high levels in the biggest companies in the world. Either they're straight up lying, or it is in fact possible to resolve things with a single meeting. Why wouldn't that be the case?

[ris58h]

I can tell you many other wisdoms: code should be tested, code shouldn't contain bugs, everything should be done before deadline, etc.

The thing is in reality it's not that easy.

> Either they're straight up lying, or it is in fact possible to resolve things with a single meeting.

Something can be done in a single meeting but not everything. But you gave me only two alternatives without anything between so there is another useful link for you https://en.m.wikipedia.org/wiki/False_dilemma

[sethammons]

oh sweet summer child; have you not heard of the fallacy fallacy?

snark aside, just because a logical fallacy exists in an argument, it does not mean the argument is untrue. My experience echoes jedburg's - services should maintain their own datastore and provide api access. This allows them to be decoupled and allows the service to alter their datastore as needed. When multiple services leverage the same underlying datastore, things can get overly coupled. This becomes increasingly important as organizations grow because the coupling means more overhead communicating and aligning around changes.

Jedburg is an expert because he has seen this happen in multiple companies. I have too, but I don't have the speaking/consulting breadth of experience that they have. Credentialing and appeals to authority work because we are squishy humans and we can't verify everything so we lean in on others. That does not mean that authorities are always right, but when their experience and advice mirrors other's experience and advice, there is something to it.

And for the record, in public companies (two of them), I have exactly seen this play out: a well defined api that does not allow others to muddle in their datastore leading to _single_ meetings where new functionality is discussed and agreed upon and later implemented. I have also experienced the pain of multiple teams sharing a datastore when the datastore now needs to be altered which led to dozens of meetings across several teams and a rollout plan that was measured in months and quarters due to coordination needs. I can firmly say that the latter is a much harder (and expensive!) problem to solve in each case I've experienced.