An informal SLA
In this post, Brad Feld describes the following as the best SLA he’s ever seen:
Our SLA is fairly simple (and I’m happy to write it up for you in more official language):
- We can’t control data publishers’ availability, but if they’re up, we’ll get the data.
- Machines and clouds fail, even on EC2. If Amazon is up, we’ll get the data.
- The best way to guard against machine failure is duplicate hardware. We offer highly discounted backup boxes.
- You’ll always have my cell phone number — if our software breaks, you can call me 24/7 and I’ll get my team on it.
- If we aren’t living up to our end of the relationship, you can cancel the contract with no penalty.
This was actually the response of Gnip‘s CEO to a customer who asked what’s their SLA.
I find it an interesting approach, as it makes more apparent the direct relationship between the customer and the service provider, and builds on trust and good will. So there’s certainly a lot value to it in smaller setups. Nevertheless, I can’t see how could anyone use that successfully with critical services, e.g. investment banking. At the end of the day, if Amazon’s EC2 fails, and you (as a service provider) rely on it, it’s not your customer’s problem — he signed a contract with you, not Amazon.
This is just to say, strict SLAs may not be necessary in simpler cases, but for those kinds of services that make the world go around, it’s hard to do without them.
