I’m using iPage as my cloud based server provider. I haven’t had any problems with them yet. They hold the scripts for my RESTful services for the mobile app I’m developing. My problem however is that tonight the service went down. I got a “This is a 500” error.
I’m wondering how do I build redundancy into my RESTful services to prevent this stuff from happening. They say it’ll be 2 hours at least until they can solve this problem. If my app is live I can’t wait 2 hours. My users will get annoyed. I know this happens anyway but how can I build redundancies to prevent it.
1
A traditional trade-off in outsourcing any part of the business to a supplier, not just cloud computing: you get to give up working on the bits that are “plumbing” in what you offer, and focus on the parts where you think you can add most value. On the other hand, you give up control of the plumbing to another company, which introduces its own risks.
Your options are:
-
accept that outages like this might happen.
-
to have some Service Level Agreement with your supplier so that if they can’t satisfy your availability requirements you can penalise them. This doesn’t stop your customers getting angry, but provides some financial restitution should your service become unavailable.
-
use a different supplier with a better ability to suit your needs.
-
handle the server provision yourself. That has some costs in terms of hardware, bandwidth, power, cooling, administration time and so on, but puts you in control of what you say is a key part of your work.
-
outsource the backend to multiple suppliers. You could host a load-balancer, so that requests go to servers from different companies. Should one backend go down, you can configure the load-balancer not to point to it. However, notice that this just moves the problem up the chain: your load-balancer is now a single point of failure. How do you ensure that box doesn’t go offline for two hours? Also, this solution introduces new problems: do the backends need to be in sync? How is that managed? How does that synchronisation recover from an outage? Can you afford to pay multiple providers? And so on.
I can think of to types of redundance:
- Have a second fallback provider that hosts a copy of your REST service and a mirror of your data and let your app call the fallback if the main system is down.
- have a local file copy of your last rest-service-calls-results in case that the server is offline.
both solutions can be costly. The alternative is to accept the downtime and tell your appusers
"Sorry, the Servers is down for maintanance reasons. Please try again later"