Application Release Automation and Infrastructure Automation · Deployment Automation vs. Puppet for ... Application Release Automation and Infrastructure Automation ... Application

Application Release Automation and Infrastructure Automation by Julian Fish, Director of Product Management, Serena Software (now part of Micro Focus)

White Paper

Table of Contents page

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Why Automate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

A Brief History of Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Progress Isn’t Always Difficult . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

What Is Infrastructure Automation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

What Is Application Release Automation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Common Traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Deployment Automation vs. Puppet for Infrastructure Automation . . . . . . . . . . . . . . . 8

Deployment Automation vs. Puppet for Application Release Automation . . . . . . . . 10

The Value of Pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Model Driven Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

A Small Matter of Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

The Best of Both Worlds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1www.microfocus.com

Executive Summary

Organizations beginning their DevOps transformation journey or those that are simply looking to automate and setup and configuration of their environments are often confused as to the value of Application Release Automation as opposed to Infrastructure Automation tools. A plethora of tools are available, with many performing seemingly overlapping roles. This paper discusses two of the market leaders: Micro Focus Deployment Automation1 for Application Release Automation and Puppet2 for Infrastructure Automation. The value propositions of each, main focus area of each tool and the benefits that each can provide as part of an integrated DevOps tool chain are also discussed.

Why Automate

Many organizations are looking to simplify and reduce the complexity of application deploy-ments while maintaining operational stability, adhering to SLAs, and ensuring application responsiveness are met. Increased business responsiveness and “moving fast without breaking things” is critical to enterprise survival. In order to support such competing goals, the need to automate the ‘full application stack’ has become more and more important. Unfortunately, the definition of ‘full stack’ tends to vary depending upon the area of the organization describing it.

Operations often see the ‘full stack’ as the infrastructure required to host applications and the supporting systems, with the application seen as a small component of the stack, whereas Development organizations tend to see the ‘full stack’ as all tiers of the application working successfully in conjunction with one another and have much less interest in the underlying infrastructure. The reality, especially from a DevOps perspective, is that all areas are required to work in full collaboration to ensure what has rapidly become the critical assets of an organization are supported. Over the past decade, the function of IT is no longer seen as a key business differentiator; simply keeping business systems running is no longer seen as a value add. It’s seen as a mandatory requirement. To businesses, the application is king, and it is application change that drives corporate differentiation and business value. Implementing as many business changes as possible, in as short a time as possible, whilst maintaining high levels of quality, stability and feature function is critical. Manual processes to deploy applications simply don’t support these key requirements. Automation is mandatory, not optional.

This paper discusses two of the market leaders: Micro Focus Deployment Automation for Application Release Automation and Puppet for Infrastructure Automation . The value propositions of each, main focus area of each tool, and the benefits that each can provide as part of an integrated DevOps tool chain are also discussed .

__________

1 Deployment Automation (SDA) is a market leading tool used for application automation that can both integrate with and initiate infrastructure provisioning tools. www.serena.com/sda

2 Puppet is a market leading tool used for infrastructure automation that can, with a degree of investment and coding be used for application release automation. https://puppetlabs.com/

2

White PaperApplication Release Automation and Infrastructure Automation

A Brief History of Automation

The last 15 years has seen an increased rate of change in the Software industry, which, as Glenn O’Donnell of Forrester has commented, is leading to the “Industrialization of IT”3. Initially driven by a reduction of IT spend post-Y2K and the dotcom bust, then extended by the mass adoption of the Internet and an ‘always on’ approach to business, these changes have had a huge impact upon the world of both Corporate and Enterprise IT. Companies that 15 years ago had no call for a corporate website, let alone the notion of ‘always on’ customer accessibility 24 hours a day, have had to adapt to a completely new way of working. Reduction of IT spend has led organizations to do more with less—reducing headcount and increasing the demands on corporate IT. The adoption of the ‘internet everywhere’ requires a level of operational efficiency, system uptime and responsiveness never before mandated. The level of complexity inherent in many enterprise applications means that efficient and repeatable delivery of business change is no longer a simple task. The risks of exposing applications to third parties who may be looking for weaknesses or backdoor access to business critical back office systems means that simply increasing the rate of delivery is not sufficient—applications must be deployed rapidly whilst maintaining a high level of quality, security and with the next big feature included. Relying upon manual processes to ensure reliability, traceability and repeatability is no longer feasible. To continue delivering applications in a manual manner runs the risk of leaving an organization many steps behind the competition.

