3 ms·
> Great, then a new US comes in that changes the intention and you enjoy the pleasure of changing the interface. That's not a microservices problem, not even a
by rumanator 6y ago
> Great, then a new US comes in that changes the intention and you enjoy the pleasure of changing the interface.
That's not a microservices problem, not even a software architecture problem. That's at best a project management problem. In fact, pretty much every single engineering project there ever was would struggle to meet any form of neck-breaking change in design requirements.
- quonn 6y agoBut with microservices you have more supposed independent interfaces. With a more monolithic approach you might just change a system internally and deploy it. Internal interfaces are generally easy to adapt.
- rumanator 6y ago> But with microservices you have more supposed independent interfaces. You don't. You have more services accessed over a network, and might not have control over all services. But that's already par for the course in nonoliths. If you were to refactor your components by changing classes around (say, a major version update in a dependency) while not updating the components that used them then you would also have problems. That's why versioning and service discovery and HATEOAS are a thing.
- quonn 6y agoBut the compiler will find that. It‘s very different from deploying services. (And I‘ve been doing both, for years.)