Related topics

Unravelling the cloud confusion

Everything as a service?

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.

Sponsored: Designing and building an open ITOA architecture