The Enterprise Cloud

Chapter 4. Application Transformation

Key topics in this chapter:

• Application evolution to the cloud

• Application categories and characteristics

• The new approach to application development and delivery

• Continuous application delivery automation

• Application transformation methodology

• Application operational considerations

• Application assessment

• Application transformation best practices

Although many clouds initially focused on Infrastructure as a Service (IaaS), enterprise organizations often have applications listed as their top business priority. The reality is that a private or public cloud requires a base infrastructure of server, storage, and networking in order to begin hosting anything—an IaaS, Platform as a Service (PaaS), or Software as a Service (SaaS). In earlier chapters, I covered architectures for baseline IaaS clouds, but the largest task in the journey from enterprise IT to the cloud is in application transformation.

Key Take-Away

IaaS virtual machine services are now considered the very minimum capability for a public or enterprise private cloud. Application transformation is the longer-term goal and will take the most amount of time.

Application transformation is a fancy term for assessing the current applications and then planning and conducting migrations. When planning for your cloud transition or deployment, assessing your existing applications will lead you to decisions on what to migrate to the cloud, what apps to redesign, which to maintain in the existing enterprise, and the priorities for an eventual transition to the cloud. Before planning any application transition, it is essential to understand the basic characteristics and features of traditional and cloud-native applications. 

Evolving Your Applications for the Cloud

Chapter 1 discusses the evolution of computers, including a graphic depiction in Figure 1-1. Figure 4-1 repeats that illustration, but this time let’s focus on the evolution of applications that are shown below the trend line.

Figure 4-1. The evolution of cloud applications

Though computer hardware has evolved at a continuous and rapid pace, software traditionally has been slower to progress—until now. Although cloud computing is a new style of IT delivery, a new style of application architecture, development, and delivery is upon us. The pace of application development and delivery of new features to consumers is now expected at a pace never seen before in the history of the IT industry. In fact, I will go as far as saying that software is now outpacing hardware in terms of innovation and impact to business and everyday life.

Coming back to Figure 4-1, there are some very important software architecture concepts of particular note:

• Desktop applications are still common but remain inefficient to support and upgrade. Remote desktops or  Virtual Desktop Interface (VDI) is often still too expensive as well and still a compromise in ease of use for many organizations. Application publishing essentially pushes desktop applications into the cloud-enabled app category for at least a temporary bridge until a true cloud-enabled application is available.

• Client-server applications have been considered legacy since as early as 2010 (in case you didn’t get your official notice in the mail). They are considered too chatty or noisy for efficient network communications and scalability, and they are expensive to deploy in high availability/resilient configurations. These applications are good candidates for refactoring (this term is defined later in this chapter) to the cloud.

• Internet applications are really a combination of multitiered client-server applications and web applications hosted on the Internet—this is the Internet service provider (ISP) and application service provider (ASP) era in the years up to 2009 before the cloud. These were rarely very efficient, but they were profitable for the providers and software developers and considered bleeding edge at the time. Most of the software languages, application programming interfaces (APIs), and tools used to create these applications are effectively dead. These applications, providers, and software companies either already upgraded to cloud applications and SaaS or went out of business because they didn’t upgrade fast enough in the early days of the cloud.

• Cloud-enabled applications, also referred to as cloud-native applications, are designed to take advantage of a cloud infrastructure and all of its capabilities. Cloud-native is fully defined later in this chapter.

Application Categories

Applications can be categorized in many ways, but for this discussion, I will group them into four categories for clarity and relevancy in a cloud service environment:

COTS

COTS applications are readily available from numerous software vendors, but their suitability for implementation in the cloud is not always straightforward. Many software vendors are rewriting their applications to both fit into a multitenant cloud environment and adapt their licensing models for pay-as-you-go cloud usage models; however, there are still software vendors that do not have properly designed cloud-native applications that work in a multitenant environment.

Open source

These applications are often not shrink-wrapped or ready for purchase “on the shelf” such as with COTS products. As the name indicates, open source also means that the source programmed code is freely published so any party can customize it for its own needs, scan it for security vulnerability, and integrate other software components. Open source applications are often considered a community project with numerous (meaning hundreds or thousands) of developers, contributors, and integrators across the world. These open source applications are free for anyone to download and use, but they sometimes have licensing limitations such as not being able to use them for profit without permission or royalties paid. Some software companies take an open source application, enhance it with their own software, and sell their own distribution of the system. One key advantage is that open source applications often utilize industry standards and APIs or end up becoming a standard after sufficient adoption and industry acceptance. Besides the cost, one primary benefit to open source is that you avoid vendor lock-in. This is when you purchase and use a proprietary product and find that you are stuck with that product or it would be too costly to migrate away from it in the future.

Custom applications

