11 Dec 2019 by Mike Weaver
Integration: The Final Step in Change Management
The final step in successful change management is the Integration stage. Here’s how to bring everything together. Watch now.
Most organizations rejoice at completing lift-and-shift projects into Azure. But did the project focus on delivering a cost optimized solution? What are the common pitfalls, and how can you save over 90% on resources, like virtual machines?
The case for moving to the cloud no longer has to be made. Organizations are moving at an ever-faster pace to adopt cloud technologies. Many have moved infrastructure services into Azure to reduce their datacenter footprint, become more agile and to leverage cloud elasticity. All of these are great justifications for adopting cloud technologies.
The one argument that is always more difficult to justify on paper, is that moving to the cloud will save money. It should save money – but does it? That’s really the million-dollar question that boardrooms debate as they look to make the move and take the risk of transitioning from something they know and understand, to a platform they don’t own, control, or have a say in its future direction.
Consultants are often asked to come in to assist in providing the ‘how’ in moving services to Azure, which is fine. For some, money is not a priority, but it’s fair to say that the bottom line is important to virtually all organizations, and being seen to get value for money is often a yardstick for measuring the success of a project.
All too often cloud implementations have cost optimization too low down on the agenda. Why is this? Is it economic negligence, or something else? The fact is, that for many organizations, their first forays into IaaS and PaaS services come with inexperience. Merely getting something up and running and learning how to curate and manage new services with new tools is already complex enough. Getting a project off the blueprint and into a live functioning service in the cloud is cause for celebration for sure, but doing that at what cost?
And herein lies the problem. It’s really simple for organizations to know how much their cloud spend is. Microsoft provides you with a monthly bill that breaks down what each service has cost, to the penny. You can also see this on an on-going basis with (albeit lagged) costs since the last invoice in the portal. You can even see your likely end of month cost with a predicted spending graph.
What’s difficult, is knowing how different that cost is compared to the equivalent on-premises solution that a project may be replacing. Do you know the cost of running a given virtual machine in your datacenter? Have you factored in the electricity, cooling, support costs, hardware and software and so on? Probably not. If your monthly Azure bill is $1000, and it’s the same each month, it doesn’t come up on anyone’s radar that it could be reduced. Surely if the project was done right, it’s already at the best price – it’s running in the cloud, it must be cheap -right?
Well that’s where cost optimization comes in. Let’s look at an example. You have a line of business application that users access. You’ve decided to run that on a DS2_V2 size virtual machine. Costs vary by region, but let’s imagine we are deploying to the North Europe region. The cost of running that size virtual machine is $ xxx/month. That should be the starting point to optimization. Let’s assume for the sake of argument that a virtual machine is the right solution, because often a PaaS solution will be cheaper.
Here’s pitfall #1. Do you really need that size VM? Did you test and validate on that specification or was the size derived from an equivalent spec that was used on-premises using best-guess calcualtions in an era where servers are built once, and left alone thereafter? We can reconfigure the size of a VM at any time. Choosing a lower spec VM permanently or even for some days or weeks could save money. Scaling down to a smaller VM could save you 30%.
Does the VM need to be powered up 24/7? What if our application is only used during business hours? We could stop it when it isn’t needed, so instead of it running for 168 hours a week, we could maybe run it for 40 hours a week reflecting core business hours. Right there you could be saving 75% as you are billed for the amount of seconds of uptime. Combining these ideas could be saving you 90% over the original cost of running the VM. It’s decisions like these that are often overlooked as the on-premises mentality is to preserve as much as possible during a transition to the cloud in an effort to minimize risk, but in doing so may not maximize value. The cloud is agile, but are you?
Optimization should be an essential part of your Azure deployment plan. Failing to do this can be wasteful and lead to your business being uncompetitive. It can certainly help oil the wheels at your next pay review meeting too!
If you’re considering a cloud migration and would like to learn more about the benefits of the Azure platform, Quadrotech offers a range of migration solutions for large enterprises.