Agile and the cloud: why automating application deployment matters. Executive summary. Applications are the business

Transcription

1 Agile and the cloud: why automating application deployment matters Business white paper Executive summary Agile development methodologies and the cloud computing model have increased the pace of deployment for new applications and change requests alike. This paper, targeted at application owners and their counterparts on the IT operations team, explores how organizations can keep pace with demand by standardizing and automating the deployment process and approaching it in the context of the application lifecycle. Applications are the business It s often difficult to distinguish between a business and the applications it runs. From back-office functions, such as inventory management and human resources, to customer-facing functions, such as retail sales or customer care, companies depend on their applications to do what they do. The fact is, for many companies applications are the business. But no business succeeds by standing still. This means that as requirements evolve and new technologies emerge, businesses face an accelerated pace of change for the applications they manage. This has led many IT organizations to adopt agile development methodologies that emphasize rapid, iterative development, and frequent release cycles. Using such methodologies, companies are able to make hundreds or even thousands of application changes every month. Gartner, in fact, estimates requests for change (RFCs) for midsize enterprises can vary from 300 to 1,000 per month, while for larger global enterprises, RFCs can be in the 2,000 to 70,000 range. 1 The deployment pitfall Faster development is good but what about deployment? As the speed of development cycles accelerates, IT faces increased pressure to deploy more applications, upgrades, and changes in less time. Cloud computing only exacerbates the problem because changes made to one node can be instantly cloned to multiple virtual machines. While this makes change faster and easier, it also increases the likelihood of the kind of errors that lead to compliance risk, poor application performance, or even outages. 1 Gartner, Best Practice: Executing Release Management with Change and Configuration Management, May 2010.

2 Table of contents Executive summary...1 Applications are the business...1 The deployment pitfall...1 What s needed...4 Linking development, QA, and operations teams...4 Focusing on the entire service...5 Modeling applications for each stage of the lifecycle...5 Building flexibility into the deployment process...6 Enabling smooth deployments with HP...6 Next step...7

3 Virtualization and cloud: greater complexity, faster pace of change Cloud computing is becoming a reality. According to Forrester, 50 percent of mid-sized enterprises have plans to implement cloud computing. Thirty percent plan to do so within the next 12 months. 2 Yet IDC reports that 77.7 percent of organizations expect easy/fast deployments and 64.6 percent expect the latest functionality for the applications they use. 3 Unfortunately, cloud computing only makes deployment more difficult because it increases complexity and accelerates the pace of change. To meet this challenge, organizations need to manage deployment in a way that is repeatable and compliant so that handoffs can be executed quickly and without error. This calls for standardization and automation. Only by standardizing and automating application deployment in cloud environments can IT organizations keep pace with the increased demand for new applications with the most up-to-date functionality. It is important to focus on deployment because it is a critical stage that comes up not once, but multiple times, during the course of the application lifecycle. First, the development team deploys an application to the quality assurance (QA) team for testing. This application will most likely be deployed back and forth between QA and development several times before the product is finalized. At the end of the development stage, the application gets deployed again to the production environment. And during the course of the application lifecycle, various deployments will be conducted to apply patches, fixes, upgrades, and other modifications. This makes for a high level of complexity and virtualized cloud environments only add to the challenge. Many organizations, for example, conduct their QA testing in virtualized environments but run their live applications on physical servers. This can make the troubleshooting process more difficult when problems come up after go-live. And even when virtualization is used in production environments, the additional layer of abstraction that virtualization requires often exacerbates the problem of drilling down to the root cause of an issue for quick resolution. To makes matters even more challenging, organizations often depend on manual deployment processes that simply can t keep up with the pace of change. Devel opers run multiple source control systems and use various configuration settings for different components of an application. When the time comes to pass the application on, they rely on migration scripts that they alone develop and maintain. And as application changes move from development to QA to production, a chronic lack of coordination exacerbated by a lack of process discipline and the use of manual tools often leads to costly errors. These errors follow the application into the production environment where the operations team must start from square one to find the root cause of the problem and work out a solution. This is no small problem. According to Gartner, through 2015, 80 percent of mission-critical outages will be caused by people and process issues, and more than 50 percent of those outages are caused by change/configuration/release integration and hands off issues. 4 To keep up with the pace of change and help the business compete more effectively, IT needs to change its approach to application deployment Business Technology Trends For Midsize Enterprises, a commissioned study conducted by Forrester Consulting on behalf of HP, April IDC Enterprise Panel Q308, September Gartner, Best Practice: Executing Release Management with Change and Configuration Management, May

