The Amazon S3 crash confirmed talking to users is vital. ISVs must plan for downtime and keep users informed when it goes pear-shaped.

Early on Friday the Amazon S3 cloud storage service crashed in a big way. Lots of websites, some very well known, could not access their data.

Amazon quickly found and fixed the problem. It was not a hardware or network problem as many assumed. Amazon said that the issue was a web service at one of their 3 data centres. The service checks all user requests and SSL links. It was slowed by a sudden peak in SSL requests. Non-SSL requests were blocked. The whole of Amazon S3 stopped.

During and after the problem customers talked about the lack of feedback from Amazon. For the future Amazon will release a service health dashboard. This is a good step and is required; but how would you have responded in the same situation?

You can learn from Amazon’s mistake. Take a look at how this fault was covered by blogs and in the press. How would a problem like this affect your SaaS platform? What will you do when it occurs (and it will, sooner or later)?

Keeping your subscribers informed

Many ISVs now rely on Amazon S3 and EC2 for their SaaS platform. Not all of these ISVs were prepared for a failure in Amazon S3.

Friday’s fault showed how vital it is to inform your subscribers when things go wrong. Amazon did not do this and their customers were upset. In a chain reaction, subscribers to the ISVs sites were also very upset.

What process do you have for when a similar problem occurs on your SaaS platform?

• Do you have monitors to report a change in service status at your back-end suppliers?
• Do you use a DNS redirect to show your subscribers a status page when the system is down?
• Do you have a way to inform logged-in subscribers of the problem?
• Do you run your status and monitoring on a totally independent platform to your main SaaS platform?
• Do you provide status information in human and machine readable forms?
• Do you make it easy for your subscribers to bring your status information into their existing management and support systems?
• Do you have a way to tell your subscribers the system is up again?

Its your problem now

With on-premise software you did not need to worry about all this. These were issues for customers and their IT groups to manage. This all changes with SaaS. You are now offering a service and not just the software. This is now your problem, not theirs.

Do not wait until your SaaS platform crashes. Amazon did not get away with not talking to its customers. Neither can you. Now is the time to plan and prepare!

Were you affected by Friday’s Amazon S3 downtime? If so, how did you tell your subscribers? How did you keep them up to date? How did they react to the downtime?

Tags

SaaS Trust Architecture

My new blog for technical presenters

Our success as technical presenters depends on our ability to get audiences to take action. After all, without action it’s just entertainment!

I’ve given hundreds of technical presentations at all levels in the software industry and have learned that although creating action’s hard, it’s not impossible. I share my experience by curating the best tips and tricks, examples and resources from the web at Tech Presenting. Please join me.