5 ms·

Unless you have a strong technical or organizational reason to use microservices, using microservices is just more work to achieve the same results. Organizati

Unless you have a strong technical or organizational reason to use microservices, using microservices is just more work to achieve the same results. Organizational reason would be multiple people/teams who don't want or can't talk much to each other, so they develop pieces of a larger system as relatively independent projects, with clear API and responsibility boundaries. Frontend/backend style web development is an example of such approach, even though we don't typically call these parts "microservices". A technical reason I can see is some component of a system actually having to be written in a different stack, or to be run in a separate location for business reasons (separate physical computer, separate VMs or containers don't count). Like a firmware running on an IoT system. Or most of the system uses python, but there's a really good library in java for solving some very specific problem, so let's use it. If neither of these reasons stands, you don't have a microservice architecture, you have a distributed monolith. You just replaced some function calls with RPC. RPC call which takes a much a longer time than a local one, and can randomly fail. Most of your microservices are written in a single stack, so you refactor common parts into a library, but then different services are stuck to use different versions of this library. You end up with a much slower and a much more fragile system which is harder to work on for no good reason.

bspammer 5y ago
> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “distributed monolith” like it’s a dirty phrase but I’ve found it actually a very pleasant environment to work in.
- fasteo 5y ago
  >>> If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule I call this a worker.
- goodoldneon 5y ago
  Distributed monolith can mean different things. I worked at a place with ~10 services sharing the same DB. It was awful
  - bspammer 5y ago
    Yeah that doesn’t sound fun at all
  - zo1 5y ago
    I worked at a place that had a few dozen services and one DB, worked on by dozens of developers. It was amazing. Oh and one repo, that made a huge difference.
- gwbas1c 5y ago
  That's a fallicy. You've optimized for one use case, but you've made everything else more complicated as a consequence. Deploying a single monolith is faster than deploying 10 microservices, especially if you find yourself in the model where your microservices share code, you've ended up with a distributed monolith instead of microservices.
  - galangalalgol 5y ago
    Don't forget serdes costs for microservices. They kill runtime speeds even with nice toys like flatbuffers.
  - bspammer 5y ago
    > You've optimized for one use case, but you've made everything else more complicated as a consequence. Yes, but that use case happens to be something that I need to do 5 times a day - make a small (<200 line) code change to one small part of the distributed monolith, and deploy it immediately. This also means that if something goes wrong, I can rollback those changes immediately without rolling back the work of any of the other 50 engineers in the company. Very little signoff required, very small blast radius.
    - abraxas 5y ago
      I doubt you can judge the blast radius. Say your little service just changed how it parsed backticks. Now that innocuous change may affect none of the immediately connected microservices but another services three hops away relied on the old behavior of your parser through some complex business rules driven logic. Now go test and later troubleshoot that vs standing up a single monolithic jar on your laptop and seeing the exception stack trace tell you exactly what you broke.
      - bspammer 5y ago
        I can see your point, but I’ve been working like this for 3 years and my anecdotal evidence is that kind of thing simply doesn’t happen.
  - 5y ago
- jatone 5y ago
  > deploy in minutes without having to rebuild and deploy a giant monolith that's a tooling issue not a monolith vs microservice issue. tooling can allow the exact same speed of deployment for tiny background processing without the need to completely segment your code base.
- odonnellryan 5y ago
  Why not... > branch from whatever branch is in prod > implement change on that branch (in this case adding a column), test > deploy to prod I realize the build and deployment process may be more complex than that making it hard... but it doesn't have to be. I agree that a microservice OR even another system (a collection of services) is a good solution if you need to make quick iterative changes, and you can't do so with your current system.
  - bspammer 5y ago
    That workflow is exactly what I do, but it's on a small codebase rather than on a big one. The benefits of working on a small repo include: * Faster compilation (only depend on exactly the libraries you need) * Faster testing (only need to run the tests which are actually relevant) * Easier to understand for new joiners because there's just less code to sift through * Faster startup (this is probably java specific - the classloader is slooow) * No (okay, fewer) rebase wars * Easy to see what's currently being worked on because the Pull Requests tab isn't 200 long * Very fast rollbacks without needing to recompile a git revert (just hotswap the container for that particular service). You can't do this in a monolith without risking rolling back someone else's important changes.
