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.
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.
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.
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.
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:
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:
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
Category | ASSESSMENT ITEMS/DATA GATHERING | ||||||||
---|---|---|---|---|---|---|---|---|---|
List and prioritize applications |
|
||||||||
Data classification |
|
||||||||
Requirements and compliance |
|
||||||||
Application architecture |
|
||||||||
Application modernization and migration |
|
||||||||
Application management |
|
||||||||
Operations and governance |
|
||||||||
Mission criticality |
|
||||||||
Preliminary decisions |
|
Based on lessons learned and experience from across the cloud industry, you should consider the following best practices for your organization’s planning.
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:
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:
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.
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).
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.
3.145.47.230