86 I EEE SOFTWARE | PUBLI SHED BY THE I EEE COMPUTER SOCI ETY 074 0 -74 59/ 12 / $ 31.

0 0 2012 I EEE
Editor: Diomidis Spinellis
Athens University of Economics
and Busi ness, dds@aueb.gr
Dont Install Software
by Hand
Diomidis Spinellis
THE SETUP AND confguration of an
IT system is a serious affair. It increas-
ingly affects us developers mainly due
to the proliferation and complexity of
internet-facing systems. Fortunately,
we can control and conquer this com-
plexity by adopting IT-system confgu-
ration management tools.
Veni, Vidi, Vici
Start with the complexity of Internet-
facing systems. In the past, most soft-
ware applications were monolithic con-
traptions that could be installed in a
basic standard environment. For enter-
prise and end-user applications, the en-
vironment would be the operating sys-
tem; for embedded systems, it would be
the underlying hardware. All we devel-
opers had to do was test the softwares
deployment procedures and manage
our softwares confguration with a ver-
sion control system, so that we could
deliver a known baseline to the cus-
tomer for installation.
Internet-facing systems consist of
many parts that we can no longer con-
trol as a monolithic block of software.
Availability and performance require-
ments drive the adoption of application
servers, load-balancing solutions, rela-
tional database management systems,
and disaster recovery setups, while in-
teroperability requirements and complex
standards make us use a multitude of
third-party libraries and online services.
Then consider the ubiquity of
Internet-facing systems. Whereas in
the past, most software happily ran
as an isolated island; today, we ex-
pect all our applications to be acces-
sible through the Web or connected
through the Internet. Systems rang-
ing from our fowerpots watering au-
tomation to an airliners jet engines
regularly phone home to upload their
latest status and receive instructions.
All self-respecting smartphone apps
require Internet connectivity. Compa-
nies, large and small, offer their prod-
ucts and services through the Web
and increasingly use social networks
to market and even design their offer-
ings. The ecologically unchallenged
simplicity of monolithic software had
gone the way of the dodo.
Finally, realize that complexity and
ubiquity feed on the cheaper infrastruc-
ture costs offered by cloud-based solu-
tions and virtualization. Setting up a
datacenter used to be something only
a large company could afford. Now,
armed with a credit card, a startup can
use a cloud provider to set up separate
development, test, and production serv-
ers, a database management system, a
storage subsystem, a computation clus-
ter, monitoring, and disaster recovery
in a week.
Tools, Benefts, Practices
The revolution Ive described affects us
developers, because as we build soft-
ware systems with many complex de-
pendencies, were no longer expected
to provide working code but contribute
toward a working IT system. For this,
we need to cooperate closely with the
team handling IT operations in order to
coordinate and integrate software de-
velopment, technology operations, and
quality assurance.
When the development and op-
erations teams work together in a so-
called DevOps setting, developers dont
toss software deliverables over a wall
to operations for deployment. Instead,
the two coordinate through various ag-
ile development processes like continu-
ous deployment and automated test-
ing. Dev Ops can work wonders when
the organization provides software
as a service (like Google), as a shrink-
wrapped device (like the iPhone), or as
a customized application (like the SAP
ERP). Note, however, that applying
the same principles on shrink-wrapped
software isnt realistic.
A major DevOps enabler is an IT-
system confguration management tool.
Such tools allow us to control and au-
tomate the confguration of all ele-
ments comprising an IT system: hosts,
installed software, users, running ser-
vices, confguration fles, scheduled
tasks, networking, storage, monitor-
ing, and security. (Note that although
commonly termed confguration man-
agement tools, theyre unrelated to the
TOOLS OF THE TRADE
Post your comments online
by visiting the columns blog:
www.spinellis.gr/tools
JULY/AUGUST 2012 | I EEE SOFTWARE 87
TOOLS OF THE TRADE
software confguration management
tools, like Subversion and Git, we use
to manage our softwares revisions.)
Popular tools in this domain include
CFEngine, Puppet, and Chef, but these
are only three among the list of 20 open
source tools listed in a comparison ar-
ticle on Wikipedia (http://en.wikipedia.
or g / wi ki / Compar i s on_of _open_
source_configuration_management_
software). Their main function is to
automate a systems confguration. You
write some rules expressing how an
IT system is to be confgured, and the
tool will set up the system accordingly.
You can use confguration management
tools to set up a new system starting
from a blank slate, to add functionality
to an existing system, and even to re-
pair a system whose confguration is no
longer up to spec. In all cases, through
the specifcation, you end up having at
hand precise executable documenta-
tion of the systems confguration. This,
according to Philip Armours view of
software as executable knowledge,
makes IT-system confguration man-
agement not only an essential tool of
our trade as developers but also an im-
portant craft and vital skill.
Confguration management tools
work by specifying a systems setup
through rules. For instance, we would
specify rules for confguring the systems
basic infrastructure (storage, network-
ing), each running an application or
service, and the roles of the systems us-
ers. Each step of the confguration often
depends on others: to build an applica-
tion, we must install a compiler; to run
a Web-facing service, we might need an
application and a database server. To
handle these dependencies, we typically
express each rule of the confguration to-
gether with its pre- and post conditions.
As an example, the following Puppet
rule expresses that to run the Postfx
mail server as a service, the system must
have installed the corresponding pack-
age and confguration fle. At the end,
the service will be in a running state:
service { postfx:
require => [
Package[postfx],
File[/etc/postfx/main.cf],
],
enable => true,
ensure => running,
}
High-level declarative specifcations,
such as the above, allow us to use fa-
miliar software engineering techniques
for organizing large complex confgu-
rations of diverse hosts. Specifcally, by
breaking a systems confguration into
rules and modules, we can decompose
it into manageable pieces. By organiz-
ing rules into modules and classes we
can hide irrelevant information and or-
ganize our confguration in a hier archy.
For instance, we specify a named appli-
cations confguration through discrete
rules, we group multiple applications
into a running service, and multiple
services into a system. Through pa-
rameterization and class inheritance,
we can reuse common elements and ex-
press variation in the confguration of
our hosts. Building on the preceding
example, we can confgure a running
systems production and testing in-
stances by building on a common base-
line. Finally, the pre- and postcondi-
tions provide the systems specifcation.
By now, Im sure youre convinced
that an IT-systems confguration man-
agement script is essentially code like
all the other code we deal with in our
everyday work. The DevOps commu-
nity has aptly termed this phenomenon
Infrastructure as Code. Given that
a confguration script really contains
code, treat it as such and work on it
to build up your existing coding skills.
Use meaningful identifer names and
helpful comments, and follow style con-
ventions regarding naming and layout.
At the process level, again, there are
familiar best practices. By putting the
confguration scripts under version con-
trol, you can collaborate with others,
work on branches, merge features, tag
stable deployments, and document the
complete history of your systems state.
Want to experiment with an upgrade?
Create a branch, work on it, and when
youre satisfed, merge the changes back
to your master branch. Want to know
when a new service was installed? Look
when it made its frst appearance in the
confguration fles revision history. The
daily build practice also has its parallel
here. Its instructive to regularly build
a system from scratch to ensure that
its confguration is current and that no
manually performed changes have crept
into it. By stipulating that all modifca-
tions to a systems confguration can only
be performed through its confguration
management system, an organization en-
sures that the IT systems it delivers to its
clients are not inscrutable monoliths that
just happen to work but documented
modular engines that work by design.
DIOMIDIS SPINELLIS is a professor in the Depart-
ment of Management Science and Technology at
the Athens University of Economics and Business
and the author of the books Code Reading and Code
Quality: The Open Source Perspective (Addison-
Wesley, 2003, 2006). Contact him at dds@aueb.gr.
Were no longer expected to provide
working code, but contribute toward
a working IT system.