3 ms·

I like this way of thinking about things. I do wonder if this is one of those areas where the utility/reward is very unevenly distributed across team skill leve

I like this way of thinking about things. I do wonder if this is one of those areas where the utility/reward is very unevenly distributed across team skill levels; if your team is very disciplined, and has strong alignment on architecture and internal APIs, then there are some significant benefits to testing a monolithic system (e.g. I can mock time and still test the full monolithic system end-to-end). However if the team is undisciplined (or the org is just too big to achieve tight alignment), then having some enforced architectural boundaries (bounded contexts) inside which the complexity is capped will at least limit the scope of poor architecture inside a specific service, and generally puts a floor on unintended coupling. There's another dimension too though; I think that microservices require a much higher level of devops / CI/CD maturity to do well. So the maximum value might come from poorly aligned but very ops-savvy orgs, whereas the minimal value would come from highly aligned and disciplined orgs that don't have a strong devops/automation skillset. Not sure which dimension is more important though.

dagss 8y ago
You have an assumption that the initial design/division of responsibility into microservices was perfect. If not, then no, the unintended coupling is not limited to within a service, it will find its way to the API between the services.
JamesBarney 8y ago
I think the article nails it on the head in the first paragraph >Change their database schema. >Release their code to production quickly and often. >Use development tools like programming languages or data stores of their choice. >Make their own trade-offs between computing resources and developer productivity. >Have a preference for maintenance/monitoring of their functionality. Every single one of those is an organizational problem. Microservices are fantastic for solving the problem of "very large organization trying to manage multiple releases from multiple teams with lots of interconnecting dependencies". But they solve that problem with a giant flaming chainsaw with greased up handle. It works but don't use it unless you have to.

dagss 8y ago

You have an assumption that the initial design/division of responsibility into microservices was perfect. If not, then no, the unintended coupling is not limited to within a service, it will find its way to the API between the services.

JamesBarney 8y ago

I think the article nails it on the head in the first paragraph >Change their database schema. >Release their code to production quickly and often. >Use development tools like programming languages or data stores of their choice. >Make their own trade-offs between computing resources and developer productivity. >Have a preference for maintenance/monitoring of their functionality. Every single one of those is an organizational problem. Microservices are fantastic for solving the problem of "very large organization trying to manage multiple releases from multiple teams with lots of interconnecting dependencies". But they solve that problem with a giant flaming chainsaw with greased up handle. It works but don't use it unless you have to.