DevOps 101 - A Brief History Of Time

If you have anything to do with developing products or working in IT helping to deploy and run them, chances are you have heard the term "DevOps" in one form or another.  Just like the ubiquitous "Cloud" floating out in the Internet somewhere, DevOps has become a catch-all phrase for anything that is Developer or Operations related.

Before jumping into what DevOps is, I think it's helpful to look back at the evolution of software development which will make it clear why DevOps was inevitable.

First Came The Developer And QA

I'll start be looking back a few years when software was primarily developed and targeted as software installs on end users computers with physical media (DVDs, CDs, or dare I date myself and say Floppy Disks). Development teams would work tirelessly 6+ months on the next release of their product.  When the development team gave it the green light, it would go to the quality assurance engineers to perform end user testing, then back to Dev to fix things, then back to test and so on.  When QA gave it the green light, it would go to pressing and packaging and ultimately end up at the end user.

Next Came The Internet

Once companies discovered they could distribute their applications in "soft" copy, they eliminated the overhead and costs for physical media, paper manuals, and shipping costs while providing almost instantaneous access for their customers to their latest and greatest software.

Then The End Users Got Greedy

I'm not sure who first thought of a "hotfix", but whoever did is somewhat responsible for the current need for the agile philosophies in application development.  Users no longer had to wait 6 months for a "bug" to be fixed in their local copies of the software.  Hotfixes brought an interesting dilemma as they only contained a fraction of the code needed for a major release and, consequently, needed to be produced on a much shorter timeframe and at a much higher frequency.  Developers and QA need to come up with a better way to handle the more frequent development cycles and came up with a solution with development methodologies like Agile and Scrum.  That helped them maintain sanity in their development processes. But Dev and QA needed to come up with solutions to make the delivery process more seamless.

Then Came The Web Application And Network Ops

Someone sat in a meeting in some conference room and said "We have a website right?  Why don't we build a version of our product to run on the web?"  Reducing the users need to physically install software is a big bonus as they always have access to the latest and greatest.  If the hotfix wasn't a turning point, then the migration of apps from standalone to web-based definitely was.  Network Operations (Net Ops) came into the scene here as they were needed facilitate distribution of the downloadable images.  This helpful IT folks make it their life's goal to have the bits accessible and the download as fast as possible to all users across the internet.  They took the files, put them in their distribution channels such as ftp/web servers and Content Delivery Networks, checked the box on the release document and waited until the next request.  (Ok, I know I'm simplifying things and IT does a lot more than than, but this is going somewhere I promise).

Then Came The Pain

What that guy, or gal, in that conference room didn't think of was the issues that would arise with the deployment of an application from physical media to the network.  No longer are the Ops folks just responsible for the "bits" passed to them to be accessible, they were now responsible about minor things like user experience, access controls, hackers, availability, compliance, etc.  Up until this point, the development and release process was fairly painless but now it just got a whole lot messier.  The Ops team's jobs are now at stake for maintaining all of those "minor" things and much more.  No longer can they just take the word from the development team that a product is "ready" for distribution and blindly "check" the box on the release.

Then Came The Brick Wall

Needless to say, things went from good to worse. It started enforcing process that infused them with the dev-test-production migration.  Change tickets, request queues, and delays ensued.  A brick wall was being built between Dev and Ops.  Dev would toss a release over the wall to Ops.  A response would be tossed back over the wall to Dev with either the successful QA and deployment or rejection to fix something and try again.  Dev started seeing Ops as those trying to stifle their innovation while Ops saw Dev as reckless with no regard for how the apps run in the real world.  Distrust then led to a slow development process with logs of back and forth.

Introducing Some Sanity

Since the Agile development process was so successful in helping put sanity in the code production process, at the Agile 2008 conference, Andrew Clay Shafer and Patrick Debois discussed the new concept of "Agile Infrastructure"  and afterwards created the "Agile System Administrators" group on Google.  The term "DevOps" was then born and made popular through a new "DevOps Days" set of conferences that started in 2009 in Belgium.  DevOps takes the Agile development processes to the next level by adding Ops into the mix.  Welcome to the club Ops, now you are a developer too!

Enter DevOps

To put it succinctly DevOps is a set of tools and methodologies to help Dev and Ops work together to enable pushing more software updates out faster and more reliably.  Regular communication, small batches of work, and an iterative approach are just a few pieces of the puzzle.  DevOps methods stress the following pillars which I'll refer to as the MICCAM model:

• Management
• Integration
• Communication and Information Sharing
• Collaboration
• Automation
• Measurement

By now you see how the DevOps methodology came to be and the problems that it is trying to solve.  It's important to keep in mind that "DevOps" is not a end-all-be-all solution that fits everyone to a “T”.  Just as Agile and Scrum are tweaked and adjusted by developers, the tools and execution will vary based on the companies requirements and dependencies.  To help with the execution, several companies like Chef, Ansible, and Puppet Labs are building products and solutions to help companies adopt these ideas and become productive with application development and deployment.

In upcoming articles, I'll dig more deeply into the different pillars of DevOps, how companies are implementing them, and the various companies that are helping with the execution.