- deniska 5y ago
  > People throw around “distributed monolith” like it’s a dirty phrase but I’ve found it actually a very pleasant environment to work in. For ones I saw, the answer to the question "how do I run our project on a single laptop?" is "haha, you don't". That makes features which could take hours to implement take weeks. But deployment is 5 minutes instead of… 15? Not too worthy of a trade-off. Your CSV writer probably has both technical and organizational reasons being an independent unit of development. Or, in other words, something which appeared organically, rather than someone deciding months prior before a project even started that authentication and user profiles should live in two parallel universes.
  - p_l 5y ago
    Often with monoliths, once they go into production service at scale, the deployment can be "3 days, arranged 4 weeks in advance, requiring 9 sign offs including one VP"
    - goliatone 5y ago
      I would call that a megalith, and not to be cute but to give a sense of scale which is useful. I think there is a point in which a monolith grows so big that is painfully obvious that size became an obstacle greater than the benefits. Pain tolerance differs so the label gets applied at different sized monoliths.
  - salt-thrower 5y ago
    You bring up an excellent point. As of now, it is impossible for me to run my company's backend ecosystem on my machine locally. What we do could easily be done by one simple monolith, but our eng. lead is obsessed with overengineered microservice architecture, so nobody can actually develop locally. Everything on the backend is done by a bunch of lambdas behind an API gateway. I got so burnt out developing in that environment that I asked to become a pure frontend dev so that I wouldn't have to deal with it anymore.
- notJim 5y ago
  > it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith This is orthogonal to monolith vs microservices. I've worked on monoliths that could easily be (and were) deployed very frequently.
rtpg 5y ago
one strong operational reason I have seen recently is resource management. The monolith where most API endpoints are instant and use constant memory, but some use much more memory and can be slower... is tough.Like if you just give a bunch of memory to each process now you're overprovisioning and if you try to be strict you run into quality of service issues. If you split out homogenous API endpoints into various groups you now have well behaved processes that are each acting similarly. One process could be very small, another could be much larger (but handle only one kind of request), etc... of course the problem with standard microservice-y stuff is now you gotta have N different applications be able to speak your stack. The idea of a monolith with feature sets is tempting... but also can negate chunks of microservice advantages. Ultimately the microservice-y "everything is an API" can work well even as a monolith, and you would then have the flexibility to improve things operationally later.
- __jem 5y ago
  At the same time, you have to be at a pretty huge scale before resource over-provisioning really hurts the bottom line. You can buy a lot of compute for the price of a single engineer's salary, and it usually takes more than one engineer to support a microservice architecture. Most applications hit problems scaling the database vertically long before they exhaust resources at the application level.
  - rtpg 5y ago
    Hmm I get what you’re saying of course but in certain domains (think B2B SaaS) you might be running some compute-intensive stuff enough to where the differential is an issue. Imagine 95% of your workload can run in 100 megs but 5% requires 1000 megs. You can overprovision of course but in a world of containers if you can isolate the 5% and route it you’re going to have a lot less in terms of operational headaches
    - hnzix 5y ago
      I mean, this is kind of how microservices should be done. Start with a MVP monolith then carve off microservices if needed (performance or large team size). The problem is when the lead dev has been huffing the architecture paint too hard and starts prematurely spinning up microservices because it feels good.
dr-detroit 5y ago
Work up to SOLID and we can cover microservice architecture in the next course, son

bspammer 5y ago

> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “distributed monolith” like it’s a dirty phrase but I’ve found it actually a very pleasant environment to work in.

fasteo 5y ago
>>> If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule I call this a worker.
goodoldneon 5y ago
Distributed monolith can mean different things. I worked at a place with ~10 services sharing the same DB. It was awful
- bspammer 5y ago
  Yeah that doesn’t sound fun at all
- zo1 5y ago
  I worked at a place that had a few dozen services and one DB, worked on by dozens of developers. It was amazing. Oh and one repo, that made a huge difference.
gwbas1c 5y ago
That's a fallicy. You've optimized for one use case, but you've made everything else more complicated as a consequence. Deploying a single monolith is faster than deploying 10 microservices, especially if you find yourself in the model where your microservices share code, you've ended up with a distributed monolith instead of microservices.
- galangalalgol 5y ago
  Don't forget serdes costs for microservices. They kill runtime speeds even with nice toys like flatbuffers.
- bspammer 5y ago
  > You've optimized for one use case, but you've made everything else more complicated as a consequence. Yes, but that use case happens to be something that I need to do 5 times a day - make a small (<200 line) code change to one small part of the distributed monolith, and deploy it immediately. This also means that if something goes wrong, I can rollback those changes immediately without rolling back the work of any of the other 50 engineers in the company. Very little signoff required, very small blast radius.
  - abraxas 5y ago
    I doubt you can judge the blast radius. Say your little service just changed how it parsed backticks. Now that innocuous change may affect none of the immediately connected microservices but another services three hops away relied on the old behavior of your parser through some complex business rules driven logic. Now go test and later troubleshoot that vs standing up a single monolithic jar on your laptop and seeing the exception stack trace tell you exactly what you broke.
    - bspammer 5y ago
      I can see your point, but I’ve been working like this for 3 years and my anecdotal evidence is that kind of thing simply doesn’t happen.
