Hacker News Reader

Comment by dylan604 | Hacker News Reader

The fun thing about these types of outages are seeing all of the people that depend upon these services with no graceful fallback. My roomba app will not even launch because of the AWS outage. I understand that the app gets "updates" from the cloud. In this case "updates" is usually promotional crap, but whatevs. However, for this to prevent the app launching in a manner that I can control my local device is total BS. If you can't connect to the cloud, fail, move on and load the app so that local things are allowed to work.

I'm guessing other IoT things suffer from this same short sitedness as well.

View on HN

If you did that some clever person would set up their PiHole so that their device just always worked, and then you couldn't send them ads and surveil them. They'd tell their friends and then everyone would just use their local devices locally. Totally irresponsible what you're suggesting.

A little off-topic, but there are people working on it: https://valetudo.cloud/

It's a little harder than blocking the DNS unfortunately. But nonetheless it always brings a smile to my face to see that there's a FOSS frontier for everything.

An even more clever person would package up this box, and sell it, along with a companion subscription service, to help busy folks like myself.

But this new little box would then be required to connect to the home server to receive updates. Guess what? No updates, no worky!! It's a vicious circle!!! Outages all the way down

this is why everyone runs piholes and no one sees ads on the internet anymore, which killed the internet ad industry

Dear person from the future, can you give me a hint on who wins the upcoming sporting events? I'm asking for a friend of course

Also, what's the verdict on John Titor?

>The fun thing about these types of outages are seeing all of the people that depend upon these services with no graceful fallback.

Whats a graceful fallback? Switching to another hosting service when AWS goes down? Wouldn't that present another set of complications for a very small edge case at huge cost?

In this case, just connect over LAN.

Or BlueTooth.

Well, BT is a hell of a protocol. I wouldn't wish that on anyone.

Right -- I think I've misread OP as graceful fallback e.g. working offline.

Rather than implement a dynamically switching backup in the event of AWS going down which is not trivial.

> Wouldn't that present another set of complications for a very small edge case at huge cost?

One has to crunch the numbers. What does a service outage cost your business every minute/hour/day/etc in terms of lost revenue, reputational damage, violated SLAs, and other factors? For some enterprises, it's well worth the added expense and trouble of having multi-site active-active setups that span clouds and on-prem.

Usually this refers to falling back to a different region in AWS. It's typical for systems to be deployed in multiple regions due to latency concerns, but it's also important for resiliency. What you call "a very small edge case" is occurring as we speak, and if you're vulnerable to it you could be losing millions of dollars.

AWS itself has a huge single point of failure on us-east-1 region. Usually, if us-east-1 goes down, others soon follow. At that point, it doesn't matter how many regions you're deploying to.

My workloads on Sydney and London are unaffected. I can't speak for anywhere else.

"Usually"? When has that ever happened?

https://awsmaniac.com/aws-outages/

Thanks. That shows that OPs claim that "Usually, if us-east-1 goes down, others soon follow." is false.

Cognito (and r53) have hard dependencies in us-east-1. It’s mentioned up and down this thread.

I don't want to minimize the impact from cognito and r53, but that's quite a different scale of failure than the OP implies. It's been a while since I used AWS, but we had multiple regions and saw no impact to our services in other regions the one time that us-east-1 had a major failure. And we used r53.

Perhaps I could've been more precise with my words. What I meant to say is IAM and r53 are two of many critical services that all depend on us-east-1. It goes without saying that if those services go down in us-east-1, the whole AWS is affected. This doesn't just happen "usually." When IAM goes down, AWS experiences major issues across all regions. If you were okay, perhaps you got lucky? Our team has 7 different prod regions and we see multiple regions go down every time a problem of this scale occurs.

If your product requires 100% uptime, you may need to look at backup options or design your product in such a way that can handle temporary cloud failures.

probably not possible for a lot mroe services than you'd think because AWS Cognito has no decent failover method

I heard from someone at <big media company> that they couldn't switch to their fallback region because they couldn't update DNS on Route53. All the console commands and web interface were failing.

There is a company that delivers broadcast video ads to hundreds of TV stations on demand. The ad has to run and run now, so they cannot tolerate failure.

