

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

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&#x27;s simple to setup, but doesn&#x27;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.
======
Oculus
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/](https://www.digitalocean.com/)

2 - [https://www.digitalocean.com/community/tutorials/5-common-
se...](https://www.digitalocean.com/community/tutorials/5-common-server-
setups-for-your-web-application#example-combining-the-concepts)

3 - [https://speakerdeck.com/modulus/planning-for-the-
horizontal-...](https://speakerdeck.com/modulus/planning-for-the-horizontal-
scaling-node-dot-js-applications)

------
tlubinski
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.

------
MalcolmDiggs
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".

------
ishener
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)

------
hashtag
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.

------
nyddle
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.

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

