Whitepaper

Migrating to the Cloud: A Cookbook for the Enterprise A whitepaper by David Linthicum

Migrating to the Cloud: A Cookbook for the Enterprise

EXECUTIVE SUMMARY As cloud computing matures, its value becomes better known and better understood. Cloud hype is now transitioning to competitive and economic pressure to accelerate software capabilities. Migration of applications to the cloud is no longer “if” but “when” the IT organization will have a deep understanding of cloud opportunities and limitations. Moving the wrong applications could result in huge, expensive projects that do not meet expectations while failing to move the right services could mean lost opportunities. This paper is business case-focused, which means the migration to the cloud should have a clear business benefit. We’ll provide concepts designed to help you better understand the value proposition for the use of cloud-based platforms, as well as suggest approaches and tools to help you understand the existing state of your applications, and how to approach the migration of those applications. You’ll also see how you can benefit from moving some or most of these applications to public, private, and hybrid cloud platforms, and how to monitor that value, once your cloud-based systems are in production. Those who have put off the move to the cloud for the last several years now face situations where cloud computing can provide some unique strategic and economic advantages that can no longer be ignored. However, many in IT find it hard to translate their existing business needs into a true migration plan. We will soon reach a point in time when a migration plan will be a requirement, one that includes financial considerations and strong metrics. The migration model (or, Cookbook) provides the knowledge and methodology you’ll need to get through the initial analysis, and put you on the right path toward application migration to the cloud. The model is meant to be modified to meet your exact needs. As such, it will provide a sound foundation to get you started on the right path to move your IT services to cloud computing, or give you an understanding as to why certain applications should not be moved to the cloud. This approach provides the ability to understand the technology benefits of leveraging cloud computing for certain applications, as well as how to form business cases that will typically guide you toward the right services selections. It’s a matter of understanding what goes where, and then following a process to create the right prioritization of application migration (when it goes), and how this all translates into a master plan (how it goes).

2

Migrating to the Cloud: A Cookbook for the Enterprise

CONTENTS Executive Summary 2

Optimize and Test

11

Performance

11

Define 4

Stability

11

Selecting Applications for Migration

4

Fit-to-use

11

New or Existing?

6

Gathering Metrics

Workload Profile

6

Execute 12

Application Architecture

6

Business Case

7

Application Validation

7

The Cloud Migration Cookbook 4

Develop 7 Options

7

Becoming Cloud Native

8

When to Refactor?

8

Dealing with the Data

8

Application Security

9

Application Governance

9

How to Approach Testing

9

Selecting the Cloud Platform Selecting the Development Platform

3

Validate 11

10 11

11

About the Author 12 About the Sponsor 12

Migrating to the Cloud: A Cookbook for the Enterprise

THE CLOUD MIGRATION COOKBOOK

DEFINE

The purpose of this paper is to provide you with a very clear path to migrating new, as well as existing applications to public cloud platforms. Instead of focusing on the concepts of cloud computing, which is done in plenty of other places, we’ll focus on a step-by-step procedure to host a new or existing application on a cloud or clouds, or, a Cloud Migration Cookbook. This guide, if followed, will help insure success the first time. The Cloud Migration Cookbook outlines the migration of new or existing applications, including how to define the application requirements, migrate or develop the cloudbased application, validate the workload, and, finally, put the application into production, or execution (see Figure 1).

Define

Develop

In this step of the cookbook, we define the requirements for the migration or development of our application, which includes selection of the right applications for migration, a definition of the workload, creation of the business case, creation of the application architecture, and validation of the application.

Selecting Applications for Migration When migrating existing applications to the cloud, enterprises typically have hundreds or thousands of applications to select for migration. When making these decisions, there are a few basic rules to follow: • It is technically impractical to relocate many applications to the cloud since they are based on traditional technology. This would include moving old COBOL systems.

Validate

Execute

Security & Governance

Profile Lift & Shift Security & Governance Existing Apps

Architecture Business Case

Partial Refactor

Test

Optimize

Deploy

Operate & Monitor

Complete Refactor

Validate

Data

Metrics

Select

Cloud Platform

Figure 1: The approach to application migration for new and existing applications iterates through four major steps: Define, Develop, Validate, and Execute.

4

