Comment by temporallobe
1 year ago
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.
> 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.
Surely one can imagine a middle ground between one giant monolith and a huge mess of microservices?
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.
1 reply →
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
2. https://noop.dev/docs/sleepy-services/
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.
10 replies →
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.
A modular monolith is distinct from a "plain" monolith. It's a good middle ground for most web services.
3 replies →
A distributed monolith! Worst of both worlds! I’m just kidding of course.
yes, it’s called SOA and it’s been around for decades at this point.
1 reply →
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.
> 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.
> 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.
1 reply →
Is this correct? Practically every job advert I've seen claims they are using microservices (and want candidates with such experience).
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.
7 replies →
You're generalizing way too much. There are still tons of teams out there running and creating new microservices.
> 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.
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.
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.
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.
not what I've seen. seniors have used these latest tools to ship before and are aware of the negatives.