The YouTube video: Velocity 09: John Allspaw and Paul Hammond, “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”, is a great starting point for anyone really looking to learn why DevOps is important for organization that are trying to improve their software delivery process. They share a great story on how lots of organizations have internal conflicts in how software is delivered. They go over a use case that discusses at the time one of the hottest websites that existed in 2009; Flickr.
In the first 5 minutes they discuss an important concept that a lot of organizations that have an online presence (nowadays its referred to cloud) need to learn and adopt a culture of DevOps. It’s a must because this is the only way they can survive in a world that requires faster and quality deployment as a standard. They mention that the development and operations team share the responsibility to enable the business and keep it pumping improvements the overall delivery of software. They mention that it’s important to build tools and change the culture of an organization so that it can adopt a DevOps mindset and ensure its success in being able to meet the ever changing customer demands.
One thing that was mentioned was the stigma that I feel exists in my current organization, which is change breaks software. (in their slides they mention a statement: Discourage change in the interests of stability) I agree, that it does as anytime you modify code the risk of introducing new issues increases. But in a DevOps world you build a process that will counteract this by ensuring automated tests are performed and completed prior to releasing new builds to production. (in their slides they mention a statement: Lowering risk of change through tools and culture) They go on to discuss what I felt happened quite often early in my career at Ricoh. Being called early in the morning because our site was down. There were times when it was because of an error introduced by the operations team and there were times it was a bug that was introduced by the development team. We had a deployment strategy of releasing on Friday was I felt was a big issue. Because that meant that the site would not start reporting issues until Monday since usage of our site on Saturday and Sunday were low.
I like that they discuss failure as it will happen. This is an important concept because I feel that today there are a lot of people that fear failure and are afraid that they will be scolded by management and their peers. I feel that a culture around DevOps will help teams to understand that failure is necessary and it shouldn’t be something that we fear, rather than use it as a learning experience and mitigate the failure from reoccurring in the same way. I like the recommendation of training junior engineers when fires do occur. Not making them feel that they have to solve it, but go through the process of seeing what they will do if they were in charge of getting a system back up.
I really enjoyed the video as well as the following that I watched to enhance my knowledge of DevOps: