9 ms·

The amount of staff you have to have on-hand and amount of pre-planning (and up-front capital commitment) can all make that very unattractive long after the bas

The amount of staff you have to have on-hand and amount of pre-planning (and up-front capital commitment) can all make that very unattractive long after the basic per-GB price would seem to make it attractive.

b112 5y ago
No. You already have 24x7 staff at this scale. Hardware requires thought and skill, but then so does software. It isn't voodoo.
- fwip 5y ago
  Not always true. Some data is intrinsically bigger than others. If you have a petabyte of chatlogs, sure, you have 24x7 obligations to millions of people. If you have a petabyte of astronomy data, you have like 3 research scientists using it.
  - Robotbeat 5y ago
    The research scientists DEFINITELY can’t afford to run petabytes of astronomy data on AWS. Source: am a research scientist.
    - fwip 5y ago
      Oh, for sure. Just that you don't usually have the amount of dedicated staff that was implied.
- koolba 5y ago
  It is a different skill though. Going from zero to one for physical infrastructure is a significant leap in both cost and operational process. You need to manage inventory, provide 24/7 physical access, and set up supply chains to ensure you have ongoing availability.
  - Spivak 5y ago
    Y'all are making "buy an asset tag printer", "have a rep from Dell/HP" and "use the data center's remote hands if you need it" sound crazy complicated.
  - z3t4 5y ago
    You don't have to do everything in house, you can for example buy servers with a on site support agreement. Then you just have to buy new servers at regular intervals, you don't need to have a guy that can fix a server with a soldering pen. Same for internet connection, you can buy transit, no need to become your own ISP. So you don't need people who deal with peering agreements, etc. For electricity you can make a support deal with a local electrician company. You don't need a guy who can build and maintain a custom power supply unit. It does help however to have someone with basic sysadmin and network skills. But if you don't have that, you will sooner or later screw up your AWS infrastructure too.
    - tomnipotent 5y ago
      > support deal with a local electrician company Maybe if you're wiring a closet in your office, but no colo facility is letting you within ten feet of their power infrastructure. The best you're getting is a racked-mounted UPS.
      - manquer 5y ago
        I think OP means setting up your own DC, for colo most of this is anyway offered by the DC partner, you would only go with something else if there is very good reason not to use what they offer.
        tomnipotent 5y ago
        > I think OP means setting up your own DC This is far more fiscally irresponsible for most companies than just using AWS.
        5y ago
- outworlder 5y ago
  > No. You already have 24x7 staff at this scale. Hardware requires thought and skill, but then so does software. It isn't voodoo. Not necessarily. Hardware requires people to physically replace failed drives and otherwise do on-site maintenance. In the unlikely event that an AWS volume fails, I can (and have) automation to fix that. While everyone sleeps.
  - deeblering4 5y ago
    > Hardware requires people to physically replace failed drives and otherwise do on-site maintenance. This is the premise of colocation (as opposed to building your own server room). A colo is a secure building with round the clock staff. Hardware vendors offer rapid on-site parts replacements and can gain access via the on-site staff, and the colo has services to perform on-site work like "remote hands" as well. > In the unlikely event that an AWS volume fails, I can (and have) automation to fix that. While everyone sleeps. Fault tolerant architectures can be be deployed on colocated hardware too.
    - outworlder 5y ago
      The point is - I can do any changes I need to the underlying resources programmatically and near instantly, without ever having to talk to anyone. Including cloud provider staff. Or rather, automation can. There may exist some colo where I can get a server(or storage, or network cards or anything else) added in minutes over an API call but I haven't heard of any. That's usually found on the VPS side. > Fault tolerant architectures can be be deployed on colocated hardware too. They can, usually requiring that you specifically setup redundancies and the like. Which is something that you already have for many cloud offerings. Your automation and redundancies sit on top of the vendor's existing redundancies. For instance, the EBS volume I mention. It is not a disk. Its not even just an array. It's a far more sophisticated abstraction. If there are issues, it can automatically fetch blocks from your snapshots(if the blocks are unmodified, something they also keep track of). Not happy with spinning disks and want a SSD? No need to place a service order to your colo provider, just send an API call and this will be automatically migrated to SSDs without your applications ever noticing the difference (other than the response time) and with zero downtime. Your software could even do this if it notices that the workloads require it. If an AWS datacenter goes up in flames the systems I manage will still function (and will self-heal, assuming they even get affected, which for big zones they might not be). I don't have to talk to anyone. I can be sleeping and this will still happen. It's a completely different level of abstraction. If you want to compare a big cloud provider with either your own datacenter or colocation facility, there's a big disparity in scale. At a minimum, you would have to compare with several interconnected datacenters or colos. You still don't get the abstraction layer. It's all missing the point though - I was pointing out that software doesn't necessarily need to have 24x7 staff, as the parent poster was pointing out, even for exceptional (but predictable) issues. Sure, you need someone on-call to handle completely unexpected events, but I don't think that was the point being made.

