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
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 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 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 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
Drew Markham is a service strategist at Fordway