[rezonant]

I missed the part where the person describes that they have a very large development team which justified a non-monolithic architecture. True microservices (with independent development and inter-service contracts) are a reflection of the makeup and scale of the development team. Using true microservices for performance reasons is a misnomer these days: A modular monolith (one codebase that can be deployed into multiple independently scalable services) makes much more sense when the dev team is not big enough to justify the added overhead, but some aspects of the application require independent horizontal scaling.

[Arcanum-XIII]

I'm currently working in an environment where the company I work for has a quite limited IT department that has responsibilities covering hardware and software. One of our investor has a bigger headcount for IT only that's bigger than our company size and we're trying to integrate with them... they're on micro service. It's funny because even though it seemed very well engineered, it create a bureaucratic environment. That means it's very hard to have the right people on the table, they're slow to react to any change (if they even can)... For a small change, they requested 3 months. On our side, if a dev is available, this would have been solved in a week.

Neither situation is good: we're under stress for ressources availability, when they're stuck in Kafka's world. Last week I learned that two different team ingest some of our data — which is fine, except that we moved to an API and only the first team use it. The second team was not aware that it exist (well, forgot about it).

I don't know what the good solution when you reach this kind of headcount would be. As a PM/PO, I'm baffled about this kind of complexity. My experience lead me to think that no one is managing that currently... it's kind of working, till it falls, hard.

[zdragnar]

The problem you describe is one of a lack of ownership. I'm at a company that has a quite small engineering team, but other departments have their own services (dashboards that read from our database, marketing CRM, etc) which means any change at all to any database table requires bringing together multiple departments to make sure nobody gets upset by the change.

It's easier to have a single owner at a smaller scale (something we should do) but even at a company with a large engineering team, there needs to be someone whose responsibility is to manage dependencies. Otherwise, it falls back to design by committee, and that's how you end up in your situation: nobody actually knows how anything works, and there is literally no way to find out.

[pc86]

Exactly this - they needs months to respond to "small" changes because nobody knows who at the day is responsible for a given service. They probably need to time to filter the request through the product office, find out which service(s) are affected, find the dev team(s) responsible for those service(s), and beg/harass/bribe the EM(s) for those teams to get the work scheduled.

If they had documented service contracts with ownership information attached they could probably have the GP's team communicate directly with the service devs and it would likely go a lot smoother.

[hermanradtke]

> missed the part where the person describes that they have a very large development team which justified a non-monolithic architecture.

I am not agreeing with the author, but they said it here:

> the number of pull requests produced daily by a few hundred developers was so large

[rezonant]

Oh, thanks. I still don't necessarily agree with the author either, but at least there's a passing justification.

[claytongulick]

> True microservices (with independent development and inter-service contracts) are a reflection of the makeup and scale of the development team.

Conway's Law [1]:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?

[1] https://en.m.wikipedia.org/wiki/Conway%27s_law

[dvfjsdhgfv]

It's a long article but they do mention it a few times.