Progress Isn’t Always Difficult

Development teams have traditionally been accepting of change—for example the transition from ‘legacy’ programming languages like COBOL and C to newer languages such as Java and .Net. Development teams have modified both their applications and processes to support change, even when initial benefits may be outweighed by transition costs. The transition from Waterfall project management disciplines to Agile disciplines, the adoption of LEAN practices and the prevalence of open source software adoption are all prime example of the willingness of Development teams to support change. The ability of these Development organizations to become more efficient and to deliver business capabilities more effectively and rapidly has increased the pressure on Operations teams to effectively and quickly deliver these new features.

Companies that 15 years ago had no call for a corporate website, let alone the notion of ‘always on’ customer accessibility 24 hours a day, have had to adapt to a completely new way of working .

__________

3 O’Donnell, Glenn. 2010, IT Is Industrializing—What Does That Mean To Me?, Glenn O’Donnell’s Blog, viewed February 24, 2015, http://blogs.forrester.com/ glenn_odonnell/10-04-21- it_industrializing_%E2%80 %93_what_does_mean_me

3www.microfocus.com

Operational teams have historically taken a ‘zero risk’ approach to the management of production or operational environments, as has generally been mandated by their business. Businesses require system stability and uptime, making this approach completely under-standable. The responsibility to keep a trading system operating successfully, an ordering system functioning correctly or a banking system providing accurate information to consumers is not a responsibility to be taken lightly. The investment in and adoption of ITIL-based practices, processes and procedures by many organizations show the serious regard that operational systems are held in. Ensuring that everyone is in agreement is critical to allow common practices and procedures to be followed.

As businesses strive to provide the best possible customer experience, compelling new features or gain competitive advantage, the delivery of more and more application change as quickly and efficiently as possible has come sharply into focus. The question becomes how to enable these two apparently conflicting requirements? Can the increased rate of application delivery required by Development and the levels of stability, traceability, control and rigor required of Operations be delivered, whilst maintaining any regulatory, industry or corporate compliance requirements?

________________________________________________________________

As businesses strive to provide the best possible customer experience, compelling new features or gain competitive advantage, the delivery of more and more application change as quickly and efficiently as possible has come sharply into focus .

Fig. 1

Development vs . Operations Challenges

________________________________________________________________

4

White PaperApplication Release Automation and Infrastructure Automation

The automation of application deployments, application installation and system configurations ensures that consistency is achieved across the environment; that deploy­ments can be repeated as required; and full audits can be put in place and tracked to see exactly which version of which artifacts have been deployed in which environment at any given point in time .

Technological advancements mean that it is now much easier to automate the delivery of Applications and all supporting infrastructure. The DevOps movement that strives to address the people, processes and communication challenges prevalent in two disparate organizational units (Development and Operations) can certainly benefit from the use of Automation. In the same way that organizations have found that recompiling code in different environments leads to different build outputs and numerous issues in subsequent environments, there is a growing realization that the lack of consistency of deployment across different environments will also lead to major issues and challenges. The automation of application deployments, application installation and system configurations ensures that consistency is achieved across the environ-ment; that deployments can be repeated as required; and full audits can be put in place and tracked to see exactly which version of which artifacts have been deployed in which environ-ment at any given point in time. Automation generally also leads to a reduction in time spent performing deployments, increased confidence in delivery quality (machines don’t make mistakes or forget to execute commands) and the ability to prove exactly what was planned actually occurred—ensuring that important audit compliance deliverables are met.

