How to assess a hosting business case

This guide outlines how departments should evaluate a hosting business case, particularly before beginning the spend control process.

The public cloud is the government’s preferred option for hosting. We introduced a Cloud First policy in 2013. We’re now moving towards a ‘cloud native’ government. It’s important technology purchasing decisions are made with this objective.

Criteria for choosing a hosting supplier

Departments should always source a hosting supplier that fits their needs, rather than selecting a supplier based on a recommendation. Cost should never be the sole factor in decision making. Departments should assess their hosting options based on a number of criteria, including:

  • elasticity and resilience: the public cloud helps you scale more efficiently than on-premise physical infrastructure (instead of maintaining large amounts of redundant infrastructure, you can expand capability on demand and usually pay for it by the minute or hour)
  • pay-as-you-go pricing: cloud services are usually billed based on consumption down to a very low level of granularity (this reduces change costs and penalty costs associated with switching off redundant systems, and allows you to achieve optimum balance of cost and performance)
  • falling costs of Infrastructure as a Service (IaaS) over time: major providers are increasingly competitive, leading to a significant downward pressure on IaaS pricing (teams should consider the impact of these falling prices and pay-as-you-go pricing on their budgeting processes)
  • quality of management tools: you are likely to manage your public cloud services via APIs and there are lots of management tools that can help you do this, like vCloud tools and Terraform
  • best of breed security: public cloud services have a large budget to mitigate many common risks and it’s worth strongly considering their offerings(maintaining the security of a data centre and virtualised infrastructure is an increasingly challenging job and not one that many organisations can specialise in)
  • flexibility and opportunity costs: adopting IaaS will let you focus resources at the application level, ensuring you can develop your services in an agile way, adapting approaches as new understanding emerges

Your team should conduct a full audit of all your technology infrastructure before making a case for hosting. You should also have a plan in place to retire or replace systems that aren’t appropriate to move into public cloud hosting. This should be as detailed as possible, considering the options for each application and area of functionality.

Third parties in cloud hosting arrangements

Departments should own their own hosting contracts.

Specialist support companies can play an important role in helping to migrate, develop and operate hosting services for departments. They can also advise departments how to best take advantage of cloud provider capabilities.

If you’re using a third-party supplier, you should ensure they have an appropriate level of access to your accounts and contracts with your cloud provider so they can understand how you’re using the service. Make sure your cloud providers’ access control measures provide for this.

Make sure your department maintains overall ownership of the accounts and contracts so you can:

  • fully understand how you’re using the cloud service
  • work freely with a range of suppliers simultaneously
  • keep your hosting arrangements separate from your contract with your third-party supplier (this will make it easier * for you to change either relationship)

Reducing the risk of lock-in

There are no formal standards for describing or managing most types of cloud resources. This is because the cloud hosting market moves so rapidly. Organisations are very quick to adopt new cloud products that offer significant opportunities, but this reduces the opportunities to work with standards.

Your department should take steps to avoid lock-in with cloud hosting providers. For example you can maintain a record of how many times you use something that’s unique to a specific provider. You can also avoid lock-in by working through abstraction layers like CloudFoundry or Kubernetes or by using common multi-cloud tooling like Terraform.

You should also be able to give indicative figures for the cost of exit from each of your cloud providers.

Sometimes departments have a significant commitment to a particular feature offered by a cloud provider. In these cases, your department should be able to explain its strategy for reducing lock-in over time. For example, your department could sponsor open source tools that work across multiple providers or develop equivalent feature functionality that works with other cloud providers.

Published 10 February 2017