How Will You Cope With A Cloud Disaster?

What happens when a cloud service fails?

What happens when a cloud provider has a disaster?

How does your business continue?

Why does my internal IT cost me so much more than buying a few VMs from a cloud provider?

I've recently read some interesting points on this topic (they are paraphrased below and the authors will not be named), which gives me cause to think about the approaches that businesses are taking to cloud services, and some of the areas which appear to be adding risk to their business for their business critical IT services.  Here are a couple of examples and why they're not correct:

"One of the benefits of cloud is that IT service continuity becomes the problem of the service provider".  No!  This is one of the most concerning statements I've seen recently.  Service continuity is never the problem for the service provider.  It is always the concern of the business consuming that service.  It is possible that the way in which the service continuity is provided is within the remit of the service provider, but the continuity of the service itself is the problem of the consuming business.  Your business must ensure that the right provisions are in place, either through contractual arrangements (guaranteed service level agreements, recovery point objectives, recovery time objectives all with penalties which are commensurate with the business you will be loosing if these are not met) or, your business needs to think about service design as part of adopting cloud. See thoughts further down this article.

"public clouds do not offer disaster recovery".  That's also not strictly true.  By default, most probably don't.  However, many will offer the option to add such services.  Also, if you have an application that can run in multiple sites to provide high availability (HA) facilities, by agreeing with your service provider that they guarantee to run your application in multiple sites, then your HA can become your disaster recovery (DR) approach.  Also, the public cloud could be your DR facility - more later.

So a cloud strategy, just like any other IT strategy, needs back ups and DR plans. To dismiss public cloud as not providing DR is missing some of the options, equally to just assume that the service provider will look after DR is equally problematical. There are many approaches to this, and I'll suggest some below, but this isn't a comprehensive list or guide, its here to provoke some thoughts and some ideas.

By default, public cloud usually does not include DR in the traditional sense. However, by carefully selecting multiple cloud providers for a single business process or a cloud provider who can guarantee your systems will run in multiple sites, DR can be achieved - as long as your application is also designed with multi-site capabilities. In this case, DR is essentially just an extension of your HA approach.

Additionally, cloud can be part of your DR strategy. For example, you can run all your systems in house and upload data and source code up to cloud services on a regular basis. With the right process design and cloud service provider contract you can then invoke your DR by running that code and using that data that is stored in the cloud wherever your cloud provider has the capacity available.

So be careful how you design your service provision.  Think about the options, of which these are some:

- multiple physical locations offered by your service provider (make sure your data is still geographically compatible with relevant regulations, and your applications are designed for multi-site use);
- service provider provisioning of DR processes and facilities.  Make sure the design and contractual arrangements meet the business criticality of the system.  Where contractual penalties are agreed, make sure an hour of penalties equals or exceeds an hour of lost business, and this is maintained as business volumes fluctate;
- choose multiple service providers for the same service on a continuous basis - make sure they don't share data centre facilities;
- choose one service provider to provide the service on an ongoing basis, and another to provide quick burstable capacity for use in a DR situation.  Design processes to ensure that the second service provider has current copies of your systems and regular updates of data, commensurate with your recovery point and recovery time objectives;
- use the cloud as your DR strategy for your in-house systems.  Regular copies of systems and data up to the cloud provider with a contract that allows you to start up your systems very quickly.  Treating the cloud provider as your second "warm" standby data centre is a viable approach.

Make sure you use one of the above, or a similar approach to ensuring your business can continue when there's an IT disaster and make sure that each of the above can meet your security requirements. And test them frequently to make sure whichever approach you choose, actually delivers to the design parameters and service requirements.  Remember that when to invoke, how to invoke and who is responsible for what during invocation is just as important as the IT elements.  Also cover what happens when the disaster is over and you need to return to your regular service provision - getting back to normal can be just as hard or harder than invoking disaster recovery.

When comparing the costs of your internal IT with the cost of buying a few VMs from a cloud provider, remember that you are unlikely to be comparing apples with apples - make sure the capacities, performance and guarantees of up time and recovery time are equal.  Only then will costs of the insurance service provided by most internal IT teams become more apparent.  Its surprising how quickly the cost of a cloud service escalates when you truly match the service levels to existing provision.  This is one of the greatest risks with shadow IT services - they are often not comparable to internal services and are often putting critical business processes at risk.

Or choose to take the risk of course - that's always an option, as some business services are not critical to the business - if you can afford for service to be unavailable for a few days or weeks, then its probably appropriate not to pay for contingency planning up front.

What Are The Top 3 Benefits of Cloud?

 Thanks to linked in user Brian Murphy for raising the following question:

What are the top 3 benefits of cloud computing?

Here are my musings:
The top 3 benefits will vary by customer size, complexity, maturity, market vertical etc.  What do I mean by this?
Well, for an SMB, lower cost may be number 1, but they'll only get that if they buy from public cloud - they won't achieve lower cost if they build a private cloud from scratch until they reach a critical mass..



For a large organisation's dev and test teams, agility, low cost of entry, ability to tear the environment down when they've finished etc., will be a great benefit.  If they're doing that in a public cloud offering, that could well be acceptable for that particular use case.  But for a production environment in the same organisation's highly regulated market place (where regulators are notoriously difficult to pin down when they use the term "adequate"), a private on site solution (cloud or not) could be the most cost effective and / or lowest risk approach to meeting regulatory requirements.

For a large and complex organisation that needs agility, that might be their number 1 benefit, but it doesn't apply if the main business of a large and complex organisation is doing the same business activity over and over again and they're busy refining their processes to eek out every last cent of efficiency.  However, that organisation might choose to sell their super-efficient process as a "cloud" offering to other companies...

And so it goes on.  I wish you luck with your video, but I do find that there are many attempts to simplify "the cloud" that business execs are exposed to (e.g. airline magazines) which really don't cover off the basics of going back to what the organisation needs to achieve and then mapping the right approach specific to their needs, be that public, private, hybrid or no cloud at all.  Missing this fundamental point and doing cloud because an article, video or other source says you should do cloud because its a "good thing" is a mistake.

Struggling With Large Scale VDI?

Through customer conversations and ad-hoc surveys at events,  I find that most organisations that have embarked on VDI projects tend to deliver to somewhere between 10 and 20% of their user base.  This is usually where the business case is easily justified - typical examples would be offshore developers or senior executives who would like to use their tablets for business use.

Those who have not embarked on VDI are often deterred from doing so by the costs per user, or the complexity implications.  Those that have delivered to more than 20% of their user base often find that they are seeing poor performance or much higher costs per user than they were expecting - often needing to throw more and more storage at the environment to get somewhere near the performance users are expecting.

Many of the costs are related to the costs of purchasing and operating the storage environment that underpins VDI sessions - either the cost of capacity or the cost of providing enough storage performance to support the required user experience.

As a result of this, I've been working on looking at a number of options for removing these performance and cost bottlenecks.  Using the Dell lab facilities, we've been stress testing a number of these options technically and from a business case perspective, in partnership with large customer organisations.

Our conclusions lead us to a different way of thinking about VDI and a solution that will allow organisations to scale out to 10s of thousands of users and give those users high performing VDI sessions.  You can learn about them through our webcast which will be recorded for future viewing, but if you want to hear about this first, and in an interactive session where you can ask questions, please register for the event on 27 March 2014 at the link below.  This will also give you access to the extensive white paper documenting the test results in our labs:

REGISTER NOW