2 ms·

I'm curious what language and data stack they're using? Asking because I've seen real scale (billions of devices running our software) and the real leverage is

I'm curious what language and data stack they're using? Asking because I've seen real scale (billions of devices running our software) and the real leverage is in how you architect your application (software and how the data is stored, retrieved, moves around) and things like choice of language. Not where it's hosted. Languages like Python and Ruby are just grossly inefficient. Single-threaded, huge memory profiles, and fully synchronous I/O. Whereas in C#, Tasks and async/await probably provide no shit 10-100x the performance in both compute and concurrency. It would probably be the same deal with Go or Java. The point is, we tend to hand-wave these kind of choices away on HN. "Just ship it, language doesn't matter". But increasingly, I think it does. You want to make a product with an aggressive free tier, where only like 1% of the user base pays, or some data-heavy analytics thing, these kinds of decisions can be make or break for a business.

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 ago
  I 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.

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 ago
I 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.