4 What s needed In practical terms, application deployment requires a common set of tools and processes that can be customized for all stages of the lifecycle (development to-test and test-to-production). Such a solution should help improve application quality by making it easier for development, QA, and operations teams to consistently model and deploy applications throughout the lifecycle. It should help reduce time and cost through automation and improve collaboration by allowing teams to work together and share knowledge as much as possible. It should also put in place the controls necessary for each stage to reduce problems in production environments. The ultimate goal, in fact, should be for teams to focus less on the mechanics of application deployment and more on improving application quality. Linking development, QA, and operations teams One of the chief obstacles to effective application deployment management is a lack of coordination among the various groups involved in the application lifecycle. For example, when an application is moved from development to QA for testing, there seldom exists any consistent, repeatable way to capture the steps necessary for deployment. Thus the development team tends to reinvent the wheel time after time. The QA team is forced to master the personal idiosync rasies of multiple developers in order to move the application into QA with any degree of efficiency. Testers need to know which source control system the developer is using, in which directory the application lives, how the files are configured (Windows /Linux/ UNIX ), and any peculiarities of the script used to migrate the application. Before executing the test, QA needs to stand up servers with the correct operating systems and patch levels. Because it would be cost prohibitive to replicate the high redundancy of the production environment, the goal is to best approximate live conditions. This requires QA to work closely with the operations team. When live environments change on a daily basis, this level of collaboration and communication becomes quite a challenge. Far too often, applications that perform in testing environments end up failing in production because of inconsistencies in how the underlying landscape is configured. Once QA completes testing, the application gets promoted to the production environment where the challenges continue. For example, the operations teams must manually edit multiple configuration files on multiple servers to deploy the application to the production environment and get it to run according to expectations. Invariably, security issues arise that are often difficult to address. Even if the right security controls are in place coming out of QA, the operations team may inadvertently make a con figuration change that may cause the application to fail in production. The end result is costly troubleshooting and last minute fixes to successfully deploy even simple changes to the live environment. This increases IT costs and fosters animosity between teams that only reinforces the problems of a siloed IT organization. With a single system for managing the deployment process, on the other hand, IT can help improve the way teams work together to deploy applications and changes. Such a system provides a single place accessible by all teams to track the status of a release across multiple stages and versions. This puts all teams at the same table to support rather than impede the collaboration required to enable successful deployments. 4

5 Understanding the outcome Critically important for the modeling process is the ability to report on outcomes. How long did it take an application to move into production? Which stages take the longest? Do resource constraints for any of the stages adversely impact the process? How many defects made it into production? An application deploy ment management system with integrated analytics can help answer these questions so that teams can fine-tune the deployment process over time. Focusing on the entire service Many organizations today depend on components from a variety of composite applications to support end-to-end business services in a flexible manner. Thus, when deploying an application, teams need to consider the entire service and all the application components that comprise it. For example, the operations team may need to integrate an application with other technology components in the infrastructure, provision new storage and virtual machines to support the application, configure network devices, add a load balancer, and incorporate the application into the monitoring environment to help ensure performance. The operations teams may also need to open up a help desk ticket to track imple mentation activities in the system and coordinate with the change advisory board to obtain the necessary approvals. To state the obvious, appli cation deployment does not happen in a vacuum. This calls for an application deployment solution capable of coordinating the activities required to support the service; not just applications. Deploying with a single system that serves as a single source of truth for all deployment-related information goes a long way toward this end. Organizations need workflow that can reinforce the process across hand offs, automating tasks wherever possible. This can help simplify provisioning tasks and change requests. For example, teams can configure processes ahead of time to clone virtual servers so that they automatically inherit management policies. In the end, this helps IT manage deployments in a way that keeps up with the pace of change while enabling the highest end-to-end service quality. Modeling applications for each stage of the lifecycle To help ensure deployment consistency and reduce the potential for errors downstream, applications should be defined in relationship to the environment in which they will be deployed from the earliest phases of development. This requires application modeling capabilities. To model an application, teams need to work together to define the standard components on which the application is built. They also need to define any application specific content, configuration details, and the processes necessary for deployment. All of this information needs to reside in a single place accessible to all teams involved in the deployment. Equally important is the modeling of the target environment. QA and operations teams, for example, will want to know which servers in what configuration are available for a given deployment. The target model provides a way to capture this information in a manner that is independent of the application itself. For example, target environment information might tell the QA team which Web proxy to use to access an application in development or on which port a database runs. While it is important to model the application itself on real-world production environments as much as possible, the reality is that necessary differences exist in the developing and testing environments. The ability to make allowances for these differences can help facilitate the deployment process. 5

