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.
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.
This is far more fiscally irresponsible for most companies than just using AWS.
We can argue whether it is billion dollars or few millions , but there are 1000s companies spending 50million + or even 500 million a year on compute globally.
For a lot of these companies it would make economic sense to keep their own DCs , however hiring that talent and retaining is very very hard, especially if you need even 1-100th of what AWS offers in their IaaS services, this is what will cost a company a lot more than cloud.
It is really shortage in devops/sysads that drives cloud . The talent shortage is just getting worse, newer devops engineers who know only k8s blink seeing a bare metal VM let alone know how to do proper cable management.
No, it's not. I've have never once met a company that went cloud because they couldn't find someone to rack and configure infrastructure. There's considerably more to building and running a data center than just hiring staff.
This thread is full of comments making it sound that running your own hardware is black magic and cloud is the only way to deploy at scale. Yes it is hard, but not so hard that spending $500 Million/year [1] on cloud is cheaper than running your own DC.
It is even harder for companies that already had investments in DC operations to justify.
Leveraging public clouds for workloads that need flexible scaling or use cloud native services which are not cost effective / feasible to develop in-house it always makes sense to shift, however the lift and shift for everything we have been seeing has no justification for companies already running their own infra unless developers and system admins are demanding cloud, either they want cloud in their resumes or don't know how anymore to write traditional applications.
Many enterprise apps even today are not cloud native or leverage anything beyond basic compute and storage IaaS services and do not have high load variations and not even set to auto-scale, they never had technical or economic reasons to be moved to the cloud if you already had sunk costs running a DC.
[1] We can argue what that number is all day , when including everything you need to do run a DC it is cheaper than on the Cloud. There is a definitely a number, as at very top end of usage companies like Apple or Facebook etc are not sitting on top of AWS and it would never make sense for them at their scale, somewhere in between that point does exist.
The rest of your comment makes it clear you're entirely speculating, like hiring being an obstacle to spending tens of millions of dollars to build a DC.
I am not entirely speculating, I have been part of the recruitment industry for the last decade, but you have already decided to discard statements from a random stranger on the internet (totally reasonable!) so no point in arguing this further.
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.
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.
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.
To be fair, you can't get hardware added in AWS via API call either. What you can do is spin up instances/storage/etc via API call, as long as that spare capacity hardware is already set up, available and ready to be allocated to you. Which you can also do on on-prem hardware.
If you're saying that your utilization is so peaky or unpredictable that you end up needing an order of magnitude more, or fewer, resources available day to day, then you are absolutely correct that provisioning so much spare capacity on-prem would be prohibitive. This is an use-case where AWS excels.
But if your utilization doesn't have dramatic peaks and growth is mostly predictable, then it becomes practical to provision for it on-prem and it'll be a lot cheaper.
You're right, hypergrowth (a subset of unpredictable capacity needs) is a perfect use case for AWS or similar.
The vast majority of companies, for the majority of their corporate life, aren't in these categories (spiky, unpredictably) phase though, so for those, AWS is a large cost premium.
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.