1. Nephophobia
.
Manon Buettner
Principal, Nuvalo
August 18, 2011
2. Nephophobia: n. a fear of clouds
Symptoms may include:
breathlessness, excessive sweating, nausea, dry mouth,
feeling sick, shaking, heart palpitations, inability to speak or
think clearly, a fear of dying or losing control, a sensation of
detachment from reality or a full blown anxiety attack.
You are not the only one to suffer from this phobia.
Most sufferers are surprised to learn that they are far from
alone in this surprisingly common, although often unspoken,
phobia.
2
3. Agenda
Fear of the Cloud – What’s holding you back?
Cloud is not magic
“Do SLAs really matter?”
Charting your course – Where do you begin?
Five levels of redundancy
Conclusion
3
5. It’s not magic – it’s just outsourced
Cloud Computing = centralizing compute resources and taking
advantage of multi-tenancy… NOT a new technology
– Squeezing compute resources to reduce CapEx via
virtualization
– Providers allowing an OpEx model to offer scalability and
shared cost model
YOU own architecture
YOU identify criticality and consequences
YOU now procure these infrastructure resources differently
5
7. Cloud Outages in the Media
Amazon cloud glitch knocks out popular websites
Server outage hits sites Reddit, Quora and Foursquare hard
By Sharon Gaudi
April 21, 2011
Computerworld - Popular websites, including like Quora and Reddit, have
been hampered or totally knocked out today because of server problems in
Amazon.com's data center that handles the company's Web hosting services.
http://www.computerworld.com/s/article/9216036/Amazon_cloud_glitch_knocks_out_pop
ular_websites?taxonomyId=71
7
8. “Do SLA’s Really Matter?”
A 1 year case study of 38 cloud services - January 15, 2011 post
Is there a correlation between SLA and actual availability?
39% met or exceeded SLA
61% did NOT meet SLA
6 lowest performing vendors all provided 100% SLAs
3 of the top 7 performers provided the lowest SLAs
You cannot rely on an SLA for a mission-critical application!
http://blog.cloudharmony.com/2011/01/do-slas-really-matter-1-year-case-study.html
8
9. Charting your Course – Where do you begin?
1. Create a framework for internal discussion
- Education
- Speak the same language “What type of Cloud?”
2. Total Cost of Ownership Analysis
- Baseline financial analysis
- Asset inventories
- Diagrams/Flowcharts interdependencies
- Systems Management
9
10. Charting your Course – Continued
3. Outline your objectives
- What are your strategic and tactical initiatives
- What are you trying to solve? Why?
4. Form consensus on most compelling applications
- Prioritize based on EOL, customer-driven (SLAs,
redundancies), revenue or market share?
5. Define your requirements
- Business: Application availability, who/where are users?
- Technical: HW/SW specs, projected growth, etc.
- Cultural: How will you interact with Provider?
10
11. Charting your Course – Continued
6. How much of OSI stack do you need to own/control?
Facility?
Network?
Storage?
Security?
HW/OS? Database? Application?
Security & Compliance – SOX, HIPAA, PCI, SSAE 16
Where is the hand-off?
11
12. The Five Levels of Redundancy
1. Physical – Most end here!
Traditional N+1
HW, Data Center, vMotion, able to replicate NW topology
2. Virtual Resource
Allocate redundant VMs – not relying on 1 infrastructure
3. Availability zone (all we needed until April!)
Spread VMs across multiple geographic areas
4. Region
Spread VMs outage
5. Cloud
Multiple providers
12
13. Conclusion
We acknowledge giving up control of the infrastructure level
when moving to cloud…
Don’t:
hang your hat on an SLA
assume the cloud will be more robust than your own DC
Do:
Architect for your business objectives
Research proposed providers history, culture, processes
Negotiate contracts to future-proof the business
The cloud is compelling and ready now, but YOU own your brand
13
My name is Manon Buettner and I am the Founder and Principal of Nuvalo, a DC and MgdSvcs Consulting Firm specializing in Cloud Services. I work closely with Executive IT teams to help them understand how to get from where they are today, to where they’d like to be over the next several years. As I was searching for a topic for today’s presentation I felt strongly that the message speak to the relationship between ITO’s and the Cloud Provider. I am in a unique and amazing position to not only learn the challenges and initiatives each ITO face, but also get to know in great detail how the Providers are supporting their clients from every department. Today’s theme of “DFF” specifically addresses
Most fear stems from perception of adopting a new technology, but centralizing resources and the use of mainframes dates back 20 years. The only difference is that now we have virtualization software which allows us to squeeze every bit of compute resources and utilization possible to decrease CapEx. Simultaneously, Providers are allowing an OpEx model to offer scalability and a shared cost model at a time when our economy is struggling.
This is the Cloud Services Stack as defined by Cloudbook.net. I’m a big fan of laying a framework for discussion, andyou’ll see I’ve circled the DC and C/S tiers because this is where IaaS sits. Everyone has their own definition of Cloud, but one thing we can all agree on is that it implies a new purchasing paradigm where traditionally capital intensive acquisitions like HW, SW, and Support contracts are now amortized and bundled with staffing, security, facility and network costs. Where the hand-off is between you and the Provider will differ depending on your business and technical requirements. For example, compliance may dictate that you have a “Managed-Dedicated” environment vs. “Managed-Multi-Tenant.” Or perhaps you ask the Provider to sign your BAA documenting the degree to which they are responsible for your data. The bottom line is that Providers all offer varying degrees of managed services and you must first and foremost decide how much you want OR NEED to own and control. Many Providers aren’t willing to assume as much as you may like!
Thursday's crash happened at Amazon's northern Virginia data center, one of five global sites that underpin EC2. In its status log, Amazon said that the networking glitch caused many of its storage volumes to create new backups of themselves. That filled up Amazon's available storage capacity and kicked off a series of connectivity problems.By late Thursday, Amazon had most of its system running normally, but lingering connectivity problems remained.
Don't let SLAs lull you into a false sense of security. SLAs are most likely influenced more by marketing and legal wrangling than having any basis in technical merits or precedence. SLAs should not be relied upon as a factor in estimating the stability and reliability of a cloud service or for any form of financial recourse in the event of an outage. Most likely any service credits provided will be a drop in the bucket relative to the reduced customer confidence and lost revenue the outage will cause your business. The only reasonable way to determine the actual reliability of a vendor is to use their service or obtain feedback from existing clients or services such as ours. For example, AWS EC2 maintains the lowest SLA of any IaaS vendor we know of, and yet they provide some of the best actual availability (100% for 2 regions, 99.996% and 99.993%). Beware of the fine print. Many cloud vendors utilize minimum continuous outage thresholds such as 30 minutes or 2 hours (e.g. SoftLayer) before they will issue any service credit regardless of whether or not they have met their SLA. In short, we are of the opinion that SLAs really don't matter much at all.An April 2011 survey by CloudHarmony.com compared 38 provider SLAs to their uptimes and found that there was no correlation between the SLA offered and the amount of uptime their clients received. It is my contention that while it is important to contract with providers willing and able to offer aggressive SLAs, I caution you to not rely on this ‘marketing’ tactic alone. You need to be assured the architecture in place substantiates their claims and meets your business needs.
We are going to take a look at five areas under the hood to ensure your cloud architecture is truly capable of the uptime your business applications require to ensure your revenue stream, brand, and competitive advantage.
In a CC environment, there are 5 possible levels of redundancy, meaning the ability to survive failures with zero downtime. You wouldn’t put one server with one application into a location prone to earthquakes – at least you shouldn’t if that application is revenue generating or tied to your brand.
When you are ready to evaluate a migration to cloud, or build the elements we discussed into your hosted infrastructure, I encourage you to save valuable time and resources by seeking help from a firm specializing in IaaS deployments. No company today has the cycles necessary to understand the players, the costs, and the terms.