Also known as homegrown applications, these are what many large organizations have the most difficulty with when planning the transition to the cloud. These applications can range from legacy mainframe programs, all the way to heavily modified COTS systems. Because there are often no integration standards and often little integration among these custom applications, there is also no single method of integrating or porting them to the cloud. Careful assessment and planning for each major application is required. A significant portion of this chapter is dedicated to this assessment topic.

Cloud native

Cloud native applications are designed to be hosted in a cloud environment and take advantage of a cloud infrastructure. This means the applications can, for example, remain online during planned or unplanned infrastructure outages and scale up or scale down to meet workload demands. Cloud applications are designed to work with other components and services within a cloud, such as databases, frontend web services, transaction queuing, payment engines, and so on, all working together in what appears to be a single cloud application or service. Cloud native apps consist of composable services (more on this term in the sidebar that follows) designed to be dynamic with respect to the infrastructure and other services with which they integrate—essentially discovering and dynamically registering services with other applications and components within the cloud rather than hardcoded mappings or static configuration. Cloud-native applications are developed to be elastic so that they can scale out automatically based on defined workload parameters. Finally, cloud applications are designed to be resilient so that the system can recover or self-heal when a problem is detected in the infrastructure, such as temporary hardware, software, or communications failures.

Composable Services and Applications

As the cloud continues to evolve, along with it has developed a small dictionary of new words and terms that, although they might not pop up in day-to-day conversation at the supermarket or while you’re watching your kid’s soccer game, they are common within the industry and often indispensable at getting an idea across concisely. Composable is one such term. Essentially, a composable service or application is one that is not hardcoded. Instead, it is flexible and adaptable, and can sense and detect its surroundings and nearby applications and services so that it could function in any cloud or environment in which it’s functioning. Think of a composable as somewhat like creating a form using sculpting clay (whose shape is inherently flexible and responsive), as opposed to using wood or some other inflexible materials; when a wood sculpture is completed, it’s nearly impossible to shape it into anything else, but a composable, like clay, can adapt to its environment and whatever new form that entails.

Application Characteristics

There are numerous characteristics that an application should have when transitioning to a cloud infrastructure. A public cloud provider will design these attributes into their application and cloud offerings, whereas a private cloud operator will have to assess and migrate legacy applications. Key characteristics of cloud-enabled (cloud-native) applications include the following:

Secure multitenancy

This means that the application is configurable so that multiple customers can share the same instance of it, while maintaining separation of all data and user accounts. Customers and users within the shared application instance cannot see one another nor any data other than their own by using security access controls lists (ACLs), role-based permissions, and sometimes separation of databases (the application is still shared but can access and utilize separate databases when appropriate).

Elasticity

Applications should be elastic as traffic, demand, and usage increases. Elastic means that an application can scale out (adding more compute resources or additional virtual machines) to handle an increase in workload or utilization. A properly designed cloud-native application should be able to automatically detect high utilization and trigger the necessary steps to start up new VMs or application services to handle peak workloads. Then, when peak utilization diminishes, it should reduce VMs or compute instances. Legacy applications that were not specifically designed to run in the cloud can often use a VM hypervisor to monitor processor and memory utilization, triggering more VM instances when a manually defined peak-utilization threshold is attained. These elasticity techniques make it possible for the applications to take advantage of the power of the cloud infrastructure to dynamically scale—even if the application wasn’t originally designed as cloud-native; although, a cloud native application is more efficient.

Resiliency

Resiliency refers to the application’s ability to survive and remain online during an infrastructure outage or failure. A properly designed cloud-native application would have multiple techniques to retry failed transactions and there would be multiple instances of the application services running on other servers or VMs. Legacy applications that were not designed for a cloud can use tools within a hypervisor or cloud infrastructure such as traffic load balancing, clustering, and server/VM failover, but these are not as effective and transparent to the end user as a cloud-native application’s resiliency. There are many other aspects of resiliency and cloud-native application design benefits that will be covered later in this chapter.

Authentication systems

Applications that might have run within existing enterprise datacenters often utilized the internal corporate Microsoft Active Directory or some other identity management system to authenticate user logons. Ideally, applications hosted in a cloud should not assume Active Directory or the internal identity system is available; instead, they should favor an industry standard for authentication and directories such as Lightweight Directory Access Protocol (LDAP) or Security Assertion Markup Language (SAML). Both provide authentication capabilities—SAML is a bit more robust and appropriate as part of a single sign-on (SSO) system.

Universal access

The applications must be accessible from anywhere on the Internet or other wide area network (WAN) circuit. The application should be compatible with any and all access methods, from web-based access, virtual private network (VPN) access, and every variety of desktop, notebook, tablet, and mobile device. This also means that the user data must also be immediately available when moving from one computing device to another. As a general rule, you should follow the same philosophy as software-defined networking: never hardcode any network addresses or assume anything; always assume applications, users, and data could exist or operate from anywhere in the world through any network connection and any form of user interface or device (see also the section “Mobility” that follows momentarily).

Multitiered applications and platforms

