Lift-and-Shift

The lift-and-shift cloud migration model involves replicating existing applications to run on a public or private cloud platform, without redesigning them. The underlying infrastructure is moved to run on virtual servers in the cloud; however, the application uses the same technology stack as before and thus is not able to take full advantage of cloud platform features and services. As a result, applications migrated following the lift-and-shift approach typically make less efficient use of cloud computing resources than cloud-native applications. In addition, they might not be as scalable or cost effective to operate in the cloud as you would like. However, lift-and-shift is a viable strategy: redesigning a monolithic application to take advantage of new technologies and cloud platform features can be time consuming and expensive. Despite applications migrated via a lift-and-shift approach being less efficient than cloud-native applications, it can still be less expensive to host a ported application on a cloud platform than on traditional static infrastructure.

Challenges Migrating Applications to the Cloud

Although the applications can remain largely unchanged, there are a number of challenges to migrating applications to virtual servers, which organizations will need to consider when developing their cloud migration strategies in order to minimize business impacts throughout the process. The biggest challenge identified by survey respondents was knowing all of the applications and dependencies in the existing environment (59 percent of 134 respondents to this question—see Figure 2-1).

Figure 2-1. Challenges migrating to the cloud

Not all applications are suitable for hosting in the cloud. Migrating resource-intensive applications that run on mainframes, doing data-crunching, media processing, modeling, or simulation can introduce performance or latency issues. It can be more expensive to run these in a cloud-environment than to leave them where they are. Applications that rely on local third-party services also might not be good candidates for migration, because it might not be possible to (or the business might not be licensed to) run the third-party services in the cloud.

Some parts of an application might require minor refitting to enable them to operate or operate more efficiently within the cloud environment. This might include minor changes to the application’s source code or configuration; for example, to allow the application to use a cloud-hosted database as a service instead of a local database. Getting a picture of current applications and their dependencies throughout the environment provides the basis for determining which applications are the best candidates for migration in terms of the extent of any changes required and the cost to make them cloud-ready.

Starting small and migrating a single application (or part of an application) at a time rather than trying to migrate everything at once is considered good practice. Understanding dependencies through analyzing and mapping out connections between applications, services, and cloud components, will help to identify which part to migrate first, and whether other parts should be migrated at the same time as well, as to reveal any technical constraints that should be considered during the migration.

Understanding an application’s dependencies and how it works can provide some clues for predicting how it might perform in a cloud environment, but benchmarking is an even better strategy for determining whether the level of service provided by a newly migrated cloud application is acceptable. The second biggest cloud migration challenge identified by 37 percent of the survey respondents in Figure 2-1, was ensuring service-level agreements (SLAs) before, during, and after migration. The level of service in terms of availability, performance, security, and privacy should be assessed through performance, stress, load, and vulnerability testing and audits. This can also inform capacity planning as well as vendor selection and sizing (simply for the sake of cost savings)—a challenge reported by 28 percent of respondents from Figure 2-1.

Continuous Integration and Delivery

Migrating applications to the cloud is not an overnight process. New features or bug fixes will likely need to be introduced while an application is in the process of being migrated. Introducing Continuous Integration and Continuous Delivery (CI/CD) as a prerequisite for the migration process allows such changes to be rapidly integrated and tested in the new cloud environment.

Organizations can achieve a faster release cycle by introducing a CI/CD pipeline. A deployment pipeline breaks the build-up into a number of stages that validate that recent changes in code or configuration will not result in issues in production. The purpose of the deployment pipeline is threefold:

• To provide visibility, so that information and artifacts associated with building, testing and deploying the application are accessible to all team members

• To provide feedback, so that all team members are notified of issues as soon as they occur so that they can be fixed as soon as possible

• To continually deploy, so that any version of the software could be released at any time

Automation

Operating efficiently is key to becoming cloud-native. CI/CD can be performed through manually merging, building, testing, and deploying the software periodically. However, it becomes difficult to release often if the process requires manual intervention. So in practice, building, testing, and deployment of cloud applications are almost always automated to ensure that these processes are reliable and repeatable. Successfully delivering applications to the cloud requires automating as much as possible.

Automated CI/CD relies on high-quality tests with high code coverage to ensure that code changes can be trusted not to break the production system. The software development life cycle (SDLC) must support test automation and test each change. Test automation is performed via testing tools that manage running tests and reporting on and comparing test results with predicted or previous outcomes. The “shift-left” approach applies strategies to predict and prevent problems as early as possible in the SDLC. Automated CI/CD and testing make applications faster and easier to deploy, driving frequent delivery of high-quality value at the speed of business.

Infrastructure as a Service

In the early stages of moving into the cloud, the tech stack for most applications will remain largely unchanged—applications use the same code, libraries, and operating systems as before. Porting applications to the cloud involves migrating them from running on traditional infrastructure, to virtual machines (VMs) running on an Infrastructure as a Service (IaaS) platform. Seventy-four percent of respondents to the Cloud Platform Survey reported that they are already running IaaS in production (364 out of 489).

