Moving to the cloud is all we hear these days and Sales Reps love to throw “cost savings” to the Powers That Be in order for cloud migration to happen. In the ever fast paced IT world, decisions have to keep up with this pace and it’s difficult at times to really know (and calculate) the impact a decision makes on your cost savings. Migration to the cloud is one of those decisions.
Before pulling the cloud trigger, let’s put value on your current costs:
- Determine the cost for running IaaS in house. The infrastructure cost includes hardware/software, back-up software, networks, and monitoring tools. Don’t forget the cost for providing power and the value of real estate where it resides as well. Next, look at the cost of the contractual agreements in place for each application. Finally, it takes a village to run the network so determine the cost of the people it takes to implement, develop and maintain all the things listed above. Analyzing all these costs allows the total cost of ownership to be ascertained.
- Understand each applications resource requirements. It’s as easy as defining the actual usage of memory, storage and cpu by each application. However, there are pitfalls that companies tend to fall into which can result in inaccuracies that more often than not overstate an application’s requirements.
Pitfall #1 – Permitting or giving applications resources they don’t require. An example of this would be organizations operating in a capex model that make infrastructure purchases based on the forecasted growth of its applications. Because this model does not scale or flex easily, most organizations will overbuild greatly. This model creates a buffer of high cost resources to be used down the road as an app scales out over the course of its lifecycle. Without a disciplined approach to awarding “buffer” infrastructure resources to an application based on actual requirements, applications are typically left to consume infrastructure uninhibited. As these bloated apps continue on through their lifecycle it becomes widely accepted that this increased resource consumption over time is both valid and accepted as a necessity.
Pitfall #2 – Falling hostage to your current infrastructure restraints. Here we are talking the speeds and feeds your environment needs to run most effectively. We have actually seen a customer decide not to go after a piece of business because of the time and effort it would take to launch a new application or service with their current infrastructure. Remember the cloud is a la carte so you can pick and choose which applications get what resources. Highly transactional databases may require all flash storage where a file server typically would not. The cloud is highly flexible and scalable where on premise infrastructure is rigid and unable to react proactively to the changing needs in today’s competitive business model. The “one size fits all” model for your applications simply no longer works with regards to cost or agility.
Pitfall #3 – To lift and shift or to refactor – that is the question (sorry Shakespeare). Here is the good news: many of today’s applications are designed in such a way that they can easily migrate to the cloud. The bad news: not every application is ready for cloud migration. When the cloud first hit the scene it was regarded as some magic elixir that would universally heal any and all application and networking issues. Certainly, this is not the case and it never will be the case but today, more times than not, the cloud is a valid option. One case in particular: we had a client who decided to move an application to our cloud that had no business migrating. The application was ten years behind and the OS it was running on was no longer supported. What happened in this scenario was that when breaking the hardware restraints that were in place on the aged infrastructure, hidden issues from the application that were so fundamental, came to light. In this case, “lift and shift” was not the right approach. We ended up helping the client refactor the application to be cloud ready before we migrated it over.
Pitfall #4 – Building for seasonal peaks. It’s extremely common to build infrastructure to accommodate the very highs of the business. Yes, having apps ready and able for those peak times is important, but it gives a false picture of what your infrastructure supports for the other seasons that aren’t so busy, and it is typically very expensive to build out for the exception. This pitfall does not allow you to get to the brass tax of what your applications require at all times. Understand the peaks and valleys that your applications go through. The cloud allows you to Flex build and to tier your applications. The cloud option can be perfect in order to support your apps during both the highs and lows without waste.
Pitfall #5 – Not understanding your contentions. Don’t let contentions skew the numbers if you are trying to determine your application resource requirements. Apps can be bloated from service constraints and infrastructure restraints. Sometimes apps are blamed for being the problem when they actually aren’t the problem at all. Don’t assume the application is the issue if things start to get hairy. Dig in and find the true source of the problem. Understand that contentions in your environment will disappear in the cloud so finding the true picture of your application’s resources/requirements is key in order for them to work efficiently in the cloud.
Though many, these are the necessary, first steps to take when determining the cost comparison of On Prem vs. the Cloud. Join us next week as we discuss how to determine your application’s value to the business, AKA application/business value relationship.