3 ms·

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

by 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

by adql 4y ago

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