DevOps Celebrates it’s 100th Birthday!
Yes, you read the title right – DevOps is officially 100 years old. Way back before Dr. Deming, Agile, Jez Humble or anything labeled “continuous”, the principles of DevOps were being created and refined. But like a rebellious teen, our current iteration of DevOps may be ignoring some of the guiding principles that have proven to be so successful in previous generations.
Think about the automobile industry circa 1905. These high-tech shops were pure DevOps as cross-functional teams collectively engineered, fabricated, assembled and tested every single automobile that was “released”. These DevOps forefathers strived for the same important ideals our current generation has set out to achieve – to increase release speed, improve release quality and gain a competitive advantage.
Back then, DevOps teams were super agile and could adapt quickly to the changing needs of their end-users. Quickly, teams at Buick, Oldsmobile and Cadillac began to discover the power of interchangeable components and automation (i.e., open source tools). Productivity and efficiency skyrocketed as a result.
But starting around 1912, Henry Ford began thinking beyond the prevailing brand of DevOps. Ford came up with is own DevOps secret sauce. Unlike the other DevOps teams of the era, Ford placed relentless focus on two key concepts: repeatable processes and standardized inputs/outputs. He recognized the lack of standardization resulted in low process repeatability which in turn raised cost and lowered quality. In 1913 he began to standardize processes and the inputs they require, thereby launching the very first Continuous Delivery pipeline for the auto industry. Once implemented, Ford’s new CD pipeline was assembling, testing and releasing new automobiles at a rate far exceeding anything previously thought possible.
What was true about delivering cars in 1913 is also true about delivering software today. Without highly standardized inputs, DevOps teams can not design repeatable processes. Without repeatable processes, automation is not possible. This means DevOps craftsmen will always be required to manually build, test and deploy software change.
Today a handful of select companies like Netflix, Facebook, Ancestry.com and Flickr have largely removed this type of craftsmanship from the software delivery process, replacing it with highly-repeatable processes and relentless automation. Some call these companies “Unicorns” because they seem to have magical powers. A few months ago I talked to the DevOps team at Ancestry.com. They have hundreds of fully automated delivery pipelines and production deployments happen on average about every six minutes with the same level of fanfare as the next new Ford rolling off a production line. These organizations build, test and deploy software change effortlessly by relying on Henry Ford’s two core ideals: standardized inputs and repeatable processes.
Here’s a quick story… John DiMarco, Chief Operating Officer at CEDAR Document Technologies, is very happy with his agile Development process. New development output is very strong, so strong in fact, that Delivery is quickly becoming the agile bottleneck. To combat this problem, he’s well on his way toward a complete transformation of CEDAR’s current Delivery methodology. When we first met, he equated the process of delivering software with the effort required to deliver “finely handcrafted Italian marble”. At that time, his Delivery process was able to produce a high-quality output but it was overly reliant on individual effort and creativity. Now, one of DiMarco’s strategic objectives for 2015 is to evolve his software Delivery process toward the kind of high-tech assembly lines found at Ancestry.com.
Assembly lines require highly standardized inputs in order to function efficiently. Therefore, a clear line between Development and Delivery must exist to define the discrete point at which Delivery inputs (i.e. software change) must tightly conform to a set of very strict standards agreed upon by all stakeholders. Without this formal entry point and standardized inputs, you’ll be handcrafting marble all the way to production.
Devops needs to take a cue from our fellow microservice advocates. Imagine a Service Oriented Process (SoP) where Development and Delivery are both first-class citizens in the larger agile machine. Both services have inputs and outputs, are bound by contracts and interface through a standard “API”. With this type of mindset, Development and Delivery services can evolve as needed without affecting each other, as long as all contracts are honored.
Payoff – The Unicorn Secret Sauce
Over the past six months, I’ve talked to over 50 CIO’s and VP’s of Dev/Engineering. A few are unicorns, others are well on their way, while most are just now plotting their course. Based on these conversations, and so many others with customers and DevOps thought leaders, I have identified the Unicorn Secret Sauce.
Standardization – There is one simple reason you must break your agile Develop/Deliver stream into two (or more) discrete services – Standardized Inputs/Outputs. Whether you define two big services (develop and deliver) or twenty micro services, each service along the pipeline should have documented inputs and outputs as well as detailed contracts between any two interacting services – in writing. While this step won’t be easy, it’s absolutely critical for two reasons:
Assembly lines require standardized inputs. With no standard inputs you are handcrafting Italian Marble.
When the definition of “done” can be objectively proven via satisfied contracts, pipeline throughput is no longer dependent on cooperation and the DevOps group hug (while that’s still awesome). Now, statistics can be generated, quality can be measured and performance can be objectively quantified and compared between and across services and teams. Welcome to the DevOps Party Dr. Deming!
Test-Driven-Design – The Development service must be able to hand off a standardized package that can be easily ingested by a downstream service without the need for creative thought or subjective analysis. This has always been pretty easy when it comes to the change package itself (code), however, the question of quality has always been a much tougher nut to crack. The best way around this is by adopting some form of TDD. It doesn’t matter which teams create and define quality tests – what matters is that success and quality have been implicitly defined and that proof can be easily achieved (manually or automatically) downstream. Without tests as a primary input to delivery, there can be no contract between services and we’re back to Italian Marble.
The Journey – It’s a Marathon not a Sprint
Clearly the metamorphosis from marble craftsman to unicorn will not happen overnight or this quarter – It took Ancestry.com two years to get there. But here is a proven roadmap that will get you from here to there:
Define your version 1.0 Service Oriented Process design. Pay careful attention to ensure inputs/outputs have been standardized and clear contracts are in place between “service API’s”.
Next implement basic delivery infrastructure (the assembly line operating system). This platform will orchestrate flow across/between services, gather data, and provide real-time status, reporting and analytics. This will get all teams and service providers on the same page and rowing in the same direction leveraging a unified world view.
Next, start eating the elephant one bite at a time by continuously replacing manual services with automated replacement versions still remembering to focus on inputs/outputs, API’s and contracts.
Over time, your body of automated quality tests will grow at a speed equal to your rate of change. Soon coverage will be broad enough to accurately predict release quality allowing manual release testing to quickly decline as automated test coverage (read confidence) increases.
Twelve to twenty-four months later…congratulations, you’re a unicorn!
No doubt, many will disagree with my perspective. I value every opinion and will learn from your shared ideas. Please express yourself and add your voice to the discourse with a comment below!
About the Author/Dennis Ehle
Dennis Ehle, is a pioneer and thought leader in continuous delivery automation and agile delivery methodologies. Dennis is passionate about helping agile teams dramatically reduce the transaction cost associated with delivering incremental change. His company, ClearCode Labs, does just that by helping organizations continuously deliver high-quality software releases more frequently merging proven methodologies with empowering tools and technology. Twitter: @DennisEhle