Migrating to the Cloud: A Cookbook for the Enterprise

• Many applications are not cost justifiable due to the amount of changes that need to occur within the application that would allow them to be hosted in the cloud. This is the case with new or dated applications. • Applications should be placed in priority order, from those that will provide the most value to the business when migrated, to those that will provide the least amount of value. • Applications should be analyzed as to the amount of work needed to meet the requirements, including a direct port (lift-and-shift1), to different degrees of refactoring the applications.

Figure 2 depicts a sample application evaluation form used to determine the amount of work required to move an application to a public cloud. Note the use of key metrics such as “Lines of Code,” “SLA” (Service Level Agreement), and performance requirements to determine if the applications are “Very Simple” to “Very Complex.” Note that we also select the number of people/resources required to port the application to the cloud, running from 1 to 50, depending upon the complexity.

Complexity

Duration

Architects

Notes

Breadth Analysis

Moderate

1 Day

1

1 experienced architect analyzes 30 applications/month on average

Depth Analysis (Modernization)

Moderate

10 Days

2

2 architect teams can perform detailed migration analysis for 2 applications/month on average

Lines of Code

Data Layer

Changes Required

SLA

Perf Required

Time

People

Very Simple

< 10,000

1 RDBMS, < 10 GB

< 5%

99

Simple

< 1 week

1

Simple

< 100,000

1 RDBMS, < 50 GB

< 5%

99

Simple

< 1 month

2

Moderate

< 500,000

1 Replica, < 1 TB

< 10%

99.9

Moderate

< 6 months

5

Complex

< 2,000,000

ActiveActive, 2,000,000

Global, PBs

> 20%

> 99.95

High

> 24 months

50

Figure 2: The approach to application migration for new and existing applications iterates through four major steps: Define, Develop, Validate, and Execute.

1. Lift-and-shift means moving the applications from traditional platforms to the cloud, with little or no modifications to the code or the data.

5

Migrating to the Cloud: A Cookbook for the Enterprise

Security & Identity Management & Service Governance

Monitoring & Management Process Management (BPMS)

Rules Management

Composites/Portals

Transactional Services

Data Services/Abstraction

Data Figure 3: An application architecture defines the core components of the application, and how they interact.

New or Existing? While building new applications in the cloud is an aspect of current trends in skills and cultural migration, the focus of this paper is on moving existing applications. Migrating existing applications does provide you with a starting point. However, you’re typically limited to the way the applications were designed. In many instances, the existing applications need to be heavily modified to take advantage of “cloud native” features. This would include allocating resources directly from the applications, which allows the applications to scale more effectively. Examples of cloud native features include applications that can provision their own resources from the cloud platform, such as when applications require more storage or more virtual machines to scale the application. The application can take full advantage of the cloud platform where it’s hosted, and leverage all of the native features to optimize both performance and efficiency.

Workload Profile No matter if you’re moving an existing application, or building new, you need to create a profile of the workload you’re looking to host on a public cloud platform. This gives you a good idea of what types of resources will be required when operating in the cloud.

6

While the types of profiles vary a great deal, typically you need to define the services required for the application, such as database and messaging, and the amount of resources it will likely need. This includes cores, memory, storage, etc., and how they relate to each other. As an example, for one application instance, you would need 3 cores and 1 TB of storage. This gives you an initial idea of the number of resources the new or existing application will require.

Application Architecture At this step, we define the overall application architecture: List the core components of the application and define how they work together. This provides a clear understanding of how the new or existing application is designed, and thus provides a good understanding of how it should be properly hosted in the public cloud. Figure 3 depicts a sample application architecture that includes data, data services, process management, monitoring and management, and security and governance. There is no standard way to define an application architecture. Indeed, the components will vary greatly depending upon the requirements of the application.

Migrating to the Cloud: A Cookbook for the Enterprise

Business Case

Options

A basic business case for a new or existing application defines both the benefits of the application, and the benefits of hosting that application in the cloud. This allows you to justify the resources required to build or migrate an application to the cloud. A business case typically includes:

The options when migrating applications include a direct port without code modification; lift-and-shift. Or, in order to customize the applications for the cloud platform, you may design a partial refactoring or a complete refactoring. A partial refactoring modifies only specific portions of the application to take advantage of the cloud platform, where a complete refactoring changes most of the application.