Many cloud applications employ a multitiered design wherein there are multiple layers, or tiers, of services. These tiers separate the backend database, middleware and applications, and frontend processing. This tiered design facilitates higher levels of security, application upgrade modularity, and independent scalability of individual tiers as needed, based on utilization. Tiered applications also benefit from shared platform or PaaS applications in the cloud, such as a database service, that multiple applications can share for lower cost of maintenance, licensing, and operations.

Mobility

With the increasing number of applications hosted in a cloud environment, users or consumers often use mobile computing devices such as tablets or smartphones. The legacy assumption that end users only have desktop PCs or a particular PC operating system (OS) is no longer true. The concept of mobile first was adopted over the past few years but is more recently replaced with ubiquitous access—the intention of both being that applications need to be designed with the ability for users to access the system through any form of computer device, from any location, and have the same experience. Mobility might also require additional security and asset configuration management features and tools to ensure identity, data encryption, data privacy, and synchronization to mobile devices for offline viewing.

Key Take-Away

Ubiquitous access, elasticity, resiliency, and persistent data are the keys to successful cloud-native applications. Applications and data must always be accessible, from any form of computing device and any location, and with a consistent user experience.

As described later in this chapter, you should consider these characteristics when developing any new applications that you plan to host in the cloud. Also, evaluate your current applications to determine if any of the features are already embedded or how legacy applications could be modified to incorporate them.

The New Approach to Application Development and Delivery

Today’s newest and most modern approach to application development is focused on rapid and continuous delivery. Private organizations and software developers are now considered “legacy” and uncompetitive, following previously traditional practices such as releasing applications once or twice a year. It is not just a trend but an expectation of business users to get more frequent updates and new software releases—as often as quarterly or monthly. Many commercial software manufacturers are already using software release cycles measured in weeks if not days, launching not just bug fixes but true new features regularly rather than saving up these enhancements for a big “annual product launch.”

Now, enter the public cloud providers and their software applications. Cloud providers have used their infrastructure and automation to further increase the pace of software delivery, sometimes daily if not multiple times per day, particularly because there are so many cloud offerings and subcomponents within each offering. The point here is that the automation and cloud management systems used by the public cloud providers can also be used in a private or enterprise cloud to facilitate rapid application development, testing, and continuous pushing to production as quickly as you and your organization can muster. Figure 4-2 compares notional application delivery cycles for a traditional application to a cloud-based continuous delivery application (future state).

Figure 4-2. Notional application delivery cycle—traditional and with continuous delivery

Welcome to the new style of IT—developer style!

Figure 4-3 presents a comparison of traditional application development compared to cloud-based development. Technically, this new pace and style of application development is not specific to the cloud; however, the cloud does provide unique capabilities such as elasticity, software-defined networking, on-demand Development/Testing as a Service (Dev/Test), shared application lifecycle platforms and tools, and an enormous worldwide hybrid infrastructure. Many of the other cloud-based development characteristics shown in the figure were described earlier in this chapter.

Figure 4-3. Cloud-based application development

Continuous Application Development and Delivery

Although not unique to the cloud, the term continuous delivery, sometimes called continuous application development, is now considered the modern methodology for application development and delivery. Continuous delivery employs an Agile-type approach to deliver continuous small software releases into production. To facilitate this application development lifecycle, continuous delivery in a cloud environment takes advantage of automation and software-defined networking to speed application development and promotion to production.

Through the use of VMs and cloud automation, new development environments—consisting of one or more VMs—you order, can provision services on-demand within minutes. You can create multiple sets of VMs so that multiple development teams can work in parallel or on different versions of the same application. Using VM snapshots and automation, these development VMs can be copied to a separate network segment/subnet for testing purposes while the original VMs remain intact for the developers to continue their work. Again, using snapshot technology, you can run multiple testing scenarios and then reset the application back to the previous snapshot for more testing. Finally, you can promote the test VMs or copy them to a production network or subnet through the application development automation—thereby launching the new application for production users. This lifecycle is repeated over and over again while also allowing continuous development and testing activities on the next application release. Figure 4-4 offers an overview of the continous application development and delivery process.

Figure 4-4. Continuous application development and delivery process

Now, consider adding preconfigured VMs with your favorite application lifecycle management (ALM) tools that automatically launch when you order a new Dev/Test subscription. Combine this with automated OS and VM templates, and you can truly appreciate how drastically cloud automation can improve a development team’s efficiency. Maybe the best part is that you can easily pause, archive, or terminate your Dev/Test environments when they are not needed and thus stop paying for the service—no servers to disassemble or clear, and your VMs are ready to become active whenever you need them again.

Although the continuous delivery process is nothing new to software teams, the integration of cloud automation and multiple software-defined network segments greatly speeds up and governs an Agile software development lifecycle. This new style of application development has essentially replaced the legacy processes of delivering major software releases in one- or two-year increments. Although the cloud is not necessarily responsible for this shift, it certainly provides further automation and elasticity to facilitate the continuous delivery model.

