5 ms·

> > A huge part of my career has been splitting monoliths into cohesive smaller codebases > Did that ... create business value for your company? Not OP, but t

> > A huge part of my career has been splitting monoliths into cohesive smaller codebases > Did that ... create business value for your company? Not OP, but the big value of splitting into microservices is isolation. In production, this isolation offers a limited blast radius in the case of an errant service. Also, independent scaling. Business value: improved reliability. In code, isolation lets development teams have a smaller and more focused domain / set of concerns to reason about (vs. the entirety of the monolith). Business value: Increased dev velocity.

bedobi 6y ago
Exactly this!
- e-brake 6y ago
  Agreed, isolation is a good reason to opt for microservices. One app goes offline, others still accessible, and you can do isolated maintenance. That, and features that aren't directly related, are super lightweight (quick to build, run, low on memory and CPU) as little projects.
whakim 6y ago
In my experience, it's easy enough to have services which have a large blast radius themselves and can become points of failure for your entire ecosystem. I don't find this to be a huge point of difference from a monolith, although of course it depends a lot on what you're working on. To pick on the OP a bit here (sorry!), they said that their entire legacy system "could go down because of issues to do with completely unrelated, non critical things like eg internal staff vacation hours." To me that sounds like poorly written software regardless of architecture. I can't imagine a scenario in any of the recent codebases I've worked on (microservices and monoliths both) where errors in what sounds like an internal CRUD tool would cause an entire production application to crash. I find it even harder to imagine if the application has a halfway decent test suite. To add to that, when you have hundreds of services running around and something goes wrong, it ends up being a lot harder to track down exactly what's happening. So when you do get that critical error, oftentimes the downtime is worsened. As for dev velocity, I find the claims of the microservice gospel a little bit exaggerated. Your layers of nested services all talk to each other, and any of them could be a point of failure. This isn't really all that different from calling another function in your monolithic app - you've just distributed that function call across a network boundary. You still need to know the callee's API, and you'll still spend a decent amount of time trying to understand the ways that the callee might fail. But you've also created a huge amount of additional developer work whenever you need to do something that spans the boundaries of existing services. I think microservices certainly have their advantages but a lot of the simplistic claims made by their biggest proponents only hold up prima facie.
- dodobirdlord 6y ago
  > In my experience, it's easy enough to have services which have a large blast radius themselves and can become points of failure for your entire ecosystem. I don't find this to be a huge point of difference from a monolith, although of course it depends a lot on what you're working on. It's a huge different because if some core critical service starts causing problems it's almost certainly because the last binary push was bad, and you roll it back. You only have to roll back that particular service any everything starts behaving correctly again. Moreover, you probably detected the problem in the first place when the rollout of that service began by replacing a single instance of the updated service with the new binary. Monitoring picks up a spike in errors/latency/database-load/whatever and the push is stopped and rolled back. Monoliths have inventive ways to address this problem without having to roll the entire binary back, like pushing patches or using feature flags, but few would argue that the microservice approach to handling bad pushes isn't superior. > To me that sounds like poorly written software regardless of architecture. I can't imagine a scenario in any of the recent codebases I've worked on (microservices and monoliths both) where errors in what sounds like an internal CRUD tool would cause an entire production application to crash. I find it even harder to imagine if the application has a halfway decent test suite. Easy enough with a sufficiently large codebase in C or C++. Somebody's parser encounters an input that was supposed to never happen and now it's off clobbering the memory of who-knows-what with garbage.
  - whakim 6y ago
    If you find yourself routinely pushing a bad binary that has (1) passed your test suite; and (2) passed whatever manual QA process you have on sandbox/staging deployments, then I would again suggest the problem is the process and not the architecture. Not to mention that if the service is indeed critical, you're not rolling out a deployment to every production server at once (or you're low enough scale that it doesn't matter). Either way, easy enough to roll back a bad deploy before things get hairy regardless of architecture. Also, I'm not sure what kind of internal CRUD tools you're writing, but "malicious input" doesn't really seem likely to come from your coworkers.
    - 6y ago
shrimpx 6y ago
How is a blast radius limited in the case where a bunch of things depend on that microservice? It seems a microservice can have an arbitrarily large blast radius.
- 8note 6y ago
  The things that don't depend on it don't go down. Eg. Your email system doesn't go down because the building's elevator had a bug. It also let's you choose which parts to pay closer attention to - the microservices that's depended on by everything gets the extra operations