They write the videos to GCS storage in Google Cloud, and to S3 in AWS. Every point of their workflows are checkpointed and cross referenced across GCP and AWS. If either side drops the ball, the other picks it up.

So yes, you can design a super fault tolerant system. This company did it because failing to deliver a few ads would mean lose of major contracts.

Now think of how many assets of various governments' militaries are discreetly employed as normal operational staff by FAAMG in the USA and have access to cause such events from scratch. I would imagine that the US IC (CIA/NSA) already does some free consulting for these giant companies to this end, because they are invested in that Not Being Possible (indeed, it's their job).

There is a societal resilience benefit to not having unnecessary cloud dependencies beyond the privacy stuff. It makes your society and economy more robust if you can continue in the face of remote failures/errors.

It is December 7th, after all.

> I would imagine that the US IC (CIA/NSA) already does some free consulting for these giant companies to this end,

Haha, it would be funny if the IC reaches out to BigTech when failures occur to let them know they need not be worried about data loses. They can just borrow a copy of the data IC is siphoning off them. /s?

> I would imagine that the US IC (CIA/NSA) already does some free consulting for these giant companies

This comment is how I know you don't work in the public sector. Those agencies' infrastructures are essentially run by contractors with a few GS personnel making bad decisions every chance they get and a few DoD personnel acting like their rank can fix technical problems.

I'm not talking about running infrastructure, I'm talking about working with HR and making sure that the people they've hired as sysadmins aren't meeting with FSB or PLA agents in a local park on weekends and accepting suitcases of USD cash to accidentally `rm -rf` all of the Zookeeper/etcd nodes at once on a Monday morning.

I doubt it. We’re shit at critical infrastructure defense and the military cares mostly about its own networks. And industry really doesn’t want to cooperate. I was in cyber and military IT. Can’t speak for the IC, but I really doubt it.

I wouldn't jump to say it's short sitedness (it is shitty) but it could be a matter of being pragmatic... It's easier to maintain the code if it is loaded at run time (think thin client browser style). This way your iot device can load the lastest code and even settings from the cloud... (advantage when the cloud is available)... I think of this less of short sitedness and more a reasonable trade off (with shitty side effects)

Then you could just keep a local copy available as a fallback in case the latest code cannot be fetched. Not doing the bare minimum and screwing the end user isn't acceptable IMHO. But I also understand that'd take some engineer hours and report virtually no benefits as these outages are rare (not sure how Roomba's reliability is in general on the other hand) so here we are.

I don't think that's ever a reasonable tradeoff! Network access goes down all the time, and should be a fundamental assumption of any software.

Maybe I'm too old, but I can't imagine a seasoned dev, much less a tech lead, omitting planning for that failure mode

there's a reason it is called the Internet of things, and not the "local network of things". Even if the latter is probably what most customers would prefer.

There’s also no reason for an internet connected app to crash on load when there is no access to the internet services.

indeed.

A constitutional property of a network is it's volatility. Nodes may fail. Edges may. You may not. Or you may. But then you're delivering no reliabilty but crap. Nice sunshine crap, maybe.

The internet was originally designed to still work if there was a nuclear strike on a node. Now we can’t even cope with us-west-1 down.

In a traditional internet style architecture, your Roomba and phone would both have globally routable addresses and could directly communicate - your local network would provide hosts with internet connectivity.

"If you can't connect to the cloud, fail, move on and load the app so that local things are allowed to work."

Building fallbacks require work. How much extra effort and overhead is needed to build something like this ? Sometimes the cost vs benefits says that it is ok not to do it. If AWS has an outage like this once a year, maybe we can deal with it (unless you are working with mission critical apps).

Yes, it is a lot of work to test if response code is OK or not, or if a timeout limit has been reached. So much so, I pretty much wrote the test in the first sentence. Phew. 10x coder right here!

Remember the Signal outage? Which is to say, the testing is the problem, not the implementation itself. (Which isn’t to say I think it’s optional—I myself generally don’t run online-only local-by-their-nature things.)

Reply on news.ycombinator.com