3 ms·

Indeed, people vastly underestimate how far you can go with a single server. Even Digital Ocean offers a 48 vCPUs/96 GB instance for ~1000 USD which you'll be a

Indeed, people vastly underestimate how far you can go with a single server. Even Digital Ocean offers a 48 vCPUs/96 GB instance for ~1000 USD which you'll be able to host most of the businesses seen on HN with. Obviously, if you're doing storage intensive stuff, you wouldn't use the built-in storage, if you're doing really CPU intensive stuff you might outsource that to a different instance and so on. But people tend to want to distribute their app with 5k monthly users to 10 really weak instances instead of just 2 medium ones or 1 big one. And in that, they think it makes it more reliable but fail to account for the added complexity of distributed architectures and start to fail when doing deployments and changes instead. Another part people underestimate is the performance of dedicated instances vs "virtual" instances. Many times I've seen people shocked at how last applications work when running on dedicated instances, and how far you can scale with them as you won't have to upgrade as often as you think. Cloud is mainly meant (for me at least) for software you need to be able to scale really fast up AND down, not just up as you get more users. But most businesses I've worked for, with and started myself, never really had that need.

adql 4y ago
Well, you probably want at least 2 for redundancy, but active/passive setup on 2 nodes can cover great many use cases if you're not running some memory hogging Rails blob that needs hundreds of MB just to render a site.
- capableweb 4y ago
  In reality, complexity of deploys and introducing new changes are way more likely to shut down your service than anything else, unless you're dealing with very large scale. And for those problems, it doesn't matter if you have 1 or 10 instances, shit would go down anyways as you push out your change to all of them. Services falling over themselves for no reason is really uncommon in my experience, and usually are because A) introduced changes, B) hitting performance bottlenecks that are really bugs in the code or C) downtime of 3rd parties that someone failed to account could actually be down so that brought down "our" application too.
  - adql 4y ago
    Complexity of rsyncing your app onto 2 nodes instead of one isn't a problem tho. The DB is the hard part (not with automation but that's more to learn), and storing the files to be seen by all nodes (if app needs to create files during its normal work) is, but in most cases delegating that part to cloudy cloud isn't a problem. > In reality, complexity of deploys and introducing new changes are way more likely to shut down your service than anything else, unless you're dealing with very large scale. And for those problems, it doesn't matter if you have 1 or 10 instances, shit would go down anyways as you push out your change to all of them. Right, but updating OS is one of those changes, can't do that hitless if there is only one node in the system. And you do update your OS (or whatever FROM you got your container), right ? Sure, most downtimes will be more "developer fucked up" than "something happened with hardware". But those fuckups are usually on smaller scale than "well, server needs to be rebuilt from scratch/backup/CM manifest" and "just" need revert. > And for those problems, it doesn't matter if you have 1 or 10 instances, shit would go down anyways as you push out your change to all of them. If you have tens of instances you can be responsible developer and do some kind of staged deploy to cut those fuckups by order of magnitude or two.
- ta988 4y ago
  In practice for most projects being inaccessible for a couple hours is not the end of the world. And you loose less money than falling in the DevOps SRE hole where you pay for everything 5 times plus the people that take care of it all of that for it to go down anyway because of a long tail event.
  - adql 4y ago
    Most projects don't make money... obviously someone's personal blog is near-zero monetary loss if it is down. But honestly if you want to not do ops, outsource it instead of half-ass it, there are plenty of options > And you loose *lose
