Menu

Six questions to answer before migrating to the cloud

September 1, 2022 by Christopher Sherman

Migrating workloads to the cloud is not without risk. The first step is developing a plan with buy-in from stakeholders across the organization. The team should be comprised of executives, managers, and engineers from the Infrastructure, Operations, and Software Engineering teams, as well as the end users of the services being migrated. Before going forward with a cloud migration, we should define migration goals and ground our plans in hard metrics. This allows us to make data-driven decisions about migrating to the cloud.

Example metrics:

  • Infrastructure costs will fall by 25%
  • Download speeds will improve by 60%
  • Time to provision new infrastructure will fall by 99%
  • Duplicating infrastructure in the cloud enables a warm backup site for disaster recovery
  • Consolidating data centers by moving to the cloud provides a centralized view of our environment with improved visibility into where our infrastructure spend is coming from

Five Ws of cloud migration

ScienceLogic has years of experience advising a variety of organizations on cloud migration. They have distilled the migration process into five questions to answer before moving to the cloud (ScienceLogic 2015):

  1. Why migrate?
  2. What to migrate?
  3. What are the migration steps?
  4. When to migrate?
  5. Where to migrate?
  6. Who to ask for help?

Why migrate?

Businesses have a variety of motivations for migrating to the cloud. Common reasons include improved utilization via resource elasticity, ease of infrastructure provisioning, and reduced maintenance and compliance costs. Considered together, these capabilities increase the agility of the business by seamlessly handling spikes in traffic, obviating capital expenditure on physical infrastructure, and reducing the friction involved with introducing new services or entering new markets.

What to migrate?

Some services are easier to migrate than others. Commercial-off-the-shelf (COTS) products, such as Microsoft Exchange, are easily migrated, because the migration is limited to our data. Public clouds provide platforms for provisioning infrastructure for popular COTS products with the click of a button. Once we migrate our data, operating the platform in the cloud is little different than operating it on premises.

Highly customized services with hardcoded IP addresses and manually-installed dependencies are the most difficult to migrate. We may have difficulty identifying the external resources these services make use of, such as APIs and databases. Even if we identify where to change these settings in the code or configuration, the services themselves may have security settings to prevent a server with a different IP address from connecting. Manually-installed dependencies on a particular machine are an additional challenge, because there may be no documentation of what dependencies a service requires to run. When we migrate such a service to the cloud, we should document these dependencies so we can run the service on an arbitrary host rather than being tied to a dedicated machine. We can accomplish this via an infrastructure-as-code strategy, whereby we automate the steps required to stand up a host machine.

What are the migration steps?

Migrating to the cloud requires determining which types of cloud services we want to use. Rarely can our organization “forklift” a service from on premises to the cloud and enjoy reduced costs (ScienceLogic 2015). Instead, we must select the type of cloud services we need and embrace the capabilities the cloud offers.

There are three primary types of cloud services:

  • Infrastructure as a Service (IaaS) provides the physical infrastructure for running software, but it is entirely up to us to configure and maintain the software running on the servers. IaaS relieves us of acquiring, racking, powering, and cooling physical infrastructure. An example of IaaS is a virtual machine running on the Microsoft Azure platform.
  • Platform as a Service (PaaS) provides an environment with all the software required to run a particular class of products preinstalled. It is our responsibility to operate and maintain the service itself, but the cloud provider takes care of platform maintenance and offers features such as elastic scaling. An example of PaaS is Lamba Functions: individual HTTP endpoints running on the Amazon Web Services platform.
  • Software as a Service (SaaS) is a fully-managed deployment of COTS software. Office 365 is an example of SaaS. We configure and use Office apps, but we do not operate the underlying Exchange server.

When migrating to the cloud, a common misconception is everything will be cheaper than a traditional on-premise or co-located data center. However, this is not always the case, especially when comparing the on-premise cost to PaaS or SaaS offerings. The margin a cloud provider charges above its costs typically increases as the number and complexity of the resources it manages increases. Generally, the cost of IaaS is less than the cost of PaaS, which is less than the cost of SaaS.

