Deployment
Deployment and QA
Are your software developers and QA testers
working in sync with the delivery cycle?
Are all aspects of your deployment pipeline smoothly
sequenced?
Thorough QA testing validates applications,
interfaces, and infrastructures, as well as the
What Are Deployment and Mobility?
A software system cannot fulfill its purpose until it is
deployed
Deployment
is the process of placement of a
system’s software components on its hardware hosts
Changing the deployment of a component during
runtime is called
migration
or
redeployment
Runtime migration or redeployment of a system is
thus a type of software system’s
mobility
What Are Deployment and Mobility?
During a component’s migration, its runtime state
may need to be preserved and migrated. On the
other hand, during initial deployment, prior to system
start-up components are typically stateless
Temporary downtimes or at least degradation in
What Are Deployment and Mobility?
The time at which a component is migrated during execution
must be chosen very carefully as the component must not be
in the middle of computation or interaction with another
component. Again, these concerns are not applicable during
the system’s initial deployment
The deployment view of a software system’s architecture can
be critical in assessing whether the system will be able to
satisfy its requirements.
For example, placing many large components on a small
Heterogeneity
Deployment and Mobility Challenges
Widely distributed target processors
Physically deploying the software in such settings presents
logistic problems and affect quality especially if the software
has to be distributed and deployed during the system’s
execution
Target processors embedded inside heterogeneous devices
with different operating environments and serve different
purposes
A software component running on one device may not be able
to run in a different environment. Therefore, use of
sophisticated adapter software connectors may be required
Different software components may require different hardware
configurations e.g. screen resolution, CPU speed, I/O
devices, memory
Deployment and Mobility Challenges
System lifespans may stretch over decades, which means
that the redeployment is an unavoidable activity
e.g. a buggy component may be replaced or a more
reliable component is introduced. Engineers might have to
resort the migration to improve system performance
Software system evolution is continuous (requiring
redeployment). So a possible risk is architectural degradation
Mobile code solutions, such as mobile code agents may
mandate that running
components be redeployed. This
requires carefully assessing acceptable system downtimes
and requires techniques to capture and transfer the system’s
dynamic state
Software Deployment and Quality Considerations
A software system is deployed to a set of hosts or sites
Each site provides a set of resources that can have influence on the
quality
Hardware
Network
Peripheral devices
System software
Other application software
Data resources
Resources may be exclusive (IP port number) or sharable (CPU etc.)
Multiple versions of the software components and connectors may exist. A
version is defined to be a time-ordered revision, a platform-specific variant, or a functional variant.
Initial deployment involves the transfer of system components or
Deployment Activities and QA
Planning
Modeling
Analysis
Deployment Planning
It is critical that the deployment of a software system be carefully planned
as several important properties particularly in distributed settings will be affected by the system’s deployment
E.g. latency in delivering a service can be improved if the system is deployed such that the most frequent and voluminous interactions required for that
service occur either locally or over reliable and capacious network links
Important system properties, such as dependability, availability, security,
and fault-tolerance should be ensured and preserved as a system that meets its requirements and preserves these properties is said to deliver a desired level of Quality of Service (QoS).
Heterogenous components connected in an
Emergency Response System (ERS)
Deployment Planning
The problem of determining an effective deployment becomes hard to
control, if multiple QoS dimensions must be considered simultaneously while taking into account some additional constraints
E.g. component X may not be deployed on hosts Y and Z because of the component’s size, the host’s inability to provide the resources necessary for its execution, security concerns. This may be due to several challenges, such as:
A very large number of system parameters (e.g. network bandwidth) may
influence the QoS dimensions of a software system
Many services provided by the system and their corresponding QoS
influence the system users’ satisfaction
Conflicting service qualities—improving one may degrade another
The space of possible software deployment architectures for a given
software system is exponentially large
In general, for a system comprising
C
software components and
Deployment Planning
How do we find and effect a deployment architecture
Scenario with a Single QoS Dimension
ResourceMonitor ModifyResourceMap
Latency
Schedule
Objective is to minimize latency
Conflicting QoS Dimensions
Durability
ResourceMonitor ModifyResourceMap
Latency
Schedule
Objective is to minimize latency and maximize durability
There is no optimal deployment architecture!
Deployment Modeling
An effective deployment model requires the following elements:
Software system elements (components and connectors), their configuration, and their parameters
Hardware systems elements (hosts, network links), their configurations and parameters
Any constraints on the system elements and their parameters
Formal definitions of QoS dimensions of interest
The model can be very large if the architects decide to capture
many parameters and constraints.
Example parameters of software components: CPU and memory requirements for the component’s execution, characteristics of the required execution substrate (e.g. required version of JVM)
Deployment Modeling
For large, long-lived distributed software system, the system’s architect
Deployment Analysis
The development of deployment models requires the modelling of many
system elements, capturing the constraints, and defining the QoS dimensions.
Doing all that will be worthwhile only if the model is used effectively to
make the necessary complex deployment decisions. To that end, the system’s deployment model will have to be analyzed for properties of interest
1. Are both deployments valid?
Deployment Analysis
Is a deployment valid?
Relatively easy to determine. If the system constraints have been specified rigorously, then this becomes a straightforward constraint satisfaction problem
Which deployment is better?
Much more uncertain. It requires the architect to have clearly defined measure of goodness for a system’s deployment
Therefore, QoS dimensions will have to be measured or estimated.
In case multiple QoS dimensions are in use, the architect may likely to have deal with Pareto Optimal situations
Alternatives:
(i) Rank the QoS alternatives e.g. durability vs. latency
Deployment Analysis Strategies
Is there a better deployment than the current one?
Very challenging and requires considering a very large
number of deployment options
Different strategies with different strengths to
address the issue
Most of them offer approximate solutions
Mixed Integer Non-linear Programming (MINLP)
Mixed Integer Linear Programming (MIP)
Heuristic-based strategies
Greedy
Deployment Implementation
Release
Install
Activate
Deactivate
Update
Adapt
Reconfigure
De-install or remove
Deployment Implementation
Release
A system is packaged so that it can be transferred to the consumer sites
System’s description along with software architectural configuration,
dependencies on system level facilities and external components, and requirements specific to individual software elements
All of the necessary modules
A deployment model indicating which components need to be installed on
which hosts
The deployment procedures that must be effected on the consumer sites in
order to extract and deploy the software system from the release package
Install
Extraction of system description, software architecture, and deployment models from the deployment package
Assembling all of the system elements
Ensuring that all the resources needed for the system’s correct operation are available and properly configured
Activate
Once the system is installed, it needs to be activated for use on the target hosts
Deactivate
Deactivation involves disabling any of the system activities that are still on the target hosts
Update
Once a system has been installed and activated on the target hosts, over time it may need to be updated for different reasons
Adapt
Adaptation can result in redeployment i.e. repositioning of its software components across execution processes and hardware hosts.
De-install or remove
Reverse the steps of installation
De-release or retire
Decision to retire the system
