4 ms·

I don’t quite agree with all the calculations of AWS vs DIY. m3.medium instance - 1 core, 3.75GB RAM, 4GB SSD Typical server this days: 2*10 physical cores, 2

by rkwasny 12y ago

I don’t quite agree with all the calculations of AWS vs DIY. m3.medium instance - 1 core, 3.75GB RAM, 4GB SSD Typical server this days: 2*10 physical cores, 256GB RAM, 2 TB SSD For around ~$10k So you can run AT LEAST 20 m3.medium instances on a physical box (without overbooking). If you use overbooking a single server can handle probably 40 m3.medium class machines. So instead of 100 servers, you need 30, or more probably 20. Bottom line is: People locked in the cloud mindset do not understand how fast physical hardware is this days compared to "cloud" offerings.

jdub 12y ago
People locked in the physical mindset do not understand how flexible cloud infrastructure is these days compared to "metal" offerings. By the way, your rack is on fire.
- deitcher 12y ago
  "by the way, your rack is on fire." LOL!
- beachstartup 12y ago
  http://www.datacenterknowledge.com/archives/2015/01/09/fire-amazon-data-center-construction-site-ashburn-contained/ http://www.datacenterknowledge.com/archives/2015/01/09/fire-...
  - jdub 12y ago
    And isn't it just wonderful how I don't have to give any fucks at all?
    - beachstartup 12y ago
      well, it wasn't in production yet, but it could happen in production, and will. my point was that aws is still metal servers in racks.
  - jdcarr 12y ago
    The point of his comment was that if Amazon have a fire that they'll deal with the issue, you won't have to do anything.
    - beachstartup 12y ago
      if your instances go down you're going to have to deal with it.
      - deitcher 12y ago
        Yes, absolutely. Which means you need to architect and run expecting failure, which is so much different than traditional apps. (I am calling architectures 10 years old, "traditional"; that is funny.)
        beachstartup 12y ago
        you're supposed to architect assuming failure no matter what. it's been like this for years. most engineers just choose to ignore best practices. aws is just the first provider to explicitly tell their users "we don't care if your servers go down. tough cookies." which is what they all should have been doing in the first place.
warfangle 12y ago
When are you running something that's optimized to use all of: CPU, memory, storage? Maybe with something like Riak, I suppose. Compare to one of (reserved instances @ no up-front): (memory): r3.8xlarge: 32vCPU (xeon e5-2670 v2) / 244GB / 6.4TB @ $1.3760/hr (time to cost inversion with spec rounded $10k server: ~302 days) (compute): c4.8xlarge: 36vCPU (xeon e5-2666 v3 haswell) / 60GB / EBS storage @ 1.3760/hr (time to cost inversion with spec rounded $10k server: ... ~302 days) (storage): hs1.8xlarge: 16vCPU / 117GB / 48TB SSD @ $2.5740/hr (time to cost inversion with the 24 of the $10k servers needed to reach that density: ....10 years) Hell, if storage is your thing, 48TB of 800GB Seagate 1200 SSD's alone would cost you $155,026 -- you wouldn't beat AWS's storage cost here until 6.8 years in. And that's not including the rest of the box to drive them. > So instead of 100 servers, you need 30, or more probably 20. Okay, then. $10k * 25 (split the difference, yeah?) vs. 100 * $.05/hr... $250k immediate outlay; you start getting cheaper than AWS (discounting labor, datacenter fees, and replacement hardware -- because I doubt your servers are going to last this long) in just under six years.
- georgebarnett 12y ago
  hs1.8xl's don't come with SSD storage. See http://aws.amazon.com/ec2/instance-types/ http://aws.amazon.com/ec2/instance-types/ where it's not flagged as having SSD's. As I noted above - cloud pricing is hard.
  - warfangle 12y ago
    Ah, you're right.