Deploying an application is generally not as simple as just moving files from one location to another. It may involve the creation or extension of infrastructure to support new features, increased storage capacity or implement new capabilities of the application, requiring complex installation routines. Infrastructure and Application automation are subtly different capabilities that require additional definition.

What Is Infrastructure Automation?

Infrastructure automation is creation and management of environments, up to and including installing operating systems, installing and configuring servers on physical, virtual or cloud instances, to configuring how the instances and software communicate with one another. It’s also commonly referred to as provisioning, scripted infrastructure, infrastructure as code or confusingly configuration management (a term that has many different meanings depending on the part of the lifecycle being discussed). The principle is simple: define a system configuration via script or a set of scripts to allow users to create or recreate environments as simply and quickly as possible, while ensuring fewer errors and rapid turn-around times.

________________________________________________________________

5www.microfocus.com

What Is Application Release Automation?

Application Release Automation is the scripted management of applications within environ-ments, including installation, application configuration and application deployment onto physical, virtual or cloud environments. These target environments may in fact have been created through the use of Infrastructure Automation. Application Release Automation includes configuring how applications are installed, deployed and how different tiers of an application interact with one another at runtime. It’s also commonly referred to as application automation (AA), deployment automation, Agile Deployment or even Release Management. The term

Application Release Automation includes configuring how applications are installed, deployed and how different tiers of an application interact with one another at runtime .

Fig. 2

Infrastructure Automation

________________________________________________________________

6

White PaperApplication Release Automation and Infrastructure Automation

‘script’ is commonly used to cover package, declarative, custom and process centric tools, with or without UI definition capabilities. The principle is simple: define a model via script or a set of scripts to allow users to create or deploy applications as simply and quickly as possible while ensuring fewer errors and rapid turn-around times.

________________________________________________________________

Application Release Automation is also commonly referred to as application automation (AA), deployment automation, Agile Deployment or even Release Management .

Fig. 3

Application Release Automation

________________________________________________________________

7www.microfocus.com

Application Automation and Infrastructure Automation can be seen as compli­mentary in the broader world of DevOps and in the world of Continuous Delivery or Continuous Deployment .

__________

4 Continuous Delivery (CD) is about keeping your application in a state where it is always able to deploy into production. Martin Fowler, viewed February 24, 2015, http://martinfowler.com/delivery.html

5 Continuous Deployment is actually deploying every change into production, every day or more frequently. Martin Fowler, viewed February 24, 2015, http://martinfowler.com/delivery.html

Common Traits

Both Application Automation and Infrastructure Automation can be seen as complimentary in the broader world of DevOps (the processes and practices of aligning Development and Operations teams) and in the world of Continuous Delivery4 or Continuous Deployment5. The commonality of aims between these two tool types, namely increased responsiveness, reduced errors, improved audit, accountability and traceability and the intention to ‘script everything’ leads to the two tool sets commonly being seen as either direct competitors or as a potential replacement for the other. The reality is that both tool sets have a well-defined objective and ‘sweet spot’. Whilst it is certainly possible to use one to perform certain functions of the other, it is preferable to pick the right tool for the job.

________________________________________________________________

Application Release Automation Infrastructure Automation

Process Centric Deployments ● ● Application Deployment ● ● Application Installation ● ● Pipeline Support ● ● Environment Management ● ● Infrastructure Provisioning ● ● Infrastructure Modification ● ● Bare Metal Provisioning ● ● Full Stack Automation (Tool-Chain Based) ● ●

Fig. 4

Application Release Automation vs Infrastructure Automation

________________________________________________________________

8

White PaperApplication Release Automation and Infrastructure Automation

Deployment Automation vs. Puppet for Infrastructure Automation

