Table Of ContentDevOps Tools for Java
Developers
Best Practices from Source Code to Production
Containers
With Early Release ebooks, you get books in their earliest form—the
authors’ raw and unedited content as they write—so you can take advantage
of these technologies long before the official release of these titles.
Stephen Chin, Melissa McKay, Ixchel Ruiz, and
Baruch Sadogursky
DevOps Tools for Java Developers
by Stephen Chin, Melissa McKay, Ixchel Ruiz, and Baruch Sadogursky
Copyright © 2022 Stephen Chin, Baruch Sadogursky, Melissa McKay, and
Ixchel Ruiz. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North,
Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales promotional
use. Online editions are also available for most titles (http://oreilly.com). For
more information, contact our corporate/institutional sales department: 800-998-
9938 or [email protected].
Acquisitions Editor: Suzanne McQuade
Development Editor: Corbin Collins
Production Editor: Kate Galloway
Interior Designer: David Futato
Cover Designer: Karen Montgomery
Illustrator: O’Reilly Media
February 2022: First Edition
Revision History for the Early Release
2020-12-18: First Release
2020-01-07: Second Release
2021-06-11: Third Release
2021-09-01: Fourth Release
See http://oreilly.com/catalog/errata.csp?isbn=9781492084020 for release
details.
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. DevOps
Tools for Java Developers, the cover image, and related trade dress are
trademarks of O’Reilly Media, Inc.
The views expressed in this work are those of the authors, and do not represent
the publisher’s views. While the publisher and the authors have used good faith
efforts to ensure that the information and instructions contained in this work are
accurate, the publisher and the authors disclaim all responsibility for errors or
omissions, including without limitation responsibility for damages resulting
from the use of or reliance on this work. Use of the information and instructions
contained in this work is at your own risk. If any code samples or other
technology this work contains or describes is subject to open source licenses or
the intellectual property rights of others, it is your responsibility to ensure that
your use thereof complies with such licenses and/or rights.
978-1-492-08395-5
Chapter 1. DevOps for (or
Possibly Against) Developers
Baruch Sadogursky
A NOTE FOR EARLY RELEASE READERS
With Early Release ebooks, you get books in their earliest form—the
authors’ raw and unedited content as they write—so you can take advantage
of these technologies long before the official release of these titles.
This will be the 1st chapter of the final book. If there is a GitHub repo
associated with the book, it will be made active after final publication.
If you have comments about how we might improve the content and/or
examples in this book, or if you notice missing material within this chapter,
please reach out to the editor at [email protected].
“While you here do snoring lie, Open-eyed conspiracy His time doth take. If
of life you keep a care, Shake off slumber, and beware: Awake, awake!”
—William Shakespeare, The Tempest
Some might ask if the DevOps movement is simply an Ops-inspired plot against
developers? Most (if not all) who’d do so wouldn’t expect a serious response,
not least because they intend the question as tongue-in-cheek teasing. It’s also
because – and regardless if your origins are on the Dev or the Ops side of the
equation – when anyone strikes up a conversation about DevOps, it will take
approximately 60 seconds before someone inquires: “But what DevOps really
is?”
And you’d think, ten years after the coining of the term (a decade within which
industry professionals have spoken, debated, and shouted about it), that we’d all
have arrived at a standard, no-nonsense, commonly-understood definition. But
this simply isn’t the case. In fact, despite an exponentially-increasing corporate
demand for DevOps personnel, it’s highly doubtful that any five DevOps-titled
employees, chosen at random, could tell you precisely what DevOps is. So, don’t
be embarrassed if you still find yourself scratching your head when the subject
comes up. Conceptually, DevOps may not be easy to grok, but it’s not
impossible either.
But regardless of how we discuss the term or what definition(s) we might agree
upon, there’s one thing, above all else that’s critical to bear in mind:
DevOps is an entirely invented concept, and the
inventors came from the Ops side of the
equation
That may be provocative, but it’s provable, too. Let’s start with two exhibits.
Exhibit #1: The Phoenix Project
Co-written by three info-tech professionals, The Phoenix Project, A Novel About
IT, DevOps, and Helping Your Business Win 1 was released in 2013. It’s not a
how-to manual (not in the traditional sense, anyway). It’s a novel that tells the
story of a highly problematic company and its IT manager who is suddenly
assigned the task of implementing a make-or-break corporate initiative that’s
already way over budget and months behind schedule. If you dwell in the realms
of software, the rest of the book’s central characters will be very familiar to you.
For the moment, though, let’s have a look at their professional titles:
Director, IT Service Support
Director, Distributed Technology
Manager, Retail Sales
Lead Systems Administrator
Chief Information Security Officer
Chief Financial Officer
Chief Executive Officer
Notice the connective tissue between them? They’re the protagonists of one the
most important books about DevOps ever written and not one of them is a
developer. Even when developers do figure into the plotline, well…let’s just say
they’re not spoken of in particularly glowing terms. When victory comes, it’s the
hero of the story (together with a supportive board member) who invents
DevOps, pulls the project’s fat out of the fire, turns his company’s fortunes
around, and gets rewarded with a promotion to CIO of the enterprise. And
everyone lives happily – if not ever after, then for at least the two or three years
such successes tend to buy you in this business before it’s time to prove your
worth all over again.
Exhibit #2: The DevOps Handbook
It’s better to read The Phoenix Project before The DevOps Handbook, How to
Create World-Class Agility, Reliability, & Security in Technology Organizations
2 because the former places you within a highly believable, human scenario. It’s
not difficult to immerse yourself in the personality types, the professional
predicaments, and the interpersonal relationships of the characters. The hows
and whys of DevOps unfold as inevitable and rational responses to a set of
circumstances, which could have just as easily led to business collapse. The
stakes, the characters, and the choices they make all seem quite plausible.
Parallels to your own experience may not be too hard to draw.
The DevOps Handbook allows you to explore the component conceptual parts of
DevOps principles and practices in greater depth. As its subtitle suggests, the
book goes a long way toward explaining “How to Create World-Class Agility,
Reliability, and Security in Technology Organizations.” But shouldn’t that be
about development? Whether it should or shouldn’t may be open to debate.
What’s incontrovertible is the fact that the book’s authors are bright, super-
talented professionals who are, arguably, the fathers of DevOps. However,
Exhibit #2 isn’t included here to praise them so much as to take a close look at
their backgrounds.
Let’s start with Gene Kim. He founded the software security and data integrity
firm, Tripwire, for which he served as its Chief Technology Officer for over a
decade. As a researcher, he’s devoted his professional attentions to examining
and understanding the technological transformations that have and are occurring
within large, complex businesses and institutions. He also co-authored The
Phoenix Project and, in 2019, The Unicorn Project (about which, more later).
Everything about his career is steeped in Ops. Even when Unicorn says it’s
“about Developers,” it’s still developers as seen through the eyes of an Ops guy!
As for the other three authors of the Handbook:
Jez Humble has held positions including Site Reliability Engineer
(SRE), CTO, Deputy Director of Delivery Architecture and
Infrastructure Services, and Developer Relations. An Ops guy! Even
where the last of his titles references development, the job isn’t about
that. It’s about relations with developers. It’s about narrowing the divide
between Dev and Ops, about which he has written, taught, and lectured
extensively.
Patrick Debois has served as a CTO, Director of Market Strategy, and
Director of Dev♥Ops Relations (the heart is his addition). He self-
describes himself as a professional who is “bridging the gap between
projects and operations by using Agile techniques in development,
project management, and system administration.” That sure sounds like
an Ops guy.
John Willis, as of this writing, holds the title of VP of DevOps and
Digital Practices. Previously, he’s been a Director of Ecosystem
Development, a VP of Solutions, and notably a VP of Training and
Services at Opscode (now known as Chef). And while John’s career has
been a bit more deeply involved with development, most of his work
has been about Ops, particularly to the degree that he has focused his
attentions on tearing down the walls that had once kept developers and
operations personnel in very distinct and separate camps.
As you can see, all the authors have an Ops background. Coincidence? I think
NOT.
Still not convinced that DevOps is Ops driven? How about we have a look at
who are the leaders trying to sell us on DevOps today.
Google It
In mid-2020, if you entered the term “What is DevOps?” in a Google search just
In mid-2020, if you entered the term “What is DevOps?” in a Google search just
to see what would come up, it’s likely that your first page of results would have
included the following:
Agile Admin, a system administration company
Atlassian, whose products include project and issue tracking, list
making, and team collaboration platforms
AWS, Microsoft Azure, and Rackspace, all of which sell Cloud Ops
infrastructure
Logz.io, which sells log management and analysis services
New Relic, whose specialty is application monitoring
All of these are very Ops-focused. Yes, that first page contained one firm that
was a bit more on the development side and one other which really wasn’t
directly related to the search. The point here is that when you try to look for
DevOps, most of what you’ll find tends to skew towards Ops.
What Does It Do?
DevOps is a thing! It’s in big demand. And with this, there are many who will
want to know, concretely, what DevOps does, what it substantively produces.
Rather than go down that route, let’s look at it structurally, conceptualizing it as
you would the sideways, figure 8-shaped infinity symbol. In this light, we see a
loop of processes that goes from coding to building to testing to release to
deployment to operations to monitoring, and then back again to begin planning
for new features.