b112 5y ago

No. You already have 24x7 staff at this scale. Hardware requires thought and skill, but then so does software. It isn't voodoo.

fwip 5y ago
Not always true. Some data is intrinsically bigger than others. If you have a petabyte of chatlogs, sure, you have 24x7 obligations to millions of people. If you have a petabyte of astronomy data, you have like 3 research scientists using it.
- Robotbeat 5y ago
  The research scientists DEFINITELY can’t afford to run petabytes of astronomy data on AWS. Source: am a research scientist.
  - fwip 5y ago
    Oh, for sure. Just that you don't usually have the amount of dedicated staff that was implied.
koolba 5y ago
It is a different skill though. Going from zero to one for physical infrastructure is a significant leap in both cost and operational process. You need to manage inventory, provide 24/7 physical access, and set up supply chains to ensure you have ongoing availability.
- Spivak 5y ago
  Y'all are making "buy an asset tag printer", "have a rep from Dell/HP" and "use the data center's remote hands if you need it" sound crazy complicated.
- z3t4 5y ago
  You don't have to do everything in house, you can for example buy servers with a on site support agreement. Then you just have to buy new servers at regular intervals, you don't need to have a guy that can fix a server with a soldering pen. Same for internet connection, you can buy transit, no need to become your own ISP. So you don't need people who deal with peering agreements, etc. For electricity you can make a support deal with a local electrician company. You don't need a guy who can build and maintain a custom power supply unit. It does help however to have someone with basic sysadmin and network skills. But if you don't have that, you will sooner or later screw up your AWS infrastructure too.
  - tomnipotent 5y ago
    > support deal with a local electrician company Maybe if you're wiring a closet in your office, but no colo facility is letting you within ten feet of their power infrastructure. The best you're getting is a racked-mounted UPS.
    - manquer 5y ago
      I think OP means setting up your own DC, for colo most of this is anyway offered by the DC partner, you would only go with something else if there is very good reason not to use what they offer.
      - tomnipotent 5y ago
        > I think OP means setting up your own DC This is far more fiscally irresponsible for most companies than just using AWS.
        5y ago
outworlder 5y ago
> No. You already have 24x7 staff at this scale. Hardware requires thought and skill, but then so does software. It isn't voodoo. Not necessarily. Hardware requires people to physically replace failed drives and otherwise do on-site maintenance. In the unlikely event that an AWS volume fails, I can (and have) automation to fix that. While everyone sleeps.
- deeblering4 5y ago
  > Hardware requires people to physically replace failed drives and otherwise do on-site maintenance. This is the premise of colocation (as opposed to building your own server room). A colo is a secure building with round the clock staff. Hardware vendors offer rapid on-site parts replacements and can gain access via the on-site staff, and the colo has services to perform on-site work like "remote hands" as well. > In the unlikely event that an AWS volume fails, I can (and have) automation to fix that. While everyone sleeps. Fault tolerant architectures can be be deployed on colocated hardware too.
  - outworlder 5y ago
    The point is - I can do any changes I need to the underlying resources programmatically and near instantly, without ever having to talk to anyone. Including cloud provider staff. Or rather, automation can. There may exist some colo where I can get a server(or storage, or network cards or anything else) added in minutes over an API call but I haven't heard of any. That's usually found on the VPS side. > Fault tolerant architectures can be be deployed on colocated hardware too. They can, usually requiring that you specifically setup redundancies and the like. Which is something that you already have for many cloud offerings. Your automation and redundancies sit on top of the vendor's existing redundancies. For instance, the EBS volume I mention. It is not a disk. Its not even just an array. It's a far more sophisticated abstraction. If there are issues, it can automatically fetch blocks from your snapshots(if the blocks are unmodified, something they also keep track of). Not happy with spinning disks and want a SSD? No need to place a service order to your colo provider, just send an API call and this will be automatically migrated to SSDs without your applications ever noticing the difference (other than the response time) and with zero downtime. Your software could even do this if it notices that the workloads require it. If an AWS datacenter goes up in flames the systems I manage will still function (and will self-heal, assuming they even get affected, which for big zones they might not be). I don't have to talk to anyone. I can be sleeping and this will still happen. It's a completely different level of abstraction. If you want to compare a big cloud provider with either your own datacenter or colocation facility, there's a big disparity in scale. At a minimum, you would have to compare with several interconnected datacenters or colos. You still don't get the abstraction layer. It's all missing the point though - I was pointing out that software doesn't necessarily need to have 24x7 staff, as the parent poster was pointing out, even for exceptional (but predictable) issues. Sure, you need someone on-call to handle completely unexpected events, but I don't think that was the point being made.