• The direct cost savings of moving an application to a cloud host. • The direct cost savings of building and deploying a new application to a cloud host. • The value to the business of any increases in agility, including time-to-market. • Any indirect savings, such as improved user productivity or volume discounts

A summary of the pros and cons of each approach include: LIFT-AND-SHIFT Pros • Minimal work required to move application • Faster migration and deployment Cons

Application Validation Application validation means analyzing the application as to its ability to meet the stringent requirements of many regulatory agencies. This could be financial auditors, including the SEC (Sarbanes-Oxley), or drug regulators, including the FDA and MCA, and so forth. Applications that are out of compliance need to be identified and dealt with before they are hosted on the cloud.

DEVELOP Now that the new or existing application has been defined, verified, and justified, we can look at approaches to build and deploy the application. At this stage, we focus on how the application will be built, not what the application was in its previous incarnation. Thus we’ll focus on more practical matters, such as security, governance, and testing. You’ll also notice that this is where the actual cloud platform, or cloud platforms, enter the picture. Part of the task at this stage of development or migration is to select the proper cloud platform by using the application profile and architecture we previously defined as the basis for the requirements of the cloud platform. Examples of public cloud platforms include Amazon Web Service, Microsoft Azure, or Google Cloud Platform.

7

• Typically does not take advantage of cloud native features of the platform • May cost more to operate in a cloud

PARTIAL REFACTOR Pros • Only parts of the application modified • Faster migration and deployment than complete refactoring Cons • Only takes advantage of some cloud features of the platform • May cost more to operate in a cloud

COMPLETE REFACTOR Pros • Applications are typically higher performing • Applications can be optimized to operate at lower costs Cons • Much higher cost since you’re changing a large portion of the application • Slower time to deployment

Migrating to the Cloud: A Cookbook for the Enterprise

Examples of applications that are ideal for lift-and-shift would be applications that employ a well-defined architecture, where the data is coupled to the application logic, and is difficult to separate. Thus, the cost of modifying or refactoring the application would be prohibitive. If the application runs well on the cloud, there would be no compelling reason to refactor the application. However, there are some applications that are businesscritical, but also poorly designed. Moving them to the cloud without refactoring means inefficient use of cloud resources, thus a much higher public cloud bill, and perhaps performance or stability problems. In this case, given the importance of the application, its cost justifiable to rewrite most of the application to take full advantage of the cloud platform. Or, a complete refactor.

Becoming Cloud Native To take proper advantage of a cloud platform, including IaaS and PaaS, you have to design the applications so they’re decoupled from any specific physical resource. Of course, clouds can provide an abstraction or virtualization layer between the application and the underlying physical (or virtual) resources, whether they’re designed for cloud or not. But that’s not good enough. When decoupled architecture is considered in the design, the efficiency of the development and deployment stages of an application, as well as the utilization of the underlying cloud resources, can improve by as much as 70 percent. This cloud computing efficiency equals money. You’re paying for the resources you use, so applications that work more efficiently with those resources run faster and generate smaller cloud services bills at the end of the month. Each cloud has its own way to leverage its native features. Typically, you can access these features via layers, including the topmost virtual platform/OS, underlying resources (such as storage and data), and then the cloud-native services (such as provisioning and tenant management). The cloud provides the capability you need. But to be truly cloud-native, you have to understand how to properly use each layer. This means understanding the cloud platforms, as well as the subplatforms and resources.

8

When to Refactor? So, when do you refactor an application? Before or after moving? Like most answers in the world of technology, there are dependencies that you need to consider. However, this has become a matter of some debate, as massive amounts of applications move to public cloud providers. Let’s examine the relevant facts: First, cloud providers tend to recommend the lift-and-shift approach. You would refactor the application once ported to the cloud, and then do any refactoring at the destination. The advantage of this approach is that you would learn more about the cloud platform, as well as how the application functions in the cloud, before modifying the application. Other advantages of refactoring after moving to the cloud include the ability to get internal recognition for developers’ quick successes, which can be built upon. Other advantages include getting the application into production on the public cloud platform where it can be monitored, data gathered, and then that data can be used to optimize the application on the public cloud platform. Finally, the cost could be lower. We’re perhaps doing fewer things around refactoring the application, even taking an agile iterative approach to optimizing the application. Second, there are those application architects and developers who prefer to refactor before moving to the cloud. Arguments they cite include the ability to think more methodically through the application architecture, and how the application should be changed. In some cases, very complex applications need a great deal of analysis and forethought that can be supported as well through agile, and development iteration. They also cite that taking a “one-and-done” approach could lower costs with complex applications moving to the cloud.

