Offset-based pagination will be a problem on big tables.
Building Modular Rails Applications: A Deep Dive into Rails Engines
21–30 of 51 posts
Re: Building Modular Rails Applications: A Deep Dive into Rails Engines
#22Earlier quoted context omitted.
This is exactly my experience. Most of the time people go to microservices for the wrong reason and they will regret that for years
I've built numerous systems on AWS Lambda over the last 10 years, and have never once regretted it. YMMV.
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”.
Re: Building Modular Rails Applications: A Deep Dive into Rails Engines
#23Re: Building Modular Rails Applications: A Deep Dive into Rails Engines
#24Earlier quoted context omitted.
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.
What can you not do in a monolith? You can still have async queues and different event processors that stop and start independently within a monolithic deployment.
Speaking as a monolith fan, IMO/IME the main drawback is RAM usage per instance.
You can have a "big, beautiful" Rails monolith codebase used by both Puma and Sidekiq queues etc, and that works well from most standpoints. But RAM usage will be pretty high and limit horizontal scaling.
Re: Building Modular Rails Applications: A Deep Dive into Rails Engines
#25Earlier quoted context omitted.
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. Gi…
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.
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.
Re: Building Modular Rails Applications: A Deep Dive into Rails Engines
#26Earlier quoted context omitted.
I've built numerous systems on AWS Lambda over the last 10 years, and have never once regretted it. YMMV.
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”.
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.
Re: Building Modular Rails Applications: A Deep Dive into Rails Engines
#27One 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'v…
> 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”.)
Re: Building Modular Rails Applications: A Deep Dive into Rails Engines
#28One 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'v…
> 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”.)
You can have a modular monolith with multiple entrypoints that enable autoscaling of independent "deploys".
Re: Building Modular Rails Applications: A Deep Dive into Rails Engines
#29Earlier quoted context omitted.
> 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”.)
You can have a modular monolith with multiple entrypoints that enable autoscaling of independent "deploys".
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.
Re: Building Modular Rails Applications: A Deep Dive into Rails Engines
#30One 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'v…
> 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”.)
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.