Application Transformation Methodology

Every  modernized datacenter or cloud will provide, at a minimum, the basic VM infrastructure, storage, and network services. When you transform mission-critical applications for use in the cloud, your applications can avail themselves of the unique benefits that the cloud offers. Purchasing or deploying a basic IaaS-focused cloud service is just an initial step in an overall enterprise IT transition to cloud. It is the application porting or redevelopment that will become the long-term path to complete the transition to cloud.

Key Take-Away

You must assess each application to determine whether a simple porting is possible or if the application will require a complete redesign to migrate to the cloud.

Application Modernization Strategies

There are  four types of application modernization strategies to migrate legacy applications in the cloud (see Figure 4-5). You first need to carry out a careful analysis of each legacy application to determine the best method to maximize long-term benefits, taking into account time, costs, and user impact. Some legacy applications are mission critical and unique to your business such that the long-term effort to redesign and recode them is worth the time and cost. Then, there will be relatively simple applications that you can quickly port (i.e., rehost or refactor) to a cloud platform, or even eliminate and replace with a SaaS offering from a cloud provider.

Figure 4-5. Application modernization strategies

Rehosting

Rehosting (or porting) of applications is essentially a “copy and reinstall” technique to take relatively simple legacy applications and host them in the cloud. These applications typically include one or more VMs and, possibly, a database that includes traditional applications which were not originally designed for the cloud. In a perfect scenario, a physical-to-virtual (P2V) migration is possible. Testing and minor configuration changes are often required, but the overall effort to port a single application is usually measured in only days or weeks. Although you might be able to rehost on the cloud quickly and without modifying the application architecture, many of the cloud characteristics (e.g., scalability, resiliency, and elasticity) might not be fully realized.

Refactoring

Refactoring an application is similar to rehosting, but some components of the application are enhanced or changed. You might break up the application into components such as frontend web servers and backend databases so that you can cluster each tier and load balance to provide higher availability, elasticity, and handle more traffic and workload. In this scenario, the core application itself needs little or no reprogramming, because the cloud infrastructure and hypervisors provide some of the scalability without the application having any of the “awareness” that a cloud-native app would.

Redesign

If there are legacy applications that you cannot rehost or refactor (because doing so would not produce the desired performance, quality, or ROI), you should consider redesigning. These applications are often the oldest and most complex legacy applications, possibly mainframe-based, that might require multilayered platforms, databases, middleware, and frontend application servers to be deployed in the cloud. More complex legacy software might require significant assessment and planning just to come up with a project plan and budget to determine the feasibility, risk, and business decision to proceed with the reprogramming. The long-term benefits of a new, properly designed cloud-native application include dynamic elasticity, resiliency, distributed processing, high availability, faster performance, and lower long-term code maintenance.

Replace

Purchasing services from an existing SaaS cloud provider and retiring the legacy application is often a fast and effective cloud-transition strategy. If the ROI to transition a legacy application to the cloud is poor, the organization should consider if the application is truly mission critical or necessary, and whether you could use a COTS or SaaS cloud provider, instead. Technically, you can consider an application hosted in a private cloud as SaaS, but most SaaS applications in the industry are hosted with public cloud providers. Excellent examples of this are public cloud email providers such as Microsoft Office 365 and GoogleApps, or customer relationship management software such as Salesforce.com. Sometimes these SaaS applications provide more features than your legacy software, but they also might not be as configurable as you are accustomed to because they are normally hosted on a shared public cloud infrastructure.

Operational Considerations for Applications

Regardless of which application modernization strategy you use, organizations must also consider operational factors. For example, applications that have been ported to a public cloud might still need database maintenance, code updates, or other routine administrative support. Applications that are hosted as a PaaS or SaaS offering might need less support because the cloud provider will have responsibilities for updating and patching OSs and software components. Of course, in a private-enterprise cloud, your staff (or hired contractor) continue to provide this support but hopefully in a more automated manner than a traditional datacenter. Consider your current staffing levels, outsourced support, and overall IT organizational structure. Most organizations that have already deployed a private cloud or use some public cloud have not reduced their IT staffing levels; however, they have changed the skillsets and team structures to better accommodate a more service-oriented model that is best suited to support a cloud ecosystem. For more details on recommended operational and support staff changes and best practices, refer to Chapter 2.

Application monitoring

When it comes to mission-critical applications that are core to your organization’s customers and livelihood, you might keep these applications hosted within a private enterprise cloud or a secure public provider. In either situation, you should still be concerned with monitoring the performance and user experience (UX). The private or public cloud management tools will provide some level of VM, and maybe some limited application-level, utilization monitoring but this is usually not adequate for truly mission-critical applications (they’re likely OK for normal business productivity systems). So, regardless of where your mission-critical apps are hosted—public or private cloud—you should still use your own application monitoring tools and techniques that include synthetic transactions, event logging, utilization threshold alerts, and more advanced UX simulated logon tools. For lessons learned and best practices for IT operations, monitoring, and process changes related to cloud-based application hosting, refer to Chapter 2.

