5 ms·

I work on different projects that use with Rails and others that use a microservice-based architecture, and while the trend has been to encourage avoiding monol

I work on different projects that use with Rails and others that use a microservice-based architecture, and while the trend has been to encourage avoiding monolithic architectures like Rails, I can say that I highly appreciate what it provides at its core. I love that the Rails team continues to trudge forward to add value and improvements despite the trends.

HatchedLake721 2y ago
> the trend has been to encourage avoiding monolithic architectures like Rails I'd say's it's completely the opposite. Yes, microservices might've been the trend in late 2010s, but after everyone got burned by it with unnecessary complexity (unless you're at "Google" scale), people just went back by being productive building modular "monolithic" architectures, and using "microservices" only when absolutely necessary.
- zeendo 2y ago
  Surely one can imagine a middle ground between one giant monolith and a huge mess of microservices?
  - loloquwowndueo 2y ago
    A distributed monolith! Worst of both worlds! I’m just kidding of course.
  - moritonal 2y ago
    Depends what you wanted from Microservices. If all you wanted was scale, then Rails ActiveJob solves that very effectively allowing you to scale your job-runners. If you're looking for the "mindset" of microservices, where you store the data separately and impotently, then I believe Rails discourages that mindset.
    - berkes 2y ago
      I keep hearing this "microservices to allow scale", in which "scale" implies performance, as some counterargument against microservices. Honest question, who ever seriously proposed microservices to improve performance? It doesn't take a lot of thought to figure out that microservices have overhead that will always put it in a disadvantage over a monolith in this regard. The only "scale" that makes sense wrt microservices is that of the scale of teams, and manage-ability of the scale of features and codebase. They are primarily a solution to "too many people working in too many poorly bounded domains". But as a solution to performance problems? Is it really proposed as that?
      - spyckie2 2y ago
        It was proposed in the sense that Ruby, or python, or whatever webserver language you used (Perl, php, even JavaScript) was slow, single core, synchronous, database blocked, or whatever else made it “unscalable” and you built this tiny service that only focuses on your core bottlenecks like an api call that only returns coordinates of your map position on things like aws lambda. Then for some reason some junior engineers thought that you could make everything an api call and you can make services in the most optimal language and glue them all together to have functional “scalable” apps. And thus the horrors of being a web dev in 2016+ began. Of course it didn’t help SPAs were encouraging backends to be decoupled from front ends and completely hidden in their implementation so the fact that “it was now possible” enticed backend devs to experiment with multiple api services.
        berkes 2y ago
        Well, Ruby (on Rails) is slow, single core, synchronous, database blocked and hard to scale. But certainly almost everyone realises that's not a feature of it being a monolith, but comes from it's language/stack/paradigms (AR, template, dynamic, JIT etc)? I have, certainly, replaced some endpoints in Rails apps with lambda's, rust, or even standalone sinatra services for performance reasons. For example an endpoint that generated "default stable avatar pngs" for new users: Ruby just isn't cut for image generation and manipulation. Rewriting that in a stack that performed x100 in this use-case (we picked rust) took a lot of heat off the cluster of servers. Or moving the oauth and registration to a separate rails app that served these pages - the only endpoints that did HTML. Allowing the "main" Rails app to remain leaner by not loading all of the templating, and other HTML middleware in memory when it would never be used. In that sense, I guess, monolyths can have a performance disadvantage: they require the entire app to load stuff for that one endpoint or feature even if 99% of the requests and users never use that. Like the "PDF generation for reports" we once had, that was rarely used but still loaded in every running thread that would never handle anything related to reports or PDFs. Extracting that to a separate "PDF report generation worker" freed GBs of memory on almost all servers.
  - noworriesnate 2y ago
    A modular monolith is distinct from a "plain" monolith. It's a good middle ground for most web services.
    - crabmusket 2y ago
      What's a "plain" monolith? Is a modular monolith "just a monolith except we don't suck at coding"?
      - noworriesnate 2y ago
        A modular monolith has a single executable which runs in different modes, typically depending on environment variables. So you can run three processes in the mode that handles web requests, five processes in the mode that processes events on a queue (e.g. Kafka), etc. Eight processes, running in two different modes, but it's all the same executable. That's the basic idea of a modular monolith. By "plain monolith" I meant just any kind of monolith.
      - closeparen 2y ago
        Let's use MVC for the sake of argument. A regular monolith has lots of models, lots of controllers, and lots of views. A modular monolith has several collections of models/controllers/views, which might be tightly coupled internally, but the collections as a whole exposes much smaller APIs to each other. You cannot just reach into an implementation detail of distantly related functionality, even if this functionality is "public" in the programming language package visibility sense (i.e. users repository is visible to users controller). This is basically what's accomplished by publishing a Thrift/Proto/OpenAPI IDL from a collection of packages comprising a network service. The key insight is that the serialization and networking parts of this are superfluous, what you actually wanted was the visibility rules.
  - mattbrewsbytes 2y ago
    In some ways its more about organization of humans doing the work. Breaking some piece of a monolith off into its own application, not micro-service, has advantages that you avoid having to deal more than a 2 pizza team size on an app. Sometimes the business grows and you go from startup idea one-app-does-everything implementations into needing more de-coupled, single business responsibility organizations of code. I suppose places like Spotify or Github may have good practices around working on large monoliths but I would think that takes a lot of effort to get right and may have trade-offs.
    - brightball 2y ago
      This is correct. It was always more of a team organization solution than a system architectural solution. Leaning into it too much on the latter created a lot of complications for the former.
  - imhoguy 2y ago
    Modulith - you still program app usually as single repo project, but you take care about code level modularization so in any case you are able to simply extract separate (micro)service.
  - karmajunkie 2y ago
    yes, it’s called SOA and it’s been around for decades at this point.
    - kstrauser 2y ago
      Hey, we should invent a Protocol for it!
  - noop_joe 2y ago
    Totally, I think there's a lot of retroactive justification for what's familiar whether it be microservice or monolith. They both have advantages and disadvantages -- we're at a point where deploying and running either is available on most clouds. That said, I think interesting possibilities exist where the two approaches are blended. I work for a cloud [1] that supports a concept of "services" grouped within an app each of those services is a web server that can be configured to sleep [2] under specific conditions -- effectively serverless but without the loss of shared memory and all the efficiencies of running a more traditional web server. The grouping of services also provides a way to spin off parts of an application while keeping it within the same deployment process. 1. https://noop.dev https://noop.dev 2. https://noop.dev/docs/sleepy-services/ https://noop.dev/docs/sleepy-services/
- hello_moto 2y ago
  > people just went back by being productive building modular "monolithic" architectures, and using "microservices" only when absolutely necessary. The number of hi-tech companies that are in the middle-to-large scale have increased significantly from the first wave of Rails era. Majority of hi-tech companies with listed stock have complexity more than "monolithic" architecture. Sadly, if a company doesn't grow, they will get eaten by their competitors.
  - int_19h 2y ago
    > Majority of hi-tech companies with listed stock Isn't that kinda circular? Generally speaking, companies only list their stock when they grow large. The vast majority of web dev is not happening in those kinds of companies.
    - hello_moto 2y ago
      There are publicly listed hi-tech companies that may not be that big...
- sosodev 2y ago
  You're generalizing way too much. There are still tons of teams out there running and creating new microservices.
- arunix 2y ago
  Is this correct? Practically every job advert I've seen claims they are using microservices (and want candidates with such experience).
  - Alupis 2y ago
    It is not correct. This is the sentiment people who don't understand k8s often have, because of handwavy complexity blah blah blah. The predictable quote is always along the lines of "unless you're Google scale..." - which misses perhaps 80% of what microservices bring to the table. Then they go off and build complicated monorepos that take 6 months to learn before you can effectively contribute. All paradigms have trade offs. Engineering is about understanding those trade offs and using them where appropriate. Unfortunately too many people just jump on the "k8s is complicated" bandwagon (because it challenges most of the assumptions they've previously held in software development) and entirely write-off microservices without taking the time to learn what problems microservices solve.
    - int_19h 2y ago
      People are well aware of what problems microservices solve. They are also aware of all the numerous problems they introduce, such as making debugging much more complicated, for starters.
      - Alupis 2y ago
        Well, you're repeating one of the myths yourself here. Debugging is different and some people find that harder because it's not what they are used to. That does not mean it is actually more complicated.
        chucke 2y ago
        Debugging IS more difficult. Observability is much harder, sometimes needlessly. When you're 4 languages deep and have to enable distributed tracing across a variety of brokers/protocols (http, sqs, grpc, queue in a database) you know the lord intended you to spend your time in a more useful way.
- ninininino 2y ago
  We stopped making microscopic microservices but we still ship services. Services are deployable independently from each other, can be scaled independently from each other. A monolith that results in a single build artifact / executable or whose contents must all run in a single pod or application server is inherently harder for larger teams to work on. Deploying a small change means re-deploying your entire application. Scaling your authz system means scaling up your analytics data producers. Separating your code into services that run and deploy independently from each other means organizations can scale without creating headaches for developers.
ch4s3 2y ago
> while the trend has been to encourage avoiding monolithic architectures like Rails I'm of the opinion that this was always bad advice for most people most of the time. Achieving any real infrastructure cost savings this was is difficult, its easy for delivery speeds to suffer, and the debugging experience is terrible.
sergiotapia 2y ago
microservices, like graphql, have certainly fallen from grace by more senior engineers. i see mostly jrs advocate for it because that's what they were taught. a senior engineer will try to keep the monolith for only as possible and only then explore a new tiny service.
- Alupis 2y ago
  To the contrary, it is often the "senior" engineers that refuse to learn new architectures, and only want to build in ways they already know and used in the past.
  - sergiotapia 2y ago
    not what I've seen. seniors have used these latest tools to ship before and are aware of the negatives.
  - int_19h 2y ago
    Senior engineers are more likely to be the ones who have seen how mindless adoption of fad-of-the-day translates to product quality, and are more likely to choose a solution that they have seen actually work, and for which they know the warts and how to handle them. That's a good thing - experienced engineers should be conservative when it comes to code that runs in prod. Customers are not guinea pigs.

HatchedLake721 2y ago

> the trend has been to encourage avoiding monolithic architectures like Rails I'd say's it's completely the opposite. Yes, microservices might've been the trend in late 2010s, but after everyone got burned by it with unnecessary complexity (unless you're at "Google" scale), people just went back by being productive building modular "monolithic" architectures, and using "microservices" only when absolutely necessary.

zeendo 2y ago
Surely one can imagine a middle ground between one giant monolith and a huge mess of microservices?
- loloquwowndueo 2y ago
  A distributed monolith! Worst of both worlds! I’m just kidding of course.
- moritonal 2y ago
  Depends what you wanted from Microservices. If all you wanted was scale, then Rails ActiveJob solves that very effectively allowing you to scale your job-runners. If you're looking for the "mindset" of microservices, where you store the data separately and impotently, then I believe Rails discourages that mindset.
  - berkes 2y ago
    I keep hearing this "microservices to allow scale", in which "scale" implies performance, as some counterargument against microservices. Honest question, who ever seriously proposed microservices to improve performance? It doesn't take a lot of thought to figure out that microservices have overhead that will always put it in a disadvantage over a monolith in this regard. The only "scale" that makes sense wrt microservices is that of the scale of teams, and manage-ability of the scale of features and codebase. They are primarily a solution to "too many people working in too many poorly bounded domains". But as a solution to performance problems? Is it really proposed as that?
    - spyckie2 2y ago
      It was proposed in the sense that Ruby, or python, or whatever webserver language you used (Perl, php, even JavaScript) was slow, single core, synchronous, database blocked, or whatever else made it “unscalable” and you built this tiny service that only focuses on your core bottlenecks like an api call that only returns coordinates of your map position on things like aws lambda. Then for some reason some junior engineers thought that you could make everything an api call and you can make services in the most optimal language and glue them all together to have functional “scalable” apps. And thus the horrors of being a web dev in 2016+ began. Of course it didn’t help SPAs were encouraging backends to be decoupled from front ends and completely hidden in their implementation so the fact that “it was now possible” enticed backend devs to experiment with multiple api services.
      - berkes 2y ago
        Well, Ruby (on Rails) is slow, single core, synchronous, database blocked and hard to scale. But certainly almost everyone realises that's not a feature of it being a monolith, but comes from it's language/stack/paradigms (AR, template, dynamic, JIT etc)? I have, certainly, replaced some endpoints in Rails apps with lambda's, rust, or even standalone sinatra services for performance reasons. For example an endpoint that generated "default stable avatar pngs" for new users: Ruby just isn't cut for image generation and manipulation. Rewriting that in a stack that performed x100 in this use-case (we picked rust) took a lot of heat off the cluster of servers. Or moving the oauth and registration to a separate rails app that served these pages - the only endpoints that did HTML. Allowing the "main" Rails app to remain leaner by not loading all of the templating, and other HTML middleware in memory when it would never be used. In that sense, I guess, monolyths can have a performance disadvantage: they require the entire app to load stuff for that one endpoint or feature even if 99% of the requests and users never use that. Like the "PDF generation for reports" we once had, that was rarely used but still loaded in every running thread that would never handle anything related to reports or PDFs. Extracting that to a separate "PDF report generation worker" freed GBs of memory on almost all servers.
- noworriesnate 2y ago
  A modular monolith is distinct from a "plain" monolith. It's a good middle ground for most web services.
  - crabmusket 2y ago
    What's a "plain" monolith? Is a modular monolith "just a monolith except we don't suck at coding"?
    - noworriesnate 2y ago
      A modular monolith has a single executable which runs in different modes, typically depending on environment variables. So you can run three processes in the mode that handles web requests, five processes in the mode that processes events on a queue (e.g. Kafka), etc. Eight processes, running in two different modes, but it's all the same executable. That's the basic idea of a modular monolith. By "plain monolith" I meant just any kind of monolith.
    - closeparen 2y ago
      Let's use MVC for the sake of argument. A regular monolith has lots of models, lots of controllers, and lots of views. A modular monolith has several collections of models/controllers/views, which might be tightly coupled internally, but the collections as a whole exposes much smaller APIs to each other. You cannot just reach into an implementation detail of distantly related functionality, even if this functionality is "public" in the programming language package visibility sense (i.e. users repository is visible to users controller). This is basically what's accomplished by publishing a Thrift/Proto/OpenAPI IDL from a collection of packages comprising a network service. The key insight is that the serialization and networking parts of this are superfluous, what you actually wanted was the visibility rules.
- mattbrewsbytes 2y ago
  In some ways its more about organization of humans doing the work. Breaking some piece of a monolith off into its own application, not micro-service, has advantages that you avoid having to deal more than a 2 pizza team size on an app. Sometimes the business grows and you go from startup idea one-app-does-everything implementations into needing more de-coupled, single business responsibility organizations of code. I suppose places like Spotify or Github may have good practices around working on large monoliths but I would think that takes a lot of effort to get right and may have trade-offs.
  - brightball 2y ago
    This is correct. It was always more of a team organization solution than a system architectural solution. Leaning into it too much on the latter created a lot of complications for the former.
- imhoguy 2y ago
  Modulith - you still program app usually as single repo project, but you take care about code level modularization so in any case you are able to simply extract separate (micro)service.
- karmajunkie 2y ago
  yes, it’s called SOA and it’s been around for decades at this point.
  - kstrauser 2y ago
    Hey, we should invent a Protocol for it!
- noop_joe 2y ago
  Totally, I think there's a lot of retroactive justification for what's familiar whether it be microservice or monolith. They both have advantages and disadvantages -- we're at a point where deploying and running either is available on most clouds. That said, I think interesting possibilities exist where the two approaches are blended. I work for a cloud [1] that supports a concept of "services" grouped within an app each of those services is a web server that can be configured to sleep [2] under specific conditions -- effectively serverless but without the loss of shared memory and all the efficiencies of running a more traditional web server. The grouping of services also provides a way to spin off parts of an application while keeping it within the same deployment process. 1. https://noop.dev https://noop.dev 2. https://noop.dev/docs/sleepy-services/ https://noop.dev/docs/sleepy-services/
hello_moto 2y ago
> people just went back by being productive building modular "monolithic" architectures, and using "microservices" only when absolutely necessary. The number of hi-tech companies that are in the middle-to-large scale have increased significantly from the first wave of Rails era. Majority of hi-tech companies with listed stock have complexity more than "monolithic" architecture. Sadly, if a company doesn't grow, they will get eaten by their competitors.
- int_19h 2y ago
  > Majority of hi-tech companies with listed stock Isn't that kinda circular? Generally speaking, companies only list their stock when they grow large. The vast majority of web dev is not happening in those kinds of companies.
  - hello_moto 2y ago
    There are publicly listed hi-tech companies that may not be that big...
sosodev 2y ago
You're generalizing way too much. There are still tons of teams out there running and creating new microservices.
arunix 2y ago
Is this correct? Practically every job advert I've seen claims they are using microservices (and want candidates with such experience).
- Alupis 2y ago
  It is not correct. This is the sentiment people who don't understand k8s often have, because of handwavy complexity blah blah blah. The predictable quote is always along the lines of "unless you're Google scale..." - which misses perhaps 80% of what microservices bring to the table. Then they go off and build complicated monorepos that take 6 months to learn before you can effectively contribute. All paradigms have trade offs. Engineering is about understanding those trade offs and using them where appropriate. Unfortunately too many people just jump on the "k8s is complicated" bandwagon (because it challenges most of the assumptions they've previously held in software development) and entirely write-off microservices without taking the time to learn what problems microservices solve.
  - int_19h 2y ago
    People are well aware of what problems microservices solve. They are also aware of all the numerous problems they introduce, such as making debugging much more complicated, for starters.
    - Alupis 2y ago
      Well, you're repeating one of the myths yourself here. Debugging is different and some people find that harder because it's not what they are used to. That does not mean it is actually more complicated.
      - chucke 2y ago
        Debugging IS more difficult. Observability is much harder, sometimes needlessly. When you're 4 languages deep and have to enable distributed tracing across a variety of brokers/protocols (http, sqs, grpc, queue in a database) you know the lord intended you to spend your time in a more useful way.
ninininino 2y ago
We stopped making microscopic microservices but we still ship services. Services are deployable independently from each other, can be scaled independently from each other. A monolith that results in a single build artifact / executable or whose contents must all run in a single pod or application server is inherently harder for larger teams to work on. Deploying a small change means re-deploying your entire application. Scaling your authz system means scaling up your analytics data producers. Separating your code into services that run and deploy independently from each other means organizations can scale without creating headaches for developers.

ch4s3 2y ago

> while the trend has been to encourage avoiding monolithic architectures like Rails I'm of the opinion that this was always bad advice for most people most of the time. Achieving any real infrastructure cost savings this was is difficult, its easy for delivery speeds to suffer, and the debugging experience is terrible.

sergiotapia 2y ago

microservices, like graphql, have certainly fallen from grace by more senior engineers. i see mostly jrs advocate for it because that's what they were taught. a senior engineer will try to keep the monolith for only as possible and only then explore a new tiny service.

Alupis 2y ago
To the contrary, it is often the "senior" engineers that refuse to learn new architectures, and only want to build in ways they already know and used in the past.
- sergiotapia 2y ago
  not what I've seen. seniors have used these latest tools to ship before and are aware of the negatives.
- int_19h 2y ago
  Senior engineers are more likely to be the ones who have seen how mindless adoption of fad-of-the-day translates to product quality, and are more likely to choose a solution that they have seen actually work, and for which they know the warts and how to handle them. That's a good thing - experienced engineers should be conservative when it comes to code that runs in prod. Customers are not guinea pigs.