bright ideas

How to save a staggering 30% when moving to IaaS

Save money when moving to IaaS - Infrastructure as a Service

At ViFX we have the good fortune to work with many organisations that are either planning, migrating to, or have already made the move to IaaS. These organisations have moved to a variety of locations; either our own ViFX IaaS platform, other local IaaS platforms, or to the large offshore providers.

Organisations that move to other local providers often engage us to run an impartial eye over the allocation of resources, post migration. The potential cost savings are staggering but are often not realised. Why is that?

Realising the cost savings of IaaS

Often, the move to IaaS is a significant mind shift for staff and especially application owners. Why?

In the context of moving enterprise workloads to IaaS, the issue is that the applications are typically not cloud-native. If they were they would utilise PaaS, or perhaps Cloud Foundry or Azure Stack - but more on that in another blog. When an enterprise application needs an Operating System to run on, the App owners are accountable for their system working optimally at all times, so therefore they don't typically like change.

So, when a conversation with an App owner goes along the lines of:

"Oh, hi App owner. Hey, we are going to move your app off this stable, high performing platform, that it's been running successfully on for the last x years, and that your KPI's and therefore bonus are tied to (read "ability to take your family on an overseas holiday that they were all expecting and will slaughter you if you bugger it up!"), to someone else's platform that we've never used before and where we have no infrastructure visibility. But hey, what can go wrong right?".

I'm obviously being a little facetious here, however I'm sure you get the point that the App owner's anxiety levels will be high. So when you double-whammy the App owner with "Oh, and by the way, we are going to reduce the amount of Memory and CPU available to your app" you can literally watch a meltdown occur before your eyes.

This is a typical scenario (somewhat dramatised for effect) that typically ends up with a decision to migrate VMs with the same specifications in terms of CPU and RAM.

Why is this bad you ask?

In a typical large enterprise, an organisation will refresh virtual infrastructure once every three years. When they refresh there is a degree of forward capacity planning and therefore there is typically a significant volume of capacity ready for use. So when the App owner comes to the VMware admin and says "Hey, my app is running slow, can you please give it a bit more RAM" the VMware admin will often concede. And here's why:

  1. The energy required to suggest to the App Owner that their app needs to be optimised rather than just have more horsepower thrown at it, may require too much energy, or the App Owner may not be able to facilitate the request.
  2. The VMware admin might suspect that the app doesn't need additional resource, but due to thin provisioning/balooning/{insert other resource sharing technologies here} it won't impact the platform resources, so why argue?

And this is how VM's end up bloated. In the context of a private data centre it often doesn't really matter, so it's not rectified.

However, in the IaaS world, the customer pays per x per hour, and the more x the happier the IaaS provider. The empirical data that we have gathered from our post migration engagements at ViFX tells us there is typically at least 30% over-provisioning, and this can potentially translate to millions of wasted dollars per year.

What about right-sizing?

So why don't customers just do a right-sizing exercise and scale them down? Good question, and here are a few reasons why:

  1. Your anxious App Owner might be able to improve their departmental P&L by reducing their resources and therefore their IaaS spend, but now that they only have Application Performance Monitoring (APM) tools to identify the impact of the reduction of resources, they can no longer lift the bonnet to see what's happening at the infrastructure layer when problem solving. Most IaaS providers won't provide visibility at that layer either. Also, most organisations fresh off the IaaS migration boat typically haven't yet developed their APM skills, so the App Owner is unlikely to go ahead with a reduction in capacity.
  2. The Change Management process to reduce the specification of instances can be arduous and difficult, as it typically means outages. It's also not in the best interest of the provider, and we've observed some resistance to these changes from time to time, from the providers themselves.
  3. It can be contractually difficult if the low watermark commitment level for spend will be breached.

Scale your resources to meet demand

So what is the answer to this situation? It's quite simple - run a right-sizing exercise before migrating, slim down the instances according to the results, migrate the workloads, and scale up if required.

A significant feature, so often overlooked, is that IaaS (if it's getting close to the NIST definition of Cloud) has the self-service capability to scale resources to meet demand. It is significantly easier to add resource to VMs than to remove it. Modern operating systems can often facilitate the additional capacity without interruption to service.

ViFX are specialists in the operation and management of on-premise and cloud infrastructure, so contact us if you would like advice or assistance with your migration to cloud.

Author: Symon Thurlow

Symon is responsible for the evolution of our managed services for private and public cloud, virtual infrastructure and data protection services.

17 February 2016 / 0 Comments