Getting ready to move to the cloud

The difference, when sipping and gulping a liquid has everything to do with the nature of the liquid. The nature including properties such as hot the liquid is, and how much liquid there is. You wouldn’t chug a scalding hot 20-ounce coffee. You might chug a 20-ounce cold soda on a hot day though.

Cloud is a lot like that beverage of choice.

First how the what and how of the consumption has a huge impact. Not that you would be looking for the hot cloud on a cold day or cold cloud on a hot day. Rather there are some things we need to consider before we consume our cloud. The focus of this article is on that broad concept of consumption. Consumption, as denoted in my above example has to do with how much, what-what gets consumed. In the world of cloud computing, that can when planned represents significant cost savings for the organization. Numbers as high as 20% savings are often tossed around. 20% is possible, even likely if you are aware of the rules of consumption.

In the world of on-premise applications, the focus of building out your data center is to have available 100% of the maximum required a capacity for the computing solution you are building. Regardless of how much you use most of the time, you have to buy enough hardware to cover the maximum. Many organizations in moving to the cloud, don’t consider that reality. They simply purchase the computing power they have needed in the past from the cloud provider.

That means the initial cost reductions your organization would see end up being the overall reduction in cost generated by the overall efficiency of the cloud provider. That would be a 2-5% savings overall and nowhere near the 20% savings often talked about. The real value in moving to the cloud is to evaluate your solutions as you move them. The quick evaluation is are you using the application. The next evaluation is the broader who is using the application today. Finally, the last initial question to determine if the application itself and its capabilities vis a vis what is often called Cloud Functionality. That would allow the application to take advantage of the cloud technology that is called auto-scaling (as the application increases in usage, it can automatically increase the servers that it is running on. As it begins to decline in usage, it releases the additional resources and returns to a normal baseline.

Based on understanding the initial three questions for each of the applications in our portfolio we can quickly generate a list. The list will encompass applications that have little to no changes required before they are moved. Applications that have minor modifications before they can be moved, moderate changes required and finally our last of the four initial buckets beings applications that require a major rework.

Once we have the four buckets detailed, we have both a path forward and a very loose migration timeline.  We will be able to say the easy applications can start moving pretty much right away. But we still should do one more thing first…

((more to come))