Dealing with the Data Most applications leverage data, and that data is either stored with block or object storage systems, or on some sort of database management system. Given the number of ways that data is persisted by applications, in this step, you need to consider the best way to store and retrieve data. In some cases, the method and mechanism that have been employed by the on premises system work just fine when the

Migrating to the Cloud: A Cookbook for the Enterprise

data is moved to the cloud. However, in some instances, new ways of storing and retrieving data are required, thus the data must be converted and the application modified. Often times the amount of data stored by the original on premises applications is significant. In this case, moving the data to a public cloud provider may not be feasible over the open Internet and other means are better employed. This might involve sending data to the public cloud provider on USB drives.

Application Security Application security should be systemic, built into the application at all levels, including user interfaces, processes, and the data. Since the applications are hosted on public clouds, it’s important to leverage the proper security technology to insure the application and the information are secure. In some instances, the approach to security is dictated by regulations, such as in the healthcare and financial verticals. Identity-based security approaches have emerged as a best practice for securing applications that reside on public clouds. This means that application services, data, users, and other items are secured by means of their identity. Thus, you can configure the security system to define how each item interacts with another item. This seems to be a better approach than traditional security methods, where access to the application is more ‘off’ or ‘on,’ and not fine-grained.

Application Governance Governance in the cloud exists at a few different levels: First is infrastructure governance, or the ability to manage cloud resources such as storage and compute services. These typically exist outside of the application. Second, application-level governance. This means managing, monitoring, and controlling application-specific components such as services, data, and processes. For our purposes, we’ll focus on application governance. Application governance provides a few core solutions to your application, including the ability to govern cloud microservices. Microservices have a software architecture where complex applications are composed of small, independent processes that communicate with each other using language-agnostic

9

APIs. These are fine-grained services, loosely coupled and highly decomposed. You need application governance approaches and technologies to inventory these services, tracking access, SLAs, and any dependencies. For instance, a composite service may be made up of many other services. If those services change, the impact of those changes needs to be tracked back to the composite services, as well as to the applications that leverage those services. Microservices must be managed as to how they are discovered, provisioned, changed, and function in runtime. Governance tools can track and manage these services across domains, and even across the entire enterprise. This is typically done by providing a service repository, which uses policies to govern and secure these services.

How to Approach Testing When testing applications in the cloud, we have a few things to consider: First, we don’t own nor control the cloud computing-based systems, thus we have to deal with what the providers give us, including the limitations, and we typically can’t change the system. Thus, we can’t do some types of testing, such as finding the saturation points of the cloud computing platform to determine the upward limitations on scaling, or attempt to determine how to crash the cloud computing system. That type of testing may get you a nasty e-mail. White box testing of the underlying platform or services, meaning viewing the code, is also not supported by most cloud computing providers, but it’s clearly something you can do if you own and control the systems under test. Second, the patterns of usage are going to be different, including how one system interacts with another, from enterprise to cloud. Traditionally, we test systems that are on premises, and almost never test a system that we cannot see nor touch. This includes issues with Internet connectivity. Finally, we are testing systems that are contractually obligated to provide computing service to our architecture, and thus we need a way to validate that those services are being provided now and into the future. Testing takes on a legal aspect; if you find that the service is not being delivered in the manner outlined in the contract, you can take action.

Migrating to the Cloud: A Cookbook for the Enterprise

Selecting the Cloud Platform As you can see in Figure 1, underlying everything is the cloud platform. It’s where the application will be hosted, and thus how the application or applications will be deployed to users. Selecting the right public cloud platform is much like selecting platforms in the past; you define the requirements of the platform, weight each requirement in terms of importance, and find a platform that best matches your requirements.

Disruption Vectors

