Ask HN: How, if at all, do you build infrastructure for side projects to scale? | Hacker News Reader

Ask HN: How, if at all, do you build infrastructure for side projects to scale?

12 pointsrelaunched7 comments

I am considering using the free tier on one of the major cloud service providers and wanted to get thoughts on if and how people build their infrastructure for side projects. Do you route your DNS directly to your main instance and keep both your database and middleware there (it's simple to setup, but doesn't really scale). Or, do you invest time setting up a load balancer, redundant databases in more than one zone, a middleware instance in more than one zone, remote code execution for spinning up new instances, etc.

View on HN

This all depends on the goals of your side project. If the goal is something other then learning how to set up infrastructure, then deploy your app on Heroku. You get most of the difficult problems dealt with and only have to focus on a couple configurations. Yes, admittedly Heroku is pricey when you start to scale up, but keep in mind that your time isn't free and that you'd need a considerable amount of traffic before it makes sense to spend a lot of time on properly setting up your app to scale.

On the other hand, if you want to learn how properly design a web application to scale, I'd suggest to get a couple boxes on DO[1]. This[2] article describes the common design for 99% of applications on the web (The last 1% is reserved for companies that have achieved enough traffic to justify hiring their own ops team). Finally, I'd suggest you read through this[3] slide deck. It goes through the steps of scaling up your application from one server to a cluster of machines.

1 - https://www.digitalocean.com/

2 - https://www.digitalocean.com/community/tutorials/5-common-se...

3 - https://speakerdeck.com/modulus/planning-for-the-horizontal-...

All on one box until it gets some traction. But I always setup an external monitoring (e.g. pingdom) service to get a notification, when something is down and a cronjob for daily (db-)backup.

Scaling steps with traction:

1.) dedicated server for DB

2.) loadbalancer (AWS ELB) & 2nd app-server

3.) scripting server mgmt (AWS OpsWorks, chef, puppet, ...)

4.) adding missing server roles (e.g. caching through memcache) to scripts

5.) deployment, up-/down-scaling with button clicks

6.) Slave-DB (more for ongoing backup and fail-over than for read-distribution)

7.) if you don't use AWS ELB don't forget to make sure the LB is not your single point of failure

Usually I have more than 1,000 registered users before I start with scaling step 1.

For a true side project (as in: I'm probably going to forget about it in a couple weeks and let it fade away), I don't bother with any of that.

If it's a professional project in any sense (as in: something I'm being paid to do) I'll at least route the DNS to a load balancer, and I'll use some kind of hosted RDS or NoSQL service for the DB. That's kind of the bare minimum effort (just in case the client is right about the product getting a million hits on the first day...).

But for 99% of side-projects, you can build and refactor for scaling concerns after you've done practically everything else. Scaling is the ultimate "Champagne Problem".

For side projects I have found App Engine to be the best choice. The free quota gives you time and space to develop and explore if this project is of any worth. And if suddenly there's an explosion you really don't need to do anything other than enable billing... (of course, giving that the design of the model is scalable)

None of that until it does scale. Speaking from prior experience of previously running on our own server setup (a long time ago before cloud and hosting were the norm, after scaling on AWS, and to current stuff.

Worry about server setup when you have those problems or otherwise you might be over optimizing the wrong things.

I use Heroku. You can use it for free and scale with one click if your project gets off the ground (or you are hitting HN front page). The downside is that Heroku gets very expensive as you add more resources.

You can host static content on github pages, which includes a CDN.

Reply on news.ycombinator.com