In today’s world, most organizations are looking for ways to move their applications to the cloud. Some opt for a public cloud whereas others look to build their own private cloud. Irrespective of public or private cloud, the major goals remain more or less the same. For organizations, cloud presents them with three main motives:
- Potentially lower costs by adopting a pay-as-you-go model
- Bigger scope of innovation by exposing yourself to the vast array of cloud-native services
- Higher growth in business by ensuring high uptime, quick time to market and easy integration with public platforms without compromising on security
But, are all companies who have already undertaken the cloud journey achieved their goals? Often we hear that cloud is not as inexpensive as it appears to be. Also, due to many internal restrictions or industry regulations, organisations are not able to innovate the way they would want to do. So, the question remains, “Why do organizations fail to achieve the benefits in reality while everything looks so rosy and perfect on paper?”
Public or Private Cloud?
I will try to explain why many cloud projects do not immediately return the investment. We know, eventually, it will pay dividends but in today’s world where technology takes a giant leap every 5 years, any breakeven period of 3 years or more definitely looks like an eternity. But, fortunately, this is not always true; in fact, cloud projects if done in the right way will start paying rich dividends right from the very first year itself.
Even though I will focus primarily on public cloud in this discussion, I still want to touch upon the topic of private cloud just to throw a perspective. Once an organization decides to build a private cloud, it is taking a huge risk in terms of cost and the final result. Building a cloud is not easy, it requires time, effort and a lot of innovation and testing over long periods to really get it to a level suitable for a large enterprise. If one looks at the major cloud providers in today’s world, be it AWS, Azure or GCP, all of them took years to get their services to current levels in terms of variety and maturity.
So, for a private cloud to be used solely by an organization for whom IT is not the core business, it automatically gets restricted in terms of service offerings and at the same time involves a huge amount of initial investment. So, though a cloud becomes available for their own use, in reality, other than quick provisioning of infrastructure and better storage management a private cloud is not very much different than virtualization of physical data centers that most companies undertook about four or five years ago.
Now, let’s talk about public cloud. If you have a legacy application which you are planning to migrate it to the public cloud, be it AWS or Azure, will it ensure lower cost of maintenance or give you ample opportunities for innovation? The answer is probably – No! To get all the benefits of cloud, before migration there needs to be a proper Discovery and Assessment phase in which a roadmap has to be designed for every application for its migration to cloud.
The Two-Step Approach
Essentially, in the discovery and assessment phase, we take a two-step approach. Firstly, we analyse the infrastructure with the help of a discovery tool that gives us data on utilization, I/O, peak times, interconnectivity between different servers and possible target instances based on the type of operations (eg. Memory intensive, high CPU, bigger instances as a whole etc.). Secondly, we collect data on applications with the help of a questionnaire that provides us with information about individual applications. For example, one of the most innovative services of AWS is autoscaling that enables an application to automatically scale out in the number of app/web servers, but it is only possible if the application is stateless. So, unless the application is stateless neither autoscaling will work nor it will be able to cut down on resource costs during non-peak hours. For a stateful application, the only possible way of cutting down on resource costs to have a static scale out and scale in based on historical data collected by the discovery tool.
A 6R Migration Plan
Typically, we devise a 6R migration plan for applications which essentially refers to Rehost, Replatform, Refactor, Retain, Repurchase and Retire. Applications that need some changes to the architecture or the platform to be able to make full use of services on Cloud fall under the category of Replatform and Refactor. Applications that are legacy and need to be redesigned completely will either be retained in the physical data center or maybe retired depending on its end of life. Often some applications especially COTS products may have their alternative cloud-based solutions. So, they are the classic case of repurchase.
There are also other considerations before embarking on a cloud journey, such as skills available internally among people, business expansion plans and licensing agreements but those can still be managed during the migration. But making the correct design and taking the right approach is paramount to ensuring a successful cloud journey. So, this may attract few extra costs in the beginning or delay your actual migration by few weeks. In addition, it will also enable your organization to achieve the goals of moving to the cloud.
Furthermore, BlazeClan has helped more than 100 customers in migrating their workloads to the cloud seamlessly. Contact us today at firstname.lastname@example.org to explore new opportunities on how we can help you to migrate or select the right approach for your cloud needs.
Abhradip, an IT professional having more than 12 years of experience for working in different geographies. Abhradip started as a developer and gradually moved across different technologies, he is currently leading the cloud and automation team at Blazeclan. He has spent much of his career contributing for the BFSI domain and has extensive hands-on experience of working with global multinational banks and financial institutions in the Europe and APAC region.