5 ms·

One of the reasons microservice architecture originally became popular was to break apart monolithic applications. In many cases, I bet a big driver was a lack

One of the reasons microservice architecture originally became popular was to break apart monolithic applications. In many cases, I bet a big driver was a lack of separation of concerns, and a more modular design was desired. There are many ways to put up walls in software to help make software more modular and self-contained. Rails engines are a good way to make more a rails app more modular. The number of times I've seen microservices created for the purpose of modularity (not scaling concerns), and the complexity that has brought has really soured me on microservices.

giovapanasiti 1y ago
This is exactly my experience. Most of the time people go to microservices for the wrong reason and they will regret that for years
- whstl 1y ago
  Different sections of an app can use different databases, if the bottleneck is in the database. Different routes can be served by different servers, if the bottleneck is in CPU usage. Different async tasks can run on different task runner services, if the problem is tasks competing with each other. Different test suites can run for different sections of the app, if the problem is with tests taking too long to run. Github and others even allow specific subfolders to be "owned" by different teams. What else is there? Even slowness of compilation and/or initialization can be alleviated, depending on the language or framework.
  - stronglikedan 1y ago
    I think the point is that all of that adds complexity that is often unnecessary - a premature optimization if you will. It's like a hammer, and everything looks like a nail to a lot of people.
    - inopinatus 1y ago
      GP isn’t oppositional, they listed runtime constructs that all run off a single monolith. The point being you don’t need so-called microservices for flexibility in the production environment.
    - whstl 1y ago
      As the sibling poster said, you probably misunderstood my point. I'm talking about how monoliths can also fix such problems when they happen.
  - the_sleaze_ 1y ago
    Old incompatible library versions; dependency hell, security SLAs. Old company couldn't get off of Rails 3 for a multitude of reasons and splitting off microservices was a good decision. Syncing state across the services turned into its own barrel of monkeys, but was better overall.
- leptons 1y ago
  I've built numerous systems on AWS Lambda over the last 10 years, and have never once regretted it. YMMV.
  - ecshafer 1y ago
    Ive regretted 99% of the services Ive built in AWS lambda over the years. Everytime it gets more complex than a couple hundred lines of code over a few lambas I start to think “if this were just one service, development, deployments, cicd, testing, storage would all be simpler”.
    - leptons 1y ago
      My deployments to Lambda are extremely simple. All I do is hit save in VSCode and the Lambda is updated. Change the env to prod and it deploys instantly to prod. There's tools that make it easy, I'm still using a tool I built 10 years ago. Very little has changed except the addition of layers, which are also pretty easy and automatically handled in my dev tool. All the Lambdas I write also run locally, and testing isn't an issue. The only gripe I have with Lambda is when they deprecate older nodejs versions, and I am forced to update some of my Lambdas to run on current nodejs, which then leads to refactoring due to node module incompatibilities in some specific situations. But those are really nodejs problems and not so much Lambda problems, and it does get me to keep my apps updated. YMMV.
    - jamesfinlayson 1y ago
      I inherited a Lambda application at one job - when I started it was probably 200+ Lambdas and it got to 128 Lambdas. Lots of message queues, lots of Lambdas subscribed to queues where they ignored 99% of incoming messages... quite a mess. The Lambdas that are gone got repackaged into a SpringBoot application which thoroughly simplified things.
- fhub 1y ago
  Some might, but I imagine some have left the company when the pain is really felt and are excited to do it all again at the next company.
  - burnt-resistor 1y ago
    They're the people with guitar websites and say how "awesome" they are. In truth, they're superficial technology terrorists.
    - mattgreenrocks 1y ago
      Guitar websites?
      - burnt-resistor 1y ago
        Rock-and-roll/metal band content congratulating themselves. They're "so cool".
