5 ms·

Two virtual machines are more than enough to a startup for the first 2 to 4 years.

justinclift 7y ago
One for Website + database, the other for monitoring? I guess backups could just be snapshots or something, depending on how active the database is. ;)
- jordic 7y ago
  Haha, some scripts to manage the deployments and rollbacks, plus some other scripts to manage the environment (ansible, terraform.. ).. also some scripts to manage the machines.. log aggregations, cleanup, upgrades... Later add some crons.. some more scripts to manage Dev environments.. and a bit more for having an staging env... That's without using any big cloud provider (add to it firewalls, vpcs, iam.. ) You know, managing some yml files that describes all of this it's so hard and so expensive...
- peterburkimsher 7y ago
  One for dev, one for production. Database snapshots and code can be backed up locally.
vorpalhex 7y ago
While your average startup doesn't need to go "uberscale", they probably need to be highly available.
- bpicolo 7y ago
  Two VMs in two separate availability zones is pretty ridiculously available. Certainly more so than other least-common-denominators in your stack. There are a ton of successful startups who made it a long way with less than 2 VMs.
  - Spivak 7y ago
    I'm in the "first 4 years were on two physical machines colo'd sitting at a local datacenter" club. Our cheap operating costs are actually a competitive advantage in our space.
- SteveNuts 7y ago
  Do they though? I've had plenty of virtual machines with over a year of uptime no problem (sometimes quite a bite more). I'd argue the only important thing in an early stage startup is a robust backup plan, including monitoring your backups and test restores often.
  - vorpalhex 7y ago
    Sure and my home server had an uptime for a year and a half until the local power company had a few brownouts one summer. Downtime doesn't happen until it does.
    - luckylion 7y ago
      So then your website is down, the monitoring alerts you and you fix it. Or, worst case, your monitoring doesn't alert you and you fix it on monday when you notice. You've been down the whole weekend. For most startups: so what, your dog-walker-as-a-service marketplace didn't work for 48 hours, that doesn't really matter. You've had a working system very quickly and saved plenty of money that you were able to invest into more features or runway though.
      - vorpalhex 7y ago
        Except as a startup potentially targeting enterprise customers or hospitals, that downtime may cost you significant contracts or future work. It's probably something that gets disclosed in investor decks - and depending on your offering may really hurt you.
        luckylion 7y ago
        I totally agree with "you can't just replace availability with pagerduty" if you're dealing with stuff like pacemakers. But that's not what most startups do. I believe that too many engineers worry about "what if a million users sign up tomorrow" and plan a system that will handle that (which also happens to be fun and tickles all the right places), which takes a lot of time and money and manpower instead of building something that works reasonably well and worrying about building the "right" solution when they're beginning to actually grow rapidly. I'd much rather hear "our servers can't handle the load, there are too many users signing up" than "when we're done here in six months, our system will be able to handle any load you throw at it". I wouldn't say that it's a no-go (there absolutely are situations where it makes sense), but it often looks like premature optimization.
- cloverich 7y ago
  With something like Heroku, you can have multiple VM's in staging and production, w/ a deployment pipeline that supports rollbacks, monitoring, alerting, autoscaling, all in a managed environment w/ a managed, highly available Postgres setup, with very little effort and 0 maintenance. This is what I've setup at my current startup. My last company was on K8's and I loved it -- but this is nearly as good and requires literally no maintenance and _far_ less expertise / setup.
- TeMPOraL 7y ago
  High availability is much easier when your product is a single runtime, and not a bunch of services running a complex communication network, any of which is likely to go belly up at any given moment.
- deleted 7y ago
  [deleted]
- bdcravens 7y ago
  If you have your k8s cluster in a single region, you probably aren't much more HA than a couple of instances load balanced.

One for Website + database, the other for monitoring? I guess backups could just be snapshots or something, depending on how active the database is. ;)

jordic 7y ago
Haha, some scripts to manage the deployments and rollbacks, plus some other scripts to manage the environment (ansible, terraform.. ).. also some scripts to manage the machines.. log aggregations, cleanup, upgrades... Later add some crons.. some more scripts to manage Dev environments.. and a bit more for having an staging env... That's without using any big cloud provider (add to it firewalls, vpcs, iam.. ) You know, managing some yml files that describes all of this it's so hard and so expensive...
peterburkimsher 7y ago
One for dev, one for production. Database snapshots and code can be backed up locally.

vorpalhex 7y ago

While your average startup doesn't need to go "uberscale", they probably need to be highly available.

bpicolo 7y ago
Two VMs in two separate availability zones is pretty ridiculously available. Certainly more so than other least-common-denominators in your stack. There are a ton of successful startups who made it a long way with less than 2 VMs.
- Spivak 7y ago
  I'm in the "first 4 years were on two physical machines colo'd sitting at a local datacenter" club. Our cheap operating costs are actually a competitive advantage in our space.
SteveNuts 7y ago
Do they though? I've had plenty of virtual machines with over a year of uptime no problem (sometimes quite a bite more). I'd argue the only important thing in an early stage startup is a robust backup plan, including monitoring your backups and test restores often.
- vorpalhex 7y ago
  Sure and my home server had an uptime for a year and a half until the local power company had a few brownouts one summer. Downtime doesn't happen until it does.
  - luckylion 7y ago
    So then your website is down, the monitoring alerts you and you fix it. Or, worst case, your monitoring doesn't alert you and you fix it on monday when you notice. You've been down the whole weekend. For most startups: so what, your dog-walker-as-a-service marketplace didn't work for 48 hours, that doesn't really matter. You've had a working system very quickly and saved plenty of money that you were able to invest into more features or runway though.
    - vorpalhex 7y ago
      Except as a startup potentially targeting enterprise customers or hospitals, that downtime may cost you significant contracts or future work. It's probably something that gets disclosed in investor decks - and depending on your offering may really hurt you.
      - luckylion 7y ago
        I totally agree with "you can't just replace availability with pagerduty" if you're dealing with stuff like pacemakers. But that's not what most startups do. I believe that too many engineers worry about "what if a million users sign up tomorrow" and plan a system that will handle that (which also happens to be fun and tickles all the right places), which takes a lot of time and money and manpower instead of building something that works reasonably well and worrying about building the "right" solution when they're beginning to actually grow rapidly. I'd much rather hear "our servers can't handle the load, there are too many users signing up" than "when we're done here in six months, our system will be able to handle any load you throw at it". I wouldn't say that it's a no-go (there absolutely are situations where it makes sense), but it often looks like premature optimization.
cloverich 7y ago
With something like Heroku, you can have multiple VM's in staging and production, w/ a deployment pipeline that supports rollbacks, monitoring, alerting, autoscaling, all in a managed environment w/ a managed, highly available Postgres setup, with very little effort and 0 maintenance. This is what I've setup at my current startup. My last company was on K8's and I loved it -- but this is nearly as good and requires literally no maintenance and _far_ less expertise / setup.
TeMPOraL 7y ago
High availability is much easier when your product is a single runtime, and not a bunch of services running a complex communication network, any of which is likely to go belly up at any given moment.
deleted 7y ago
[deleted]
bdcravens 7y ago
If you have your k8s cluster in a single region, you probably aren't much more HA than a couple of instances load balanced.