DevOps is an important technology movement that is often misunderstood. It may seem like just another exotic and passing software fad. However, DevOps is gaining enough steam that it’s important to understand its impact on IT.
What is DevOps and Where Did it Come From?
DevOps is primarily a cultural or philosophical movement about how to achieve the best software development (Dev) to operations (Ops) deployment outcomes. It is not a codified set of practices like ITIL. The genesis of the philosophy can be traced to the observation made by commercial Web startups that much of the reason for poor software outcomes was due to a lack of effective cross-team collaboration. After DevOps initially surfaced as a concept in 2008, a series of conferences called DevOps Days started in 2009 to foster the discussion. James Turnbull, an early participant who now works at Docker, describes the problem colorfully in his 2010 blog post “What DevOps Means to Me:”
“In many shops the relationship between development (and engineering) and operations is dysfunctional to the point of occasional toxicity. Here’s an example I think everyone will be at least partially familiar with: the minefield that is project to production software deployment. Curse along as I explain. Development builds an application … built using cutting edge technology … throw[s] their masterpiece over the fence to operations to implement and dash off to the pub for the wrap party. Operations catches the deployment and is filled with horror. … ”
Despite its Web startup roots, DevOps was destined to enter the mainstream of enterprise IT practice because of a constellation of simpatico movements and issues such as ITaaS, cloud computing, and shadow IT. ITaaS is essentially a competitive business model where IT departments assume that line of business (LoB) departments have many choices for IT services and therefore must have a business focus and pay a great deal of attention to the needs and requirements of the LoB groups. One of the reasons that ITaaS has become so important is because of the rapid rise of cloud computing. Public cloud service providers can offer extremely competitive, pay-as-you-go infrastructure as a service (IaaS) and software-as-a-service (SaaS) offerings directly to LoBs. Compared to the complexities of outsourcing IT under huge, multi-year contracts, public cloud offers LoBs instant access to IT services with the swipe of a credit card. This in turn has led to a growing shadow IT reality, where nearly a quarter of IT spending is now done directly by LoBs and not under the control, governance, security, and compliance oversight of the IT department. The result is IT organizations are under more pressure to successfully deliver business-enabling application software, faster, and with higher quality — just like those Web software companies. Ah, how the world does turn, and it seems like it’s happening faster and faster doesn’t it? But we digress.
In recent years DevOps as an enterprise IT movement has been championed by DevOps popularizers. For example, in 2013 Gene Kim, Kevin Behr, and George Spafford published an IT novel on DevOps called the “Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win.” In it, they describe the travails of Bill, an IT manager at an auto parts distributor who must solve a seriously dysfunctional IT department’s problems. Today, if you search for DevOps, you’ll find a plethora of DevOps information to help enterprise IT organizations cultivate DevOps know-how.
DevOps: A Bit Deeper Cut
There are definitely some key notions that are championed within the DevOps community, aside from the whole collaboration issue. It’s impossible to be exhaustive, but here are a few:
- Agile: Agile development methodology was codified in the Agile Manifesto in 2001, and espouses human interaction over processes, delivering working software over comprehensive documentation, collaboration with end-customers over contract negotiations, and flexibility to changes rather than just following the plan. There are 12 principles of agile development, which are detailed in the manifesto. A concept that encapsulates agile principles is the idea of “failing fast” — that is, getting smaller chunks of valuable software functionality into a real-world customer environment as quickly as possible and iterating the software rapidly as issues are found. This is in contrast to waterfall processes that try to deliver huge batches of functionality but take so long that when software finally sees the light of day, requirements may only be discovered to have been misunderstood or that the requirements actually morphed since they were originally communicated.
- Continuous: If you’re trying to fail fast, then optimally you should automate that process to work at the granularity of developers’ code commits into source control systems. There are three types of “continuous” processes:
- continuous integration: every code commit launches a build server process that takes the latest code, builds an executable, deploys it on a server, and runs a set of automated regression tests to ensure that the commit didn’t break any previous functionality
- continuous delivery: extends automated testing of software beyond simple servers or virtual machines (VMs) into a real-world test environment, with the goal being to ensure software could be deployed into production operations environments at any time if desired
- continuous deployment: automatically deploys certified code updates into operations
- Flow: This is less familiar but very important. DevOps focuses on maximizing the productive flow of software work through all teams. The concept of flow comes from Lean IT, an emerging discipline derived from Lean Manufacturing principles originally pioneered by Toyota Motor Company. Think of the software dev to Ops stages as analogous to the manufacturing stages between raw materials and finished goods – except instead of manufacturing stations, you have development, QA, security, compliance, and IT Ops. Good flow requires effective hand-offs which means that when development provides code to QA and on to Ops, they will not struggle to figure out how to test and deploy it. So, if developers ignore the real-world infrastructure the software will be deployed on, they will hand off software that can’t be easily tested. This results in unproductive delays, lower test coverage, more deploy failures, and bugs found post-deployment. This means poor flow. Proper collaborations’ impact on flow can’t be underestimated.
DevOps Tools
While DevOps is not a technology, nor is it essentially about tools, DevOps assumes automation and tools as enablers. Probably the most foundational “tool” is cloud automation of infrastructure. This doesn’t meant that DevOps has to happen in the public cloud; it actually means that infrastructure should be self-service (via a GUI or an API), automatically provisioned, elastic in its ability to scale out/in to user or application requirements so it can be a private, public, or hybrid cloud. Cloudy infrastructure is important because without it, you suffer flow-destroying timeframes to allocate infrastructure to developers and QA. A three-week wait to get a VM or server for testing on is a huge hit on the flow. Self-service infrastructure removes that bottleneck. There are tons of other tools such as source version control and build servers, configuration management, plus application lifecycle management (ALM) tools.
What DevOps Means to Business Continuity
DevOps is important because it is a movement that affects how IT organizations think of delivering high quality outcomes. It’s possible to think of ways that DevOps could help business continuity. For example, business continuity planning suffers from infrequent real-world testing, according to “The State of Business Continuity Preparedness,” the joint DRJ, and Forrester Research study:
“The situation is largely unchanged from 2008. For all test types (walk-through, tabletop exercises, simulations), most organizations only test once per year and as tests become more extensive, test frequency declines.”
How does BCP rate on collaboration? Per the same report, only Business Owners take part in the BCP process 28 percent of the time. What about automation? Sixty percent of respondents did not use any commercial or SaaS tool to manage their BCP process, which at least implies that automation could improve. A DevOps approach to DR would encompasses cross-team collaboration work, agile and continuous “fail fast” updates along with automated testing on real-world, real-world infrastructure sandboxes, and a focus on eliminating the bottlenecks to achieve productive flow in getting these updates through that process.
Conclusion
DevOps is an important trend that started in the Web startup space but is quickly going mainstream in enterprise IT. Business continuity professionals can benefit from awareness but also from the practices that DevOps espouses.
Alex Henthorn-Iwane (@heniwa) is vice-president of marketing at QualiSystems (http://www.qualisystems.com), the leading provider of software automation to build, operate, and deliver clouds for ITaaS and DevOps. Henthorn-Iwane currently focuses on IT infrastructure automation, software-defined networking, and DevOps automation.
