In the last post we looked at why we consider DevOps a practice, and less a movement or a culture. To recap we then updated the definition of DevOps as follows:

DevOps is a practice with an associated philosophy, methodology, toolkit, and operating model, that enables the rapid deployment of software.

Let us now take a  closer look at the philosophy and methodology driving the DevOps practice.

The DevOps philosophy can be summed up as simply as this:

Ship quality code to end users as fast as possible.

This philosophy is driven to a large degree by another related philosophy surrounding the lean startup movement (in my opinion much more representative of a movement than DevOps), i.e. the “fail fast” philosophy. Startups have embraced the “fail fast” philosophy nearly completely, and the philosophy has now rubbed off to the enterprise as well, to the extent that conglomerates like GE are leveraging the “fail fast” philosophy to develop everything from new types of pizza ovens to rally fighters.

So how are startups and even enterprises today able to “fail fast” and, arguably more importantly “fail cheaply”? From a software development perspective they are able to do this because they leverage a methodology that looks something like this:

Product development teams leveraging a lean startup approach recognize that in order to reach their critical first milestone of obtaining product traction or proving market viability, they have to release software (or hardware) to end users for feedback early and often. A DevOps driven agile methodology fits perfectly into this new product development paradigm.

In contrast though the typical enterprise software development methodology for the longest time (and still to a great extent today) continues to be a waterfall methodology that looks something like this:

…and now perhaps with the slow, but inevitable adoption of agile in the enterprise it has started to look something like this:

What is key to note here is that even though with agile you are producing code faster, you are not necessarily deploying that code to production systems as fast you should in order to solicit the necessary feedback required from end users to “fail fast”. This is primarily due to the following factors:

• Organizational misalignment: even though your design, development, and test teams have begun to function in an agile manner, the rest of your organization, in particular operations and various infrastructure teams still continue to operate in a waterfall approach.
• Toolkit gaps: in order to deploy code to production as quickly as software is built and tested a toolkit is needed that almost entirely automates the entire build, test, and deploy process.
• Platform gaps: what type of platform are you deploying your code on? Are you deploying on an IaaS or a PaaS based platforms, or on more traditional legacy infrastructure? Legacy infrastructure lacks the self-provisioning and rapid elasticity capabilities provided by cloud technologies, and these capabilities are an absolute must for DevOps to be successful.
• Company culture: is your company culture aligned with the lean startup movement and fail-fast philosophy? If not, then even if you address all off the above, i.e. your companies organizational structure, as well as toolkit and platform related gaps, chances are the adoption of DevOps will still not deliver optimal results, and will most likely falter.

In the next post we will look closer at the toolkit gaps are and the DevOps toolchain required to close these gaps.