Service levels

Consider the service-level agreements (SLAs) for applications hosted in the cloud. I cover contracts, terms, and SLAs in Chapter 5; however, specific to this chapter’s subject, you might need a higher SLA or specific terms for some of your mission-critical applications. Many public cloud providers provide a default level of service guarantee and support that is insufficient for mission-critical applications. In some cases, the public cloud provider does not even guarantee that it will back up, provide credit, or be liable for data loss. Be careful how cloud providers word their SLAs because they might only guarantee network availability in their uptime calculations instead of PaaS or SaaS platform service levels. Other vendors claim extensive routine maintenance windows (in other words, potential outages) that are also excluded from their SLA. Refer to Chapters 2 and 5 for more information on service levels and contractual terms as well as how and what changes to demand from the provider before signing an agreement.

Federated authentication

Consider  user authentication and access controls for cloud-hosted applications. You might want to federate an enterprise user directory and authentication system (e.g., Microsoft Active Directory or LDAP) to the cloud for an always up-to-date and consistent user logon experience. As stated earlier, a preferred method is to use a vendor-agnostic industry standard for authentication, such as SAML, especially when federation and SSO is required. For more information about federation and authentication systems, refer to Chapter 6.

Scalability

When migrating applications to IaaS or PaaS-based cloud services, you might gain scalability features that were not easy, cheap, or available in the legacy enterprise environment.

Scale out

Depending on the type of application modernization undertaken for a given application, the cloud-based system might now be able to take advantage of dynamic or automated scale out of additional VMs—technically, scale out is called elasticity. It is preferable that the application be cloud native or cloud enabled so that it is capable of detecting peak utilization and triggering scale out automatically. For legacy applications moved to the cloud, you can use the hypervisor and cloud infrastructure to measure utilization with defined thresholds that will trigger scale out, even though the application is unaware of these events. Scaling down after peak utilization subsides is just as important as scaling out. Again, cloud-native applications that handle this automatically are more efficient and faster to react than legacy applications that rely on the hypervisor to scale.

Scale up

Scaling up an application refers to increasing the size of a server, or more common in cloud computing, a VM with more memory and processors to handle increasing workload. Whereas the aformentioned scale out involves launching new VMs to handle peak utilization, scale up involves enlarging the configuration of the same physical server or VM(s) running your applications (up to the maximum number of processors and memory capacity for that particular physical server or VM). 

Scale up is considered a legacy technique for scaling. Scale up does not provide cloud-level resiliency or redundancy and is not as efficient compared to scale out. Scale up is considered a legacy technique whose underlying philosophy is “just buy a bigger server” rather than smaller more purpose-built servers and services in a scale-out cloud configuration. Another downside of scale up is that you often need to reboot the VMs to recognize the new processor and memory configuration. However, the need for this additional step will likely recede because some hypervisor platforms are beginning to support dynamic flexing of additional processors and memory.

Finally, consider scalability of your applications in terms of geographic access and performance. Although I discuss geographic data sovereignty and redundancy in Chapters 3 and 6, respectively, here I’m referring to load balancing and/or hosting applications in multiple geographic locations to maximize performance and reduce network latency (inherent delays in the communications path over the network). You might want to deploy your application in multiple cloud datacenters on opposite sides of the country in which you reside or in different regions of the world so that end users of your applications are automatically routed to the closest and fastest datacenter. Be aware, however, that many cloud providers charge additional fees for data replication, geo-redundancy, bandwidth, scale up/scale out, and load-balancing capabilities. For an enterprise private cloud, these geo-redundant communication circuits are often cost prohibitive.

Application performance and benchmarking

When you migrate applications to the cloud, you should keep in mind that most public cloud providers do not guarantee the performance of your custom applications nor for any customer-managed PaaS databases or platforms. The cloud provider is simply trying to avoid the argument of who is at fault if an application—particularly one that they didn’t create or manage—is not performing the way the customer believes it should. Hosting your own cloud keeps you in complete control of your applications and their performance.

Poor application performance in the cloud is often an indicator of a legacy application ported to the cloud that has not been optimized. For example, just because an application might be copied to a technically faster cloud—“as is” with little or no modifications—does not mean the legacy application will perform well. Performance testing—using live test users and possibly load-testing tools—is recommended for all applications before and after porting them to the cloud. Having the original application performance baseline measured before any transition to the cloud will give you valuable data to determine expected performance levels. You might be able to use the scale-up or scale-out techniques described earlier to improve performance and meet acceptable levels without redesigning the entire application.

Network bandwidth