noirscape 4y ago
The reality of it is that a lot of people vastly overestimate the activity of what they build will actually reach. You can easily host a lot of stuff with just a "basic" SQL database and a single frontend as long as you have proper rate limiting on your APIs and make sure your frontend is sane. NGINXs original design goal was to handle 10,000 connections at the same time and nowadays it can handle up to ~400,000 without needing reconfiguration. Even a basic cache layer on nginx can often completely circumvent the need of calling the backend, especially for open APIs. Postgres can easily handle dozens of connections at the same time with the right config flags. To give a bit of an estimate on how far basic infrastructure can carry you; the entire RetroArch project[1], which I'd say has about the same userbase as any small tech company is entirely hosted, buildbot (so CI) included, on a single 40$ DigitalOcean instance. Most software is suprisingly efficient/resilient if you just configure it properly. The only place where I've seen horizontal scaling as an actual necessity vs. just properly configuring the tools you're given in most cases is Rails. There's no real efficiency fix for Rails tooling from what I can tell. It's just slow as molasses and you're gonna foot an ever expanding server bill as your userbase grows. [1]: No endorsement.

adql 4y ago

Well, you probably want at least 2 for redundancy, but active/passive setup on 2 nodes can cover great many use cases if you're not running some memory hogging Rails blob that needs hundreds of MB just to render a site.

capableweb 4y ago
In reality, complexity of deploys and introducing new changes are way more likely to shut down your service than anything else, unless you're dealing with very large scale. And for those problems, it doesn't matter if you have 1 or 10 instances, shit would go down anyways as you push out your change to all of them. Services falling over themselves for no reason is really uncommon in my experience, and usually are because A) introduced changes, B) hitting performance bottlenecks that are really bugs in the code or C) downtime of 3rd parties that someone failed to account could actually be down so that brought down "our" application too.
- adql 4y ago
  Complexity of rsyncing your app onto 2 nodes instead of one isn't a problem tho. The DB is the hard part (not with automation but that's more to learn), and storing the files to be seen by all nodes (if app needs to create files during its normal work) is, but in most cases delegating that part to cloudy cloud isn't a problem. > In reality, complexity of deploys and introducing new changes are way more likely to shut down your service than anything else, unless you're dealing with very large scale. And for those problems, it doesn't matter if you have 1 or 10 instances, shit would go down anyways as you push out your change to all of them. Right, but updating OS is one of those changes, can't do that hitless if there is only one node in the system. And you do update your OS (or whatever FROM you got your container), right ? Sure, most downtimes will be more "developer fucked up" than "something happened with hardware". But those fuckups are usually on smaller scale than "well, server needs to be rebuilt from scratch/backup/CM manifest" and "just" need revert. > And for those problems, it doesn't matter if you have 1 or 10 instances, shit would go down anyways as you push out your change to all of them. If you have tens of instances you can be responsible developer and do some kind of staged deploy to cut those fuckups by order of magnitude or two.
ta988 4y ago
In practice for most projects being inaccessible for a couple hours is not the end of the world. And you loose less money than falling in the DevOps SRE hole where you pay for everything 5 times plus the people that take care of it all of that for it to go down anyway because of a long tail event.
- adql 4y ago
  Most projects don't make money... obviously someone's personal blog is near-zero monetary loss if it is down. But honestly if you want to not do ops, outsource it instead of half-ass it, there are plenty of options > And you loose *lose

noirscape 4y ago

The reality of it is that a lot of people vastly overestimate the activity of what they build will actually reach. You can easily host a lot of stuff with just a "basic" SQL database and a single frontend as long as you have proper rate limiting on your APIs and make sure your frontend is sane. NGINXs original design goal was to handle 10,000 connections at the same time and nowadays it can handle up to ~400,000 without needing reconfiguration. Even a basic cache layer on nginx can often completely circumvent the need of calling the backend, especially for open APIs. Postgres can easily handle dozens of connections at the same time with the right config flags. To give a bit of an estimate on how far basic infrastructure can carry you; the entire RetroArch project[1], which I'd say has about the same userbase as any small tech company is entirely hosted, buildbot (so CI) included, on a single 40$ DigitalOcean instance. Most software is suprisingly efficient/resilient if you just configure it properly. The only place where I've seen horizontal scaling as an actual necessity vs. just properly configuring the tools you're given in most cases is Rails. There's no real efficiency fix for Rails tooling from what I can tell. It's just slow as molasses and you're gonna foot an ever expanding server bill as your userbase grows. [1]: No endorsement.