Before migrating to the cloud, we should carefully consider the actual cost of running our current infrastructure relative to the expected cost of running that infrastructure in the cloud. When calculating costs, we should factor in services that come baked into most cloud services, such as securing and updating software and maintaining the physical infrastructure, each of which we are responsible for in a physical data center. Keep in mind prices charged by cloud providers are not static, so migrating to the cloud will introduce additional uncertainty when forecasting future costs.

To reduce the cost of operating in the cloud, consider reserving infrastructure or committing to a minimum level of spend. On-demand resources, sometimes called pay-as-you-go, are the most expensive and should be used judiciously. Reserving compute instances over a one-to-three-year horizon can reduce costs by 50-75 percent relative to on-demand costs. For fault tolerant, stateless services, we can consider spot instances, whose prices fluctuate and run only when our bid is greater than the market price. Spot instances can reduce costs by up to 90 percent, but we must tolerate the termination of spot instances with limited warning when prices exceed our bid amount. Storage resources offer similar discounts in exchange for committing to a minimum level of usage or spend.

Once we move some resources to the cloud, it is time for our team to begin embracing the cloud’s capabilities. This may include changing how we allocate resources. For instance, the elasticity of cloud services enables us to expand storage capacity automatically rather than allocating a large block of storage to satisfy our maximum expected utilization on six month intervals. Similarly, we may not need a powerful, dedicated server if we can leverage Lambda Functions that bring up additional nodes on-demand. Taking advantage of these capabilities usually typically requires refactoring our services, particularly those that operate on the assumption of a single server providing local storage and compute.

Optimization is the final step in the migration journey. In this stage, we leverage DevOps tooling to automatically scale up and down our cloud resources based on actual utilization. By increasing utilization, we avoid unnecessary costs. Compare this paradigm to running infrastructure in a co-located data center, where we dedicate resources to handle infrequent spikes in demand, tying up resources while minimally utilizing them. It is in this area where we can bring the cost of operating in the cloud near or even below the cost of operating on premises.

When to migrate?

Migrating to the cloud involves more than technical challenges. Personnel, legal requirements, and return on investment are a few aspects to consider before attempting a migration (ScienceLogic 2015).

While cloud services are similar to on-premises offerings, there are important differences. Operating in the cloud requires taking a cloud-native approach to managing infrastructure and building services. For instance, we may no longer be able to guarantee a service runs on a particular host or at a particular IP address. Our developers should embrace strategies like the 12-factor app methodology before we start migrating services to the cloud. If we currently silo the organization into security, networking, systems, and apps teams, the migration and subsequent development of new services will bog down. Migrating to the cloud requires our teams to adapt its practices and work together to determine things such as:

  • Who is authorized to provision new cloud services?
  • How will users on our intranet access services on the cloud provider’s network?
  • What refactor/rewrite is required to get services to the cloud?
  • What refactor/rewrite is required to take advantage of the cloud’s elasticity?

Beyond these immediate considerations, we should consider how to handle the ability to create “rogue” services. When our infrastructure was physically located in a data center, is was not easy for someone to stand up a new service without the blessing of the systems team. After migrating to the cloud, any developer with the right permissions can provision cloud services without directly interfacing with the systems or management teams . This could expose the organization to security vulnerabilities and unnecessary costs.

Migrating to the cloud involves additional legal considerations. Large cloud providers have infrastructure spread across the world, and where they run our services and store our data is not always transparent. Some governments require their citizens’ data be stored within their borders, so we may need to use special configuration or even separate cloud products to ensure we meet these requirements.

