April 10, 2012 3 Comments
Last week I was in Miami presenting at Sogeti’s Windows Azure Privilege Club summit. Had a great time, talked with some smart, brave, and generally great people about cloud computing and Windows Azure. But what really struck me was how little was out there about how to properly architect solutions so that they can take advantage of the promise of cloud computing.
So I figured I’d start putting some thoughts down in advance of maybe trying to write a whitepaper on the subject.
What is an SLA?
So when folks start thinking about uptime, the first thing that generally pops to mind is the vendor service level agreements, or SLA’s.
An SLA, for lack of a better definition is a contract or agreement that provides financial penalties if specific metrics are not met. For cloud, these metrics are generally expressed as a percentage of service availability/accessibility during a given period. What this isn’t, is a promise that things will be “up”, only that when they aren’t, the vendor/provider has some type of penalty they will pay. This penalty is usually a reimbursement of fees you paid.
Notice I wrote that as “when” things fail, not if. Failure is inevitable. And we need to start by recognizing this.
What are after?
With that out of the way, we need to look at what we’re after. We’re not after “the nines”. What we’re wanting is to protect ourselves from any potential losses that we could incur if our solutions are not available.
We are looking for protection from:
- Hardware failures
- Data corruption (malicious & accidental)
- Failure of connectivity/networking
- Loss of Facilities
- <insert names of any of 10,000 faceless demons here>
- And since these types of issues are inevitable, we need to make sure our solution can handle them gracefully. In other words, we need to design our solutions to be resilient.
What is resilience?
To take a quote from the Bing dictionary:
Namely we need solutions that can self recovery from problems. This ability to flex and handle outages and easily return to full functionality when the underlying outages are resolved are what make your solution a success. Not the SLA your vendor gave you.
If you were Netflix, you test this with their appropriately named “chaos monkey”.
How do we create resilient systems?
Now that is an overloaded question and possibly a good topic for someone doctoral thesis. So I’m not going to answer that in today’s blog post. What I’d like to do instead of explore some concepts in future posts. Yes, I know I still need to finish my PHP series. But for now, I can at least set things up.
First off, assume everything can fail. Because at some point or another it will.
Next up, handle errors gracefully. “We’re having technical difficulties, please come back later” can be considered an approach to resilience. Its certainly better then a generic 404 or 500 http error.
Lastly, determine what resilience is worth for you. While creating a system that will NEVER go down is conceivably possible, it will likely be cost prohibitive. So you need to clear understand what you need and what you’re willing to pay for.
For now, that’s all I really wanted to get off my chest. I’ll publish some posts over the next few weeks that focus on some 10,000 foot high options for achieving resilience. Maybe after that, we’ can look at how these apply to Windows Azure specifically.
Until next time!