georgebarnett 12y ago
I'm always wary of posts that proclaim that one thing is definitively better, especially using overly simply comparisons. Cloud offerings and usage have very complicated billing and a huge number of line items. Many of these are very dependant on architecture and deployment choices and are very hard to predict up front. Add to that the complication that the people doing the deployments are often not optimising for price, it's a recipe for a big bill. So on one level, I completely agree with you. In my experience, it's almost always cheaper to hand roll hardware yourself. That said, of all the reasons to move into the cloud, cost should be at the bottom. Instead I feel companies should be asking themselves "Can I gain a competitive advantage by outsourcing my infrastructure?" In many cases, the answer is yes - but it depends on the business; For example I can imagine that a business like Backblaze would not be able to compete as successfully using commodity cloud storage.

by rkwasny 12y ago

jdub 12y ago

People locked in the physical mindset do not understand how flexible cloud infrastructure is these days compared to "metal" offerings. By the way, your rack is on fire.

deitcher 12y ago
"by the way, your rack is on fire." LOL!
beachstartup 12y ago
http://www.datacenterknowledge.com/archives/2015/01/09/fire-amazon-data-center-construction-site-ashburn-contained/ http://www.datacenterknowledge.com/archives/2015/01/09/fire-...
- jdub 12y ago
  And isn't it just wonderful how I don't have to give any fucks at all?
  - beachstartup 12y ago
    well, it wasn't in production yet, but it could happen in production, and will. my point was that aws is still metal servers in racks.
- jdcarr 12y ago
  The point of his comment was that if Amazon have a fire that they'll deal with the issue, you won't have to do anything.
  - beachstartup 12y ago
    if your instances go down you're going to have to deal with it.
    - deitcher 12y ago
      Yes, absolutely. Which means you need to architect and run expecting failure, which is so much different than traditional apps. (I am calling architectures 10 years old, "traditional"; that is funny.)
      - beachstartup 12y ago
        you're supposed to architect assuming failure no matter what. it's been like this for years. most engineers just choose to ignore best practices. aws is just the first provider to explicitly tell their users "we don't care if your servers go down. tough cookies." which is what they all should have been doing in the first place.

warfangle 12y ago

When are you running something that's optimized to use all of: CPU, memory, storage? Maybe with something like Riak, I suppose. Compare to one of (reserved instances @ no up-front): (memory): r3.8xlarge: 32vCPU (xeon e5-2670 v2) / 244GB / 6.4TB @ $1.3760/hr (time to cost inversion with spec rounded $10k server: ~302 days) (compute): c4.8xlarge: 36vCPU (xeon e5-2666 v3 haswell) / 60GB / EBS storage @ 1.3760/hr (time to cost inversion with spec rounded $10k server: ... ~302 days) (storage): hs1.8xlarge: 16vCPU / 117GB / 48TB SSD @ $2.5740/hr (time to cost inversion with the 24 of the $10k servers needed to reach that density: ....10 years) Hell, if storage is your thing, 48TB of 800GB Seagate 1200 SSD's alone would cost you $155,026 -- you wouldn't beat AWS's storage cost here until 6.8 years in. And that's not including the rest of the box to drive them. > So instead of 100 servers, you need 30, or more probably 20. Okay, then. $10k * 25 (split the difference, yeah?) vs. 100 * $.05/hr... $250k immediate outlay; you start getting cheaper than AWS (discounting labor, datacenter fees, and replacement hardware -- because I doubt your servers are going to last this long) in just under six years.

georgebarnett 12y ago
hs1.8xl's don't come with SSD storage. See http://aws.amazon.com/ec2/instance-types/ http://aws.amazon.com/ec2/instance-types/ where it's not flagged as having SSD's. As I noted above - cloud pricing is hard.
- warfangle 12y ago
  Ah, you're right.

georgebarnett 12y ago

I'm always wary of posts that proclaim that one thing is definitively better, especially using overly simply comparisons. Cloud offerings and usage have very complicated billing and a huge number of line items. Many of these are very dependant on architecture and deployment choices and are very hard to predict up front. Add to that the complication that the people doing the deployments are often not optimising for price, it's a recipe for a big bill. So on one level, I completely agree with you. In my experience, it's almost always cheaper to hand roll hardware yourself. That said, of all the reasons to move into the cloud, cost should be at the bottom. Instead I feel companies should be asking themselves "Can I gain a competitive advantage by outsourcing my infrastructure?" In many cases, the answer is yes - but it depends on the business; For example I can imagine that a business like Backblaze would not be able to compete as successfully using commodity cloud storage.