nurettin 1y ago
I use multiple services for resilience. Example: With multiple services that have clear separation of concerns, you can debug and fix your processing layer without stopping the collection layer. You can update a distributor while workers wait and vice versa. This way I never have downtime anxiety. No regrets.
- zrail 1y ago
  Separation of services is orthogonal to separation of concerns. There's nothing stopping you from having multiple entry points into the same monolith. I.e. web servers run `puma` and workers run `sidekiq` but both are running the same codebase. This is, in fact, the way that every production Rails app that I've worked with is structured in terms of services. Concerns (in the broad sense, not ActiveSupport::Concern) can be separated any number of ways. The important part is delineating and formalizing the boundaries between them. For example, a worker running in Puma might instantiate and call three or four or a dozen different service objects all within different engines to accomplish what it needs, but all of that runs in the same Sidekiq thread. Inserting HTTP or gRPC requests between layers might enforce clean logical boundaries but often what you end up with is a distributed ball of mud that is harder to reason about than a single codebase.
  - nurettin 1y ago
    By concern I meant performing different actions and owning write access to different tables, not having completely separate code bases you seem to have construed for some reason. I would also never connect services without a queue unless the message can be discarded (then I can use a pub sub). Using http is one of the most amateurish ways I can imagine to connect two services that I wrote. Even the thought is cringe. Is this common?
- mrinterweb 1y ago
  For your example, rails apps handle this case by default with job queues that are managed by the deployment separately. There is a way to force the job queue to process in the same process as your web server, but that's not the way most should be running prod rails apps. There usually isn't anxiety associated with rails app deploys, in my experience.
jt2190 1y ago
> One of the reasons microservice architecture originally became popular was to break apart monolithic applications. I feel like the emphasis was on autoscaling parts of the app independently. (It’s telling that this has been forgotten and now we only remember it as “splitting up the app”.)
- bwilliams 1y ago
  You can have a modular monolith with multiple entrypoints that enable autoscaling of independent "deploys".
  - ch4s3 1y ago
    That’s always made sense to me in theory, but practically speaking a lot of logical units of service just don’t scale independently of your core service. Obviously this isn’t always true but I think it’s too easy to talk yourself into popping off new services and once you’ve built out the infrastructure for it and the incidental complexity is costly.
- mrinterweb 1y ago
  Scaling concerns can be a legitimate reason for a microservice, but I think those scaling concerns should be proven and not assumed before a new microservice is born. I also hate the agreement of maybe one day we might... as a justification for a new microservice. The number of times that premature optimization didn't pay off is far less than I've seen it come to be. Microservice should be an exception, not the preferred architectural design pattern. Sometimes I cynically think system architects like them because they make their diagrams look more important.
djfobbz 1y ago
I built my first SaaS back in 2009 on Rails 2.3. Fast forward to 2025, it's still running on Rails 2.3 LTS and Ruby 3.3.8, and it's still making money. No complaints here! ;)
silasb 1y ago
I 100% agree which has led me in saying "modules > microservices" for our onboarding documentation.

giovapanasiti 1y ago

This is exactly my experience. Most of the time people go to microservices for the wrong reason and they will regret that for years

whstl 1y ago
Different sections of an app can use different databases, if the bottleneck is in the database. Different routes can be served by different servers, if the bottleneck is in CPU usage. Different async tasks can run on different task runner services, if the problem is tasks competing with each other. Different test suites can run for different sections of the app, if the problem is with tests taking too long to run. Github and others even allow specific subfolders to be "owned" by different teams. What else is there? Even slowness of compilation and/or initialization can be alleviated, depending on the language or framework.
- stronglikedan 1y ago
  I think the point is that all of that adds complexity that is often unnecessary - a premature optimization if you will. It's like a hammer, and everything looks like a nail to a lot of people.
  - inopinatus 1y ago
    GP isn’t oppositional, they listed runtime constructs that all run off a single monolith. The point being you don’t need so-called microservices for flexibility in the production environment.
  - whstl 1y ago
    As the sibling poster said, you probably misunderstood my point. I'm talking about how monoliths can also fix such problems when they happen.
- the_sleaze_ 1y ago
  Old incompatible library versions; dependency hell, security SLAs. Old company couldn't get off of Rails 3 for a multitude of reasons and splitting off microservices was a good decision. Syncing state across the services turned into its own barrel of monkeys, but was better overall.