- 5y ago
jatone 5y ago
> deploy in minutes without having to rebuild and deploy a giant monolith that's a tooling issue not a monolith vs microservice issue. tooling can allow the exact same speed of deployment for tiny background processing without the need to completely segment your code base.
odonnellryan 5y ago
Why not... > branch from whatever branch is in prod > implement change on that branch (in this case adding a column), test > deploy to prod I realize the build and deployment process may be more complex than that making it hard... but it doesn't have to be. I agree that a microservice OR even another system (a collection of services) is a good solution if you need to make quick iterative changes, and you can't do so with your current system.
- bspammer 5y ago
  That workflow is exactly what I do, but it's on a small codebase rather than on a big one. The benefits of working on a small repo include: * Faster compilation (only depend on exactly the libraries you need) * Faster testing (only need to run the tests which are actually relevant) * Easier to understand for new joiners because there's just less code to sift through * Faster startup (this is probably java specific - the classloader is slooow) * No (okay, fewer) rebase wars * Easy to see what's currently being worked on because the Pull Requests tab isn't 200 long * Very fast rollbacks without needing to recompile a git revert (just hotswap the container for that particular service). You can't do this in a monolith without risking rolling back someone else's important changes.
deniska 5y ago
> People throw around “distributed monolith” like it’s a dirty phrase but I’ve found it actually a very pleasant environment to work in. For ones I saw, the answer to the question "how do I run our project on a single laptop?" is "haha, you don't". That makes features which could take hours to implement take weeks. But deployment is 5 minutes instead of… 15? Not too worthy of a trade-off. Your CSV writer probably has both technical and organizational reasons being an independent unit of development. Or, in other words, something which appeared organically, rather than someone deciding months prior before a project even started that authentication and user profiles should live in two parallel universes.
- p_l 5y ago
  Often with monoliths, once they go into production service at scale, the deployment can be "3 days, arranged 4 weeks in advance, requiring 9 sign offs including one VP"
  - goliatone 5y ago
    I would call that a megalith, and not to be cute but to give a sense of scale which is useful. I think there is a point in which a monolith grows so big that is painfully obvious that size became an obstacle greater than the benefits. Pain tolerance differs so the label gets applied at different sized monoliths.
- salt-thrower 5y ago
  You bring up an excellent point. As of now, it is impossible for me to run my company's backend ecosystem on my machine locally. What we do could easily be done by one simple monolith, but our eng. lead is obsessed with overengineered microservice architecture, so nobody can actually develop locally. Everything on the backend is done by a bunch of lambdas behind an API gateway. I got so burnt out developing in that environment that I asked to become a pure frontend dev so that I wouldn't have to deal with it anymore.
notJim 5y ago
> it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith This is orthogonal to monolith vs microservices. I've worked on monoliths that could easily be (and were) deployed very frequently.

rtpg 5y ago

one strong operational reason I have seen recently is resource management. The monolith where most API endpoints are instant and use constant memory, but some use much more memory and can be slower... is tough.Like if you just give a bunch of memory to each process now you're overprovisioning and if you try to be strict you run into quality of service issues. If you split out homogenous API endpoints into various groups you now have well behaved processes that are each acting similarly. One process could be very small, another could be much larger (but handle only one kind of request), etc... of course the problem with standard microservice-y stuff is now you gotta have N different applications be able to speak your stack. The idea of a monolith with feature sets is tempting... but also can negate chunks of microservice advantages. Ultimately the microservice-y "everything is an API" can work well even as a monolith, and you would then have the flexibility to improve things operationally later.

__jem 5y ago
At the same time, you have to be at a pretty huge scale before resource over-provisioning really hurts the bottom line. You can buy a lot of compute for the price of a single engineer's salary, and it usually takes more than one engineer to support a microservice architecture. Most applications hit problems scaling the database vertically long before they exhaust resources at the application level.
- rtpg 5y ago
  Hmm I get what you’re saying of course but in certain domains (think B2B SaaS) you might be running some compute-intensive stuff enough to where the differential is an issue. Imagine 95% of your workload can run in 100 megs but 5% requires 1000 megs. You can overprovision of course but in a world of containers if you can isolate the 5% and route it you’re going to have a lot less in terms of operational headaches
  - hnzix 5y ago
    I mean, this is kind of how microservices should be done. Start with a MVP monolith then carve off microservices if needed (performance or large team size). The problem is when the lead dev has been huffing the architecture paint too hard and starts prematurely spinning up microservices because it feels good.

dr-detroit 5y ago

Work up to SOLID and we can cover microservice architecture in the next course, son