Comment by HatchedLake721
1 year 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.
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.
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.
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.
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?
9 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.
What's a "plain" monolith? Is a modular monolith "just a monolith except we don't suck at coding"?
2 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.
Hey, we should invent a Protocol for it!
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.
There are publicly listed hi-tech companies that may not be that big...
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.
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.
6 replies →
You're generalizing way too much. There are still tons of teams out there running and creating new microservices.