Isn't this exactly the 'single point of failure' that we are always warned to guard against, whether in our coding or deployments? Yet here in our daily lives people can't get the lights on or make coffee.
Yeah I’m ok not having my coffee made by something “smart” that depends on AWS. There’s a trend of making everything aware. But in my experience, it’s often implemented poorly, with terrible UI, and insecurely. Just look at the absolute trash they call “infotainment” in some cars. You buy a new car and feel like the infotainment is from 2006. The Internet of Crappy Things is real. There are notable exceptions, but too often “smart” is just a junky screen that send back information on me to monetize me. Do I care if some marketing company knows how many cups of coffee I drink? Maybe not, but maybe a health insurance risk database does. And I bet there are nearly zero controls over that harvested data being kept by the SmartBrew2.0
Don’t forget. In addition to smart products generally being poorer quality overall, the manufacturer can decided to pull the plug on the backend at any time and leave your product bricked. Who continues to buy such utter crap?
There’s always more you can do to drive up availability but it comes at a cost and at some point the cost exceeds the prevented losses. There’s also no real brand damage from being down when everybody else is also down due to a common and widely accepted dependency (“nobody got fired for buying IBM”). So given the SLAs offered by cloud providers like AWS it really is the most economically feasible solution.
9 comments
[ 3.0 ms ] story [ 31.6 ms ] threadSo the issue here was part aws centralization, part services not being ready for failure.
My company uses aws to run hundreds of serverless services and our infrastructure was not impacted despite half of it being on US region.
Also, I had no idea there was an outage.