4 ms·

It isn’t. I have the same overhead running my server as I do a VM. What I don’t get is a $3000 bill for $100 worth of server. You can generally buy whatever yo

by _3u10 5y ago

It isn’t. I have the same overhead running my server as I do a VM. What I don’t get is a $3000 bill for $100 worth of server. You can generally buy whatever you are renting from AWS for 1 to 3 months of an AWS bill. The only thing I don’t get from colo is a bunch of other customers thrashing the cache on my CPUs Databases are not web servers there’s no possible way to not run a database on smaller / fewer instances when running at non-peak times. Instant scaling is the only possible advantage AWS could bring. However with the prices they charge it’s simpler and cheaper to just buy/rent your own hardware. Especially if you have to pay egress fees. (bandwidth is really the biggest ripoff)

midasuni 5y ago
The argument isn’t about using AWS to run a VM (which can be cheaper that coloing your own kit, depending how many you want and for how long), it’s all the extra stuff. Start an aws load balancer rather than run and maintain your own for example. I don’t like lock-in, but the prevailing view has always been in favour of lock-in, be it IBM mainframes, oracle databases, windows servers etc, and if you swing that way aws has tempting offers. Oh and databases do scale. Say you want to run end of quarter financials that require a lot of processing for a day, you bring up tons of read replicas and away you go
- _3u10 5y ago
  If you bought hardware with what you pay for AWS RDS you could run your entire DB in RAM. Hell you could probably put the data in memory on a GPU. Also, this is generally why you run financials overnight. If your hardware is serving transactions during the day it can easily run your quarterlies at night. nginx is far easier to maintain than AWS load balancers which is what load balancers their load balancers are. The best part about nginx configs? They are cloud agnostic and will work on everything from a Raspberry Pi to a 128 core EPYC server. I'll tell you something about RDS reliabilty, your monthly maintenance window brings your DB down far more often than a single unreplicated server ever fails. EBS (like the entire thing) has failed more times in the last year on us-east-1 than my colo RAID. The selling point of AWS is that if you pick AWS and it fails you can say, well the richest guy in the world can't figure this stuff out so it must be impossible, when in reality high school kids could make a more reliable system. If you pick AWS you have the unreliability of the base software / hardware of their systems plus whatever the AWS engineers fuck up. At this point it's pretty clear that they can't even keep a SAN working.
  - spookthesunset 5y ago
    What about all the config management infrastructure to manage those nginx instances? What is the amount of work required every time some team wants to spin up new stuff? What is the turnaround time between when they file the ticket and the work being completed?
    - _3u10 5y ago
      Oh there’s this great thing called files. You put your config in there and then you can copy them anywhere, even between AWS accounts. They’re even cloud agnostic so when you move to GCP they still work. Files work great with fucking shell scripts, entirely compatible, it’s rumored that shell scripts beneath the hood are also files. https://github.com/brandonhilkert/fucking_shell_scripts https://github.com/brandonhilkert/fucking_shell_scripts You can use FSS on docker, kubernetes, bare metal (otherwise known as computers), Windows, Mac, Amiga, VMS etc. Plan9 which was made by the creators of Go works exceptionally well with files. Some people even say that AWS converts your LB config object to a config file for nginx when it’s provisioned. If you want to get really crazy you can put all your files in one dir like /etc and then you can use this program grep to search all your configs at once. You can even use things like perl -pi to provide a programmatic interface to editing all your configs at once.
      - spookthesunset 5y ago
        Who writes those scripts? How do you hire and attract talent to manage that stuff? How industry standard is it? Can you train them?

by _3u10 5y ago

midasuni 5y ago

The argument isn’t about using AWS to run a VM (which can be cheaper that coloing your own kit, depending how many you want and for how long), it’s all the extra stuff. Start an aws load balancer rather than run and maintain your own for example. I don’t like lock-in, but the prevailing view has always been in favour of lock-in, be it IBM mainframes, oracle databases, windows servers etc, and if you swing that way aws has tempting offers. Oh and databases do scale. Say you want to run end of quarter financials that require a lot of processing for a day, you bring up tons of read replicas and away you go

_3u10 5y ago
If you bought hardware with what you pay for AWS RDS you could run your entire DB in RAM. Hell you could probably put the data in memory on a GPU. Also, this is generally why you run financials overnight. If your hardware is serving transactions during the day it can easily run your quarterlies at night. nginx is far easier to maintain than AWS load balancers which is what load balancers their load balancers are. The best part about nginx configs? They are cloud agnostic and will work on everything from a Raspberry Pi to a 128 core EPYC server. I'll tell you something about RDS reliabilty, your monthly maintenance window brings your DB down far more often than a single unreplicated server ever fails. EBS (like the entire thing) has failed more times in the last year on us-east-1 than my colo RAID. The selling point of AWS is that if you pick AWS and it fails you can say, well the richest guy in the world can't figure this stuff out so it must be impossible, when in reality high school kids could make a more reliable system. If you pick AWS you have the unreliability of the base software / hardware of their systems plus whatever the AWS engineers fuck up. At this point it's pretty clear that they can't even keep a SAN working.
- spookthesunset 5y ago
  What about all the config management infrastructure to manage those nginx instances? What is the amount of work required every time some team wants to spin up new stuff? What is the turnaround time between when they file the ticket and the work being completed?
  - _3u10 5y ago
    Oh there’s this great thing called files. You put your config in there and then you can copy them anywhere, even between AWS accounts. They’re even cloud agnostic so when you move to GCP they still work. Files work great with fucking shell scripts, entirely compatible, it’s rumored that shell scripts beneath the hood are also files. https://github.com/brandonhilkert/fucking_shell_scripts https://github.com/brandonhilkert/fucking_shell_scripts You can use FSS on docker, kubernetes, bare metal (otherwise known as computers), Windows, Mac, Amiga, VMS etc. Plan9 which was made by the creators of Go works exceptionally well with files. Some people even say that AWS converts your LB config object to a config file for nginx when it’s provisioned. If you want to get really crazy you can put all your files in one dir like /etc and then you can use this program grep to search all your configs at once. You can even use things like perl -pi to provide a programmatic interface to editing all your configs at once.
    - spookthesunset 5y ago
      Who writes those scripts? How do you hire and attract talent to manage that stuff? How industry standard is it? Can you train them?