Deployment Automation can be used to perform a subset of Infrastructure Automation tasks via scripting or existing plugins to third party tools; in certain circumstances, this may be all that’s required by way of infrastructure automation. Examples of such activities may include Virtual or Cloud-based provisioning, where an existing predefined and configured image is used to provide additional Virtual or Cloud capacity. The practice of creating infrastructure based upon a predefined and configured image is commonly referred to as ‘Gold Image’ provisioning as there is little additional configuration required once the new infrastructure has been created. This model of infrastructure provisioning is suitable when organizations wish either to scale their existing application infrastructure horizontally or vertically to provide additional capacity or capability. In this instance, Virtual infrastructure provisioning would be performed using VMware ESX, ESXi or Workstation plugins, with new virtual images provisioned. Post instantiation, the new images will update agent property settings, allowing the new agents to automatically register into the correct Agent pool groups on the Deployment Automation server. Cloud infrastructure provisioning would be performed using Amazon, Azure or vCloud plugins, with new cloud images provisioned. Post instantiation, the new images will update agent property settings, allowing the new agents to automatically register into the correct Agent pool groups on the Deployment Automation server.

Infrastructure automation at the ‘bare mental’ or physical machine level requires much more in-depth capabilities, and as an application automation tool, this is not the target for Deployment Automation. In these circumstances, the use of a third-party tool such as Puppet is recommended, with the process of infrastructure provisioning being controlled by the Deployment automation tool. Using an infrastructure provisioning tool such as Puppet requires a specialist skillset. Although a number of predefined manifests and modules exist in the development community, the skills required to create, modify and update such manifests are commonly found in individuals who have an operations background. Knowing which Kernel, Memory, System and Configuration parameters to set at instantiation time, how to deploy an operating system correctly with security and networking parameters and under-standing the disk I/O requirements of attached data storage sets when instantiating new infrastructure in the context of a much larger data center is critical to provide suitable base infrastructure to deploy applications against.

Using an infrastructure provisioning tool such as Puppet requires a specialist skillset . Although a number of predefined manifests and modules exist in the development community, the skills required to create, modify and update such manifests are commonly found in individuals who have an operations background .

9www.microfocus.com

Recipes, Cookbooks and other definition scripts are generally written in a Domain Specific Language, with some scripting knowledge required to setup and configure infrastructure deployments. The deployment of applications onto this predefined or custom created ‘stack’ is the logical extension of infrastructure provisioning—you are deploying all that nice new hardware for a reason. Being able to define the deployment process for infrastructure provi-sioning, calling the correct manifests and modules to create the new physical infrastructure, to deploy new virtual infrastructure, to deploy applications and to ensure all applications across the newly created stack are configured correctly are the end goals. Through the use of plugins for provisioning tools such as Puppet, organizations get the benefits of a best-of-breed tool to create the infrastructure, the process capabilities for the automation tool plus the ability to seamlessly deploy applications into the newly created environment using an easy to use, graphically defined process with complete audit and traceability.

________________________________________________________________

Through the use of plugins for provisioning tools such as Puppet, organizations get the benefits of a best­of­breed tool to create the infrastructure, the process capabilities for the automation tool plus the ability to seamlessly deploy applications into the newly created environment using an easy to use, graphically defined process with complete audit and traceability .

Fig. 5

Full Stack Provisioning

________________________________________________________________

10

White PaperApplication Release Automation and Infrastructure Automation

Deployment Automation vs. Puppet for Application Release Automation