IaaS technologies provide virtualized computing resources (e.g., compute, networking, and storage) that you can scale to meet demand. The switch to virtual servers rather than physical servers facilitates faster and more flexible provisioning of compute power, often via API calls, enabling provisioning to be automated.

Enabling Technologies

In addition to IaaS platforms for hosting the virtual servers, enabling technologies for this first stage of cloud evolution include Configuration Management (CM) tools, to manage the configuration of the virtual server environments, and CI/CD tools to enable applications to be be deployed to these virtual servers, quickly and reliably.

IaaS Technologies

IaaS platforms provide computing resources in the form of VMs. Rather than physical CPU cores, virtual processors (vCPUs) are assigned to VMs, by default one vCPU per machine. VMs can be allocated more than one vCPU, to enable multithreaded applications to execute tasks concurrently. These are typically provided on a per-use basis, and the customer is typically billed for using these resources by the hour, or month. Virtual cores might not map 1:1 to physical cores; for example, a business might choose to over-provision vCPUs to pCPUs in their private VMWare cloud to make more effective use of physical hardware resources. IaaS allow effective management of other resources including network interfaces and storage, allowing them to be added flexibly to instances as required.

IaaS platforms can be public (hosted by a third-party like Amazon), private to the organization, or a hybrid of the two.

Private clouds are usually hosted using private infrastructure on-premises. For organizations dealing with sensitive data, a private cloud provides the benefit of more control. The close proximity also reduces latency.

A hybrid cloud is a blend of both private and public cloud for which services are spread across both public and private infrastructure with orchestration between. A hybrid cloud can provide a best-of-both-worlds solution; for example, an organization might primarily use a private cloud and only spin up instances on a public cloud for failover, when there aren’t enough resources in the private cloud to meet demand. This strategy ensures that organizations retain flexibility and resiliency while capping private infrastructure costs.

Tables 2-1 and 2-2 show the breakdown of adoption of public versus private IaaS technologies among survey respondents who indicated they are using IaaS (364 respondents in total).

Table 2-1. IaaS platform usage (public cloud)

IaaS platform (public cloud)	Count	%
AWS EC2	175	74 percent
DigitalOcean	25	11 percent
Azure Compute	18	8 percent
Google Cloud Platform CE	17	7 percent

Public cloud platforms were the most frequently adopted with 65 percent of the survey respondents using an IaaS platform in production. Of those respondents using a private IaaS platform, slightly more than half were using VMware vSphere, with OpenStack being the other commonly adopted platform.

Table 2-2. IaaS platform usage (private cloud)

IaaS platform (public cloud)	Count	%
VMware vSphere	45	54 percent
OpenStack	39	46 percent

Of the 235 respondents who have adopted a public IaaS in production, 42 percent (86 respondents) indicated that they intend to migrate from their current strategy, either within the next four years or as an ongoing process (Figure 2-2). Of those 86 respondents intending to migrate, 70 percent anticipated moving to a hybrid cloud rather than switching exclusively to a private cloud solution.

Figure 2-2. Are you planning to migrate (parts of) your public cloud to a private or hybrid cloud?

The top drivers for migrating from public to private or hybrid cloud are listed in Figure 2-3. Reducing costs was the most common motivating factor, reported by 67 percent of the 86 respondents.

Figure 2-3. Motivations for migrating from public cloud

Of the 84 respondents using private IaaS platforms in production, 57 percent intend to migrate to a public or hybrid cloud (Figure 2-4), with 77 percent of those respondents indicating that they plan to adopt a hybrid approach. This is comparable to the results for public cloud migration, with a combined figure of 72 percent of respondents who are currently using IaaS in production planning to migrate to a hybrid cloud.

Figure 2-4. Are you planning to migrate (parts of) your private cloud to a public or hybrid cloud?

Figure 2-5 shows that scalability was the number one reason given for migrating from a private cloud (71 percent of respondents) with flexibility also a major consideration.

Figure 2-5. Motivations for migrating from private cloud

Public cloud IaaS technologies

The top public IaaS technology platforms in use by survey respondents included AWS EC2, DigitalOcean, Azure Compute, and Google Cloud Platform CE.

AWS EC2

AWS Elastic Compute Cloud (EC2) is central to Amazon’s widely adopted cloud platform. AWS EC2 was the most popular of the public IaaS offerings from Table 2-1, used by 74 percent of the 235 public cloud adopters.

DigitalOcean

Digital Ocean provides low-cost Unix-based virtual servers (known as droplets) via a minimalistic user interface and simple API aimed at software developers. Eleven percent of survey respondents in Table 2-1 have adopted DigitalOcean.

Azure Compute

This is Microsoft’s compute service with support for Linux and Windows VMs. Eight percent of survey respondents use Azure Compute.

Google Cloud Platform CE

Google’s Compute Engine offers Linux and Windows-based virtual servers and is in use by 7 percent of the survey respondents from Table 2-1.

Private cloud IaaS technologies

Of those respondents on private clouds, VMWare vSphere and OpenStack were the top platforms adopted.

VMWare vSphere

