Hacker News new | comments | show | ask | jobs | submit login

I mean, that's not really AWS's problem, is it? Outages happen. If you have a mission-critical service like health care, you really shouldn't write systems with single points of failure like this, especially not systems that depend on something consumer-grade like S3.

This appears to be a normal doctor's office where there are routine appointments. Emergencies would be referred to the ER anyway. And while I obviously don't know the details of how his office is run, you'd think that you could get by on a pen-and-paper fallback to manage the office. Maybe that's an advantage to keeping experienced office staff on board.

I work in the healthcare industry and there's a big push from AWS into offering HIPAA compliant services for things like patient records. It's becoming much more common to tie in third party services into electronic healthcare software. Obviously no mission critical system should have a single point of failure and doctor's offices should have fallback plans for handling service outages, but most care providers don't have staff onsite with the technical expertise to understand the extent of the coupling. I'm just closely watching this space and found that tweet interesting in relation to the parent comment's remark about realizing the scope of this S3 outage. There's no blame unique to AWS here, but it is becoming an increasingly important piece of plumbing in the industry.

Fine. But that's just buying into one of the very common misconceptions about AWS (or any hosting provider), no? This idea that Amazon sells a fault tolerant product. They don't. Amazon sells you tools that can make a fault tolerant product, but making your own product resilient is entirely upon you.

Whatever software that doctor is using should have been built with offline capability (local storage, syncs to servers when network connectivity is restored).

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact