Is it possible for AWS to have a multi-region outage - as in is there anything connecting them that could bring them all (or several) down at once? (Apart from the result of a botched patching or update to the core software stack that was done worldwide at the same time and hopefully never happens).
Is Amazon's cloud service too big to fail?
31–40 of 164 posts
Re: Is Amazon's cloud service too big to fail?
#32What would be great is the equivalent of the ACME protocol for cloud service providers. That will take a while and shouldn't happen until the offering matures and stabilises. But in an ideal world you wouldn't tie your application to a specific cloud provider. You should be able to lift and shift to another provider. Which I think is a merit of using VMs as opposed to individual services.
Re: Is Amazon's cloud service too big to fail?
#33Earlier quoted context omitted.
It is one of the issues with choosing the cloud providers and taking their stack. They are hoping the cost of swapping once bought into their way is too costly to a competitor who can offer similar service cheaper. Lockin used to be considered bad but something changed with cloud providers and ops/developers don't seem to care as much anymore.
Maybe because pricing by, say Amazon, is published on their web site and therefore, the same for everyone ? Whereas before, when you were with one supplier, he could make specific price for you and leverage its position to make you pay more ? dunno...
Re: Is Amazon's cloud service too big to fail?
#34That's why I think containerization and orchestration will be useful; open source orchestrators can standardize the infrastructure and make switching seamless. That way the infrastructure remains a commodity.
Re: Is Amazon's cloud service too big to fail?
#35What would be great is the equivalent of the ACME protocol for cloud service providers. That will take a while and shouldn't happen until the offering matures and stabilises. But in an ideal world you wouldn't tie your application to a specific cloud provider. You should be able to lift and shift to another provider. Which I think is a merit of using VMs as opposed to individual services.
ACME protocol?
Re: Is Amazon's cloud service too big to fail?
#36This is (I was surprised) a pretty good article. Financial services are regulated and based on recent experience, they're concerned with systemic risk. Most industries do not have anyone responsible for worrying about this kind of thing. It seems reasonable to start worrying about the fragility potentially introduced by these massive internet infrastructure companies.
If you wanted to blow something up to make the west suffer, an AWS datacenter would probably be a pretty good target. I wonder at what point that becomes a legitimate national security concern, and the government steps in to provide protection.
There are a LOT of far softer targets that go unprotected. A terrorist attack on a sewage plant for a major city would be far more devastating than knocking out a few websites.
Re: Is Amazon's cloud service too big to fail?
#37Earlier quoted context omitted.
I don't know about ELB, EFS and ASG but: - S3 has a public protocol and many 3rd party providers support it (OpenIO, Scality, Ceph, Minio, etc), - EFS could be replaced with something like DRDB or GlusterFS, or DigitalOcean's block storage or Google Cloud's networked disks. - ELB could be replaced easily with similar services from other providers [1] if you use Kubernetes (I don't know if all have a LoadBalancer type…
One good way is to have automated tests which make sure that those rules actually work. What if all your AWS rules suddenly get deleted. How are you supposed to know if you have not forgotten any.
Heap has a great blog post on Terraform : https://heap.engineering/terraform-gotchas/
Re: Is Amazon's cloud service too big to fail?
#38Earlier quoted context omitted.
If you wanted to blow something up to make the west suffer, an AWS datacenter would probably be a pretty good target. I wonder at what point that becomes a legitimate national security concern, and the government steps in to provide protection.
legitimate national security concern, and the government steps in to provide protection There are a LOT of far softer targets that go unprotected. A terrorist attack on a sewage plant for a major city would be far more devastating than knocking out a few websites.
Re: Is Amazon's cloud service too big to fail?
#39Earlier quoted context omitted.
That's pretty much what Azure Stack is: https://azure.microsoft.com/en-gb/overview/azure-stack/ There might well be a commercial niche for providing Azure Stack hosting in non-Microsoft data centers.
I think there is a massive market for 100% cloud-compatible local deployments. In my personal experience every .Net shop I've seen would love to be incorporating more Azure goodness locally, but can't as they're cloud specific techs which bump into the realities of deployment and maintenance. Personally, I think MS crapped the bed a little by taking Azure Stack off of commodity hardware and onto a combined hardware/s…
"“So if the performance is dropping, do you call the server manufacturer, do you call the networking manufacturer, do you call the load balancer manufacturer, do you call the storage manufacturer? They typically point the finger at the other guy and you spend weeks and months trying to debug and get your cloud to work."
https://www.theregister.co.uk/2017/07/10/interview_with_micr...
We can all relate to that. A "cloud" is sufficiently complex that vendor blaming is an almost guaranteed outcome.
Re: Is Amazon's cloud service too big to fail?
#40What would be great is the equivalent of the ACME protocol for cloud service providers. That will take a while and shouldn't happen until the offering matures and stabilises. But in an ideal world you wouldn't tie your application to a specific cloud provider. You should be able to lift and shift to another provider. Which I think is a merit of using VMs as opposed to individual services.
You can do that easily if you just treat clouds merely as hosted hypervisors and think entirely in terms of VMDKs. But this doesn't make commercial sense to do at least in the short term - you need to utilise the layered services you are paying for anyway or you might as well just run your own DC.