As we saw when discussing Infrastructure Automation, the conjoined areas of automation provide the required capabilities to implement DevOps principles within an organization. However, as we saw with infrastructure automation, there are some key and specific areas that you would wish to target with application automation. If the deployment of your application is as simple as running a batch or shell script to copy files to the correct location, infrastructure automation tools may provide you with the capability (if not the traceability) that’s required. Such simple application deployments are unfortunately incredibly rare in the world of enterprise software. Generally, the simple copy a file and run a script approach is not sufficient to deploy an n-tier application, which may contain dependencies between different application component areas, have different Operating Systems used in different environments and require manual steps be performed to supplement scripts. Where multiple components of an application or event multiple applications must be deployed in series or in parallel, the capabilities of Infrastructure automation tools become stretched, and you eventually end up using incredibly complicated chained scripts, which become both difficult to manage and to understand. Even performing simple application deployments to commonly used application servers, such as Tomcat, require detailed and complex scripts; a simple war file deployment to Tomcat using Puppet, for example, requires over 800 lines of code. Keeping these scripts current or modifying such scripts to fit organizational requirements can become a full-time responsibility for a well-paid and highly skilled resource. In comparison, the simple deployment of a war file to a Tomcat application server using Deployment Automation is a single process step, graphically displayed to the end user. Any customizations or configuration changes between environments are passed as parameters to this step, ensuring full repeata bility of the process all the way from Development environments to Production.

The Value of Pipelines

One of the core principles of any kind of automation is that the end state is known and can be reached in a repeatable manner. Consistency across environments is key to avoiding errors during deployments. It’s not uncommon for Release Managers and Quality Engineers and Operations Engineers to struggle to deploy applications into their chosen environments,

Generally the simple copy a file and run a script approach is not sufficient to deploy an n­tier appli cation, which may contain depen­dencies between different application component areas, have different Operating Systems used in different environments and require manual steps be performed to supplement scripts .

11www.microfocus.com

only to encounter derision from their Engineering counterparts who simply state “Well it worked in my Environment.” Without a consistent goal or target end state, automation becomes a trivial exercise and fails to provide any viable value. Naturally, the target end state for any DevOps or Continuous Delivery initiative is to deliver applications to a production environment, at any point in time, in a simple, repeatable, audit compliant and automated manner. However, in the same way that planning activities upfront will ensure successful and timely completion, knowing the mechanisms, stages and levels of validation required to deliver our application to production is critical. Simply expecting code produced in development environments to work seamlessly in a production environment that has different configurations, runtime parameters, infrastructure setup and data sets becomes less and less realistic, especially as the complexity of application and cross application dependencies are encountered during deployments. For many enterprise customers, simply defining the dependencies between applications and knowing the impact of change of one application unto another is a highly complex and time consuming activity. Just ensuring successful deployment at the right time, into the correct environment is the end goal of many application delivery organizations.

To help ensure that this goal is achieved, the notion of a deployment pipeline or path to production is key. Deployment pipelines have existed in many guises over the years, from the traditional SDLC where development is followed by test followed by production, to visually defined and dynamic paths to production that may vary depending upon the application and potential risk of deploying said application.

One of the many questions customers ask when defining a pipeline or pipelines is “Do all of my applications require the same pipeline”? A simple answer is to look at the applications in question and define the compliance and audit requirements of each. Does an intranet site require the same level of rigor and validation as a customer facing online banking or trading system? To most organizations, the answer is a resounding ‘no,’ having rigour and control in place for heavily used, high visibility consumer facing applications is necessary; applying the same approaches to internal test applications, intranet sites or low priority applications is overkill. Applying different pipelines to different applications is critical to successful automation adoption.

Simply expecting code produced in development environments to work seamlessly in a production environment that has different configurations, runtime parameters, infrastructure setup and data sets becomes less and less realistic, especially as the complexity of application and cross application dependencies are encountered during deployments .

12

White PaperApplication Release Automation and Infrastructure Automation

Pipelines are the critical component when defining repeatability of deployments to multiple environments, proving compliance and adhering to standards. Deploying the same applica-tions, using the same processes to multiple environments can be easily achieved by defining and enforcing a pipeline. Pipelines also allow discrepancies between environments to be identified.

