4 ms·

Another way to look at this is microservices reduce the blast radius of problems.

by jayd16 4y ago

gadflyinyoureye 4y ago
Sometimes. If the services are all interrelated, you’re as dead on the water with Microservices was you would be in a monolith.
- mixermachine 4y ago
  Sure depends on the architecture. When the auth service is down, everything else should be down. But when the "optional feature" service is down, a core component should be unaffected by that. Split up services where it makes sense and don't over do it. That's how I design my projects.
  - varsketiz 4y ago
    For many websites, there is considerable amount of content that should be available if auth is down. Think eshops, news portals, etc.
  - vinay_ys 4y ago
    When the auth service is down, only new authentications should fail. Existing auth sessions should continue to function just fine. This exact failure mode occured at Google in early 2021 which caused a fairly big outage but not as big as it could have been because of this design choice.
- threeseed 4y ago
  You design your microservices so that they gracefully degrade. So if a database service is not available you simply return stale, cached data until the service is back up.
- deleted 4y ago
  [deleted]
noogle 4y ago
How so? If functionality A is critical to functionality B, how will wrapping it in an HTTP call (microservices) reduce the damage from breaking functionality A? I can see an advantage regarding resource hogging, but the flip side is the extra point of failure of network calls in microservices. Not saying which is better, but deployment is orthogonal to logical dependence and correctness.
- danielheath 4y ago
  Most features in a modern app are not critical functionality, though. For instance, in a shopping site, why should a crash in the recommendations engine result in a non-functional webpage (rather than a working purchase page with no recommendations)? Personally I think microservices start to make sense when you have several hundred developers (an environment I'm currently keen to never enter again - $work has 5 devs and might one day have 6).
  - noogle 4y ago
    That makes sense. I am still trying to understand why does it differ between a monolith and microservices. The app in the monolith can make the call to non-critical functionalities time-limited and fault-tolerant, just like a network call has a time-out and can return nothing (in a simplified manner, it can wrap that call with a timer and an exception handler). I agree that microservices are suitable for large organization, where the organization practically has multiple products (which could be purchased from a vendor or sold to another company).
    - Karrot_Kream 4y ago
      If your monolithic service OOMs, hits a large GC pause causing dependent requests to time out, locks a shared file descriptor, or a bunch of other things then the monolithic service as a whole can hit a fault or stall even if other threads/tasks are still executing. While classes of errors like OOMs go away when multiple processes are executing.
      - 4y ago

Another way to look at this is microservices reduce the blast radius of problems.

by jayd16 4y ago

Another way to look at this is microservices reduce the blast radius of problems.

Sometimes. If the services are all interrelated, you’re as dead on the water with Microservices was you would be in a monolith.

mixermachine 4y ago
Sure depends on the architecture. When the auth service is down, everything else should be down. But when the "optional feature" service is down, a core component should be unaffected by that. Split up services where it makes sense and don't over do it. That's how I design my projects.
- varsketiz 4y ago
  For many websites, there is considerable amount of content that should be available if auth is down. Think eshops, news portals, etc.
- vinay_ys 4y ago
  When the auth service is down, only new authentications should fail. Existing auth sessions should continue to function just fine. This exact failure mode occured at Google in early 2021 which caused a fairly big outage but not as big as it could have been because of this design choice.
threeseed 4y ago
You design your microservices so that they gracefully degrade. So if a database service is not available you simply return stale, cached data until the service is back up.
deleted 4y ago
[deleted]

noogle 4y ago

How so? If functionality A is critical to functionality B, how will wrapping it in an HTTP call (microservices) reduce the damage from breaking functionality A? I can see an advantage regarding resource hogging, but the flip side is the extra point of failure of network calls in microservices. Not saying which is better, but deployment is orthogonal to logical dependence and correctness.

danielheath 4y ago
Most features in a modern app are not critical functionality, though. For instance, in a shopping site, why should a crash in the recommendations engine result in a non-functional webpage (rather than a working purchase page with no recommendations)? Personally I think microservices start to make sense when you have several hundred developers (an environment I'm currently keen to never enter again - $work has 5 devs and might one day have 6).
- noogle 4y ago
  That makes sense. I am still trying to understand why does it differ between a monolith and microservices. The app in the monolith can make the call to non-critical functionalities time-limited and fault-tolerant, just like a network call has a time-out and can return nothing (in a simplified manner, it can wrap that call with a timer and an exception handler). I agree that microservices are suitable for large organization, where the organization practically has multiple products (which could be purchased from a vendor or sold to another company).
  - Karrot_Kream 4y ago
    If your monolithic service OOMs, hits a large GC pause causing dependent requests to time out, locks a shared file descriptor, or a bunch of other things then the monolithic service as a whole can hit a fault or stall even if other threads/tasks are still executing. While classes of errors like OOMs go away when multiple processes are executing.
    - 4y ago