leptons 1y ago
I've built numerous systems on AWS Lambda over the last 10 years, and have never once regretted it. YMMV.
- ecshafer 1y ago
  Ive regretted 99% of the services Ive built in AWS lambda over the years. Everytime it gets more complex than a couple hundred lines of code over a few lambas I start to think “if this were just one service, development, deployments, cicd, testing, storage would all be simpler”.
  - leptons 1y ago
    My deployments to Lambda are extremely simple. All I do is hit save in VSCode and the Lambda is updated. Change the env to prod and it deploys instantly to prod. There's tools that make it easy, I'm still using a tool I built 10 years ago. Very little has changed except the addition of layers, which are also pretty easy and automatically handled in my dev tool. All the Lambdas I write also run locally, and testing isn't an issue. The only gripe I have with Lambda is when they deprecate older nodejs versions, and I am forced to update some of my Lambdas to run on current nodejs, which then leads to refactoring due to node module incompatibilities in some specific situations. But those are really nodejs problems and not so much Lambda problems, and it does get me to keep my apps updated. YMMV.
  - jamesfinlayson 1y ago
    I inherited a Lambda application at one job - when I started it was probably 200+ Lambdas and it got to 128 Lambdas. Lots of message queues, lots of Lambdas subscribed to queues where they ignored 99% of incoming messages... quite a mess. The Lambdas that are gone got repackaged into a SpringBoot application which thoroughly simplified things.
fhub 1y ago
Some might, but I imagine some have left the company when the pain is really felt and are excited to do it all again at the next company.
- burnt-resistor 1y ago
  They're the people with guitar websites and say how "awesome" they are. In truth, they're superficial technology terrorists.
  - mattgreenrocks 1y ago
    Guitar websites?
    - burnt-resistor 1y ago
      Rock-and-roll/metal band content congratulating themselves. They're "so cool".

nurettin 1y ago

I use multiple services for resilience. Example: With multiple services that have clear separation of concerns, you can debug and fix your processing layer without stopping the collection layer. You can update a distributor while workers wait and vice versa. This way I never have downtime anxiety. No regrets.

zrail 1y ago
Separation of services is orthogonal to separation of concerns. There's nothing stopping you from having multiple entry points into the same monolith. I.e. web servers run `puma` and workers run `sidekiq` but both are running the same codebase. This is, in fact, the way that every production Rails app that I've worked with is structured in terms of services. Concerns (in the broad sense, not ActiveSupport::Concern) can be separated any number of ways. The important part is delineating and formalizing the boundaries between them. For example, a worker running in Puma might instantiate and call three or four or a dozen different service objects all within different engines to accomplish what it needs, but all of that runs in the same Sidekiq thread. Inserting HTTP or gRPC requests between layers might enforce clean logical boundaries but often what you end up with is a distributed ball of mud that is harder to reason about than a single codebase.
- nurettin 1y ago
  By concern I meant performing different actions and owning write access to different tables, not having completely separate code bases you seem to have construed for some reason. I would also never connect services without a queue unless the message can be discarded (then I can use a pub sub). Using http is one of the most amateurish ways I can imagine to connect two services that I wrote. Even the thought is cringe. Is this common?
mrinterweb 1y ago
For your example, rails apps handle this case by default with job queues that are managed by the deployment separately. There is a way to force the job queue to process in the same process as your web server, but that's not the way most should be running prod rails apps. There usually isn't anxiety associated with rails app deploys, in my experience.

jt2190 1y ago

> One of the reasons microservice architecture originally became popular was to break apart monolithic applications. I feel like the emphasis was on autoscaling parts of the app independently. (It’s telling that this has been forgotten and now we only remember it as “splitting up the app”.)

bwilliams 1y ago
You can have a modular monolith with multiple entrypoints that enable autoscaling of independent "deploys".
- ch4s3 1y ago
  That’s always made sense to me in theory, but practically speaking a lot of logical units of service just don’t scale independently of your core service. Obviously this isn’t always true but I think it’s too easy to talk yourself into popping off new services and once you’ve built out the infrastructure for it and the incidental complexity is costly.
mrinterweb 1y ago
Scaling concerns can be a legitimate reason for a microservice, but I think those scaling concerns should be proven and not assumed before a new microservice is born. I also hate the agreement of maybe one day we might... as a justification for a new microservice. The number of times that premature optimization didn't pay off is far less than I've seen it come to be. Microservice should be an exception, not the preferred architectural design pattern. Sometimes I cynically think system architects like them because they make their diagrams look more important.

djfobbz 1y ago

I built my first SaaS back in 2009 on Rails 2.3. Fast forward to 2025, it's still running on Rails 2.3 LTS and Ruby 3.3.8, and it's still making money. No complaints here! ;)

silasb 1y ago

I 100% agree which has led me in saying "modules > microservices" for our onboarding documentation.