Figure 4 is an example of a worksheet created to analyze several different IaaS platforms using “Disruption Vectors” such as storage, management, security, etc., and the weight of those items in terms of importance. Using this type of analysis, you can quickly determine which public cloud providers will likely meet your needs. Once you have a few contenders, you would be well advised to test each system before making your final selections. Disruption Vectors

Relative Importance

Storage

25%

Provisioning

20%

Management

10%

Governance

10%

Network

10%

Compute

10%

Security

15%

Sum

100%

Company Position, relative to Vector (1-5 scale) 1 = less advantaged 5 = more advantaged

AWS

Microsoft

Google

HP Cloud

IBM Cloud

Rackspace

Terremark

4

2.5

3

2

2.5

3

3

Provisioning

3.5

3

3

3

2

2.5

2

Management

3

3

3.5

3

2.5

2

2.5

Governance

3

2.5

2

2

3

2

2

Network

3

2.5

4

3

2

2

2

Compute

3.5

3.5

2.5

3

2

2.5

2

Security

2.5

2

2.5

2

2.5

2

2.5

Storage

Weighted Scoring, Vendor Positioning Disruption Vectors

Weight

AWS

Microsoft

Google

HP Cloud

IBM Cloud

Rackspace

Terremark

Storage

25%

1.0

0.6

0.8

0.5

0.6

0.8

0.8

Provisioning

20%

0.7

0.6

0.6

0.6

0.4

0.5

0.4

Management

10%

0.3

0.3

0.4

0.3

0.3

0.2

0.3

Governance

10%

0.3

0.3

0.2

0.2

0.3

0.2

0.2

Network

10%

0

0.3

0.4

0.3

0.2

0.2

0.2

Compute

10%

0.4

0.4

0.3

0.3

0.2

0.3

0.2

Security

15%

0.4

0.3

0.4

0.3

0.4

0.3

0.4

100%

3.0

2.7

2.9

2.5

2.4

2.4

2.4

Index Score

Relative Importance of Disruption Vectors Figure 4: This is an example of an enterprise that is comparing different IaaS cloud platforms, using a list of requirements (disruption vectors and their weights, in terms of importance to that specific enterprise).

10

Migrating to the Cloud: A Cookbook for the Enterprise

Selecting the Development Platform Finally, you select the development tools, or the platform you need to build or move an application. Development services typically include what you would expect, including support for a bundle of programming languages that are quickly expanding within most cloud offerings, including PaaS or IaaS (or a combination). Also included are code management services that are linked to configuration management, and a services catalog. Or, any other services required to build applications. Some cloud providers include deep support for mobile application development, and provide the ability to consider mobile deployment from development to deployment, and to runtime operations. Deployment services include testing, configuration management, application staging, and, once again, mobile deployment services. It’s at this layer where the application code goes through basic testing procedures, and is linked with a configuration management system, staged and placed into production. While we show the DevOps processes above the deployment layer, this is typically where the action occurs, in terms of continuous delivery and integration. Thus, the services at the deployment layers of cloud providers are largely automated, perhaps even leveraging well-known configuration management tools such as Chef or Puppet.

VALIDATE At this point in the Cookbook, we’ve already selected a new or existing application to place on the cloud, defined what it is, as well as how it will be built, and then actually built it or moved it. Now we need to turn our attention to validating that the application will work as expected, provide optimal performance and stability, and fit the needs of the business.

Optimize and Test There are several things you must test to validate that the migrated or new application will meet the expectations of the business. This includes testing the application, and using that data to optimize the application so it provides the best value for the application owners. Let’s address each concept:

Performance To get the best performance, companies moving to cloud platforms should consider these three rules.

11

RULE 1: THE CLOUD RIDES ON THE NETWORK, SO THE NETWORK NEEDS TO KEEP UP Companies that move applications and data to cloud, or perhaps build new systems on cloud-based platforms, often don’t consider the network infrastructure. When relying on systems that are connected via the network, the network is everything. Slow networks mean slow systems and poor performance. RULE 2: APPLICATIONS NOT OPTIMIZED FOR CLOUDBASED PLATFORMS RARELY PERFORM WELL Many enterprise IT pros believe they can lift an application from a traditional on premises platform and place it on a public cloud without a significant amount of redesign, and everything will end up fine. But how can applications un-optimized for cloud-based platforms produce optimal performance? They can’t, so you get higher operational costs and substandard performance. RULE 3: CONSIDER THE DATA The manner in which the data is linked to the application is very important to cloud computing performance. Data that’s tightly coupled to the application may not be able to take advantage of many performance-enhancing features of public clouds, such as placing database processing in a series of elastic instances, or using database as a service in the host public cloud. You should place the data in its own domain to provide alternatives for faster performance, as well as the opportunity to reduce costs.