Deployment Automation provides a fully featured graphical pipeline capability, with the option to mandate pipeline use and even automatically promote applications from one environment to another (assuming the previous deployment completed successfully). Puppet has no concept of pipelines. Although through the use of chained scripts, Automation jobs can be linked. The advice in this scenario would be to graphically drive the Puppet jobs through a graphical process in SDA and follow the graphical process that is defined for the deployment pipeline.

Model Driven Deployments

Understanding how to actually deploy target applications is a key factor in the adoption of any automation tool. It’s impossible to automate application deployments if there is a lack of knowledge of the steps needed to perform such a deployment. With model-based deployments, such as those used by Deployment Automation, it is possible for end users to graphically define the entire application deployment process, including application dependencies and system-to-system interactions. The ability to model both deployment processes and deployment pipelines in a graphical manner provides a significant advantage over declarative type applications, where process knowledge and understanding comes from an implicit understanding of the code used to perform any deployments. Consider a simple user case, for example deploying an application to an application server such as Tomcat. With a model-based system the definition of the activity to be performed is graphically drawn on a canvas, indicating the step and process to be performed. In a declarative system, this same activity will require the modification of code, in this case an artifact containing close to 1,000 lines of code must be changed. Naturally, it is much easier for new users to understand a graphical process definition than to have to under-stand a new programming language with many hundreds of lines of code. Future modifications are also simplified as any customizations can be easily viewed in the deployment process as opposed to having to review complex code bases.

It’s impossible to automate application deployments if there is a lack of knowledge of the steps needed to perform such a deployment .

13www.microfocus.com

A Small Matter of Extensibility

Enterprises are complex environments. It’s never a simple case of being able to run the latest and greatest versions of software on the latest and greatest infrastructure. In the majority of long-tenured enterprise organizations, legacy applications must coexist with new applications, various versions of programming languages, runtime components and abstraction layers. For many organizations, migrating to newer application versions also involves migrating infra-structure, end user desktops and updating existing data interfaces. The variation in versions of applications that need to be updated at deployment time means that having a complex and difficult to update interface between your automation technology and the third-party system puts you at a big disadvantage. Deployment Automation provides a large number of out-of-the-box integrations to many common third party systems, from database to middleware to application servers and even to testing tools. The extensible plugin model used by the applica-tion enables the rapid creation of new plugins to third party systems, increasing the ability of the Automation platform to extend to all areas of the enterprise. Puppet manifests are a great way to define your infrastructure as code and to drive the creation, update and destruction of infrastructure as part of a predefined ‘full stack’ provisioning or deployment process.

The Best of Both Worlds

As has been discussed, ‘full stack’ provisioning can involve the entire application and infra-structure stack. Application deployments, infrastructure provisioning and the processes to keep all of the above in sync are key components for organizations looking to embrace Continuous Delivery benefits and transition technology as well as people and process towards DevOps. Infrastructure provisioning tools perform a hugely valuable role in ensuring base infrastructure is in place for subsequent Application Deployments. The use of consistent processes for both Infrastructure and Application deployments ensures that compliance, audit, repeatability and insight into deployments are gained while also reducing time to deployment and removing the risks of manual deployments. Driving Infrastructure Automation via Deployment Automation is the first step towards organizational transformation, process simplification and quicker time to market. Moving Fast, without Breaking Things.

Application deployments, infrastructure provisioning and the processes to keep all of the above in sync are key components for organizations looking to embrace Continuous Delivery benefits and transition technology as well as people and process towards DevOps .

162­000085­002 | S | 04/17 | © 2017 Micro Focus . All rights reserved . Micro Focus and the Micro Focus logo, among others, are trademarks or registered trademarks of Micro Focus or its subsidiaries or affiliated companies in the United Kingdom, United States and other countries . All other marks are the property of their respective owners .

www.microfocus.com

Micro FocusUK HeadquartersUnited Kingdom+44 (0) 1635 565200

U.S. HeadquartersRockville, Maryland301 838 5000877 772 4450

Additional contact information and office locations: www.microfocus.com