Matthew Sacks - Pro Website Development and Operations: Streamlining DevOps for large-scale websites

Pro Website Development and Operations

Streamlining DevOps for Large-Scale Websites

Matthew Sacks

Pro Website Development and Operations

Copyright 2012 by Matthew Sacks

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher's location, in its current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law.

ISBN-13 (pbk): 978-1-4302-3969-7

ISBN-13 (electronic): 978-1-4302-3970-3

Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights.

While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein.

President and Publisher: Paul Manning

Lead Editor: Ewan Buckingham

Technical Reviewer: Patrick Debois

Editorial Board: Steve Anglin, Ewan Buckingham, Gary Cornell, Louise Corrigan, Morgan Ertel, Jonathan Gennick, Jonathan Hassell, Robert Hutchinson, Michelle Lowman, James Markham, Matthew Moodie, Jeff Olson,Jeffrey Pepper, Douglas Pundick, Ben Renow-Clarke, Dominic Shakeshaft, Gwenan Spearing, Matt Wade, Tom Welsh

Coordinating Editor: Katie Sullivan

Copy Editor: Sharon Terdeman

Compositor: SPi Global

Indexer: SPi Global

Artist: SPi Global

Cover Designer: Anna Ishchenko

Distributed to the book trade worldwide by Springer Science+Business Media New York, 233 Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail .

For information on translations, please e-mail .

Apress and friends of ED books may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Special Bulk SaleseBook Licensing web page at www.apress.com/bulk-sales.

Any source code or other supplementary materials referenced by the author in this text is available to readers at www.apress.com . For detailed information about how to locate your books source code, go to www.apress.com/source-code .

Contents at a Glance

Contents

Foreword

Weve all been there: Long lead times, onerous procedures, failed deployments, rollbacks, roll-forwards, middle-of-the night alerts, features that worked on my machine, emergency updates, all overlaid with a culture of blame. This will sound familiar to almost anyone who has been involved in the roll-out or maintenance of a production software application.

There always had to be a better way.

The idea behind the DevOps movement is simple enoughbring everyone with his or her own unique skill set to the table, break down any barriers to success, and work together toward a common goal. The Agile movement laid the groundwork and has been widely successful in improving communication between business stakeholders and engineering. DevOps applies the same ideas to the traditionally isolated teams who perform development, QA, and operations.

The DevOps movement started in 2009 and began gathering steam in 2010. Those behind it must have be on to something, as it continues to grow rapidly in both recognition and attempts to put it into practice.

Growth has also been fueled by a perfect storm of technology factors in recent years that pushed developers and system administrators to work together more closely. As Patrick Debois describes: Virtualization enabled ops to spin up new environments very quickly, and the cloud did away with the resource problem. The real differentiator came from two concepts: configuration management, and infrastructure as code.

It is no surprise to me how big this movement has become. Ive worked for years on improving application delivery processes and centralizing project knowledge and feedback, so when I first heard the term DevOps and the problem it was trying to address, it instantly made sense. It was one of those a ha! moments.

Reducing or eliminating the gap between development and operation is of incredible importance to businesses as they seek to not only deliver new applications and features to the market as quickly as possible, but also operationalize them at the stability and scale that the modern Internet demands.

Though this is a simple idea, it presents a huge cultural challenge for most organizations, particularly those that are large or have deeply entrenched processes. Moreover, even though the problems DevOps is solving are often clear enough, many struggle to understand what it really means to apply it to their organization. As was the case with Agile, there is some debate about the right way to do DevOps, and various groups have put forward conflicting ideas as they pursue their particular agendas. Nevertheless, certain basics are beyond dispute.