Unravelling the cloud confusion

In the last article we looked at whether virtualization provided a springboard to that loosely knit set of capability some refer to as ’cloud services’. But, as we’ve found previously when discussing such topics, cloud is a can of worms (if that’s not too much of a mixed metaphor).

So, what is meant by cloud services? As we have said, some elements are not particularly new, but ’cloud’ offers an umbrella term to capture the idea that they share the internet as a delivery mechanism. A number of sub-categories are shimmering into some semblance of clarity:

Infrastructure as a Service (IaaS).

Discussed previously, IaaS offers a cloud-based substitute for major elements of your IT infrastructure – that is, server and storage hardware, storage. In short, this will be attractive if you are short of space and/or you want to lose the hassle and capital/operational cost impact of owning and maintaining physical boxes.

Platform as a Service (PaaS).

In this case ’platform’ means an application (as opposed to hardware) platform. This enables you to grab application resources on demand to prototype, test, pilot, etc. It is also handy for deploying externally-facing applications on the web, which potentially require the ability to deal with wildly fluctuating demands.

Software as a Service (SaaS).

A cruel but accurate assessment of SaaS is that it has become a fairly meaningless catch-all term for a range of application services, from business application services such as CRM, ERP, to productivity tools, analytics, backup and archiving. You name it, it’s all in there.

There are some good things to be had from all of the above. However, from a purely techno-algorithmic perspective there is nothing inherently better about a specific capability being delivered as a cloud service, versus it running on a server in the corner of the office.

In the previous discussion around IaaS, we highlighted a number of reasons why an organization might choose to adopt one mechanism over the other. But a cloud service is just as capable of being badly put together, badly managed or poorly secured as anything we could do ourselves.

This eyes-wide-open starting point helps us see “Cloud” as an option, an additional delivery mechanism for a capability we have decided we need. So, why might we choose it versus keeping a service in-house? Criteria include:

How well the service can be managed and kept up to date
Capital and operational costs, including staff training
Space and power constraints
Security risks and legal compliance aspects
Integration requirements with in-house and external systems
Access to skills and expertise

Some of these points are being used to sell cloud services today, but they can equally apply to in-house capabilities. You may happen to have all the space and power that you need for example, or you may not.

Similarly, you may be fortunate to possess certain skills, or you may find yourselves lacking. Indeed, your IT department and environment might already be organized and delivered in a the same way as an external service provider – in today’s parlance this would equate to an ‘internal cloud’.

Hybrid horror stories

It was ever thus – and so, choosing cloud services becomes no different from choosing any other kind of service. As a result (and unless you have decided to adopt the principle of the cloud wholesale, which we would thoroughly advise against at this stage), you will inevitably continue to have some systems running in-house, even as you (may) choose to adopt some specific cloud services. The result is inevitably going to be a hybrid architecture, in which new mixes with old, and internal with external.

Which leads to questions of operations and management. Fundamentally, the challenges of managing such a hybrid architecture are yet to be worked out, and we expect a fair share of horror stories before they are. Watch this space for bylines about cloud providers failing to offer indicators of service uptime, to counter the equally likely and valid tales of how external services have been so much more resilient to their internal equivalents.

The only wrong answers will be a result of poor decision-making when it comes to selection and procurement. Right now, given the immaturity of the market, decisions should take into account the range of architectural, security and legal/geographic aspects that remain untreated for cloud services.

For example, costing models are often based around pay-per-use, which isn’t necessarily compatible with many organizations’ budgeting mechanisms. These models can be attractive for short-term needs, but start to look expensive for the longer term.

No doubt security and interoperability standards will evolve to meet the requirements we know about (and there are plenty we don’t), and the costing models will work themselves out. But in the meantime, the best guidance we can offer is due diligence, in terms of validation of suppliers to ensure that your own service, data management and compliance requirements can be met.

Some things to consider include:

Service provider stability, maturity and culture determine the risk associated with committing to a service and the ease of working with it on an ongoing basis.
Whether the service provider can meet your immediate needs for performance, safety, security, regulatory compliance, from a policy and implementation perspective.
Service compatibility with industry or de facto standards, to minimize the risk of lock-in.
Skill set requirements to get maximum value from the hosted service or application.
Service resilience and scope – what mechanisms exist to support disaster recovery, data backup and so on?
Operational access to ensure the service is flexible and manageable from your own perspective.
Integration capability with in-house applications and policy systems (such as directory, security, access, etc.), as well as with other cloud services could also be necessary.
Contract terms and service levels, including service elements, fees (now, and in the future), minimum contract length, consequences of making changes etc.
How to handle the end of a service, either to move the service somewhere else or because the vendor is no longer willing or able to provide it. Specifically who owns the data, and how to get it back?

If it looks like there is a lot to think about, then there probably is. We are pretty confident that any cloud-based services will sit alongside in-house IT capabilities for the foreseeable future.

So, a considered, eyes-wide-open approach to cloud service adoption ensures that risks can be countered as best as possible, and that the right tool can be chosen for the job.