Why is deployment coupled? Or rather, why is there a need to synchronize at deployment?
I like the idea of microservices, but I think they're overkill for most systems. By that, I mean that I see the benefits, but I think people discount the skyrocketing development and operational complexities that come with distributing a system. I heard a quote recently that "the best services are extracted from existing systems, not designed up front." I think that's right. Microservices are great IF you need them, and it's really hard to get the bounded contexts right up front with an intuitive, usable API.
Anyway, one of the benefits of microservices is that it forces you to really think about your "public" API. Any decent implementation will have some notion of API versioning. So, team A can truck along with updates, deploy them whenevs, and team B can move to the new version of A when they are ready.
Of course, supporting multiple versions is more work for team A and requires more careful planning of the upgrade path. And there will come a point when team A has to drop support for older versions. "C'mon folks, we're on version 4 of A; everybody has to move to version >=3 within 6 months." But that's just part of having truly isolated services, I think.
I don't see why you couldn't have a similar approach with versioning module API's. Right?
I think your other points are spot on. Things like performance (and error) isolation can be handled through other means, but a services approach (deployed to separate boxes, I'm assuming) makes it cleaner. And it, again, forces you to think about what happens if the dependency is unavailable. Maybe we push updates to a queue, maybe we use some async fetches here with a fallback default if we don't get a response in N MS, etc. Not that you can't do these things in a monolith, but they "feel weird" and require more rigor than most teams can maintain in the face of deadlines, i.e., it would be a whole lot easier to just call this method in this other module. Microservices/SOA force it to happen.
>I heard a quote recently that "the best services are extracted from existing systems, not designed up front." I think that's right.
Damn right. Architecture should be an emergent property of your system and built incrementally. The people who do it up front almost always do it wrong.
I like the idea of microservices, but I think they're overkill for most systems. By that, I mean that I see the benefits, but I think people discount the skyrocketing development and operational complexities that come with distributing a system. I heard a quote recently that "the best services are extracted from existing systems, not designed up front." I think that's right. Microservices are great IF you need them, and it's really hard to get the bounded contexts right up front with an intuitive, usable API.
Anyway, one of the benefits of microservices is that it forces you to really think about your "public" API. Any decent implementation will have some notion of API versioning. So, team A can truck along with updates, deploy them whenevs, and team B can move to the new version of A when they are ready.
Of course, supporting multiple versions is more work for team A and requires more careful planning of the upgrade path. And there will come a point when team A has to drop support for older versions. "C'mon folks, we're on version 4 of A; everybody has to move to version >=3 within 6 months." But that's just part of having truly isolated services, I think.
I don't see why you couldn't have a similar approach with versioning module API's. Right?
I think your other points are spot on. Things like performance (and error) isolation can be handled through other means, but a services approach (deployed to separate boxes, I'm assuming) makes it cleaner. And it, again, forces you to think about what happens if the dependency is unavailable. Maybe we push updates to a queue, maybe we use some async fetches here with a fallback default if we don't get a response in N MS, etc. Not that you can't do these things in a monolith, but they "feel weird" and require more rigor than most teams can maintain in the face of deadlines, i.e., it would be a whole lot easier to just call this method in this other module. Microservices/SOA force it to happen.