The document discusses how Docker can help development teams in a DevOps process. It describes how Docker allows for consistency across environments from development to production by packaging applications and dependencies into containers. This simplifies deployment and helps achieve continuous delivery goals like accelerating time to market. The document also addresses how Docker requires changes to an organization's culture, processes, and people to fully realize its benefits.

1. © Copyright IBM Corporation 2017
Docker’s Value for Development Teams, in a DevOps Process
The Digital Transformation
In the field of the Digital Trans-
formation, we know that we will
have to face disruptive de-
mands, without necessarily
knowing their nature, because
they break usual practices: new
business models, new custom-
ers, individualized experiences,
drastic optimization of the deliv-
ery time for new innovative services.
The DevOps approach aims to meet three major ob-
jectives:
• Accelerate the delivery of products and optimize
the time to market;
• Balance and share the success of a project;
• Reduce the customer return time.
To achieve these objectives, the production line
must adapt and respond to the requirements of con-
tinuous innovation, with an ever-decreasing time to
market, and the installation of feedback loops, ena-
bling a real-time data usage for the transformation.
The levers of change:
• The customer experience at the heart of con-
cerns;
• The wide Cloud adoption in all its forms (SaaS,
API, micro-services, Hybrid Cloud, etc.);
• A deep transformation of the manufacturing cy-
cle, abandoning the cycles of wide releases to
the benefit of scenarios of manufacture to run
water (micro releases), accelerating the answers
to the demands of the market;
• The global deployment of DevOps principles with
a realignment of the organization based on inte-
grated teams responsible for the whole cycle
(from business to operations).
This leads to a paradigm shift: the specification is no
longer the reference, and the continuous feedback
becomes the “dynamic” guide to the direction to fol-
low.
In this way, DevOps can be seen as a new capability
brought to the Enterprise, enabling a continuous,
customer-centric loop. The interactions between the
client and the production lifecycle contribute to their
continuous transformation. Several expected tangi-
ble results: an acceleration of innovation, a capacity
to reorient the services offering to meet new needs,
not initially identified, and above all to measure con-
tinuously the impact of supply on demand.
Docker for Developers
The developer will be more agile, as he becomes
more independent of the target OS, disregarding
physical deployment, virtualization, or public / pri-
vate cloud considerations. Docker ensures this con-
sistency with its natively integrated container man-
agement features and production tools.
The developer's position is drastically simplified: an
OS, supporting its "IDE", independent of the technol-
ogy used for the target implementation of the devel-
oped solution (application server, database, etc.).
The developer needs to deploy an appropriate con-
tainer from the Docker repository images. The appli-
cation code, associated libraries and configurations
stay unchanged during the transition to qualification
and production teams.
The developer, the tester, the qualifier and the ad-
ministrator maintain the code and the configuration
consistency, from the development environment to
the production environment. In particular, the level of
software libraries and packages remain unchanged
throughout the production chain, because they are
encapsulated in the provision and maintenance of
Docker images.
At documentation level, the developer also applies a
new paradigm: whereas in a traditional mode, the
developer often had to write the entire installation
procedure to the operations, Docker's contribution
drastically simplifies documentation, because it will
provide the target environment actually used and not
TEC-F TechNotes TECF Volume X, Number X, 2016

2. © Copyright IBM Corporation 2017
a set of components to be installed, deployed and
operated. The volume of documentation produced
by the developer is greatly optimized because the
target operational model is supported by the config-
uration of the container (self-documentation). The
operational teams then have only to install the con-
tainer - which they have otherwise standardized -
without having to worry about the installation and the
consistency of all the necessary components.
The developer benefits from standard images pro-
vided by the production team. He no longer has to
worry about whether he respects the company cata-
logue, whether it has the right version of the middle-
ware, or whether backup and purge procedures are
in place.
At the end of the tests, the images thus constructed
are delivered in the qualification, pre-production and
production environments, the containers being iden-
tical except for the values of the environment varia-
bles used.
Docker and the Software Lifecycle
The industrialization of the production chain is a fun-
damental vector of the DevOps transformation, and
is based on four pillars: standardization and automa-
tion, communication and sharing.
These principles are the Docker’s pillars: the lifecy-
cle of the containers being managed in a totally ag-
nostic way to the application, whether to build, pub-
lish or execute them.
This way of working allows development teams to
build containers from basic images (available in a
Docker register), from a Docker file and application
files (binary and configuration). Environment-de-
pendent variables are valued when the container is
instantiated and up & running.
This also enables the implementation of a key prin-
ciple of DevOps: the shift-left approach, which con-
sists in bringing production environments and activi-
ties closer to development activities.
The production can prepare basic images containing
the certified product versions with the appropriate
technical configuration, then make them available to
the development teams through the Docker registry
(enterprise repository). By this way, it becomes very
easy for developers to build and start their container
to test their application in a configuration very close
to production.
At the end of the tests, the built images are delivered
in the required environments (qualification, pre-pro-
duction, etc.), the containers being identical except
for the values of the environment variables used.
The lightness of the images, around the same order
as the applications, and their simplicity of use make
it possible to carry out these tasks in a quasi-trans-
parent way for the developers.