Stability Stability is the application’s ability to provide consistent service. If the application often has outages, then the end users will no longer have confidence in it.

Fit-to-use Fit-to-use means that the application meets the needs of the business, and users are able to quickly put the application to productive use. Applications that do not provide a good fitto-use will not deliver the value needed to justify the expense of the application, and moving it to a cloud-based platform won’t solve that problem.

Gathering Metrics Core to all that’s mentioned in this section is the ongoing need to monitor the application and gather metrics. This practice provides you with a proven and proactive way to monitor the

Migrating to the Cloud: A Cookbook for the Enterprise

performance of various applications and components, such as the data layer, UI layer, etc. You can also monitor how the application scales on the cloud system, and how it utilizes the resources that are provisioned by the cloud service.

As you can see, the process of building new applications or migrating existing applications to cloud-based platforms is complex. There are hundreds of paths you can take, and only a few will make sense to you and your business.

By gathering these metrics, you can understand how the application behaves at different levels of use, and how it responds to increasing and decreasing loads. Considering that the public cloud providers charge for the resources your application uses, it’s in your best interest to make sure that you get the best performance for the resources consumed, and that the application is optimized for the cloud platform where it resides.

We’re starting to see best practices emerge that should be considered and followed. Most of the practices have been outlined in this Cookbook. This Cookbook should help take some of the guesswork out of creating a recipe for your enterprise to move applications to the cloud.

In a cloud environment, historical monitoring assumptions shift from an infrastructure focus to an application focus. Since the cloud provider is accountable for the infrastructure and you are accountable for the application, you want to focus your monitoring efforts on the behavior of the application, the customer experience, and the infrastructure from the perspective of the application and your bill.

Leading technology publications frequently name David S. Linthicum among the top 10 enterprise technologists in the world. He is a true thought leader in the industry, and an expert in complex distributed systems, including cloud computing, data integration, service oriented architecture (SOA), and big data systems. As the author of over 13 books on computing with over 3,000 published articles, as well as radio and TV appearances as a computing expert, he is often quoted in major business and technology publications. In addition, David is a frequent keynote presenter at industry conferences, with over 500 presentations given in the last 20 years.

EXECUTE This is the “do it” phase of our model, depicted in Figure 1. Here we deploy the validated application to the public cloud host and begin formal operations, including monitoring and gathering data from the executing application. Items to consider as you move to deploy and operate applications include: • Application deployment, or, hosting the application on the public cloud. This means installation of all binaries, migration of data, and configuration of all security, governance, and management systems. • Application operations, or, the processes required to operate the new or migrated application. This is typically the application of specific types of processes, so operations procedures should be created for each app. • Application monitoring means that we monitor the various application components to determine the current, past, and even the future health of the cloud-based application. As described above, we monitor such things as performance and stability. We not only look for existing and past problems, but can also leverage predictive analytics to determine when issues may occur, such as running out of cloud-based resources to run the application, or spotting patterns that indicate a security breach.

12

ABOUT THE AUTHOR

David’s industry experience includes tenures as CTO and CEO of several successful public and private software companies, and upper-level management positions in Fortune 100 companies. Dave has delivered over $2 billion dollars in value by transforming companies from traditional to innovative technologies, and moving them to lucrative exits that benefitted investors, employees, and customers.

ABOUT THE SPONSOR New Relic is a software analytics company that makes sense of billions of data points about millions of applications in real time. New Relic’s comprehensive SaaS-based solution provides one powerful interface for web and native mobile applications and consolidates the performance monitoring data for any chosen technology in your environment. Hundreds of thousands of paid business accounts trust New Relic to tap into the billions of real-time metrics from inside their production software—and provide answers to their important business questions. When your brand and customer experience depend on the performance of modern software, New Relic provides insight into your overall environment. Learn more at newrelic.com.