We see just as much downtown with AWS with DR/HA/MTTR as with colo. You still have to set it all up and maintain it, its just different setup and maintenance than if you actually have a servers in DCs. Most people still have the learning curve with AWS and usually do it incorrectly, or have to wait for Amazon to admit degradation of a service is occurring.

It's really a matter of who within the company wants to know whats behind the curtain. I'd almost always vote for self hosting but its a hard argument internally when everyone thinks the cloud eliminates these issues magically.

> or have to wait for Amazon to admit degradation of a service is occurring.

Please compare apples to apples. If you are comparing to colo, I don't know of any colocation facilities which provide higher level services (say, Kinesis). They might provide some features like CDNs, but nothing very fancy.

You are left with a EC2 vs servers racked in some colocation facility comparison.

At that point, it's not even fair. I can run a terraform script and spin up a copy of the production environment in minutes. I don't have to create purchase orders and wait for hardware. I don't have to issue tickets. If any machine goes down it can be recovered in minutes, and it will spin up in another hypervisor, maybe even a different datacenter.

You don't have to spend time and resources with discussions on how the 'network topology' is going to look like, and then send people off to implement and wire up stuff.

You don't have to spend cycles diagnosing issues just to find out that there's a bad transceiver in a NIC somewhere. YOU DONT CARE. AWS cares and, even if they can't find an issue, stop/start, new hardware in minutes.

You cannot compare the two in good faith. Sure, it might make sense to host some workloads in a colo, but you are giving up a lot.

There is a lot there, and some of it is apples to apples and some is definitely apples to oranges. I'm just saying overall you have the same number of headaches, they are just different headaches. Just last week there was significant degradation that took quite some time to be admitted (admitted might be the wrong word but everyone seemed to know there was an issue with AWS before AWS said their was an issue)

  > I don't have to create purchase orders and wait for hardware.   
  

Why would this need to be done if initial implementation was planned and done correctly? Baring catastrophic hardware failures you shouldn't need to do this? Im nitpicking your comment and I think is tangential to my original point (And dont want to get into a planning/design/implementation discussion either).

> You don't have to spend time and resources with discussions on how the 'network topology' is going to look like, and then send people off to implement and wire up stuff.

This isn't that hard if you still have the expertise in house. Yes it is work and knowhow, but so is AWS networking/wiring, service interop.

> AWS cares

I think this is arguable and YMMV. Sure it depends on who you are and who you talk to.

Im not saying AWS isn't viable tech, and there are 30 ways to skin a cat at the end of the day if you end up with a skinned cat you like you're good to go. I believe most people don't need AWS to accomplish what they are looking for (subjective for sure). I also find it not the savings or experience that is in the marketing materials or sales pitches. This isn't a binary right or wrong decision, all we need is a skinned cat at the end of the day.

>Why would this need to be done if initial implementation was planned and done correctly?

Anyone who thinks they planned everything correctly is just deluding themselves. Admitting you've fucked up, don't know how you fucked up yet but will one day need to fix the fuckup is very important in engineering.

It's possible but not to think enough through the process that you need to create purchases orders large enough to need approvals? However if you don't have a basic understanding of hardware you'll need you probably shouldn't be working/in charge of this proejct anyhow. If you fked up this bad you're in for a bad time regardless of where you've decided to host.

That's the thing about this argument- it gets sold as not having to worry about something (racking etc) except the reality is it's just a different worry.

Setting up and maintaining Terraform scripts to manage your AWS infrastructure takes time and effort; besides, there’s this nagging feeling that should something happens to Terraform you’d suddenly be left trying to keep track of hundreds of resources (which cost you money each hour, or millisecond in case of Lambda) and their access policies “by hand”.

On the other hand, it could be a very powerful combo.

What’s CAB?