[nobleach]

It absolutely does. When operating a highly dynamic site that services millions of requests a day, scaling k8s pods horizontally ceases to be a "win". One bumps up against the node count that is hit by the load balancer. (NodeJS experiences this quite a bit too). Rails excels in heavily cached configurations. This requires less volatile data.

My main point here is, that while one can work hard to try and tune Rails (Shopify's done it, Stripe's done it) - and I would argue that it's more of an effort than some DevOps personnel updating a pod count - it's fairly easy to start with something that is already very performant. SpringBoot is an opinionated framework for Java that has very good raw performance. I'm simply advocating that it doesn't hurt to start with something that's already pretty good. That's not premature optimization, it's just making wise decisions from the start.

[weatherlite]

> My main point here is, that while one can work hard to try and tune Rails (Shopify's done it, Stripe's done it)

That's what I'm saying - you don't need to "work hard" to tune Rails in 99% of cases - your bottlenecks (if any) will probably be in the database layer. k8s simply solves it, so unless your argument is "infrastructure costs" or something I don't agree with your case. Shopify has such tremendous scale I think its ridiculous to use it as an example for the average company.

> When operating a highly dynamic site that services millions of requests a day, scaling k8s pods horizontally ceases to be a "win".

Why does it cease to be a win? Everyone is doing it no matter what stack they are on. So with Rails you might have a few more pods - for any startups that's going to succeed the cost is simply negligible.

[nobleach]

Yes, scaling horizontally can be quite expensive. For a startup that begins their journey with Rails, and finds out quickly how expensive that is, it can be a show stopper. Shopify and Stripe are used as an example simply because I want to agree that it is possible - given a ton of resources.

So, if I could tell you, that for your next startup, you could start with something that is easier and cheaper to scale (I find "a few more pods" very disingenuous as many benchmarks say otherwise), why would you choose something that requires a lot more resources? Because Rails is neat? I just don't see the allure at that point. It's why we're seeing companies like Podium, Divvy, PagerDuty move away from it. It's great to get a proof of concept out the door. So many stories are out there of folks that are moving away from it for their "next step".

[weatherlite]

We are not going to agree here probably. Another anecdote - because of our company's microservice/k8s architecture each dev works on their own k8s cluster. While some services are shared - most are not. That means we pay more for dev infrastructure than our production bill! So if optimizing infra from the start is the game - why is everyone doing micro services?