Do cloud economics add up? Mark, an IT consultant specialising in this area, explains the gains he’s seen and the common hidden costs.
Do cloud economics add up? Mark Walsham, an IT consultant specialising in this area, explains the gains he’s seen and the common hidden costs
You know something has hit the mainstream when you see TV ads for it, and so it is with “cloud”. Adverts from Microsoft, IBM, Amazon and Google all espouse the benefits of always-on, large-scale computing platforms. But what about the economics that sit behind those promises? Over the course of several cloud migration projects, I’ve discovered some amazing benefits for my clients – but I’ve also unearthed areas of concern that could hit you in the pocket.
Financial benefits
The financial benefits proposed by the cloud vendors is clear, and these resonate with our customers. The most obvious cost reduction comes through retiring an existing data centre, either local or hosted, as companies shift numerous servers, appliances and services to the cloud. Server rooms, power, cooling and racking are no longer needed, slashing operation and maintenance costs.
Add in the other costs associated with your own infrastructure and you can see the reason that estimates of 50% to 80% cost reductions are attractive. Conversion of capex (capital expenditure) to opex (operating expense) will often free up investment for business innovation, agility and improved customer experience, all of which are good.
However, we need to look beyond the initial decision to move your workloads to the cloud to better understand the potential pitfalls.
Auto-scaling and elasticity
The idea that you no longer have to predict how many servers you need to build and operate to meet a seasonal event – epitomised by Black Friday – is very attractive. The old method, unless you conducted expensive and time-intensive testing, was based on projected volumes and a fair amount of guesswork. Now, you can start up an application stack from top to bottom, set an auto-scaling policy and forget about it.
So where’s the problem? Often, the default policy settings for auto-scaling aren’t thought through or checked at deployment, and this can cause multiple instances of an application to spin up. Remember, if your current setup has four servers in a cluster, it might be great that your new model can scale to five, six or seven, but unless you configure carefully, you could end up with a hundred.
One of my customers was running a decision-tree process application, which at times required for a singlethreaded request to collate and process the data. However, this was interpreted by the load balancer as being under load, so it spun up additional instances. The customer was slightly confused to find that their bill at the end of the first month was only 20% less than their old infrastructure services, due to all those additional instances being spun up automatically!
Data egress
All the major cloud platforms allow you to upload “unlimited” amounts of data to the platform for free. That’s all well and good, but a little-known feature of these platforms is the cost of data egress, usually priced as a per-gigabyte figure. See the table below, which shows the relevant charges.
One of my customers specialises in the delivery of media content, such as videos, images and audio files. Given it had a over a petabyte of content, you can see the reason it was hit with a seriously large bill.
Also remember that costs increase when you transfer data from one region to another, so shipping 1TB of data from the UK to Asia will cost more. Always check the data egress costs, and calculate the churn (frequency of change) and size of your datasets before you commit, so that you don’t suffer bill shock.
Reliability
In the modern IT world, we’re accustomed to service-level agreements, which as a customer define the minimum levels of, say, availability of the platform and services. Having the assurance that a server or application has an availability of 99.99% is great, but read the small print and you’ll find there are costs associated with this.
I have a customer that uses a modest product ordering system, consisting of a classic web, app and storage server solution, run out of its own offices. Due to several factors, this needed to be moved to a cloud vendor. While my client liked the idea of the SLAs (in this case, Microsoft Azure), it didn’t realise that moving single servers to the cloud wouldn’t offer any such service guarantees. Actually, the way to achieve these was through the use of Availability Groups, which by design need at least two servers per component, and hence twice the cost. Imagine this replicated across a 1,000-server estate!
To be fair to the cloud vendors, this does provide a host of customer benefits – such as the ability to patch services whilst keeping them running – but it’s something to be aware of.
“Always check the data egress costs, so that you don’t suffer bill shock!”
Do you need everything 24/7?
Another common issue I see and help customers with is scheduling of services. I’ve encountered countless scenarios where services are spun up within a public cloud and then left running all the time. Cloud is PAYG, so the longer you leave your services running, the more charges you’ll
accumulate. This sounds obvious, but it can generate huge bills if left unchecked. So, take advantage of scheduling services, such as those available in the popular cloud platforms, and run them only when needed. Yes, e-commerce systems need to be run 24/7, but is this true of that timesheet app?
Education on storage – time to go to class
Another element of cloud we all need is storage. From simple object storage for your media files, through to block file storage and relational database storage, there are options for most customers’ needs. Not all storage is equal, though, with many vendors offering different classes of storage based on a price/performance ratio.
Beyond choosing the right class ( see table below), you must think about data lifecycle management: holding too much data in expensive storage classes makes no sense. One customer had provisioned most of its cloud storage as SSD, to maximise the performance of its IO-heavy application stack. Once its service took off in earnest, the datasets grew quickly and hence the storage costs rocketed. By using the data archiving services available in AWS (Glacier) or Google (Cloud Storage Coldline), we used policy-based rules to archive data to long-term storage, helping to reduce the day-to-day storage costs.
Discounts aren’t equal
I can hear all the seasoned PC Pro readers shouting: what about the discounts these services offer? That’s entirely true, with most of the players offering a partial or full upfront investment option that reduces the prices of the resources you consume. However, they aren’t equal in value.
For example, Amazon uses both Reserved Instances and Spot Pricing as ways of getting cheaper resources. The former is the aforementioned pay upfront, the latter a marketplace where you can bid for spare and unused resources. These don’t offer the same level of discounts respectively (75% versus variable).
Google, on the other hand, offers “sustained use discounts”. This is where the longer you run your workloads, the more discount you may accrue (maximum of 30%).
Optional extras, sir?
Like when buying a new car, there are lots of optional extras available to you with cloud, some of which are really useful. Elastic load balancers, VPNs, myriad deployment options (such as instances near your customer base for better performance), services deployed across geographies, and whitelisted DNS services are just a few. They’re offered at low unit cost, yet have the potential to cost you dear.
Recently, we’ve seen a growing trend of cloud market places, a vibrant community where vendors have written and created a spectrum of cloud native services. Take a look, as they can often replace an ageing or expensive vertical solution in your current portfolio. Security compliance checking, AV, integration hubs, host intrusion, big data lakes and analytics are all examples of predefined, built and vendor-supported solutions that can help drive real value from the cloud, many of which are just pennies per use. But look beyond the headline deployment cost. A data lake will require considerable storage and compute, and can grow enormously in size and cost.
It’s all about the apps
Finally, consider your application library. Not all applications are as easy to “cloudify” as others, and you must think about this carefully before you make the leap. Simple architectures (say, web services) will be trivial to move, but those with hefty database engines (yes, Oracle, I’m looking at you) will be a great deal more complicated and time-hungry to migrate. Don’t underestimate these costs, or get a professional to help with the assessment. Get it right, though, and you can release muchneeded investment in moving more applications to cloud, and potentially reinvent your business model!
“Like when buying a car, there are lots of optional extras available to you with cloud”
In conclusion
Think about the mid-term strategy of your organisation or customer, draw out a plan on how long services will exist, and enter into agreements based on that research. There are a host of pricing and TCO calculators out there, so make sure you use them – not just for the basic tin and wires, but the areas talked about above. You’ll then be in a much stronger position to appreciate whether, in your case, the cloud economics really do stack up.