3 ms·

It's almost 2017. The scaling choices are not limited to Docker vs. bare metal. With their budget, you should be able to clone and scale metal servers within m

by korzun 10y ago

It's almost 2017. The scaling choices are not limited to Docker vs. bare metal. With their budget, you should be able to clone and scale metal servers within minutes if you wanted to. This is like Tumblr spending $50,000 grand a month on their developer AWS instances while not making any money. Cool but not very practical.

evanelias 10y ago
Not sure if you were just using a made-up example, but Tumblr primarily isn't on EC2 and never has been. For compute they were bare-metal from the start and moved to their own self-managed datacenters in 2012.
VLM 10y ago
Bare metal is operationally very expensive because someone has to monitor it, back it up, patch it, test it, fix the software when it breaks at 2am, fix the hardware when it breaks at 2am, explain to security that its either full of confidential stuff or not, decommission it years later, and none of that is as standardized as virtualized or containerized stuff. Also "in the olden days" we had prod servers but shared dev and test servers. Now a days you just spin up resources assuming your ops is flexible enough. I'll spin up a test image to eliminate one bug and then destroy it, no sweat. In theory you can do that with metal but the accounting must be weird. You could make a pool of bare metal test boxes for people to use as they please, I guess... I also like spinning up new images for software upgrades. Oh, a new version of the database, here's a new image, test it out. Some of it is organizational hacking. After a few legendary disasters procedures will be formulated where standing up new iron takes interdepartmental meetings and signing off with the network and security and ops teams and the data center guy has to sign off on the thermal and electrical loads and power points all over the place. In comparison, you wouldn't make someone changing a cell in a spreadsheet go thru all that, right? So you deploying a virtual image is just clicking a harmless little button, as long as you operate under a blanket agreement with ops, infosec, networking, etc... At least until enough legendary disasters inevitably happen that clicking "create" on a virtual image requires weeks of time and at least 4 signatures and 3 departmental meetings of micromanagement. Hopefully we'll invent something new by then.

by korzun 10y ago

evanelias 10y ago

Not sure if you were just using a made-up example, but Tumblr primarily isn't on EC2 and never has been. For compute they were bare-metal from the start and moved to their own self-managed datacenters in 2012.

VLM 10y ago

Bare metal is operationally very expensive because someone has to monitor it, back it up, patch it, test it, fix the software when it breaks at 2am, fix the hardware when it breaks at 2am, explain to security that its either full of confidential stuff or not, decommission it years later, and none of that is as standardized as virtualized or containerized stuff. Also "in the olden days" we had prod servers but shared dev and test servers. Now a days you just spin up resources assuming your ops is flexible enough. I'll spin up a test image to eliminate one bug and then destroy it, no sweat. In theory you can do that with metal but the accounting must be weird. You could make a pool of bare metal test boxes for people to use as they please, I guess... I also like spinning up new images for software upgrades. Oh, a new version of the database, here's a new image, test it out. Some of it is organizational hacking. After a few legendary disasters procedures will be formulated where standing up new iron takes interdepartmental meetings and signing off with the network and security and ops teams and the data center guy has to sign off on the thermal and electrical loads and power points all over the place. In comparison, you wouldn't make someone changing a cell in a spreadsheet go thru all that, right? So you deploying a virtual image is just clicking a harmless little button, as long as you operate under a blanket agreement with ops, infosec, networking, etc... At least until enough legendary disasters inevitably happen that clicking "create" on a virtual image requires weeks of time and at least 4 signatures and 3 departmental meetings of micromanagement. Hopefully we'll invent something new by then.