Computers are stupidly cheap slave workers and are easy to spin up compared to dev time. Does it actually matter in almost any profitable business?
The speed argument is a much better argument imo, but we have to think if 100-300ms is worth the tradeoff of a great framework with a strong community. (I've not seen anything come near the beauty of Rails in Java, SpringBoot is not it. Last I checked there was no good SideKiq alternatives which feels kinda vital for most apps)
If a Rails app can handle only 300rqs that's over 1 million requests served an hour. A SpringBoot app handling say 2000rqs? Thats 7.2million a hour definitely a shit ton more but you know what, I'll probably just set the EC2 autoscale to 7 more instances and pay the extra $1000 a month because its still a magnitude of 10x cheaper than developer time. I can see your point in keeping server count low for simplicity being an advantage but not enough to persuade.
I say all this but I do like the speed argument, I think its important that we keep web requests fast for a better user experience. I mean Stripe, Shopify, GitHub all get by on the slowness that is Ruby but I will say that lately GitHub has been super slow for each page request but GitLab has been very fast which is also Rails.
There is another view point if you are operating on a slim margin business that keeping infrastructure costs tiny is important and that's another case for a faster backend for sure.
Now the interpreted lang vs statically type lang argument I can agree with, I hope for a language that sits somewhere between Java and Ruby. It seems Crystal fits that bill at the moment but has no backer and will be years off a great ecosystem if it takes off.
Companies who are feeding 2k+ machines to run their web servers care about cost savings. Hundreds of billions of requests/day, not millions. The database systems to handle that load, networking, power, bandwidth and all the people who maintain it.
> Computers are stupidly cheap slave workers and are easy to spin up compared to dev time. Does it actually matter in almost any profitable business?
The complexities mentioned generally fall on the developers and sysadmins who have to be aware of them and work around them, those people are definitely not cheap slave workers. Screw ups handling these complexities can bring the whole system down.
I worked at 80 person company which broke and closed because of this. We almost escaped this demise by going from PHP to HHVM which unfortunately was very alpha at the time, but we simply ran short of money and time. If it had worked, we would have scaled down 15x our AWS costs and would have saved at least 40 jobs.
Postponing (often indefinitely) the need for scaling out your application can benefit you tremendously, not so much because of the instance costs, but primarily in terms of reduced complexity in all aspects of development and operations.
Also, for a SaaS, keeping the cost per served transaction low can mean the difference between making a profit or a loss in a market that has a converged on a price-point for a type of service.
>There is another view point if you are operating on a slim margin business that keeping infrastructure costs tiny is important and that's another case for a faster backend for sure.
Which is why Rails is only suited for SaaS where you get paying user early in the development. If you require traffics for ads revenue it simply doesn't scale. And majority of the Web is still based on ad revenue model.
Computers are stupidly cheap slave workers and are easy to spin up compared to dev time. Does it actually matter in almost any profitable business?
The speed argument is a much better argument imo, but we have to think if 100-300ms is worth the tradeoff of a great framework with a strong community. (I've not seen anything come near the beauty of Rails in Java, SpringBoot is not it. Last I checked there was no good SideKiq alternatives which feels kinda vital for most apps)
If a Rails app can handle only 300rqs that's over 1 million requests served an hour. A SpringBoot app handling say 2000rqs? Thats 7.2million a hour definitely a shit ton more but you know what, I'll probably just set the EC2 autoscale to 7 more instances and pay the extra $1000 a month because its still a magnitude of 10x cheaper than developer time. I can see your point in keeping server count low for simplicity being an advantage but not enough to persuade.
I say all this but I do like the speed argument, I think its important that we keep web requests fast for a better user experience. I mean Stripe, Shopify, GitHub all get by on the slowness that is Ruby but I will say that lately GitHub has been super slow for each page request but GitLab has been very fast which is also Rails.
There is another view point if you are operating on a slim margin business that keeping infrastructure costs tiny is important and that's another case for a faster backend for sure.
Now the interpreted lang vs statically type lang argument I can agree with, I hope for a language that sits somewhere between Java and Ruby. It seems Crystal fits that bill at the moment but has no backer and will be years off a great ecosystem if it takes off.