3 ms·
There are approaches that try to get the best of both worlds. Interestingly, the micro-services architecture is just like that, but it gets a bad reputation for
by gchamonlive 3y ago
There are approaches that try to get the best of both worlds. Interestingly, the micro-services architecture is just like that, but it gets a bad reputation for being easy to devolve into a distributed monolith anti-pattern. Another cool model is maybe the propagator model. The point is maybe to find a way that you don't have to opt either for generic or specific implementations, but have many models of the same domain through different lenses operating cooperatively.
- theamk 3y agoMicroservices are 100% in the "Optimize for flexibility and you'll end up with something that's way too complex" territory. (I am watching this right now at my workplace: team next to us has updated the microservice in repo A, and accidentally made incompatible change, so that integration tests in repo B which make calls to that microservice are now falling. Is it a solvable problem? Certainly. But back before we had microservices, this problem just could not occur, as client/server versions were always identical)
- danielvaughn 3y agoYeah, I've only seen microservices used in a couple of places, but in both cases I felt they were introduced far too early. The first time I saw them was for a 2 page note-taking web app, and it had something like 65 microservices.
- gchamonlive 3y agoThey are definitely not autonomous then. Seems like a distributed monolith. Micro-services are supposed to be simple and independent, but they get crammed with more and more features and complexity and suddenly they just can't be maintained without breaking other parts of the architecture.