Correct. Don't use tools aimed for Google levels of complexity if you're not dealing with Google levels of complexity.
Does that mean you should write microservices for your toy? Probably not. But the trade-off calculus for microservices is not scale. It is a lot of things. If you had an application that was extremely trivial to run as decoupled services, and the boundaries between them are not liable to change much, maybe you really should use microservices from zero, and benefit from better failure isolation among other things. But yes, probably not.
Still, I think the idea that microservices are not really a great idea is a flimsy justification for Ruby on Rails in general. It's fair enough to say that if your language, framework and library choices are working for you and your product, you aren't beholden to justify them really. That said, that doesn't mean they couldn't be better with different decisions, and it's sincerely hard to determine that. Sometimes, I get the feeling that articles in this vein are just as much about convincing the authors that they made the right choice as it is convincing anyone else. But it's not really that important, since I don't really feel you actually need to convince much of anyone, if you like your decision.
They don't need to convince us random HN readers, that's true.
But they do need to convince new hires, potential clients, and internal stakeholders that Rails is still the right choice. If you've ever worked on a large Rails SaaS app you know this subject comes up a lot.
Now when the subject comes up they can just send folks a link to the blog post, it's very convenient to have around for this purpose.
We’ve talked many times before about how ridiculous their amount of hardware is. There are really only two arguments for “why” that make sense to me: One, they are succeeding in spite of a very large degree of excess hardware. Two, all that hardware is about advertising.
Schadenfreude wants it to be #1, but I suspect it’s actually #2. And I hope that some day - soon - “overtracking your users” becomes a hot button topic in consumer safety, maybe not as serious as industrial pollution but pretty close.
Is it a good idea? Depends.
On the plus side: You have one underlying runtime and orchestration layer, with a lot of useful primitives (including and especially around deployments).
On the negative: You introduce yet another layer of complexity and abstraction.
The real advice is “don’t run stacks that make trade-offs or give up guarantees to be able to scale to a size you’re not at or solve problems you don’t have.”
We switched to k8s early on in the company and that little bit of work to get it operating with HPAs, etc has paid off in dividends over time.
Having Google levels of traffic is another thing, but it's easy enough to get Google levels of complexity.
Serverless is amazing when you use it the way its intended. Its not there to replace your entire ec2 workload.
my view is that if you are not on serverless, you are wasting resources that could otherwise been dedicated to building out domain knowledge
our team focuses on optimizing each function and less on devops/scaling. the plumbing work is gone and all we do is now translate business requirements. security concerns are also largely removed.
its a great time to be on serverless, it had to overcome lot of doubt but it is here to stay. no need to pay $5 / month either for your weekend projects. even if your project hits front page, it will still work, the billing is not even that bad for what you are getting.
> building out domain knowledge
What about all the knowledge that is contained in applications, services and libraries that run on RDBMs?
I'm serious, one of the reasons I shy away from serverless is I want to put together components at a higher level than functions. But maybe I'm missing something?
What advances in Serverless platforms like AWS Lambda prevent the need for configuring VPCs?
I haven't gotten into Kubernetes at all, but from what I've heard the bespoke-bash-scripts problem is largely solved in that world, so I've been toying with exploring it for our next project (still hosted on Fargate).
Serverless is not a silver bullet.
A lot of complexity we add to these systems is about fairness. Fair is always about narrowing the gap between best and worst case run times and trying to keep the result close to expectations, and being able to defend it when they don’t match.
unpredictable billing - this is why you setup billing alerts and not an issue unless you hit HN front page
vendor lock in - you can take your functions and upload it to google, azure, cloudflare
That said, for my own projects I don't go that route because when it is my own money I need the certainty of cost that something like a $10 droplet gives.
I know serverless will be much cheaper (probably almost free) for most likely loads, but if I'm hit with the extremely unlikely loads I'd rather a small droplet that struggles and dies than a performant serverless system that spins up my bill as well as my resources.