3. © Copyright IBM Corporation 2017
Finally, the adoption of Docker has little impact on
good development practices:
• The configuration management: like the source
code of the applications, the Docker images are
managed in version, and stored in a dedicated
repository (Docker registry), the dependencies
between images being managed through dedi-
cated files (Docker file);
• The externalization of configuration: Containers
are configured primarily through environment
variables;
• The assembly and the delivery: as with the ap-
plications, the steps of build, packaging, deploy-
ment and execution of the containers are per-
fectly dissociated. From a built image, it can be
deployed at multiple locations and run multiple
times (Docker containers are stateless pro-
cesses).
This advanced industrialization is especially valua-
ble for Software-as-a-Service applications (SaaS),
intended to be operated in a cloud environment and
for which it is important to respect basic rules such
as those of the 12 factors.1
Docker and Organizations – People Trans-
formation
The emergence of Docker in the Enterprise is not
done without questions about the Enterprise organi-
zation itself, with direct impacts on the training of
professionals.
One of the most important topics of transformation is
to gradually work in order to allow this new tool to be
taken into account without causing a break with the
teams (those who know Docker, and others).
The minimum required set-up to start this type of
transformation must be done through a small team
that will be the future champions, able to support the
company in its digital transformation. For example, a
DevOps Competence Centre or Excellence Centre
will be able to welcome these champions. If the com-
pany is not in a DevOps transformation, the Docker
Competence Centre will be the facilitator of this
transformation.
1
http://12factor.net/fr/
A Useful technology to Remove Enterprise
Silos
Beyond classical description of transformation that
we will discuss in the next chapter, we can take ad-
vantage of Docker to remove silos between devel-
opment teams, business teams and operational
teams, with a paradigm shift: these are no longer the
design teams that provide installation information to
the production, but the production and the develop-
ment that build the images / containers that will be
implemented from the beginning of development,
based on standards validated by the production.
Ultimately, the direct contribution of the production
teams in the creation and the management of the
reference Docker is a key success factor. Con-
versely, we can see that the companies that put for-
ward Docker by starting with a transformation of the
design teams, were often stopped at the time of go-
ing into production.
A Five-Axis Transformation: "Keep
CALMS and adopt Docker"
Culture:
« Shift left », the production teams are at the origin
of the standards supply and do not wait for the in-
stallation guides of the applications resulting from
the studies, the development environments are
close to the configurations of the production.
Automation:
Docker, as a container technology, is a major
player in the transformation of IT through automa-
tion of deployments and leads to an easy imple-
mentation of continuous deployments.
Lean:
Environments provisioning often remains misun-
derstood by development teams, and represents a
set of tasks for production teams.
The provision of containers in a repository is a
source of simplification of these processes. Docker
emerging makes it possible to work on the pro-
cesses of provision of the environments and thus
simplify the management of the requests of envi-
ronment. It also makes it possible to simplify the
process of putting into production since all that is
done is to deploy.

4. © Copyright IBM Corporation 2017
Measurement:
Docker contribution is important for the time to mar-
ket. We can, through its implementation, contribute
to the culture of the measurement inside the com-
pany, and thus measure the time of making availa-
ble an application or the container to host the ap-
plications.
Sharing:
The implementation of Docker is an opportunity of
sharing within the company. Its implementation can
be done via events like Hackathon and will thus al-
low to communicate strongly on its implementation.
This sharing will take place within the company. It
is of course important to implement the concept of
sharing within the project team, so that the opera-
tional teams in charge of Docker are able to explain
their constraints and take into account those of de-
velopment. This sharing will make it possible to
progressively improve the understanding by each
of the constraints of the others.
In order to make successful the integration of Docker
technology in the IT landscape of the Enterprise, it
must also be accompanied by a joint involvement of
the Development and Production teams in the adop-
tion of a common and adapted governance, encom-
passing the complete life cycle from container de-
sign to shutdown, through to production and regular
updates. The dialogue between Dev and Ops on the
resources used and the non-functional needs of the
application (concept of a service platform "Container
As A Service") would thus be "standardized".
IBM Global Business Services Expertise
GBS supports and helps its customers in the frame-
work of digital transformation. These transfor-
mations become efficient as soon as the manufac-
turing methods of the applications become more ag-
ile and autonomous, in synchronization with the
needs expressed by the trades and the business
teams.
As part of Docker's emergence, IBM Global Busi-
ness Services (GBS) offers a various services port-
folio designed to define Docker's adoption strategy
with the client teams, and most of the time comple-
mented by an evaluation of the company's maturity.
GBS also offers the capability to implement this
transformation by accompanying as closely as pos-
sible the customer teams, from the establishment of
the Docker Centre of Excellence with the Design
teams, to the support of the operational teams in the
deployment of new solutions in synergy with the de-
velopment teams. Ultimately, the key to success re-
mains the ability to support our customers over the
entire DevOps cycle, the pillar and framework for
current and future digital transformations.
Conclusion
Docker is a tool that transforms the way we manu-
facture and run applications.
It provides, by way of comparison, the same type of
transformation that container ships have made in
maritime transport: standardization, and thus auto-
mation and efficiency gained throughout the entire
production chain, from business design to mainte-
nance in operational conditions.
It brings its own set of transformation, with a posi-
tioning value to the production teams who no longer
have to undergo the new rapid deliveries of design
teams, but to become actors of transformation and
masters of what they will exploit, while accompany-
ing their company in its digital transformation.