By: Andy Troup
Successfully assessing workloads and placing them in the appropriate private, hybrid, and public cloud environments can make or break your cloud strategy, enabling greater agility and cost efficiency.
In this series, I’m reviewing four key areas to consider when performing a workload assessment. In the first two parts, I suggested a framework for classifying workloads as potential candidates for moving to a cloud environment and then looked at service portfolio mapping and how to best determine the target cloud service and deployment model for each candidate workload. In the final part of this series, I’ll cover stakeholder analysis.
This time, I’m going to examine how to assess the costs and benefits of moving your workloads to your target cloud model. It’s pretty straightforward: The main thing to remember is to be as comprehensive as possible.
Start Me Up
The first thing to do is identify all your startup costs, including:
- Licenses, such as investment in private cloud, and also public cloud costs. Licensing restrictions of certain technologies will also need to be considered due to the rules that are applied with them such as licensing per physical socket for all potential hosts of the service.
- Production material
- Payroll
- Training. People will need to be educated in how to use the new environment. This includes the individuals supporting and maintaining the cloud environment as well as the end users who will have access to it. These costs should be relatively small compared to the benefits of self-service/self maintenance.
- Travel
You’ll also have non-monetary costs, such as:
- Imperfect processes (will they need to be improved?)
- Potential risks (both of migrating and not migrating)
- User acceptance after the migration
- Time. To perform analysis, migration and testing as well as the time it takes for the migration. These should not be underestimated and will be very dependent on the quality of your date and your organizations acceptance of the migrations.
- Lost production, such as downtime during migration. Migrations should ideally be scheduled during routine maintenance windows to mitigate this as much as possible.
- Reorganization to accommodate the new cloud services. This may include ensuring that the help desk can support the new services, and a new support model to engage with public cloud providers to guarantee that they achieve their SLAs
- Market uncertainty
- Influence on reputation
Make sure to assign monetary values to these costs, too. To ensure equality across time, monetary values should be stated in present value terms. If it’s hard to create realistic cost values, consult market trends and industry surveys for comparable implementation costs in similar businesses.
Now it’s time to figure out your ongoing costs, including:
- Ongoing CapEx and OpEx expenses (at equivalent SLAs). These will vary depending on the destination cloud environments you will be using. When more workloads are placed into public clouds, OpEx costs will most likely outweigh CapEx costs whereas for private clouds CapEx will most likely outweigh OpEx.
- Ongoing Cost of Compliance. Again, this will be dependent on the clouds you are migrating to. The costs will be greater for private clouds as it will be your responsibility to ensure compliance of the cloud infrastructure as well as the cloud services. In a public cloud, the compliance of the cloud infrastructure will simply be part of your SLA with the cloud provider and you will only need to ensure compliance of your cloud services.
Depending on the current status/age of the workload you are assessing, you will want to establish the period over which you want to calculate the ongoing costs and benefits. For example, if the workload is nearing the end of its life, the period for which you perform your calculations will be shorter than for newer services. The minimum period should be 1 year. If you discover a workload whose lifespan is shorter than this, it is very unlikely that a migration is worthwhile, and a decommissioning plan should be put together.
Finally, add up all your anticipated costs to get a total cost for startup and continued operation.
On the Other Hand
Now it’s time to move on to the benefits. Start by making a list of all the benefits you expect to see upon implementation and thereafter. These should include:
- Better insight into your workloads via a comprehensive inventory of all your workloads
- Capex reduction due to resource redeployment and efficiencies, especially when using public cloud services.
- Redeployment of the physical technology after migrations
- Optimized Opex due to new cloud capabilities such as pay-per-use, as well as reduction in operating costs due to providing some operating capabilities to the end user such as self service provisioning.
- Opportunities for new applications and integrations due to cloud architecture. It is now possible to place workloads into the cloud rather than making huge investment, for example, with High Performance Computing applications.
- Expansion into new markets as a result of cost reduction and more agile approach to service creation. It also becomes much easier to move into other geographies by utilizing cloud services that are local to the geography. For example a South American organization can move into European markets by using local European cloud services, thus removing the concern over data location.
- Current SLAs provided at reduced cost, or improved SLAs at the same cost. For example, a non-protected service could now have protection in the cloud. However, you will also need to bear in mind that it may not be possible to exactly match the current SLAs your workloads operate under, so some work may need to be done to establish how to migrate the SLAs too.
- Management of risk at the service level
Establish a monetary value to these benefits, again utilizing known values where you have them, or by evaluation of market trends and surveys.
Now, Compare!
The final step is to weigh the costs and benefits in order to determine if the proposed action is worthwhile.
To do this, compare the total costs and total benefit values:
- If the total costs are much greater than the total benefits, it’s pretty clear that the project is not a worthwhile investment of company time and resources.
- If total costs and total benefits are roughly equal, it’s best to reevaluate all the costs and benefits that you’ve identified and to revise the cost benefit analysis. Items are often missed or incorrectly quantified. Fix the errors, and you’ll very likely get a clear pointer in one direction or the other.
- If the total benefits are much greater than the total costs, then bingo! Your move into the cloud is potentially a worthwhile investment and should be further evaluated as a realistic opportunity.
Review
Most of this is pretty straightforward, but it’s what you have to do nonetheless – and it’s important to make sure you do it carefully.
To summarize, first assess all your costs and benefits of moving to the cloud, then:
- Add up all your potential costs
- Add up all your potential benefits
- Compare the two!
If you missed the first two parts of this series, you can find them here and here.
Check out our list of blogs on workload migration and stay tuned for Part 4, where I’ll dive into stakeholder analysis.
Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.