collyw 6y ago
If you have a high availability system, then one whole monolith instance going down is going to have less effect than one crucial micro-service going down.
- vp8989 6y ago
  That seems like a conveniently contrived example. Why, in this example, would only 1 instance of the monolith go down but all instances of the crucial microservice go down?
  - collyw 6y ago
    Most of the time it's one dodgy parameter or variable (or one dodgy combination of variables) that causes something to crash. The majority of bugs I fix take a bit of effort to reproduce.

bedobi 6y ago

Exactly this!

e-brake 6y ago
Agreed, isolation is a good reason to opt for microservices. One app goes offline, others still accessible, and you can do isolated maintenance. That, and features that aren't directly related, are super lightweight (quick to build, run, low on memory and CPU) as little projects.

whakim 6y ago

In my experience, it's easy enough to have services which have a large blast radius themselves and can become points of failure for your entire ecosystem. I don't find this to be a huge point of difference from a monolith, although of course it depends a lot on what you're working on. To pick on the OP a bit here (sorry!), they said that their entire legacy system "could go down because of issues to do with completely unrelated, non critical things like eg internal staff vacation hours." To me that sounds like poorly written software regardless of architecture. I can't imagine a scenario in any of the recent codebases I've worked on (microservices and monoliths both) where errors in what sounds like an internal CRUD tool would cause an entire production application to crash. I find it even harder to imagine if the application has a halfway decent test suite. To add to that, when you have hundreds of services running around and something goes wrong, it ends up being a lot harder to track down exactly what's happening. So when you do get that critical error, oftentimes the downtime is worsened. As for dev velocity, I find the claims of the microservice gospel a little bit exaggerated. Your layers of nested services all talk to each other, and any of them could be a point of failure. This isn't really all that different from calling another function in your monolithic app - you've just distributed that function call across a network boundary. You still need to know the callee's API, and you'll still spend a decent amount of time trying to understand the ways that the callee might fail. But you've also created a huge amount of additional developer work whenever you need to do something that spans the boundaries of existing services. I think microservices certainly have their advantages but a lot of the simplistic claims made by their biggest proponents only hold up prima facie.

dodobirdlord 6y ago
> In my experience, it's easy enough to have services which have a large blast radius themselves and can become points of failure for your entire ecosystem. I don't find this to be a huge point of difference from a monolith, although of course it depends a lot on what you're working on. It's a huge different because if some core critical service starts causing problems it's almost certainly because the last binary push was bad, and you roll it back. You only have to roll back that particular service any everything starts behaving correctly again. Moreover, you probably detected the problem in the first place when the rollout of that service began by replacing a single instance of the updated service with the new binary. Monitoring picks up a spike in errors/latency/database-load/whatever and the push is stopped and rolled back. Monoliths have inventive ways to address this problem without having to roll the entire binary back, like pushing patches or using feature flags, but few would argue that the microservice approach to handling bad pushes isn't superior. > To me that sounds like poorly written software regardless of architecture. I can't imagine a scenario in any of the recent codebases I've worked on (microservices and monoliths both) where errors in what sounds like an internal CRUD tool would cause an entire production application to crash. I find it even harder to imagine if the application has a halfway decent test suite. Easy enough with a sufficiently large codebase in C or C++. Somebody's parser encounters an input that was supposed to never happen and now it's off clobbering the memory of who-knows-what with garbage.
- whakim 6y ago
  If you find yourself routinely pushing a bad binary that has (1) passed your test suite; and (2) passed whatever manual QA process you have on sandbox/staging deployments, then I would again suggest the problem is the process and not the architecture. Not to mention that if the service is indeed critical, you're not rolling out a deployment to every production server at once (or you're low enough scale that it doesn't matter). Either way, easy enough to roll back a bad deploy before things get hairy regardless of architecture. Also, I'm not sure what kind of internal CRUD tools you're writing, but "malicious input" doesn't really seem likely to come from your coworkers.
  - 6y ago

shrimpx 6y ago

How is a blast radius limited in the case where a bunch of things depend on that microservice? It seems a microservice can have an arbitrarily large blast radius.

8note 6y ago
The things that don't depend on it don't go down. Eg. Your email system doesn't go down because the building's elevator had a bug. It also let's you choose which parts to pay closer attention to - the microservices that's depended on by everything gets the extra operations

collyw 6y ago

If you have a high availability system, then one whole monolith instance going down is going to have less effect than one crucial micro-service going down.

vp8989 6y ago
That seems like a conveniently contrived example. Why, in this example, would only 1 instance of the monolith go down but all instances of the crucial microservice go down?
- collyw 6y ago
  Most of the time it's one dodgy parameter or variable (or one dodgy combination of variables) that causes something to crash. The majority of bugs I fix take a bit of effort to reproduce.