The headline costs of cloud services from providers such as Amazon, Google and Microsoft appear to be remarkably good value. However, there is more to running a service in the cloud than these suggest, and organisations need consider the full picture to avoid an unpleasant shock when their first bill arrives.

Public cloud is not a bad choice, but it is vital to prepare a fully costed business case first, ensuring that all the ‘extras’ are identified. Once an organisation has got rid of its in house infrastructure and staff, it is very difficult to revert back, and once a cloud supplier has been selected it is not straightforward to change. Different cloud vendors have alternate approaches to configurations, with strengths and weaknesses that need to be considered in line with business requirements. 

The business case should consider three factors. First, what is included in the proposed cloud service and its charging structure? If other elements are required to safely run the application and are not included in the core price, such as security, resilience, management, patching and back-up, these need to be factored in. Second, what are the likely usage patterns? All public cloud services are metered, which can be good or bad, depending on the service and its use. Thirdly, how quickly is use of the service likely to grow, in terms of both user numbers and data volumes? Flexibility is a strength of cloud provision, but if the usage grows by 50% so do the costs and you have no choice but to pay.

A useful analogy is to think of buying public cloud like renting a flat. You get access to the basic premises but need utilities, flooring and furniture to make it a home. In the case of the cloud, this includes management and monitoring of back-end components, backup, anti-virus and patching. As you are sharing the facilities with other residents, you need to provide locks for the internal doors and other security features. Also, fire alarm drills can be run at very inconvenient times when you have no choice but to vacate the building.

Take a service that you believe is primarily used between 8am and 6pm, such as customer relationship management (CRM). With metered cloud costs, hosting this in the public cloud can look significantly cheaper than the fully loaded internal costs of a service which is available 24×7. However, running CRM requires additional systems, such as login/authentication and security. These need to be powered up beforehand, and you need to back up the data, so 8-6 quickly becomes 7-7 or longer, especially if staff need to access it out of hours, which is almost always the case.

Then consider multiple interactive systems. Your CRM service probably integrates with other systems which may not be able to be powered down. By now you have probably concluded your organisation needs to run CRM 24×7. Your costs are more than double the headline price and you still need to add security, monitoring and management.

The second aspect requires an understanding of the applications you are planning to move. In public cloud services such as Amazon Web Services (AWS), it costs 1p per GB each time servers in different domains talk to each other, and 8p per GB to send data over the Internet. This seems minimal, but with some applications, servers have a constant two-way dialogue, or transfer ever increasing amounts of information, and costs can quickly escalate. Similar problems can arise when trying to put a custom application into Microsoft Azure. If an application is not optimised for public cloud, it may be more appropriate to retain it in-house or use a managed cloud service.

Finally, the service level agreement (SLA) and service delivery for cloud services may not match your business or user expectations. Businesses that have moved to cloud-based CRM systems have had outages and performance issues far worse than when running in-house solutions. Yet these are within the 99.9 percent SLA the cloud vendor stipulates (which is 8.77 hours of downtime per year plus maintenance windows). If a user calls your service desk saying why can’t I access CRM and when it’s there it is much slower, how do you explain that this is an improvement for the business and that there is nothing anyone within the organisation can do about getting the service back?

Now factor in the cost of migration, the sunk costs of your existing IT infrastructure and facilities and the additional cost of a disaster recovery solution (no cloud provider can guarantee 100 percent availability). What was initially an easy cost justification becomes a more nuanced decision.

Some services can and should run in public cloud. If a cost effective, fit for purpose Software as a Service (SaaS) is available, with suitable SLAs to meet your requirements, it is likely to be a good option. However, many providers currently offer something that is more like Platform as a Service (PaaS), so you will need to provide some aspects of the service yourself, use a managed cloud service, or retain the service in-house until a suitable SaaS becomes available.

To prepare a watertight business case, the first step is to baseline your existing IT provision against business requirements. This enables you to categorise and prioritise the systems appropriate to be migrated to cloud. You can then design new architecture for those services and plan the migration before going to market, which may need external expertise. Most suppliers have different cost models, but armed with this definitive blueprint you can make a realistic comparison between the various offers.

The end result is likely to be a hybrid infrastructure that needs managing and monitoring. You should therefore retain key skills in-house to ensure effective management, security and cost realisation.  For any cloud delivered service (public/private/hybrid) you are still the owner of the data, therefore are responsible for information security.

Drew Markham is a service strategist at Fordway