Most  public cloud providers do not charge for uploading or importing data but do charge transaction, metered bandwidth, or storage input/output fees for network bandwidth. Given that your applications are moving to the cloud for the first time, it is often very difficult to estimate the bandwidth over the Internet or other network circuit. This can result in a bit of a surprise at the end of the first month that the application goes into production use. This bandwidth issue is a much lesser issue for private clouds, because they are usually hosted within your organization’s datacenters or via private network circuits. Some public cloud providers offer an optional direct connection option whereby you pay for a private circuit into the provider’s network, bypassing most of the normal variable bandwidth fees in lieu of the fixed, direct connect fee. This is well worth it for high utilization/bandwidth needs.  

Application Assessment

Assessing or evaluating your existing applications is often the most time-consuming part of the cloud transition. Implementing a private cloud, or procuring some public cloud services, is often completed within one year; however, assessing and then migrating a dozen and up to 100 applications could take a couple of years. The time it takes to perform assessments depends on (at least) three factors:

• Internal technical capabilities versus hiring external application transformation consultants

• Quantity of legacy applications and how many are complex or custom built

• Available budget as it relates to how many parallel assessment teams and work streams

Although hiring application transformation specialists will greatly improve and speed up the assessment and migration planning process, there are steps that many organizations can take to at least begin their application assessments using internal resources. Using the guidelines and checklists that follow, you might be able to self-assess many of your basic applications—saving you precious time and money—and defer hiring external application transformation-to-cloud experts for only the most complex requirements. If your organization is very large or has hundreds or thousands of applications, seriously consider using these application transformation experts who specialize in app modernization factories that have numerous experienced teams and proven processes for analyzing and migrating large quantities of applications in parallel work streams. There really is a special art to doing this type of application transformation in mass, across multiple work streams with the same standards, same governance, and same customer/cloud infrastructure requirements.

Figure 4-6 shows a recommended high-level, five-step application assessment plan.

Figure 4-6. Application assessment steps

Table 4-1 contains a checklist of tasks and items to consider during the application assessment process. Even if your organization decides to hire experts for more formal application assessments or actual application migrations, the information gathered by completing this self-assessment can be a significant head start.

Table 4-1. Initial application assessment checklist

