DevOps from an Operations Engineer s Perspective Interview with Tom Limoncelli, System Administrator, Google Tom Limoncelli is a system

administrator and coauthor of The Practice of System Administration and Time Management for System Administrators. Limoncelli recounts some of his observations regarding how the working relations hip between operations engineers and software developers has changed over time and e mphasizes the trend of both software and operations engineers working more closely togethe r and sharing similar responsibilities for producing and maintaining software. What did the operations/software developer relationship look like 20 or so years ago in comparison to today (in terms of releases, troubleshooting, and working together )? In the 1980s and 1990s, software was shrink-wrapped. Developers wrote it, tossed it to "manufacturing," which put it on floppies or (later) CD-ROM, and shipped it to stores. The stores sold it to people. If people had problems, they called customer support. Customer ser vice s goal was to prevent customers from talking to the software developers. If sysadmins had a problem with scale (automated installation, or getting a server to handle more users), they h ad a manual with a few tips, but mostly they were left to reverse-engineer enough about the produ ct so that they could create an ad hoc solution. Ratio of developers to customers: 1:many Interaction with customers: Forbidden Sysadmin tasks: improvised. How did Agile change the way you interacted with development? I look at DevOps as the natural response to Agile methods. If a software team be comes more effective because it is doing fast release cycles and greater communication, doe sn't it just make sense to start including sysadmins in that process? There are many similarities between the DevOps movement and the Agile movement. One is the evolution of the other, and DevOps certainly incorporates practices and i deals from the Agile Manifesto, the original manifesto that came about in 2001, when the Web wa s a mature and established platform. Its main concepts are: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Of course, there is quite a bit more to Agile processes and methodologies than t hese four principles, and the definitions of Agile and its implementations have grown and evolved since the manifesto s original publication.