Moving to the cloud is not easy. Challenges include security concerns, required technical skills and high costs if you’re not optimizing workloads for how the cloud works best (and is billed).
As usual, the main focus is on the technical aspects rather than on the business ones. However, successfully moving to the cloud requires proper (business) decisions to organize the big organizational change. It’s a major transformation with a lot of uncertainty.
Cloud migration use case
What is a typical use case to migrate to the cloud? Imagine you want to conduct a number of pilot projects in order to attract a different group of customers. These projects require infrastructure to host the applications you need.
Buying and spending time to set up dedicated hardware for projects that may not go to production are a risk. Why buy all that hardware? It’s not unheard of for datacenter projects like this to take months. The business opportunity might be gone already. The cloud makes sense here.
This article highlights advantages of moving to the cloud from a business perspective.
Strategy and business objectives
Every company needs a strong strategy and business objectives. A journey to the cloud is a long term strategic choice and it affects almost everyone in the organization. During and after the migration a lot will change. The overall strategy and business objectives influence the outcome of the migration.
Given this consideration, think of the following questions:
- What is your current business strategy and how will a cloud movement influence that? An example of a business strategy is to be able to serve the top 10 customers faster and to be able to roll out pilot projects to judge whether these answer this strategy. Furthermore, what are the threats and opportunities of the given strategy? Both internal and external.
- What will be the time frame for the business strategy? Is it just 1 year or 5 years from now? In the world of public cloud, things change very fast, so you need to be able to execute the goals derived from business strategy within the chosen time-frame.
- Which business objectives contribute the highest to the chosen business strategy? Objectives should be SMART to make them practical. An example of an objective is: increase the revenue of the top 10 customers by 20% over the next 3 years by launching new applications that attract more paying customers. Remember the use case: the pilot projects which require infrastructure to be set up quickly are needed to make the business objective a reality.
Technical strategy
The overall technical strategy should be defined based on the stated considerations of the business strategy. A technical implementation that is not aligned with the business strategy tends to create “shadow IT”. In fact this will just slow the organization down. It will widen the gap between the business departments and the IT departments. Solis again! In the end the IT department will be seen as a cost-center (just like in the past), opposed to the core business to generate revenue.
The business case still matters
It is interesting to note that the outcome of some surveys show that companies are not so worried about their business cases when it comes to moving to the cloud. But at the same time they see budget and costs as a bigger challenge. Perhaps the overall business case for the cloud migration as a main activity is clear, what about smaller business cases on an application level?
If you need to select the top 5 applications to start the migration, which ones you do you select? Should you choose to select to smallest and simplest applications that are easiest to migrate? From a technical point of view, that might be a good thing. But what do they contribute to the overall revenue? Perhaps it’s better to move those first since you can save a lot of operational costs and use the full potential of the cloud (e.g. when you can support more customers at the same time). Being very critical here makes a huge difference to your business case.
Other than letting folks learn from low-impact migrations before taking on the bigger challenges, it’s impossible to create a feasible business case when focusing on simple applications that are only used by a handful of people and which do not support the core processes. The big benefits of the enormous effort might never come. Management and technical people will be disappointed and they lose their interest. Budget holders are important stakeholders. Keep them happy!
Single steps
Every single step in the cloud journey should contribute to the business objectives. Not only for large scale projects like choosing the right enterprise-grade tools but also individual user stories. They should be prioritized and described according to the migration strategy. Imagine a developer needs to refactor an application. A sample description might look like this:
As a cloud-native developer I want to refactor component X of application Y so the code is easier to maintain and better suited for cloud-native service Z.
Not the last section: without it, you have optimized the code but there is no link to the cloud service you intend to use in the future. Perhaps you need to refactor it again, which is a loss of time and effort. Now you have aligned the user story with one of the objectives of the migration. Everyone should be aware of the overall vision and intended business objectives so people on every level of the organization can contribute to it in their day to day tasks. Referring back to the example of the pilot projects: if someone decides a new (commercial) tool is needed for just a single pilot project, it should be judged carefully since the pilot project might not bring the results which are hoped for. This initiative should fit into the bigger picture.
Estimate the costs
A business case requires a major section that focuses on the (proposed) costs and expected savings. A lot of companies only focus on primary costs of infrastructure like the price of a VM every month. They forget to take into account other factors like staffing, security, maintenance, patching, training, change windows which cause downtime, etc.
VMs?
For applications that require running VMs 24×7, moving to the cloud might not bring you the cost savings you expect. A lot of companies see the cents per unit for a specific type of infrastructure per time period but fail to calculate the total costs for a longer period of time (e.g. one year). This greatly affects your business case. Also take into account that prices can change over time and prices can be different across geographic regions. There are multiple ways to reduce your cloud bill, for example by requesting VMs you reserve for a fixed time period.
Or not?
However, the public cloud is different, since you might not need a running VM all the time. Perhaps you can switch off or even delete VMs which you don’t need in the weekend and re-provision them back again on Monday morning. Containers running on AWS Fargate or even serverless can be a better choice here. For these kind of pilot projects you don’t even need to provision anything yourself.
However, then you need still need to put in the effort to make this a reality. Also, your application needs to support it. It requires automation and a lot of specialized knowledge to implement this.
In case your technical strategy includes the desire to have less “traditional” system administrators employed, this might not even the right direction. It might be much better to evaluate the options to change and migrate the application to serverless functions. For this solution, you don’t need to maintain VMs at all. This last statement actually contributes to your business objectives, otherwise, you are just moving the problem of high costs and maintenance to the public cloud provider.
Be fast?
It’s interesting to see that a number of articles on the internet state: migrate as fast as you can, so you can immediately save the costs of maintaining infrastructure yourself. All of this ensures you don’t miss the boat. However, if one of your business objectives is to save 25% of your infrastructure costs over the next 18 months and your journey takes 3 years, you will not be successful. It requires an up-front investment and you really need to have a good plan ready to make sure to keep on track.
Doing it right
Every major public cloud provider offers many services for different use cases and workloads. Unless you have highly experienced cloud infrastructure staff, it is very easy to make mistakes. For example when you run your application within containers. Which solution is best for you?
Containers?
Imagine you chose AWS as your cloud provider of choice. You might want to choose their hosted Kubernetes service called EKS. If the time to market of your application is very fast and you require advanced features of Kubernetes, EKS might not be your best choice since other cloud providers offer more recent versions of Kubernetes. EKS is a bit behind. This brings a challenge since all of your other applications might be running in AWS already. Should you shift your focus on another cloud provider or wait for AWS to upgrade its EKS service offering?
Or another use case: running containers in Azure. As we’ve seen the last couple of years, Microsoft offers (cloud-native) solutions to run containers: Azure Web App (which under the hood uses containers as well), Azure Container Instances, Azure Kubernetes Service, Azure Container Service Engine. Some of them are already deprecated even if these services were just introduced recently.
Referring back to our use case. If this was all about VMs, you might need to change that, since this all deals with containers. However, shifting from VMs to containers brings new challenges to be taken into account. If this requires significantly more time, you don’t reap the benefits, since the business opportunity is over by the time you are ready.
Business continuity
Even if you have highly skilled personnel who know the cloud solutions well enough, you risk doing things wrong. Maybe not from a technical point of view, but from the organizational perspective. In case these experts create a lot of technical solutions, when they leave the company, you still need to continue the work.
When your other staff members who have less experience are overwhelmed, it takes time to learn the solutions. Mistakes are easily made. Progress will slow down or even stop, your business case is ruined since no one can put the solution forward or even maintain it. If no one can fix critical vulnerabilities, your most valuable asset (data) is at risk. This is even more important in case these solutions support your core business. Business continuity is at stake when your data is stolen and you lose your valuable customers.
What if not
Sometimes business results are not so tangible. Suppose your business case has a section which focuses on the cost savings which can be achieved by stopping certain activities, it’s difficult to estimate the true benefit.
For example: when moving to the cloud you might also want to stop doing manual deployments. Embrace CI/CD and DevOps. This can of course bring great benefits when viewed from a pure technical point of view. However, it requires a lot of challenges that need to be solved as well.
Suppose your organization maintains an application which is only subjective to changes when a specific regulation needs to be implemented. Your application might be optimized for it and it does not require a lot of frequent deployments. On top of it, your customers are not so demanding and do not require a lot of new features.
The public cloud lets you set up infrastructure very fast, but also the deployment model is different. In the case of the example above, changing and automating the deployments does not make so much sense. This case becomes stronger when you know upfront that the application will be retired soon. In case of legacy code, don’t even invest time in it to migrate. Just keep it running in your data center might be the best decision.
Your technical strategy should also answer these kinds of challenges as well. It should justify why things are needed or not. In the end it contributes to your business strategy or not.
Conclusion
As seen in this article, there are a number of business-related challenges that play an important role when considering a migration to the public cloud. This is just the beginning. It’s not just the technical aspects that counts. A proper business strategy and objects which are supported by the right (technical) solutions is crucial. Hopefully, this inspired you to help you on your journey.
