Cloud services can work out super expensive for a startup. To get going often all you need is one server that runs both the database and web server, which you can rent cheaply from any number of hosting companies out there. Sure you have to manage it yourself and it won't scale right off the bat, but sometimes that's fine. This is how we ran Scirra for a long time. Eventually you need to scale up, but that's a nice problem to have!
Yeah, that's true. We were traditional one-off software license sales via our website, so a brief outage would not be the end of the world. There are definitely cases where it would be irresponsible to only have one server, but I think there are still a lot of startups that could get by with it, and it would save them a lot on the early running costs, which could really make a difference.
Dividing your architecture into separate components is not only needed for operating at scale (the "nice" problem to have), but for having high availability (or even decent performance) at all.
Depending on one's business, HA/performance may not matter that much, but personally my startup is having a 'proper' design from day 1 - downtime is not acceptable for my business model.
Dividing your architecture into separate components will probably cause you more downtime and have much worse performance.
Less servers and components mean less things to break.
Grab a dedicated server and host your shit on it (have a DB replica because losing data sucks, but that is easy). You will be able to run like that for much longer than you probably suspect and the chance of downtime will be massively reduced.
Why? Because a single server has a very low chance of having anything going wrong.
Not only that, but there is a lot of overhead in performance when you split everything up into components. You will be surprised how many requests you can handle on a single inexpensive dedicated server when you haven't put too much effort into "architecture".
When you actually find yourself running out of headroom on that setup you will know much more about your application and it's requirements then you did at the start, so you will have a better idea of what to split out, and a better understanding of what parts of your app need more performance anyway.
Workers are a must for any minimally sophisticated web application. You cannot degrade HTTP response time (and whole app server performance) just because you are performing work synchronously before the request finishes.
Similarly, if the work you are performing has any value for your business, it must be retryable, and the queued items must be safely stored (i.e. don't use a single Redis server - use something distributed like SQS instead).
All of that calls for a 'proper' architecture. I'm not talking microservices or anything fancy - just a webapp/worker/db separation and the like. Which is exactly what dedicated server (or DigitalOcean) users tend to lack at early stages.
I'm not disagreeing that in some cases it's true. But as someone who provides infrastructure for a great many businesses including startups, most everyone changes their tune when their server goes down.
That's entirely true. But maybe those startups which 'changed their tune' didn't have to worry about servers for N months, focusing in e.g. market fit and growth hacking instead. Lean Startup mode.
Personally I'm pretty confident about market-fit and expected growth even before the launch day of my startup.
Btw, love the front-page demo of your product. Open with childhood experience, cheap laugh with quarters we lost, prop up 2D today, and then drop the demo. Great, fun ad. Good luck on the business. :)
