Considering DevOps in Your Enterprise?

“Development is an endurance exercise with incremental improvements”
-Sri Mulyani Indrawati

DevOps is a relatively new term for a concept I believe has been around a long time. At this point, it’s widely accepted as a cultural way of being in some organizations, a confluence of formerly siloed teams that together can produce faster, more frequent, and more reliable results.

I was fortunate enough to start my career in a DevOps culture before the term hit mainstream. When I became a developer at Bloomberg in 2001, the company was already well known for its relentless pursuit of time-to-market, iterative development cycles, and developers owning the ongoing operations of the systems they delivered. It didn’t take long for new developers to learn what it was like to troubleshoot a system at 4 a.m. (when London trading opened). I found that these late-night experiences served as great motivation to make your systems more robust.

DevOps may be intuitively obvious to startups because smaller businesses can gravitate toward it with relative ease. But for larger organizations with significant amounts of technical debt, monolithic architectures, and risk-averse business practices, the undertaking can seem intimidating.

The good news is that it doesn’t have to be, and over the next few weeks I’ll discuss specific areas and strategies for implementing DevOps in an enterprise. I encourage companies wanting to shift to a DevOps culture to do so in a DevOps fashion — start with small projects, iterate, learn, and improve. I encourage them to consider implementing strategies that produce commonly accepted practices across the organization, and to begin embracing the idea that, when automated, ongoing operations can be decentralized and trusted in the hands of many teams that will run what they build.

When I was the CIO at Dow Jones, we built our DevOps practice around a small team of people — four or five individuals were enough to get going on several projects. The goal, however, was not just to create a new team but to influence a change in the company’s culture. By implementing and inventing frameworks, best practices, and governance, and by automating everything, DevOps became one of our key levers for driving innovation and accelerating product development. We started with small projects, and used the results to showcase how we could successfully execute an increasing number of projects using the same model. Slowly but surely, we began to deliver more features, and improve our time-to-market in the process. What used to be Tuesday and Thursday release nights, where things often went wrong, eventually turned into developers releasing dozens of changes throughout the course of each week.

For those considering DevOps but also juggling technical debt, consider these three tenets to start:

1. Be customer service-oriented throughout your organization. Businesses today should think of their internal stakeholders as customers. These customers could be anyone from a marketing department, a product manager, or a developer. Each individual or group needs technology to do their jobs. Teams that puts those needs in the forefront will keep their customers from wandering off to other solutions (Shadow IT), will likely deliver better results (faster, better, cheaper), and have happier stakeholders. Lack of superior service could leave your customers wanting to work around you, not with you.

2. Automate everything. It’s widely understood that to get the most out of the cloud, you’ll need to be able to reliably reproduce your systems using code. This is particularly true for autoscaling (elasticity). Automation also allows organizations to be much more aggressive with implementing changes: If you make a mistake, you can very quickly go back and reliably reproduce the previous state. Other benefits include better efficiency, security, and auditability. (See my previous post on automation for more detail.)

3. Run what you build. This is often where I see traditional IT become anxious. In a traditional IT model, the operations of an application or service are sometimes managed by those that weren’t involved in creating the asset. There were a number of reasons for doing this (e.g., lower-cost resourcing, centralized expertise), but I would argue these reasons are going away. Cloud technologies now handle much of the heavy lifting associated with IT operations, and much of the operations can be automated with software. Developers are familiar with software, which means there’s less motivation to separate the operations responsibility of any given task. This is where the term DevOps comes from, after all. Since developers will be the ones most intimately familiar with the nuances of the system, they will likely be able to address issues the fastest. And by using automation, it is easy to methodically propagate changes and roll back or address issues before they impact customers. I encourage centralized DevOps teams to do what they can to make development teams increasingly independent, and not be in the critical path for ongoing operations/releases.

For those that are interested in dipping their toe in the water, there’s no time like the present. Start small and be satisfied with incremental improvements. Cultural changes don’t happen overnight. Slowly begin applying these concepts across your portfolio, and both new and old ways of working can improve. As you gain experience, you can parlay each learning to the next, leverage your growing inventory of automation, and hopefully see better results.

In my next post I hope to explore a bit more about what it means to be a customer service-centric IT organization.

What’s your DevOps experience been? I’d love to hear about it.

Keep building,
–Stephen
@stephenorban
orbans@amazon.com