Category	ASSESSMENT ITEMS/DATA GATHERING
List and prioritize applications	Create a list of all COTS and custom-built applications along with the primary use case or business function performed by each Specifically note the name of each application, the manufacturer/software vendor, and version of the application, if known Note any significant customizations to COTS applications that have been made and any updates that might have been intentionally skipped or avoided due to potential conflicts with these customizations Prioritize these applications lists based on criticality to the business, how broadly the application is utilized across the business (i.e., how many users), and if this is a customer-facing or internally focused application Flag applications that are seldom used, are candidates for retirement, have been considered for replacement already, and any workloads for which the cloud has been considered already
Data classification	Lower Impact Level The unauthorized disclosure of information might have a limited adverse effect on the organization. Moderate Impact Level The unauthorized disclosure of information might have a serious adverse effect on the organization. High Impact Level The unauthorized disclosure of information might have a severe or catastrophic adverse effect on the organization. Consider each application and particularly its data; rank the impact to the organization if the data is corrupted, or completely lost (requiring a data restore); repeat this data security assessment for all applications and data using the same ranking and criteria Assess the impact to the internal organization but also to your customers; in addition, weigh the potential harm to your company reputation Consider the cost and impact of data (e.g., trade secrets) lost to competitors Consider loss or corruption of customer data, the impact on your customers, and the impact to your organization that this can cause (damage to your reputation, legal issues, monetary damages, and other liabilities) Classify applications to determine which model they should follow (i.e., the highest-risk applications/data are likely candidates for a private cloud, whereas less-risky applications/data are candidates for public or community cloud models) Rank each application using one of the following impact categories:
Requirements and compliance	Briefly list the top business and technical goals (if known) for the application—and possible next generation of the application Goals or requirements might be to improve application performance problems, reduce licensing purchasing costs, improve user experience/usability, and improve reliability/high-availability Also note any compliance or similar requirements such as industry or government regulations that might impact the application design, security controls, where data is stored or who has access to and administration of the application and data
Application architecture	Is the application currently hosted on a single server, spanned across multiple services? Is there a backend database? Can frontend services (web, client-facing application interfaces) be separated into their own network segment from the rest of application, database, middleware? Does the current application use a multitiered architecture such as separate database, middleware, and frontend processing services? Can the application and middleware be separated into its own network segment, forming two or three tiers of networks? Can or should the application share a common database, middleware, or other application or PaaS-type services? Shared services could increase security but reduce licensing costs and easier to manage in an automated environment. What application platform or programming language was used as the basis for the application (if known)?
Application modernization and migration	For every application, consider the cost, effort, and risks to redesigning/recoding and if the application is worth the effort, cost, and risk; consider moving commodity applications, such as email, to hosted or even public cloud services Hire outside consultants and experts in application transformation, if needed, to provide more detailed analysis (even down to code level) if necessary Which applications could be ported “as is” to the cloud using scaled-up (more computer power) cloud servers? Which applications could be ported to the cloud and use hypervisor-level scale out (such as additional frontend servers) without the application having to be recoded? Evaluate which applications would benefit from application redesign to take advantage of automation, elasticity, on-demand pay-as-you-go cloud services
Application management	Always consider how consumers will order applications, how automation will provision them, and how other automated processes will upgrade and monitor them What application settings, customizations, and self-service controls should be available to administrators and users? Is there a commercial control panel already available on the market or will this need to be programmed as part of the application transformation and deployment in the cloud? Avoid relying on individual app management consoles for each application. Will there be billing or financial chargeback of application, data, transactions or data fees to the consumers or other departments? Consider how the cloud management platform will handle this. What application statistics and reports will need to be presented in the cloud management portal to the customer/consumers? What user roles and groups need to be created/managed? How will user authentication and identity for logon to each application be managed and federated through cloud management or other systems? Consider how you should treat user accounts and data, in each application, when the user no longer exists in the organization, the account is removed, and so on.
Operations and governance	Evaluate who is currently, and who should in the future, be performing all application upgrades, data maintenance, and monitoring. Are there existing challenges that could be addressed as part of application transformation (change in personnel responsibilities, governance, etc.)? Consider grouping similar application profiles from an operations standpoint into the same cloud model (i.e., private cloud with operations/management by internal employees) versus applications that are commodities (meaning, they could be operated by anyone internal or outsourced) versus mission critical (meaning, they should only be run/operated by specific persons or department). Consider advantages and disadvantages of outsourcing application management and upgrade to an external cloud provider (public cloud model) or peer agency (community model); consider which applications are commodities and where an existing SaaS or PaaS cloud provider has a similar or better offering
Mission criticality	Assess how critical the application—and particularly the data—is to your customers and/or the mission of the organization. This can be a combination of data availability, slow performance, or potential loss of productivity: Availability Low impact to the business if application is unavailable for more than eight hours No significant financial or measurable productivity impact to employees or customers Alternative methods exist during extended system outage Moderate impact to the business if application is unavailable for more than one hour Potential financial and productivity losses internally Potential customer impact including minimal loss of revenue and customer satisfaction Alternative methods are not adequate during extended outage High impact to the business if application is unavailable for more than five minutes Significant financial and productivity losses internally Significant customer impact including substantial loss of revenue and damage to reputation No alternative methods exist during extended outage Performance Application response time (latency) to user requests is not a concern Real-time processing of records/data is not required Application does not require high availability Application disaster recovery (DR) to secondary site not required Recovery point objective (RPO): 24 hours; recovery time objective (RTO):8 hours Application response time (latency) to user requests is a concern and must be measured and monitored Processing of data must be completed as soon as possible but not necessarily in real time Application must be configured for high availability within single datacenter Data replication and/or snapshot every 8 hours Application DR to secondary site required RPO: 8 hours; RTO: 4 hours Application response time (latency) is critical with strict monitoring, threshold alerting, and remediation Real-time processing of data is required Application must be configured for high availability across multiple datacenters with immediate failover Data replication in real time is required across datacenters
Preliminary decisions	Form an initial decision as to which applications are good candidates for a cloud migration, which apps should remain hosted within internal datacenters, and which workloads should not be migrated or dealt with immediately Consider which applications and workloads are best fits for hosting within an internal private cloud and which might be appropriate for a public cloud This preliminary decision should be based on the assessment steps described earlier compared to the effort (cost, time, ROI) that the migration will require and ultimately the priority to the corporation Consider hiring external application transformation-to-cloud consulting services to handle the most complex or mission-critical workloads. Have them perform detailed assessments and systems redesigns, select cloud providers/models, develop a cloud migration plan, and conduct a pilot. Most organizations have numerous applications and business priorities, so aligning these is crucial to forming a realistic cloud migration plan that meets available budgets and timelines. A common approach is to “continuously reprioritize” the application migration efforts over time to keep up with evolving business priorities.

Application Transformation Best Practices

Based  on lessons learned and experience from across the cloud industry, you should consider the following best practices for your organization’s planning.

Legacy Application Assessment

Assessing each legacy application is an essential part of your cloud planning and transition strategy. Use the following guidance when evaluating each of your existing applications:

• Analyze each application to determine which architectures, multitiered applications, or legacy applications you could move quickly to a cloud (public or private) and which will require more significant transformation.

• Consider data security and risks on an application basis. Are there applications and data that would be at risk if hosted by a cloud provider or possibly in another state, territory, or country?

• Consider breaking up legacy applications into multitiered platforms as part of the transition to cloud. For example, separating application data and databases from middleware and frontend application servers will allow more elasticity, reliability, scalability, and possibly an ability to use the data platform by other applications that are also transited to the cloud. In this analysis, consider which applications you can transform and have share a common platform rather than moving every legacy workload to the cloud as individual applications.

