White Paper
Application Release Automation
and Infrastructure Automation
by Julian Fish, Director of Product Management,
Serena Software (now part of Micro Focus)
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
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.
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 deployments 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
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/
are required to work in full collaboration to ensure what has rapidly become the critical assets
www.microfocus.com
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.
1
White Paper
Application 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
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.
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.
2
__________
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-21it_industrializing_%E2%80
%93_what_does_mean_me
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.
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?
________________________________________________________________
Fig. 1
Development vs. Operations Challenges
________________________________________________________________
www.microfocus.com
3
White Paper
Application Release Automation and Infrastructure Automation
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 environment; 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 environment 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.
________________________________________________________________
4
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.
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
________________________________________________________________
What Is Application Release Automation?
Application Release Automation is the scripted management of applications within environments, 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
www.microfocus.com
5
White Paper
Application 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.
________________________________________________________________
Fig. 3
Application Release Automation
________________________________________________________________
6
Application Release
­Automation is also
­commonly referred to as
application a­ utomation (AA),
deployment automation,
Agile Deployment or even
Release Management.
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.
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
Process Centric Deployments
Application Deployment
Application Installation
__________
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
www.microfocus.com
Pipeline Support
Environment Management
Infrastructure Provisioning
Infrastructure Modification
Bare Metal Provisioning
Full Stack Automation (Tool-Chain Based)
●
●
●
●
●
●
●
●
●
Infrastructure Automation
●
●
●
●
●
●
●
●
●
Fig. 4
Application Release Automation vs Infrastructure Automation
________________________________________________________________
7
White Paper
Application 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 understanding 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.
8
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.
Through the use of plugins
for provisioning tools such
as Puppet, organizations
get the benefits of a bestof-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.
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 provisioning, 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.
________________________________________________________________
Fig. 5
Full Stack Provisioning
________________________________________________________________
www.microfocus.com
9
White Paper
Application 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,
10
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.
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.
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.
www.microfocus.com
11
White Paper
Application 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 applications, 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-tosystem 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 understand 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.
12
It’s impossible to automate
application deployments if
there is a lack of knowledge
of the steps needed to
perform such a deployment.
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.
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 infrastructure, 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-ofthe-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 application 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.
www.microfocus.com
13
Micro Focus
UK Headquarters
United Kingdom
+44 (0) 1635 565200
U.S. Headquarters
Rockville, Maryland
301 838 5000
877 772 4450
Additional contact information and office locations:
www.microfocus.com
www.microfocus.com
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.