4 ms·

I've always got the impression that micro-services are a bad idea most of the time, apart from sometimes where they're not. Mainly if you're really big. There

I've always got the impression that micro-services are a bad idea most of the time, apart from sometimes where they're not. Mainly if you're really big. There are a lot of advantages to having a monolith, especially in statically typed languages. Every extra service you add is costly, it involves setup, build steps that can break, extra things to monitor, more complex development environment, less flexibility, harder to redesign, harder to fix flaws in the original architecture, etc.

joshdick 9y ago
You need a certain level of maturity in devops practices before microservices are worth it. Deploying an extra service to a kubernetes cluster, for example, is neither costly nor prone to breaking nor harder to monitor, etc. I think the best practice nowadays is for a small startup to first write a monolith and then later split it out into microservices when they're ready.
- mattmanser 9y ago
  To me it seems guaranteed that it is more expensive, regardless of if you use [insert trendy tool here]. There's always something that can break. More parts, more breakdowns. The services have to communicate, those communication channels are extra points of failure. What happens when one service inadvertently passes along something another one can't decode properly? Ooops, wasn't expecting unicode! Ooops, wasn't expecting a long int! Oops, the JSON encoder we used in this service spits out stuff the JSON decoder in this one hates! Ooops, we upgraded a package in this service, but not that one! And on, and on. And when something does inevitably break in the chain, there's the extra cost in debugging of figuring out which bit actually broke.
  - eropple 9y ago
    Agreed on all counts. The only time I recommend multiple services, rather than just load-balancing across monolithic applications, is when part of it's written on a different stack. As an example: I'm writing a gizmo with a Ruby core and a NodeJS ingest endpoint, and yeah, I'll probably run them on separate machines. But here's the dirty secret: if you have a load balancer in front of your application, you already have a way to send requests for feature X to a separate pool of machines if that feature is a hot spot for you currently--and unless your application hits some really degenerate cases your base RAM load Simply Should Not be that high for your application in the first place, making the marginal cost and machine sizing floor less of an issue. There are benefits to microservices in some environments, chiefly to reflect your org chart when your human protocols are breaking down. They tend to be marginal, and whether they outstrip the increased overhead of dealing with more moving parts (whether in your code or not; I quite like k8s but I still wouldn't want somebody less comfortable with it than I am running it in production, and plenty of those folks do!) is in many ways up in the air.
dsr_ 9y ago
It's important to realize the level of abstraction going on here. This is all philosophical discussion of how much Buddha-nature is in a particular company. If your application is composed of single-purpose modules, which are well documented, which have clean public interfaces, which are instrumented for monitoring, which can be scaled by using a load-balancing message router of some kind... and it works well, who cares whether you call it micro-services, Web Services, SOA, or FactoryFactory-Producer/Consumer Ecosystem?
- LargeWu 9y ago
  It's not about what you call it, it's about the overhead having many services entails.
  - dsr_ 9y ago
    You should have exactly the number of services required. This may be hard to plan out from the beginning, but if all is basically sound, you may be able to reduce that number later. (E.g. when a module is called only by one other module, and there's no requirement for them to scale independently, maybe they should be one module.)
    - mattmanser 9y ago
      I feel like you're just saying the same thing a different way. Most development doesn't happen in a "we know exactly where we're going" way. This all sounds like some perfect, waterfall development cycle, everything's designed on paper in UML and the code is then written to spec without any changes, no requirements change, no interfaces change. That model of development simply doesn't exist in the real world. Your profile and blog say you're a sysadmin, do micro-services keep you in a job ;) It's one thing to make a bunch of micro-services as a sysadmin. It's quite another to base an ever growing and mutating production code base around them that actually has no clear path to success and an only vague understanding of future requirements.
      - dsr_ 9y ago
pc86 9y ago
Even if you're not really big, sometimes it's helpful just to have everything broken up and not have to go to a 750,000 LOC solution and find the 10-line file that you need to edit. I'm on the architecture side so am bearing the brunt of the complexity but the senior and especially mid level developers who have code open 7.8 hours a day say the few things we do that have real microservices are the easiest to debug and work on. The monolithic apps take longer to get less done. Agreed though that it certainly adds complexity on the admin/arch/ops side.
- LargeWu 9y ago
  Having microservices doesn't really solve this problem, though, because you still have all those lines of code, plus all the extra code to make it all talk to each other. If the problem is one of organization, that can probably also be solved in large codebases without breaking into multiple systems.
- jjoonathan 9y ago
  Monolith: a->b Microservice: a->async->serialization->network->serialization->scheduling->b A monolith is extremely simple to traverse with a debugger, a microservice is not. I can make a dozen jumps over/into/out in less time than it would take me to open Fiddler or man tcpdump. I have heard that some companies have tooling that makes the microservices debugging situation tolerable or sometimes even better than monolith (e.g. writing tests for you by snooping the network layer), but I have yet to play with any. Do you have recommendations?
  - reacharavindh 9y ago
    Very much this. It may be worthwhile for really complex and "business vice separated" services to be written as micro services because it gives you clear separation of concerns. But, in reality, to often you see a single logical service getting implemented with a lot of (N/W + serialization + management) costs unnecessarily just because it is cool to say that you did micro services. My thumb rule is : If you don't foresee different teams of devs working on these different services, then you're better off leaving it as a monolith and scaling it as a whole application instead.
athenot 9y ago
Microservices really shine when your setup requires HA everywhere. If you're running multiple copies of everything and need your overall product to still run while parts fail, then it's a lot easier when the individual parts are small microservices that do one thing with predictable operating conditions. If you're not running in High Availability, and can tolerate one copy of everything, then monolithic probably makes more sense. Glue it all together and roll out improvements across all the parts at once.
- eropple 9y ago
  This is not a real distinction, though. You can have N instances of a monolith if it's written smartly (generally speaking, where "smart" equals "is a twelve-factor app"). And frankly, for the 95% and probably the 99% case, running a copy of each monolithic application its own auto-scaling group is probably significantly less work and less hair-pulling than the chasing the microservice dragon.
zeveb 9y ago
> I've always got the impression that micro-services are a bad idea most of the time, apart from sometimes where they're not. I'll argue that if you're building something, you should probably build it as a monolith, with the exception of some well-defined services (like authentication & authorisation). Once you've got version 1 built, then you know enough about the problem that you're ready to consider breaking stuff off into microservices (this is why auth^2 make sense to break off from the get-go: they're pretty well-understood at this point, so we all should know how to handle them). Premature microservicement is the root of much evil. Trying to break things up into services before you actually understand the problem will only lead to tears & suffering.

joshdick 9y ago

You need a certain level of maturity in devops practices before microservices are worth it. Deploying an extra service to a kubernetes cluster, for example, is neither costly nor prone to breaking nor harder to monitor, etc. I think the best practice nowadays is for a small startup to first write a monolith and then later split it out into microservices when they're ready.

mattmanser 9y ago
To me it seems guaranteed that it is more expensive, regardless of if you use [insert trendy tool here]. There's always something that can break. More parts, more breakdowns. The services have to communicate, those communication channels are extra points of failure. What happens when one service inadvertently passes along something another one can't decode properly? Ooops, wasn't expecting unicode! Ooops, wasn't expecting a long int! Oops, the JSON encoder we used in this service spits out stuff the JSON decoder in this one hates! Ooops, we upgraded a package in this service, but not that one! And on, and on. And when something does inevitably break in the chain, there's the extra cost in debugging of figuring out which bit actually broke.
- eropple 9y ago
  Agreed on all counts. The only time I recommend multiple services, rather than just load-balancing across monolithic applications, is when part of it's written on a different stack. As an example: I'm writing a gizmo with a Ruby core and a NodeJS ingest endpoint, and yeah, I'll probably run them on separate machines. But here's the dirty secret: if you have a load balancer in front of your application, you already have a way to send requests for feature X to a separate pool of machines if that feature is a hot spot for you currently--and unless your application hits some really degenerate cases your base RAM load Simply Should Not be that high for your application in the first place, making the marginal cost and machine sizing floor less of an issue. There are benefits to microservices in some environments, chiefly to reflect your org chart when your human protocols are breaking down. They tend to be marginal, and whether they outstrip the increased overhead of dealing with more moving parts (whether in your code or not; I quite like k8s but I still wouldn't want somebody less comfortable with it than I am running it in production, and plenty of those folks do!) is in many ways up in the air.

dsr_ 9y ago

It's important to realize the level of abstraction going on here. This is all philosophical discussion of how much Buddha-nature is in a particular company. If your application is composed of single-purpose modules, which are well documented, which have clean public interfaces, which are instrumented for monitoring, which can be scaled by using a load-balancing message router of some kind... and it works well, who cares whether you call it micro-services, Web Services, SOA, or FactoryFactory-Producer/Consumer Ecosystem?

LargeWu 9y ago
It's not about what you call it, it's about the overhead having many services entails.
- dsr_ 9y ago
  You should have exactly the number of services required. This may be hard to plan out from the beginning, but if all is basically sound, you may be able to reduce that number later. (E.g. when a module is called only by one other module, and there's no requirement for them to scale independently, maybe they should be one module.)
  - mattmanser 9y ago
    I feel like you're just saying the same thing a different way. Most development doesn't happen in a "we know exactly where we're going" way. This all sounds like some perfect, waterfall development cycle, everything's designed on paper in UML and the code is then written to spec without any changes, no requirements change, no interfaces change. That model of development simply doesn't exist in the real world. Your profile and blog say you're a sysadmin, do micro-services keep you in a job ;) It's one thing to make a bunch of micro-services as a sysadmin. It's quite another to base an ever growing and mutating production code base around them that actually has no clear path to success and an only vague understanding of future requirements.
    - dsr_ 9y ago

pc86 9y ago

Even if you're not really big, sometimes it's helpful just to have everything broken up and not have to go to a 750,000 LOC solution and find the 10-line file that you need to edit. I'm on the architecture side so am bearing the brunt of the complexity but the senior and especially mid level developers who have code open 7.8 hours a day say the few things we do that have real microservices are the easiest to debug and work on. The monolithic apps take longer to get less done. Agreed though that it certainly adds complexity on the admin/arch/ops side.

LargeWu 9y ago
Having microservices doesn't really solve this problem, though, because you still have all those lines of code, plus all the extra code to make it all talk to each other. If the problem is one of organization, that can probably also be solved in large codebases without breaking into multiple systems.
jjoonathan 9y ago
Monolith: a->b Microservice: a->async->serialization->network->serialization->scheduling->b A monolith is extremely simple to traverse with a debugger, a microservice is not. I can make a dozen jumps over/into/out in less time than it would take me to open Fiddler or man tcpdump. I have heard that some companies have tooling that makes the microservices debugging situation tolerable or sometimes even better than monolith (e.g. writing tests for you by snooping the network layer), but I have yet to play with any. Do you have recommendations?
- reacharavindh 9y ago
  Very much this. It may be worthwhile for really complex and "business vice separated" services to be written as micro services because it gives you clear separation of concerns. But, in reality, to often you see a single logical service getting implemented with a lot of (N/W + serialization + management) costs unnecessarily just because it is cool to say that you did micro services. My thumb rule is : If you don't foresee different teams of devs working on these different services, then you're better off leaving it as a monolith and scaling it as a whole application instead.

athenot 9y ago

Microservices really shine when your setup requires HA everywhere. If you're running multiple copies of everything and need your overall product to still run while parts fail, then it's a lot easier when the individual parts are small microservices that do one thing with predictable operating conditions. If you're not running in High Availability, and can tolerate one copy of everything, then monolithic probably makes more sense. Glue it all together and roll out improvements across all the parts at once.

eropple 9y ago
This is not a real distinction, though. You can have N instances of a monolith if it's written smartly (generally speaking, where "smart" equals "is a twelve-factor app"). And frankly, for the 95% and probably the 99% case, running a copy of each monolithic application its own auto-scaling group is probably significantly less work and less hair-pulling than the chasing the microservice dragon.

zeveb 9y ago

> I've always got the impression that micro-services are a bad idea most of the time, apart from sometimes where they're not. I'll argue that if you're building something, you should probably build it as a monolith, with the exception of some well-defined services (like authentication & authorisation). Once you've got version 1 built, then you know enough about the problem that you're ready to consider breaking stuff off into microservices (this is why auth^2 make sense to break off from the get-go: they're pretty well-understood at this point, so we all should know how to handle them). Premature microservicement is the root of much evil. Trying to break things up into services before you actually understand the problem will only lead to tears & suffering.