Another legal concern is service level agreements (SLAs) with our customers. If the SLA of a cloud-provided service is lower than the SLA we promised our customer, a cloud provider’s regularly-scheduled maintenance window could cause us to breach our SLA. Even if the SLAs of the cloud provider meet or exceed existing SLAs with our customers, we must plan for how to react if the cloud provider fails to meet its SLAs.

Most importantly, we should not migrate to the cloud without calculating our marginal revenue relative to marginal cost, otherwise known as return on investment (ROI). As mentioned previously, the cost of operating in the cloud is not necessarily cheaper than the cost of operating on premises. We should carefully forecast what benefits migrating the cloud will bring and formalize those benefits in the context of ROI. The initial cost of migration may be quite high, but if we achieve revenue-boosting agility while reducing operating expenditures over time, migrating to the cloud can generate a positive ROI.

Where to migrate?

Most people think of public clouds, e.g., Amazon Web Services, Microsoft Azure, or Google Cloud Platform, when discussing a cloud migration, but a leveraging a private cloud is a viable alternative for some organizations. AWS has the ability to run a subset of its services on-premises through its Outposts offering. Similarly, technologies like OpenStack enable us to set up a cloud environment in our own data center with many of the same capabilities offered by the public cloud. When deciding whether to migrate to a public or private cloud, considerations such as personnel expertise, security, data sovereignty, and maintenance effort come into play.

An increasingly popular approach is operating a hybrid cloud. Under this approach, an organization keeps some of its workloads on premises while migrating a subset of its workloads to the cloud. This strategy fits well when we have some services with steady utilization and others with highly-variable traffic. We operate the steady workloads on premises, taking advantage of the lower cost of owning a highly-utilized, dedicated server. Meanwhile, we operate spikey workloads in the cloud, where we leverage the cloud’s ability to elastically scale resources up and down. With a cloud-native approach, we can operate the same service both on premises and in the cloud via an orchestration tool like Kubernetes.

Within a cloud environment, we must decide whether to migrate to a IaaS, PaaS, or SaaS. Existing services we are unwilling to refactor may be best suited to IaaS, because we can fully customize the environment in which they run and minimize the changes necessary to get to the cloud. PaaS is good option for new or refactored applications, because the platform eliminates many maintenance activities associated with IaaS and often scales automatically. Finally, SaaS is the best option for mature software offerings, especially when we do not have the expertise to develop or operate this software at a lower cost using our own personnel.

Once we decide on the type of cloud services to use, we need to determine the level of support we need. Global cloud providers, such as Amazon Web Services and Microsoft Azure, offer support plans to receive advice on best practices, training, and incident triage, among other options. Managed service providers (MSPs) offer turnkey solutions with a high level of support and usually specialize in a particular area, such as backup and disaster recovery. Many MSPs provide the option to run our services on their own private cloud or on one of the public clouds, allowing organizations to selectively leverage an MSP’s expertise while directly managing other workloads. Which cloud vendor to choose is uniquely determined by our personnel, customer base, workload, and regulatory requirements.

Who to ask for help

When undertaking a cloud migration, it helps to have people who have successfully navigated cloud migrations in the past. Consulting partners leverage their expertise and experience to map out the entire migration process and, optionally, implementation. Cloud providers offer documentation and case studies on successful migrations, with many offering their own consulting services. Software vendors offer tools for mapping dependencies between on-premise services (e.g., ScienceLogic monitoring) and unifying disparate data sources into a single API for data migration (e.g., Denodo platform) that can accelerate the planning and migration process.

Conclusion

Migrating to the cloud is a significant undertaking that requires the right expertise, planning, tools, and stakeholder buy-in. Just as adopting the enterprise resource planning (ERP) systems of yesteryear resulted in both transformative successes and spectacular failures, moving to the cloud is a balance of risk and reward.

Sources

ScienceLogic. (2015). Getting to the Cloud Faster: The 5 Ws of Cloud Migration. https://www.cloudindustryforum.org/content/getting-cloud-faster-5-ws-cloud-migration

architecture