Why all these planning services?

larger service methodology wheel

Service Methodology

link to service methodology
link to Purposeful Clouds blueprints
link to strategy phase
link to planning phase
link to planning phase
link to support and review phase

We are sometimes asked why we spend all of this time and effort doing strategy and planning services. In late April, 2011, Amazon sustained a serious service interruption with its Elastic Compute Cloud (EC2) service, lasting nearly two days. Not all of Amazon’s subscribers were adversely affected. For those who were, however, it was a time of frustration and helplessness. This has generated some entirely predictable responses tolling the “death of the Cloud”, or at least the prospect of a pervasive slowdown in enterprise adoption of Public Cloud services. In our view, however, this event has simply underscored certain factors which, from the outset, have been critical to Cloud adoption in general and Public Cloud adoption in particular.

In many cases, there’s been a pervasive general impression of Cloud Services as dirt-cheap and infinitely scalable. Like anything else that sounds this good, it’s never been that simple. We at Purposeful Clouds hold the conviction that economical, easy-to-use Cloud Services are indeed attainable – provided your reliability needs are not very demanding. Consider the highly-publicized basic services as an entry-level model: they provide a functionally correct environment, but few promises are possible where operations are concerned.

As with any other part of a key operation – computers, building power, call center facilities, etc. – it’s incumbent upon the enterprise to develop a clear understanding of how much unplanned down time is acceptable to the business, and create a clear and actionable plan for dealing effectively with the inevitable service interruption, within acceptable cost parameters. This is not new to IT; the Public Cloud just adds another “utility” to be handled. In some cases, a premium service or a special arrangement with the service provider may be appropriate. This appears to have been the case for those who subscribed to Amazon’s FailSafe options, who were not severely affected by this event.

In other cases, where the business impact of an extended service outage would be catastrophic, it will be up to the enterprise to formulate alternate-operation scenarios that can be invoked under the complete control of the enterprise itself, or at least without recourse to the original service provider. They are presumably dealing with a widespread disaster or even a suspension of operations, and certainly have little incentive to help you shift to another provider. This is as true for Cloud Services as it’s always been for the corporate data center; there are just many more options.

It really is just like other forms of insurance. Sometimes you can do without it – if loss of the underlying asset will not cause too much hardship. Typically, Test and Development in the Cloud might fall into this category. Informational or promotional sites also might, but this should be a subject for further analysis.

For those assets or operations that you really can’t do without, it’s important to have an acceptable level of “replacement value” insurance – something that enables you to continue an adequate level of operation after a non-cataclysmic period of service interruption. Service Level Agreements are important as a gauge of the Service Provider’s level of confidence and commitment, but being compensated with a fraction of a month’s usual charge will be scant comfort if you’re unable to generate revenue or ship product.

An important outcome of our strategy and planning phases is that you will get a good understanding of the business importance of a workload you are thinking of moving to the Cloud.

Working with your business and technical people, we will put together a set of requirements in the area of performance, availability and security. We base these requirements not on what will be “nice to have” but what you really need to support your business. It is these requirements that determine where in our Cloud Cube each workload belongs