Feature
Last month, instead of retreading over the tired “What is DevOps?” ground, I asked a different question: “How Do You DevOps?” While the debate over litmus tests and succinct definitions continues, one voice struck a chord. While I empathize with Josh Johnson’s angst and frustration, I would offer an alternative conclusion.
Attempting to Reduce the Holistic
Narratives of exclusion and litmus test barriers don't serve the individual or the movement. DevOps is a holistic concept, but also (somewhat paradoxically) requires harmonization of interdependent efforts to yield the intended results.
Starting with automation and metrics is good, and in my view, qualifies you to claim practitioner status. To deliver the “high performance IT shop” promised by so many, you must dig deeper and create the conditions required for DevOps to flourish.
So, starting with the building blocks of automation and dashboards, here is my DevOps plan for 2015:
Building Blocks
Automation
My team's automation efforts started in earnest about three years ago and we still haven't hit our stride. There were few believers in the efficacy of robots for the first few years and a lot of my energy went to stump speeches and cajoling project teams to reject narratives that boiled down to “automation is not a business requirement, thus it is not going to get paid for.”
2015 marks the first full calendar year where most, if not all of the organization are believers in both the power of automation and in the individual responsibility we must take to reach a mode of true continuous delivery.
That said, the big struggles are still in front of us. Big hurdles for this year include:
- Advanced Quality Assurance (QA) automation -- We are laser focused onimproving two key metrics for our QA automation toolset: brittleness and reusability. In order for QA automation to pay off, scripts require a basic level of resiliency that does not require the regression scripts to be fixed before every project. Reusability of scripts is equally important in that scripts must be both componentized and dynamic to allow for an approach that can best be described as “automating the automation.”
- Single Button Deployments -- Our path from commit to build is well paved and we have made great strides in reducing manual labor leading up to deployments. This journey will not yield the intended result until we have the ability to fully script a deployment and release plan that includes all the network tasks, excludes human intervention and fully accounts for pre-existing sessions to end before calling the deployment done.
Monitoring, Alerting and Dashboards
Our dashboards are rich and plentiful and we have a robust set of listening frameworks. What we lack is a formalized monitoring strategy that accounts for not only the differing perspectives in the enterprise but also the commitment to automate the data collection, integration and generation of visualizations. Some dashboards are automated, but it still takes too much energy to collect, aggregate and publish the Key Performance Indicators (KPIs) and metrics that matter to a wide variety of audiences with different tastes that correspond to differing roles and responsibilities.
2014 was our first year integrating production monitoring APIs (Application Program Interfaces) withour enterprise social intranet. Now that we've set up a basic aggregation pattern with self subscribing users, this year we will add more KPIs and visualization to the mix.
Creating the Necessary Conditions
Loose Coupling
The industry understands the power of RESTful APIs and the microservices revolution is just beginning. But we aren't seeing the conversations about how necessary an API program is to make DevOps truly succeed. Lacking a loosely coupled architecture, you fundamentally cap what can be accomplished with fully optimized production lines with continuous delivery capability. It just won’t deliver on expectations without it.
All of our web applications lean into the servicification paradigm. 2015 is the year we plan to:
- break up monolithic API deployment into micro-services that can be deployed independently
- spin up an always-on API testing framework
- spin up a formal API gateway with crowdsourced developer documentation
Smaller Batch Size
In the same way that DevOps' potential cannot be truly attained without a loosely coupled architecture, DevOps also depends on a factory approach that reduces the size of each deployment that leaves the dock.
The longer that code branches go before being merged into the trunk, the harder it will be to merge code due to the growing differences between code versions over time. As merges become more difficult, quality will inevitably suffer as production defect rates increase. Even tougher to accept, larger batch sizes and less frequent releases will push Mean Time to Resolution (MTTR) in the wrong direction.
Given that MTTR is the golden metric of all production lines, the clear link between larger batch size and increased MTTR should make smaller batch sizes for shops that manufacture software (or anything else for that matter) the unifying force that allows the other DevOps practices to yield the intended benefits.
Bottleneck Elimination
If technology bottlenecks are the only bottlenecks you focus on, you won't get the crazy gains in speed and throughput that DevOps promises. Our shop has many goals and tactics to loosen system constraints at various points in the manufacturing process.
Learning Opportunities
Webinar
Jun
8
Attracting—and Keeping—Your High-Net-Worth Investors
Join PwC to dissect their recent survey findings on a specific customer subset — high-net-worth investors.
Webinar
Jun
13
The Future of Contact Centers with AI at the Helm
Learn how to balance human intuition and interaction with the potential uses of AI to create delightful and lasting CX
Webinar
Jun
13
Learn How to Deliver Dynamic Video Experiences at Scale
Learn how to convert existing assets into video experiences in near real-time.
Webinar
Jun
20
3 Steps to Unlock Your Customer Data and Drive Revenue
Discover how Twilio Segment’s #1 Customer Data Platform helps implement data-driven strategies.
Webinar
Jun
21
Retail Reinvented: A Masterclass in Creating Digital Experiences That Click
Hear how online retailers architect their digital experience infrastructure for peak traffic and demand
Webinar
Jun
22
How to Succeed in Today's Engagement Economy
Doing true personalization at scale with marketing automation
Webinar
Jun
8
Attracting—and Keeping—Your High-Net-Worth Investors
Join PwC to dissect their recent survey findings on a specific customer subset — high-net-worth investors.
Webinar
Jun
13
The Future of Contact Centers with AI at the Helm
Learn how to balance human intuition and interaction with the potential uses of AI to create delightful and lasting CX
In Phoenix Project terms, however, the goal of bottleneck elimination is a bit different. We refer to it as "De-Brent-ifying" the enterprise. Brent is the character in the Phoenix Project (theDevOps’ community's most celebrated book) who is essentially a “bottleneck with legs.”
Every enterprise has them and we are no exception. Our team goals for this year involve asking each operating unit to identify their own “Brents” and engage in a multipoint plan to have each individual Brent spread their knowledge and capabilities out to their teammates.
Debt Remediation
In any manufacturing facilities, two metrics tend to be the prime constraints of throughput: Work In Process (WIP) and Unplanned Work. As total WIP and Unplanned Work frequency and duration increase, capacity is sacrificed and throughput suffers. The leading indicator metric for both of these metrics is what is referred to as technical debt.
Technical debt is essentially any production code and infrastructure that has become brittle, obsolete or incapable of meeting the organization's evolving needs. 2015 is the year for our team to create the fast and flexible future we want to live in. A prerequisite for creating this future is digesting whatever gating backlogs exist in our products or platforms.
Given that it is never economically viable to ensure the complete elimination of the last case of any disease, maintaining the focus on retiring the last of several legacy technologies in the web application, API, search, content management and middleware layers is going to be a serious test of our commitment.
Holism Wins Again
Culture
If you read Johnson's essay carefully, you'll notice that culture appears to be the missing ingredient in all of his professional environments. Johnson worked in top-down environments where DevOps was a fiat -- it did not have wide buy-in and was met with disdain from his development organizational counterparts.
Successful enterprise change agents know that when introducing a new process or concept one can only hope to minimize opportunities for failure, not ensure success. In recognition of this, our shop will continue its emphasis on building an artisan culture in all teams. For product development in particular, taking pride in craftsmanship is a cornerstone for driving a high performing engineering team. For us, this means being zealous at doing the hard work of performance optimization at the millisecond level, designing for resiliency and keeping code quality metrics high.
In true DevOps spirit, our team is formalizing on our automated dashboards on each of these quantifiable metrics, which brings us right back to the first two items in our DevOps plan.
The interdependence between each of these goals is not a coincidence. This is inescapable. Dynamic systems require change on multiple fronts in order to be significantly effected.
If you take dashboards away, the plan cannot hope to succeed. If you take smaller batch size away, you cannot hope to succeed. The same is true for each of these efforts because for my shop at least, this is the DevOps MVP -- the minimal viable product. This is how we DevOps.
Title image by jbhthescots
