4 ms·
This isn't just one startup, these are multiple startups I have talked to that all end up deciding to move off the platform due to cost. Solid containers orches
by autotune 8y ago
This isn't just one startup, these are multiple startups I have talked to that all end up deciding to move off the platform due to cost. Solid containers orchestration platforms like Kubernetes are slowly reducing the need to have one specific cloud platform, but cost control is still extremely relevant with architecture design choices.
As far as language is concerned, Ruby and Ruby on Rails is the usual choice with Heroku and is marketed specifically towards RoR devs (https://www.heroku.com/ruby https://www.heroku.com/ruby) and Postgres as db. Most startups who decide to go the RoR route are not going to decide to go with C# as far as the Microsoft ecosystem is concerned, which would be a different set of architecture design choices. If you wanted to market a more performant alternative Go would 100 percent be the way to do it.
I would still somewhat disagree with your conclusion that language choice is imperative though, so much as how well you architect your application and infrastructure. A simple RoR app that pulls in a bunch of static assets from an S3 bucket is going to scale at whatever load compared to an ETL tool like Airflow that might need to process terabytes of data on a daily basis and has to have more planning from the start.
- davidjnelson 8y agoI feel you both have fantastic insights in this. Thanks for the discussion. My take is it’s great to use ec2 pricing, likely with beanstalk, and aurora or perhaps aurora serverless for sql. There’s room for moving fast with rails. Then as things grow, splitting off a microservice with the same url via your proxy server which uses go and redis. This way you are not over optimizing one data model before you know exactly what its schema is.