2 ms·

This misses some of the main reason Microservices are nice, it’s much easier to change code that isn’t woven throughout a code base. Microservices make the boun

This misses some of the main reason Microservices are nice, it’s much easier to change code that isn’t woven throughout a code base. Microservices make the boundary between units defined and forces API design on those boundaries. Yes, you can properly design these abstractions without a service boundary, but having the forcing function makes it required.

mixedCase 6y ago
> Microservices make the boundary between units defined and forces API design on those boundaries No it doesn't. Google "distributed monolith" to read some horror stories. Bad architecture, or good architecture without enough quality control over time will cause these issues one way or another. There's no silver bullet for this.
allan_s 6y ago
> Microservices make the boundary between units defined and forces API design on those boundaries until one engineer say "hmmm why adding a new endpoint in their service while we could simply connect our microservice to their database directly"
- yellowapple 6y ago
  I mean, this ain't entirely unreasonable. Considering the database to be its own "service" is perfectly valid, and you can control what things a given client can do through users/roles, constraints, triggers, etc., which you absolutely should be doing anyway. That is: the database's job ain't just to store the data, but also to control access to it, and ensure the validity of it. A lot of applications seem to only do the first part and rely on the application layer to handle access control and validation, and then the engineers developing these apps wonder why the data's a tangled mess.