4 ms·

> I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. There's a few things in play IMO. One is

• insanitybit 3y ago
  It doesn't lack a definition, there's lots of people talking about this. In general you'll find something like "a small service that solves one problem within a single bounded context". > It's definitely preferable to have a poorly-built monolith than poorly-built microservice architectures. I don't know about "definitely" at all. Having worked with some horrible monoliths, I really don't think I agree. Microservices can be done poorly but at minimum there's a fundamental isolation of components. If you don't have any isolation of components it was never even close to microservices/SoA, at which point, is it really a fair criticism?
  • mjr00 3y ago
    > It doesn't lack a definition, there's lots of people talking about this. In general you'll find something like "a small service that solves one problem within a single bounded context". How small is small? Even within this comment section there are people talking about a single developer being the sole maintainer of multiple microservices. I'm a strong advocate of (micro?)service architecture but I would never recommend doing the "all behavior is 100-line lambda functions" approach. A horrible monolith vs horrible microservices is subjective, of course, but IMO having everything self-contained to one repository, one collection of app servers, etc. at least gives you some hope of salvation, often by building new functionality in separate services, ironically. Horrible microservices that violate data boundaries, i.e. multiple services sharing a database which is a sadly common mistake, is a much harder problem to solve. (both are bad, of course!)
    • insanitybit 3y ago
      "Small" is a relative term, and not an ideal one, but what it generally means is "no larger than is needed" - that is, if you have one concrete solution within a bounded context, "small" is the code necessary to implement that solution. It's not a matter of LOC. > IMO having everything self-contained to one repository I highly recommend keeping all microservices in a single repository. It's even more important in a microservice world to ensure that you can update dependencies across your organization atomically. > Horrible microservices that violate data boundaries, i.e. multiple services sharing a database which is a sadly common mistake, is a much harder problem to solve. But that's not microservices. Maybe this is in and of itself an issue of microservice architecture, the fact that people think they're implementing microservices when they're actually just doing SoA, but microservice architecture would absolutely not include multiple services with a single database, that would not be microservices. So I think the criticism would be "people find it hard to actually implement microservices" and not "microservice architecture leads to these problems", because microservice architecture is going to steer you away from multiple services using one database.
      • sally_glance 3y ago
        A little off topic but there are even more sinister patterns than the shared database which some architects are actively advocating for, like 1. The "data service" layer, which (if done improperly) is basically just a worse SQL implemented on top of HTTP but still centralised. Though now you can claim it's a shared service instead of a DB. 2. The "fat cache" database - especially common in strongly event-based systems. Basically every service decides to store whatever it needs from events to have lower latency access for common data. Sounds great but in practice leads to (undocumented) duplicate data, which theoretically should be synchronised but since those service-local mirror DBs are usually introduced without central coordination it's bound to desync at some point.