Moving to Cloud: It's not (just) about cost saving

May 21, 2016

Cloud adoption image

We’re all familiar with the cloud narrative: move to the cloud and transform your business.

Most of the rationale for moving to the cloud is based on a cost argument: moving will save you money. My experience is that the primary benefits are often ‘non-functional’ like faster cycle times and a strong bias towards best-practice technical architecture. You may well get cost savings too - but the non-cost benefits are likely to be the ones that really transform your business.

Common Cloud Logic - It’s About Cost

Much has been written about cloud and how it can reduce your IT costs. The argument used is captured in a chart like the one below from an Amazon Web Services (AWS) presentation.

AWS Cost image

The rationale is that cloud enables dynamic allocation of tech capacity based on need. Cost benefits include no upfront hardware and software purchases and a better fit between your actual supply and demand of IT services like compute, storage, databases, and networking.

While it’s clear that this kind of elasticity may help some businesses, it depends a lot on your business’s demand profile - how variable it is and how well you can take advantage of cloud elasticity. It works well in some cases and less well in others. And while no upfront capex is great for startups, for bigger companies this is often a less important factor - especially as the cloud provider’s margin is loaded on to the variable charges.

Uncommon Cloud Logic - It’s About Speed, Flexibility and Solid Technical Architecture

So, does this mean we should ignore cloud because it may not help with IT costs? Absolutely not. Let’s look at what cloud can do for speed, flexibility, and architecture.

Speed & Flexibility

A ‘traditional tech’ example from 2001

I was the COO of a computer games start-up in the late 1990s to early 2000s. At one point we needed powerful servers to help us analyse the performance of online computer games players globally.

In 2001 the process for getting a new server went something like this:

  • Start with the Dell server website to configure the server to our needs
  • Hand over $5k to Dell and wait for a month for the new server to arrive
  • Spend a few days loading software, configuring, and testing the server
  • The final step was to put the server in a taxi and drive it to our data centre in London’s Docklands. After a few hours in a freezing cold data centre our new server would be up and running

Total elapsed time from start to functioning server was 5-6 weeks. But this wasn’t the biggest problem. The real issue was that fairly soon something would change, and we’d realise that instead of one big server we’d be better with two smaller ones, or we needed more disk space, or a different amount of RAM. Then we’d be back to the Dell website and the cycle would restart.

A ‘cloud’ example from 2012

In 2012 I was running a mobile payments and loyalty startup. One Saturday morning sitting at my kitchen table in my dressing gown I spun up and then shut down over 100 servers over a two-hour period.

I was trying to get the right server configuration using a cloud approach called ‘Infrastructure as Code’ which allows tech resources to be defined, provisioned, and managed using configuration files written in a format called JSON1. The first 99 versions weren’t quite right - the server configuration, load balancer, firewall, VPN or one of several other configuration choices wasn’t setup as I wanted it.

After two hours I had the script I wanted and could spin up instances of this environment with a single command. The whole process to start an instance would take 2-3 minutes. The exercise of creating the script had cost me less than $1.

The benefits for large corporates are just as pronounced: teams can quickly spin up development, testing and production environments quickly and cheaply - and just as easily shut them down when no longer needed. This massively lowers the barrier for teams that want to explore and test new ideas, making it even more likely they will try these new ideas.

Solid Technical Architecture

Cloud offers more than just speed and flexibility though. Cloud encourages IT teams to adopt modern patterns for technical solutions. What this means is that good practice is embedded - or at least readily available - in the way the cloud services are offered. What’s more, cloud makes it easier to verify that the architecture uses desired practices.

Some examples from AWS:

  • Regions and Availability Zones provide readily available independent datacentres
  • Compute instances are created in their own VPN making security configuration easier
  • Load balancers are redundant by design - it’s next-to impossible to deploy a load balancer that isn’t redundant. Similar for NAT Gateways.
  • Encryption of data takes just a checkbox to implement. Shared or dedicated key management (KMS or Cloud HSM) can easily provide higher levels of control and protection.
  • The S3 file storage service with - effectively - limitless numbers of files, file size up to 5TB and redundancy built-in means that disk drive full or disk drive failure has been engineered-out
  • Tools like CloudFormation enables ‘Infrastructure As Code’ which bakes-in repeatability and enables architecture verifiability
  • Audit and compliance burdens can be eased through services like Cloud Trail and Vault Lock

My experience of ‘traditional tech’ is that services fallover due to many different types of failure mode: network cards fail, log file disks fill up, SSL certificates expire and aren’t replaced in time, load balancers are misconfigured, HSMs aren’t redundant and many others. Cloud architecture removes some of these by design and makes many others easier to avoid.

Cloud doesn’t force best practice. You can still set up a single compute instance with your database, static and dynamic files and applications all running on the same machine and it will fail in just the same way as a single server will fail. However, the different services encourage a more enlightened approach to technical architecture and the separation of concerns.

Wrap Up

You should certainly see if cloud computing can help your IT costs. Depending on your use cases the savings could be substantial.

However, I believe you’re more likely to find benefits through the improved speed, flexibility, and best practice technical architecture that cloud enables.


Background: I’ve been using cloud since 2011. Primarily Amazon Web Services with some work on Google Cloud Platform.

Thanks to Ray Dogra for feedback on a draft of this.

  1. JSON is short for JavaScript Object Notation link. The Infrastructure as Code cloud service I was using was AWS’s CloudFormation service

Profile picture

The intersection of business and technology.
Written by Charles Allen who lives and works in Hong Kong.

© 2011 - 2021 Agile Projects Ltd.