6 After modeling the application and the target environment, teams need to join the two models to facilitate deployment. Here, the deployment team maps application components to the servers used, conducts all necessary sequencing activities, and accounts for any late-binding, deployment-specific variables such as actual server names and addresses. The goal here is to use the models to reinforce deployment consistency reducing the potential for errors by re-using deployment details over and over again in a uniform manner for a single project. Building flexibility into the deployment process While standardized processes are important for deployment consistency, process rigidity can stand in the way of the drive for more rapid development cycles. In a fast-moving environment, teams need the flexibility to work on multiple application versions, in multiple stages, across multiple environments. This enables them to build, deploy, and test as many times as needed throughout the application lifecycle. To support this requirement, deployment teams need robust tracking and automatic synchronization of changes so that the right application with the correct fixes gets released into production in the least amount of time on a consistent basis. Here again, a single, centralized deployment system helps facilitate the required flexibility. For example, with access to application and target environment models, the operations team can reserve all necessary resources for a planned deployment even while the application is still in development or testing. Traditional deployment scenarios would require the operations team to wait until QA stages the application for imminent deployment. With a centralized system, however, the operations team can work ahead of the curve to prepare the production environment based on easily accessible data posted for the use of all teams. This helps speed deployments, allowing IT to keep pace with demand. Rollback capabilities can help reduce such risks. With manual, disconnected deployment processes, rolling back a deployment to the last known good configuration requires an excessive amount of guesswork and attention to detail that often leads to failure. But with a centralized system that tracks all versions throughout the application lifecycle, teams have a clear record of earlier versions to which they can revert if the need arises. This provides deployment security and helps prevent the kind of costly mistakes that keep IT focused on putting out fires rather than delivering value to the business. Enabling smooth deployments with HP To speed deployment while lowering the risk of errors, organizations need to approach deployment according to the larger application lifecycle. Here deployment is seen as an ongoing core activity required to develop, test, deploy, and maintain an application in a constantly evolving IT environment dominated by virtualization technology and rapid-fire agile development methodologies. Deployment processes also need to be variable. After all, rolling out a new customer-facing application is dramatically different from implementing a minor change request. Thus, any deployment system should support modifiable processes so that the effort involved in deployment activities is commensurate to the risk of the project as a whole. 6

7 According to Gartner, through 2015, 80 percent of mission-critical outages will be caused by people and process issues, and more than 50 percent of those outages are caused by change/ configuration/release integration and hands-off issues. 5 The HP Application Deployment Manager is designed to help your organization meet these requirements. HP Application Deployment Manager provides tools and functionality that enable your IT team to: Collaborate more effectively across deployment teams with centralized access to a common knowledge repo sitory where subject-matter experts can define stan dard configuration settings, operating system versions, patch levels, dependencies, and installation details Manage applications in the context of business services with functionality that takes account of composite applications and virtualized environments to automatically configure new deployments in the proper context Automate deployment processes with tools for modeling application and target environments, managing workflow to reduce errors and enforce policies, and rolling back changes in case of problems Maintain flexibility with options that allow teams to modify the deployment process to correspond to project risk (for example, full deployments versus small technical changes) In addition, HP and HP preferred partners offer targeted services to help your organization get up and run quickly with HP Application Deployment Manager in a way that decreases risk by leveraging the expertise of our highly skilled consultants. In the end, your organization will be able to fully leverage the HP Application Deployment Manager solution to keep up with the ever-mounting demand for more applications and changes in less time. Next step To learn more about how HP Software and Solutions can help you manage the application deployment process more effectively, visit 5 Gartner, Best Practice: Executing Release Management with Change and Configuration Management, May

8 The benefits of application deployment with HP Application Deployment Manager According to research conducted by IDC, 6 organizations using HP Application Deployment Manager were able to achieve tangible benefits across a wide range of use cases. The table below provides a summary. Use case Benefits with HP Application Deployment Manager Decreased failure rate Went from 20% to 30% failure rate to 0.15% failure rate for application release processes under automation Increased ability to make changes With automation, deployment went up to 5 application updates per week to thousands of servers Greater confidence with application rollbacks Time saving Deployment consistency Gained ability to quickly rollback changes and lower the damage to customers Saved 3 6 man months of time on first automation project, and expected improvement in those numbers with experience Prior to automation, applications would be deployed slightly differently across each server. With automation there is consistency and control. 6 Source IDC Spotlight: 28% IT productivity savings with Server Automation, IDC ExpertROI SPOTLIGHT, The Business Value of HP Business Service Automation (BSA) Solutions, Sponsored by Hewlett-Packard, June Get connected Get the insider view on tech trends, alerts, and HP solutions for better business outcomes Share with colleagues Copyright 2010 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Windows is a trademark of the Microsoft group of companies. UNIX is a registered trademark of The Open Group. 4AA3-0967ENW, Created September 2010; Updated September 2010, Rev. 1