Tuesday, February 24, 2015

A Quick Summary of DevOps

What exactly is DevOps?

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support. (http://theagileadmin.com/what-is-devops/)

Like Agile, it's a rather large topic, but the main point of it is that developers work much more closely with Operations to ensure a more resilient release cycle. It's also characterised by Operations using many of the same techniques as developers - for example: source control, automation, and of course the Agile methodology.

 Adopted by all the big tech companies, DevOps allows for hyper-efficient deployments with much faster releases and far less production issues. In fact, the highest performers use DevOps to do 30x more deployments, 8000 times faster, 2x more successful, with 12x faster Mean Time To Repair than the worst performers (those who aren't using DevOps).

As a result, Amazon deploy to Production every 11.6 seconds. And they have very few Production issues. How? DevOps.

There's a lot to it, but some of the basic concepts that allow for this level of efficiency include the following.

Smaller Changes, Deployed More Frequently

Some of the biggest disasters in IT history have come from projects that had the longest lead times. Usually this is due to one reason: When they went live, it was the first time the code had ever been in a Production environment. To be good at DevOps and achieve a high level of fast, reliable releases, you need to get good at releases by doing more of them, more often. This involves shifting to a model of smaller changes, and more efficient releases.

Do Painful things More Frequently

There needs to be easier access to the painful process of releasing to Production. This is in contrast to traditional thinking that tends to treat releases as big scary things that everyone has to make a big deal over. Being efficient at DevOps involves streamlining and improving the release process in the same way we have streamlined our Development and Testing practices over the past few years.

Common Build Mechanisms

Rather than having distinctly different environments and setups for Development, Test, and Production, there needs to be a concerted effort to make all these environments as similar as possible.

Configuration as Code

To make it easier to implement Common Build Mechanisms, our deployment artifacts such as configuration, build scripts, automation scripts etc should be treated in the same way as code and managed under Source Control.

Automation

Like regression testing, deployments and environment setups should be as fully automated as possible, to allow for frequent and error-free repetition.

Definition of Done to include "Works in a Production Environment"

To take DevOps seriously, the ability to deploy to Production needs to be built into work processes.

Targeted Deployments

Techniques such as feature flags and deploying changes to small subsets of users can allow an organisation to get started with faster deployments.

High Trust, Peer Review over Approval

To adopt DevOps, we need to free ourselves of the learned behaviour that low trust, approval barriers and long lead times make our products more stable. The evidence is that they don't. Also, in studies, higher trust and lower lead times are seen as an indicator of both quality and happiness. While there might be some barriers to overcome up front, these changes overall make everyone more confident, more productive, and more efficient.

More interaction between Development and Operations

The underlying concept of DevOps is more interaction between Development and Operations. While before, we had a wall of procedures and artifacts between the two departments where work was thrown over, the goal now is to "knock that wall over and build a bridge". This means Operations getting more involved in the process earlier on to create common build mechanisms, configurations and automation. And it also means Developers being more involved in the release process.

Conclusion

Our job as developers is to release to Production without breaking anything. To get better at that, we need to do it more. A lot more.

Much the same as the adoption of automated testing, work needs to be done upfront to set up the infrastructure to allow DevOps to be safe and efficient. But like automation testing, these efforts pay huge, ongoing dividends.

DevOps is being used by most of the large tech companies and is allowing them to become extremely competitive by extensively reducing their lead times and quality issues. Those who refuse to adopt DevOps risk being left far, far behind.
*
There is a lot more to DevOps that I haven't mentioned here. Learn more with this course.
http://www.microsoftvirtualacademy.com/training-courses/assessing-and-improving-your-devops-capabilities If you don't have much time, make sure you at least watch video 2.