This is VMWare’s suite of professional products built around VMware ESXi VMs. This was the most popular private IaaS option among the survey respondents, with 54 percent of respondents from Table 2-2 reporting that they use VMWare vSphere for their private cloud.

OpenStack

OpenStack is an open source cloud operating system managed by the non-profit OpenStack Foundation, designed to be used for both public and private cloud platforms. Thirty-nine respondents (12 percent of all respondents from Tables 2-1 and 2-2) reported that they are using OpenStack in production. Fifty-four percent of respondents using OpenStack indicated that they were responsible for operating and maintaining IaaS in their OpenStack cluster, whereas 51 percent were responsible for maintaining applications running on IaaS.

Figure 2-6 shows the reported number of physical cores in the OpenStack clusters by those 39 respondents. Slightly more than a quarter (26 percent) of respondents were running between 10 and 99 cores, with a further 26 percent running between 100 and 999 cores. Thirty-eight percent of respondents were running a cluster with more than 1,000 cores.

Figure 2-6. How many physical cores does your OpenStack cluster have?

Conclusion

Initial steps into the cloud typically involve migrating existing applications to a public or private IaaS cloud platform via a lift-and-shift approach, and establishing a CI/CD pipeline to speed up application development and delivery. Key practices in this early phase of cloud migration include automated testing and monitoring:

• The processes for checking code quality need to keep pace, or the end result will be shipping poor-quality code into production faster; hence, automated testing is a key practice during this phase.

• Monitoring keeps tabs on the performance of the application and cloud platform and helps to identify and diagnose any problems that might have arisen during the migration.

Case Study: Capital One—A Bank as a World-Class Software Company

Founded little more than 20 years ago, Capital One is today one of the largest digital banks and credit card issuers in the United States. Given the fast digitization in the banking industry, Rich Fairbank, the founder and CEO is convinced that “…the winners in banking will have the capabilities of a world-class software company.”

The goal of digitization is to “deliver high-quality working software faster.” This requires a novel approach to software engineering, changed organizational roles, and a completely new set of individual skills. Software engineering strategies adopted for delivering quality software rapidly include using open source technologies and developing an open source delivery pipeline, as described here:¹

Capitalizing on open source technologies

Capital One is building its own software relying on open source technologies, microservice architectures and public cloud infrastructures (mostly AWS) as production, development, and testing environments. And it subscribed to Continuous Delivery and DevOps.

Delivery pipeline as key technology

The CI/CD pipeline covers the complete technology stack: all application software, the infrastructure (it is code, too!) as well as all testing procedures. The tests include static scans (security antipattern checks), unit testing, acceptance tests, performance tests, and security tests. Capital One developed its own open source pipeline dashboard Hygieia. The goal was to increase the visibility of code moving through the pipeline, identify bottlenecks and ultimately speed up the delivery process even more.²

Capital One employs about 45,000 people, including thousands of software engineers. The technical challenges required developing completely new skills sets, changing existing workflows and practices, and enabling continuous learning and knowledge sharing. This was achieved by moving to cross-functional teams and facilitating learning and knowledge sharing through communities of practice, open spaces, meetups, and conferences, as described here:

Individual skills

There are discussions in the broader DevOps community whether in the near future software testers will be out of their jobs and replaced by programmers. Adam and Tap talk about the evolution of skills. Previously, testers and quality assurance engineers had a single skill set for specialized tasks like security testing, performance testing, functional testing, test data generation, and so on. Now testers are part of cross-functional teams, where everybody knows a programming language. They need to know the cloud and orchestration and scheduling technologies. They need to be intimately familiar with the deployment pipeline, with integrating tests, and creating custom reports. The new generation of testers will take on DevOps roles or system integrator roles or even become full developers because of their new skill sets.

Guilds and Communities of Practice (CoP)

How can training for these completely new skill sets scale for a big enterprise? Besides an online training curriculum, CoPs and guilds became central to a culture of sharing and contributing. A CoP is a semiformal team focused on a specific topic. Members from unrelated departments come together to solve problems in their area, share knowledge, and document new solutions for the broader community.

Open Spaces

To facilitate learning on an even bigger scale, Capital One organizes meetups, Open Space events, and conferences. At Open Spaces, 100 to 200 people come together with a common problem and mingle with some experts. The events are based on the principle of self-organization for which the agenda only emerges after an initial opening circle. As Adam and Tap put it, “It’s a great way to bring a bunch of people together and jumpstart their knowledge and their networks.“

Conferences

Capital One organizes the annual Software Engineering Conference SECON just for their own employees with no vendors. In 2016, more than 2,000 employees met and 146 sessions took place. All sessions were focused on new topics that are specifically relevant to the bank like microservices, Bitcoin and the blockchain, new programming languages like Go, AWS Lambda functions, and so on. There were also 54 tech booths for teams to present and discuss their work. One purpose of conferences is to create a culture of “reuse.” In a typical engineering culture, heroes who create something new are awarded. In a big organization fast adoption also needs a rich culture of reuse and evolutionary improvements.