• Remember, you can always leave an application back in the legacy/enterprise datacenter and deal with it another day. Some organizations and businesses need to show a more immediate benefit and adherence to cloud-first standards so don’t necessarily take on the difficult applications first.

• Application assessment checklist:

  List and prioritize applications

  List all legacy applications, their business purpose and use cases, and priority to the business. List applications that might be retired or are seldom used.

  Data classification

  Determine the sensitivity of the data for each application. Assess the risk of data corruption and competitive theft of intellectual property compared to the harm this might cause the corporation, your customers, or shareholders.

  Requirements and compliance

  List your top business priorities and technical goals for each application. Do legacy applications have performance problems or require change regardless of the cloud migration? Note any regulatory or security compliance requirements.

  Assess applications

  Assess each application based on the priority list. Determine as best you can the legacy application’s software architecture, servers/hosts, programming language, database or middleware, network configuration, authentication/user controls, end-user interfaces, and so on.

  Preliminary decision

  Discuss and determine your initial list of applications that are good candidates for cloud migration. Consider application complexity, risks, costs/effort to migration, ROI and priority and criticality to the business.

Application Modernization Techniques

Evaluate each legacy application to determine if, when, and in what priority to migrate the system to the cloud. Based on the assessment, select from the four application modernization strategies:

Replace

Depending on your business priorities, it might not be cost effective to re-create some legacy applications for the cloud, so consider porting these “as is” to a cloud provider or replacing the legacy application entirely with a new public-provider hosted SaaS offering.

Rehost

It might be possible to copy and reinstall less complex applications in a cloud environment with little or no changes. Testing and network address changes are often required.

Refactor

You can redeploy multilevel applications into the cloud using multiple VMs to gain more performance, reliability, or scalability.

Redesign

When legacy applications are critical to the business and you cannot use the other migration techniques, a redesign and reprogramming of the software might be required. Although the advantages of the new modern application in a cloud are numerous, you need to make a financial decision to determine if the effort and cost are worth such investment.

Consider Cloud Architectures for New Applications

You should consider a cloud-based design and operations approach for all new applications and IT systems to achieve scalability, elasticity, and resiliency. Do not forget that the business outcomes and consumers of the applications is also critical. Here are some considerations:

• You should build applications with embedded multithreading, multitenant, highly scalable architectures to span across multiple servers, VMs, datacenters, and cloud providers.

• Though new applications can start on a small infrastructure, having these inherent capabilities will greatly improve the ability to make applications redundant, resilient, and scalable—all part of reduced operational, management, and support costs in the long term.

• Implement new application development practices around continuous development and delivery.

• Consider cloud-native application characteristics in every new application—and as a goal for all applications that are being redesigned as part of your cloud migration.

Operational Considerations

Consider the following recommendations when evaluating your legacy applications and transitioning them to a new cloud operating environment. Remember that simply moving or porting applications to the cloud without modification is certainly possible, but may not provide the best performance, scalability, or long-term supportability.

• Consider establishing unique service levels for mission-critical applications rather than accepting the default cloud-wide service level proposed by the cloud provider.

• Implement federation tools to connect your enterprise user directory and authentication system to any public or managed private clouds to provide SSO capabilities to your users. This also greatly helps maintain security and permissions by having an always up-to-date user directory.

• Use scale-out and scale-up techniques to increase or decrease system capacity and application performance as applications workloads change. You might be able to use these scaling techniques to improve migrated legacy application to achieve better performance even if the app was not rewritten specifically for cloud hosting.

• Measure application performance of your existing enterprise applications before and after you migrate or port them to the cloud. This will make it possible for you to properly set scaling options and avoid the “blame game” with the cloud provider if application performance problems are found.

• As part of testing and during the initial days, weeks, and month of a new application hosted in the cloud, pay careful attention to network bandwidth utilization so that you are not surprised when the end-of-month invoice is calculated. Remember that most public cloud providers charge for network bandwidth (sometimes after a base allowance is exceeded).

Replace Components and Legacy Licensing Agreements

While evaluating your legacy applications and determining whether or when to move them to the cloud; consider renegotiating any software licenses, replace components of the system with COTS software, or use cloud-based platform/PaaS offerings. Here are some considerations:

• As part of the migration to cloud, consider replacing certain components of the system with COTS software of a PaaS offering from the cloud provider.

• Consider changing or renegotiating a legacy software license with a different vendor or in a more pay-as-you-go model—chances are that the legacy software platform and license agreements haven’t kept up with modern licensing practices or pricing models.

• Consider what commercially available SaaS offerings are available in the industry and whether your organization could save money on internal software development, maintenance, and hosting. Many SaaS offerings might even provide more features than your current applications and might be able to assist in data importing/transition.