3 ms·

Scaling businesses, yes. All inter-team communication becoming API contracts enables autonomy in each team. As long as you stick to the contract you can deploy

Scaling businesses, yes. All inter-team communication becoming API contracts enables autonomy in each team. As long as you stick to the contract you can deploy when you want, make the changes you want, etc. without having to bog yourself down in endless meetings with other teams to ensure your changes won't break theirs. In a small organization this may not matter, but in a large organization you might not even know who to talk to, so it becomes a practical necessity to have clearer boundaries between teams in order to keep more people manageable. What you describe sounds more like Service Oriented Architecture (SOA). SOA is one way – some might say the best way – to keep the aforementioned boundaries strict, so it does often go hand in hand with microservices. But technically you could achieve microservices using shared libraries or even logically separated areas in the same codebase. Of course, the more opportunity you give someone to break the boundaries, the more likely they will which is why especially the last one is bound to fall down in practice.

ameliaquining 4y ago
You could have build-time-enforced restrictions on interdependencies if you wanted to do an SOA-like thing without the runtime overhead, if you wanted to. The real issue is that "logically separated areas in the same codebase" doesn't solve the release-management part of the problem. If you have a monolith, then each team can autonomously control how their code behaves at head, but they all have to conform to the centrally-dictated schedule for when those changes roll out in production. Often this doesn't matter, but sometimes it does, and then you have to have lots of meetings again. Shared libraries are somewhat better about this, assuming that it's reasonably cheap to restart instances of the monolith, but some kinds of rollout strategies work better if you can divert which release to use at the request level rather than the instance level. Also, in a lot of languages, the tooling surrounding shared libraries just isn't as good.

ameliaquining 4y ago

You could have build-time-enforced restrictions on interdependencies if you wanted to do an SOA-like thing without the runtime overhead, if you wanted to. The real issue is that "logically separated areas in the same codebase" doesn't solve the release-management part of the problem. If you have a monolith, then each team can autonomously control how their code behaves at head, but they all have to conform to the centrally-dictated schedule for when those changes roll out in production. Often this doesn't matter, but sometimes it does, and then you have to have lots of meetings again. Shared libraries are somewhat better about this, assuming that it's reasonably cheap to restart instances of the monolith, but some kinds of rollout strategies work better if you can divert which release to use at the request level rather than the instance level. Also, in a lot of languages, the tooling surrounding shared libraries just isn't as good.