Habit number three is automating the build, test and release processes so they contain less human error. For testing to work, it must include scalability testing on the systems with which the application will run, as well as business function tests, the thing that traditional development teams excel at. Puppet and Chef now capture and help automate configurations and deployments; use them. (The authors didn't specifically mention Puppet and Chef).
The whole data center infrastructure must be revamped toward delivery of services from a more standardized environment. The process will be a long one, with both business users and developers losing some of their preferred, best-of-breed systems in favor of good enough Linux and Windows systems. The old way led to ever-increasing complexity, and that complexity was accompanied by an increasing fragility. So habit number four is simplify, standardize the development and production environment. Rigorously enforce that simplification on new applications. Then as much as you can, simplify legacy applications. It's a huge task.
Number five is to instill a culture of systems engineering across both development and operations. "Real engineering works in a disciplined, thoughtful way ... to reduce solutions to be -- as Albert Einstein recommended -- as simple as possible but no simpler." Building up software based on simple modules makes it easier to deploy and maintain, and to reuse.
Number six, the authors said, is implement feedback and feed-forward loops. Software is complex and requires feedback on how it's operating. Oftentimes, developers don't know. Testers and operators are often engaged only at the end of a project. They need to be involved early. Likewise, information that explains how an application is expected to operate, such as its dependency mapping, needs to be fed forward to operations and development teams that may be working on the next similar application.
The last habit is put developers on the frontline of support. They don't want to be there. It takes them away from the creative process of building more code, the place where their reputations are already staked out. But the developers who built the code will have the greatest understanding of why it's running poorly in production and produce the quickest fixes. And needless to say, developers will learn a lot about production as they watch their code run in its target environment.
These seven habits will not come as any surprise to the people who have already struggled with DevOps and moved their organizations closer to a combined-function IT staff. But they will come as education to more traditional staffs that are comfortable in their isolation from each other. That isolation includes some protection from being taken out of one's comfort zone and put in a situation where something more is expected of you.
Facebook automated the configuration and deployment of software to 17,000 servers using one Chef server, point out the authors. That's because it was able to build from scratch a simplified and standardized environment. The DevOps gain in automation is self-evident.
Amazon is constantly updating its production systems without fear of unintentionally torpedoing its operation. It does so through an automated test procedure in an environment that matches the production environment. Jon Jenkins, Amazon's director of platform analysis, stated at the Velocity conference in 2011 that someone is deploying code to production "every 11.6 seconds," usually to 10,000 servers at a time. In the average IT shop, such deployments would be suicidal, considering most outages are due to software updates. The DevOps gain in production reliability is self-evident.
Etsy deploys new features to its online, artisan marketplace with only one IT person on duty, thanks to its DevOps rigor of developing new code. Each addition is carefully tested and pushed when ready, rather than planning for a big team push to update a system once or twice a year.
The point of DevOps is to get both teams to treat their responsibilities as a science and to reduce the amount of science fiction involved when dealing with one another.
Learn more about DevOps by attending the Interop conference track on the Business of IT in New York from Sept. 30 to Oct. 4.