Many years ago, Oleg Vishnepolsky and I worked together at IBM's T. J. Watson
Research Center on the OS/2 1.1 port of the TCP/IP protocol stack. Recently, I had a conversation with Oleg, who is currently the CTO at The Daily Mail Online, about DevOps and how it seems companies miss the whole point of what DevOps promotes.
During our conversation (via email), it came out that he was of the opinion that DevOps is not a successful paradigm to follow and asked me for my thoughts on the matter. I decided (with his permission) to publish the conversation because it seems that a lot of people are of a similar mind when it comes to DevOps (just as there were similar attitudes when the OGC released ITIL in the late 1980's), and while I do agree that many companies are not seeing the benefits of DevOps that it is supposed to bring to an organization, I don't believe that the problem is with the paradigm. Hopefully, my answers to Oleg will not only clarify why DevOps is important but will also underscore why care must be taken to ensure that it is embraced correctly in order to fully realize the potential benefits that it can bring to your organization.
Oleg,
Here's my take on your blog entry, which I just read: DevOps is truly nothing new, like ITIL was nothing new either. Both were simply a formal means of describing things that were occurring for many years already upon their release. What ITIL and, to a lesser extent, DevOps does is describe the best practices that are needed to increase the chances of success. You note this "best practices" connection in your article, but I don't think you fully appreciate the value in doing so.
The biggest "problem" here (and I use that term loosely) is that you seem to have little experience working with organizations where the "software development pipeline" is so poorly implemented that it causes more problems than the extra value that Agile is supposed to bring to the organization. (I jokingly call this "frAgile".) I have, however, run into these types of organizations on a high enough frequency that it is scary.
One thing that is clear about DevOps, which was similar in the days when ITIL was initially released in 1988 by the OGC: it is not meant to be a "you must do it this way" process. Instead it is meant to describe ways that application development and operations can work together. The biggest benefit of this is by highlighting what many people like you and me with the appropriate level of experience already know: development is all about writing code while rarely giving the appropriate amount of consideration to quality, while operations is all about ensuring stability in the production environments, meaning they aren't too happy about software releases because that means constant change, which is counter to the concept of ensuring stability.
This is a critical point because although application development organizations are frequently measured by the number of defects, true, getting applications out the door on time trumps everything including software quality. I can recall one such time during my days in application development when development was halted for an entire month so that we (a team of 40+ developers) could all do testing (like a staff aug for the QA group). That sounds great until you realize that we only tested for and fixed severity 1 and 2 defects and ignored severity 3 and 4, which dwarfed the former categories of defects in terms of quantity by an order of magnitude.
So DevOps screams at developers that operations wants stability so they need to make quality a priority. At the same time, it screams at operations that developers are trying to release things quickly to get new business functionality in the hands of the end users. That last point cannot be understated. In March 2014, Gartner told a group of CIOs the following: "CEOs must focus on leading their organizations to think like and become more like ‘tech’ companies, because within a few years, digital business capabilities will dominate every industry. Urgent action is needed because first-mover advantage is common in digital business, and fast followers must be very fast."
To put that more succinctly, "constantly innovate or rapidly become irrelevant."
So DevOps is not only a buzzword but it is, in a very real sense, a "must have" since without this coordation between the two organizations, a company will lack the velocity to do exactly what Mark Raskino at Gartner said in that quote, above. Consider this for a few moments: in May 2011, Amazon was noted as releasing something to production every 12 seconds. One of my customers, Bet365, releases to production every 4 minutes. And when I was at a previous employer, one of our large financial services customers in EMEA had 60,000 production releases every month. This need to scale to massive throughput from development to production is here now, and so the coordination proscribed by the DevOps movement is needed now as well.
I hope this helps.
Kind regards,
Larry
Thank you. What i see happening though in the industry is that devops is taken as a mandate to let developers loose on production environment.
Oleg
Oleg,
Well, that's kinda what I meant by "poorly implemented." That's similar to when people thought (and, unfortunately, frequently still think) that Agile means "release more quickly." In the latter, the part they miss is "release more quickly without incurring more operational risk." (To wit, the official mantra of Agile is to "fail fast" but that ultimately has the goal of allowing an organization to release more quickly with less risk because bugs are identified earlier in the SDLC and fixed there when the amount of effort to remediate is significantly less.)
Organizations that take the word "DevOps" and use that as a shield to justify poor decisions related to operational impact are headed for failure. But that's not the fault of the DevOps movement and is instead the fault of the leadership at the company that allows this to happen.
Kind regards,
Larry
Your comments on this subject are highly encouraged because it's important to have thoughtful discussions about this and how you and your company can reap the greatest benefit from having fully and correctly embraced the DevOps mindset.
During our conversation (via email), it came out that he was of the opinion that DevOps is not a successful paradigm to follow and asked me for my thoughts on the matter. I decided (with his permission) to publish the conversation because it seems that a lot of people are of a similar mind when it comes to DevOps (just as there were similar attitudes when the OGC released ITIL in the late 1980's), and while I do agree that many companies are not seeing the benefits of DevOps that it is supposed to bring to an organization, I don't believe that the problem is with the paradigm. Hopefully, my answers to Oleg will not only clarify why DevOps is important but will also underscore why care must be taken to ensure that it is embraced correctly in order to fully realize the potential benefits that it can bring to your organization.
Oleg,
Here's my take on your blog entry, which I just read: DevOps is truly nothing new, like ITIL was nothing new either. Both were simply a formal means of describing things that were occurring for many years already upon their release. What ITIL and, to a lesser extent, DevOps does is describe the best practices that are needed to increase the chances of success. You note this "best practices" connection in your article, but I don't think you fully appreciate the value in doing so.
The biggest "problem" here (and I use that term loosely) is that you seem to have little experience working with organizations where the "software development pipeline" is so poorly implemented that it causes more problems than the extra value that Agile is supposed to bring to the organization. (I jokingly call this "frAgile".) I have, however, run into these types of organizations on a high enough frequency that it is scary.
One thing that is clear about DevOps, which was similar in the days when ITIL was initially released in 1988 by the OGC: it is not meant to be a "you must do it this way" process. Instead it is meant to describe ways that application development and operations can work together. The biggest benefit of this is by highlighting what many people like you and me with the appropriate level of experience already know: development is all about writing code while rarely giving the appropriate amount of consideration to quality, while operations is all about ensuring stability in the production environments, meaning they aren't too happy about software releases because that means constant change, which is counter to the concept of ensuring stability.
This is a critical point because although application development organizations are frequently measured by the number of defects, true, getting applications out the door on time trumps everything including software quality. I can recall one such time during my days in application development when development was halted for an entire month so that we (a team of 40+ developers) could all do testing (like a staff aug for the QA group). That sounds great until you realize that we only tested for and fixed severity 1 and 2 defects and ignored severity 3 and 4, which dwarfed the former categories of defects in terms of quantity by an order of magnitude.
So DevOps screams at developers that operations wants stability so they need to make quality a priority. At the same time, it screams at operations that developers are trying to release things quickly to get new business functionality in the hands of the end users. That last point cannot be understated. In March 2014, Gartner told a group of CIOs the following: "CEOs must focus on leading their organizations to think like and become more like ‘tech’ companies, because within a few years, digital business capabilities will dominate every industry. Urgent action is needed because first-mover advantage is common in digital business, and fast followers must be very fast."
To put that more succinctly, "constantly innovate or rapidly become irrelevant."
So DevOps is not only a buzzword but it is, in a very real sense, a "must have" since without this coordation between the two organizations, a company will lack the velocity to do exactly what Mark Raskino at Gartner said in that quote, above. Consider this for a few moments: in May 2011, Amazon was noted as releasing something to production every 12 seconds. One of my customers, Bet365, releases to production every 4 minutes. And when I was at a previous employer, one of our large financial services customers in EMEA had 60,000 production releases every month. This need to scale to massive throughput from development to production is here now, and so the coordination proscribed by the DevOps movement is needed now as well.
I hope this helps.
Kind regards,
Larry
Thank you. What i see happening though in the industry is that devops is taken as a mandate to let developers loose on production environment.
Oleg
Oleg,
Well, that's kinda what I meant by "poorly implemented." That's similar to when people thought (and, unfortunately, frequently still think) that Agile means "release more quickly." In the latter, the part they miss is "release more quickly without incurring more operational risk." (To wit, the official mantra of Agile is to "fail fast" but that ultimately has the goal of allowing an organization to release more quickly with less risk because bugs are identified earlier in the SDLC and fixed there when the amount of effort to remediate is significantly less.)
Organizations that take the word "DevOps" and use that as a shield to justify poor decisions related to operational impact are headed for failure. But that's not the fault of the DevOps movement and is instead the fault of the leadership at the company that allows this to happen.
Kind regards,
Larry
Your comments on this subject are highly encouraged because it's important to have thoughtful discussions about this and how you and your company can reap the greatest benefit from having fully and correctly embraced the DevOps mindset.