What is DevOps? The word DevOps is a clipped version of the words Development and Operations [1].
What does development mean? Development is the process of designing, building and testing software. This includes product design user experience, software architecture, software design and coding.
What does operations mean? The term operations describes the process of building a network and ensuring its security as well as configuring servers, databases or any other piece of the environment that the software may operate in. Operations is also responsible for deploying software. If something goes wrong with a software program, Operations personnel are the folks that woken up at 3 am to fix it.
So then, what is DevOps? At Agile Indy, Paul Hacker defined DevOps as “The union of people, process, and products to enable the continuous delivery of value to our end users”. In the book the Phoenix Project, Gene Kim defines the underpinning principles that all DevOps patterns derive from as “The Three Ways.” [2]
The First Way
The main goal of the First Way is to optimize the system to improve the flow of planned work. In order to do this we much treat the whole IT value stream as one system. This includes ideation, development, testing, deployment and maintenance. When making an improvement in one area, one must consider the effects it will have on the other areas such as testing and operations. For example, increasing the number of story points per week in development does not add value to the end user if it takes six months to test and deploy it to production. When the business, development, test and operations work together toward a common goal then improvements can be made to the entire system to reduce the lead time to the end users.
Image from Agile Indy Meetup, DevOps as a Strategy for Business Agility, by Paul Hacker
The Second Way
The main goal of the second way is to ensure changes that flow through the value stream are delivered with high quality. The Second Way is about using feedback loops to detect and amplify failures at all stages of the value stream. In addition, this means “stopping the line” when a problem is detected and fixing it. For example, to get immediate feedback on a change, teams use a continuous delivery pipeline that will build, deploy and test the software on every commit to source control. When your build fails a test, someone must drop what they are doing to fix it. Other feedback loops are using retrospectives as a place for amplifying things to improve in our daily work. One technique I learned at the 2016 Agile Indy conference this year was the continuous retro where when some notices a problem it is talked about immediately instead of waiting for a retro meeting.
The Third Way
The Third Way is about two things experimentation and learning from success and failure. It focuses on the understanding that repetition and practice are prerequisites to mastery . I once heard someone say “In software, if it hurts, do it more often”. If testing is painful or if deployments take forever and requires days of troubleshooting, do it more often and look for ways to improve. The “pain” is often referred to as technical debt. The Phoenix Project suggests that we take 20% of our time to focus on these improvements so when something does go wrong we are prepared to quickly react and fix it.
A great example of the application of The Three Ways was in a story I read about Netflix. Netflix, an AWS customer, made an architectural decision years ago that they were not going to allow a single point of failure to bring down their services. So what did they do? They practiced recovering from failures. They built a tool they called “Chaos Monkey”, which was a program that would randomly shutdown machines their services were running on to test how well they could recover. In 2014 AWS sent out a notice for an emergency upgrade to some of their EC2 instances that would cause them to have to reboot. This affected 10% of Amazons Database nodes; however, Amazon applied the update one weekend and Netflix customers experienced 0 down time. [3]. By practicing recovering from failure they were able to seamlessly recover from outages and their customers did not even notice.
Conclusion
DevOps is not a process, company, tool, person or team. It is a philosophy, a movement that is changing the way we work as IT professionals similar to the way lean manufacturing changed the way companies manufactured goods. It is a change in culture that requires everyone involved in the application life cycle to be responsible for the continuous delivery of value to their end users. DevOps is the key to true marketplace agility. DevOps is the future.
References
[1] https://en.wikipedia.org/wiki/DevOps
[2] The Phoenix Project by Gene Kim
[3] https://techblog.netflix.com/2014/10/a-state-of-xen-chaos-monkey-cassandra.html
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
You Might Also Like
