Organizations have begun moving applications and workloads to public cloud at an increasing rate. According to Gartner, the worldwide infrastructure as a service (IaaS) public cloud market grew 31% in 2016 to total $22.1 billion1. In 2016, Amazon AWS had the No. 1 market share of 44.2%, Microsoft Azure 7.1% of the market and Alibaba 3.0% of the market.
Organizations are relying on the public cloud for a successful digital transformation. Many organizations have established a cloud strategy and business plan for moving workloads and applications to public cloud infrastructure, but are still working to determine the migration plan to support that strategy. But not all workloads and applications may be suitable for public cloud infrastructure services.
According to ESG Research, 91% of organizations expect to have substantial on-premises infrastructure deployments for the next five years2. Most, but not all, applications and workloads can be migrated to public cloud. But just because you can migrate workloads and applications to public cloud doesn’t mean you should. As indicated, most organizations will have hybrid IT environments for the foreseeable future.
(This tutorial is part of our AWS Guide. Use the right-hand menu to navigate.)
Step 1: Take inventory
The first step in a migration to public cloud is understanding the applications you have, the on-premises infrastructure resources supporting them, and the workload interdependencies. The best way to accomplish this is by using a discovery tool that automates the discovery and dependency mapping process. A discovery tool should provide an accurate inventory of infrastructure that includes:
- Servers (physical and virtual, hypervisor, OS, CPU, RAM, disk)
- Software (+EOL), databases, web sites
- Network devices (switches, load balancers, etc.)
- Storage (devices, but also their logical partitioning)
Discovery tools will collect server specification information, server to storage relationships, performance data, and details about running processes and network connections. Use the learnings from the discovery tool to help establish a migration sequence, minimize downtime and assist in test plans.
Step 2: Evaluate applications
Not all applications and workloads are well suited for public cloud. When developing a migration plan, it is essential to evaluate the workloads and applications that are candidates for moving to the public cloud. The considerations must be measured against the goals of your cloud strategy and the potential business risk. The key is to examine all applications and workloads under a consistent framework – not on an ad hoc basis.
When assessing the readiness for running applications in the public cloud, all the options need to be considered – from retaining as is, to replacing.
Rehost
Redeploy an application to a cloud-based platform without modifying the application’s code. The reason for doing a lift and shift can be to quickly scale in order to meet a business need. Established applications that were not designed for efficient use of infrastructure will most likely cost more to run in a public cloud. Because of this, a simulated migration is recommended for rehosting applications to prevent cost surprises.
Refactor/Rearchitect
Refactoring/rearchitecting involves making modifications to the application, application framework or runtime environment. This can include making application code or configuration changes to attain some tangible benefit from moving to public cloud platform without making major changes to the core architecture of the applications.
For example, you may swap out a database server for a cloud service equivalent to reduce the amount of time you spend managing database instances. The goal is to get some optimization benefit from public cloud service with very little code change to the application.
Rebuild
For applications that you wrote, redesigning and rebuilding a cloud-native application on a provider’s PaaS may be worth the investment. This typically provides better performance and lower costs (if done correctly). This may be the right choice for applications that are business-critical, but not designed to take advantage of the services offered on a cloud platform. In addition, non x86-based applications, like mainframe and midrange applications that rely on operating systems other than Linux and Windows will need to be rewritten. This is the most expensive option, but the investment to rewrite an application may be worth it if looking to boost agility, reduce costs and improve business continuity.
Replace/Repurchase
For commercial, on-premises applications, replacement with a SaaS offering may be the best solution. Many vendors offer both SaaS and on-premises solutions now. And even if the preference is to run on-premises, many ISVs have upgraded their applications to better run on cloud platforms and it could be a matter of upgrading the application to a more current version.
Retain
Running applications on-premises is always an option. It may make good business sense to keep some applications on-premises. Lower costs and better security and compliance are strong considerations for doing so. Not every application benefits from a cloud platform. Applications that have static workloads with no agile demand, and that are running on stable systems, are good candidates to be retained on-premises.
The application evaluation phase also provides an opportunity to identify applications and workloads that are no longer needed or lack the business justification to warrant the ongoing cost to support them. This is a great time to rationalize your portfolio.
Step 3: Analyze cost
Migrating applications to public cloud platforms is a business decision that requires both financial and technical assessment. This is particularly important if the migration includes rehosted or refactored applications. If a preliminary assessment of the cost difference for running these applications on-premises vs. in a public cloud is not done, you will most likely get a big cost surprise later.
In a recent BMC survey, 40% of respondents stated they are unclear of their costs associated with cloud – even though lower cost was the primary driver (45%) for moving to public cloud.
Every IT organization should have a history of resource usage and workload patterns for their applications, along with the unit cost of infrastructure resources. Many organizations gather this information routinely and use it for chargeback or showback for IT infrastructure costs. If you do not have this information, you can still gain cost insights – they just won’t be as accurate. At a minimum, you need a unit cost for on-premises infrastructure resources and compute, storage and network resources for the workloads and applications you want to migrate. Otherwise you have no costs to compare.
The first step for determining cost of on-premises vs. public cloud costs is to identify the resources needed in public cloud. You can start by identifying the closest type of VM instance and configuration needed in public cloud. For AWS, this will be an EC2 instance and for Azure, a Windows VM. AWS has over 90 different types of VMs to choose from, and each type has multiple configurations from which to choose, and multiple locations or regions. Azure also has similar choices.
Once you have identified the compute resources, you must determine if you want to pay an on-demand price or a 40-60% discount price that you can get with one or three-year service commitments. AWS refers to these discounted VMs as Reserved Instances. If you have not yet selected a public cloud provider, you will want to compare costs across providers. Without having an automated tool to do this analysis for you, this effort can take weeks, depending on the number of applications and workloads you are analyzing.
There may be special storage, database or network resources that you need to identify and factor in as well. Once the analysis is completed, you should view it as a snapshot in time. IT environments are naturally dynamic, so costs will change over time. An ongoing cost management practice is essential to regulating operating and capital expense for a hybrid, multi-cloud environment.
Moving forward
Developing a migration plan takes time and a dedicated team. To streamline the effort and reduce time, you can use a solution like BMC Helix Discovery to automate the discovery and dependency mapping work. Once you are ready to begin migration, both AWS and Azure offer tools to help you move workloads and applications to their platforms.
Migration is just the first step of incorporating public cloud into your IT environment. To keep costs under control, you will need to establish a capacity management practice to ensure you are optimizing the use of public cloud and on-premises resources. And because of the change from capital expense to operating expense associated with this move, you will need to have an ongoing cost management practice to ensure that you adhere to both capital and operating budgets and maximize your IT infrastructure investment.
Done right, you can achieve your goals of greater agility and lower costs by extending your IT environment to include public. It just may not be as simple as you had thought.
1 Gartner Press Release, Gartner Says Worldwide IaaS Public Cloud Services Market Grew 31 Percent in 2016, September 2017, https://www.gartner.com/newsroom/id/3808563↩
2 ESG Survey, 2017↩
