Follow
DevOps is a development methodology that was born out of the need for increased collaboration between development and operations. Second to this, the view was to incorporate Agile operations into development and operations themselves in order to create a continuous cycle of development, testing, automated release build and deploy methods to ramp up product delivery and increase reliability in the code being deployed.
The life cycle flow is a continuous flow as follows: Plan>Code>Build>Test>Release>Deploy>Operate>Monitor, back to Plan – as seen in the infographic.
If one had to truly implement this development methodology, it is said, due to the elements of iterative design and approach, to dramatically increase code output that is of a far higher quality. Furthermore the view is expressed that one could recover from a critical failure more than 50 times faster than those who do not follow the DevOps development methodology.
So where did this term DevOps come from exactly?
The term DevOps was first coined by Patrick Debois in October 2009 when he was unable to attend a specific talk at the O’Reilly Velocity June 2009 conference given by John Allspaw and Paul Hammond named 10 Deploys a Day: Dev and Ops Cooperation at Flickr.
On posting a tweet stating that he could not make the conference, he had responses stating why did he not organise his own Velocity event in Belgium where he was based. In turn that is what Patrick did and coined the name DevOpsDays. Patrick also liked the analogy of DoD which he referred to as Dead on Delivery and felt the name apt for use.
Later on in a live InfoQ video interview in 2012 he stated the first name he had in mind ‘Agile System Administration’ was just too long and felt it did not portray what he was thinking of and picked the words dev and ops from the areas he knew had to work together to create the foundation and noted that the conference was over a few days – hence DevOpsDays – not realising that this was going to be the word forever going forward. The event happened on October 31st 2009 and people came from across the globe to attend this first event which was pleasantly surprising for Patrick. This conversation carried on on twitter under the handle DevOpsDays – which was eventually shortened to what it is today as #DevOps. Since that first conference in 2009, many advocates for the trend went out to start their own DevOpsDays – starting in Australia and then the USA (see graphical representation in this blog), in turn the word has spread on this new Development methodology that is out there to increase productivity.
It is important to note that this is a grass roots movement and growing from practitioners promoting this movement in their own free time. This ultimately spoke to legacy tools and the issues practitioners had with them who then built and formalised their own tools.
This is evident in the names given to such tools, which I personally believe is ground breaking and entrepreneurial, such as Puppet, Vagrant, Chef, Juju, FPM – if you google what FPM stands for you will understand the view on how frustrated teams were with the legacy tool-sets they had available that drove them to create their own nimble tools, fit for purpose.
So what does this exciting aspect of practitioners taking on enterprise tool-sets translate to for you?
Well – as a practice built from the ground up it is one that is:
- For practitioners by practitioners,
- An experience based movement,
- Selling of ones wares in this sphere doesn’t work,
- Decentralised and open to all.
How powerful is that thought that you are in the hands of people that are passionate about making things work together as a crowd of practitioners, and I use the word crowd as the more i read the more I come to believe this is like crowd sourcing and control of who plays in this sphere – and as long as you are a true practitioner you are in. The blogs are active out there and practitioners eagerly await to help and they have dealt with all problems we have as organisations and solved the majority of them too in their contexts!
A useful background from Pinterest is below:
The mainstream vendors started to get involved about 16 months post the 2009 conference however I believe this was due to an influencer being Gartner forcing the tipping point when a well known research analyst, Cameron Haight in March 2011 added a slide which effectively stated to all big organisations at the Gartner conference that this concept of Devops is coming to enterprise and you best be aware of what it is already doing to organisations. Using words as niche to mainstream i believe was a clincher.
The slide he slipped into his deck referenced below:
Large vendors are now well involved and providing good solutions – and this can be seen in the Garnter Magic Quadrant view in the Information Systems fashions – Justifying the trend post.
So where does this leave us now?
Well DevOps is a rather new concept and many people have differing definitions for what DevOps truly is.
If we look at Gartner – The Science DevOps Decoded, they define DevOps as follows: “Gartner defines DevOps as a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.” Whilst academical definitions provided in a research papers have some interesting definitions to note.
Gottensheim 2015 refers “DevOps aligns business requirements with IT performance, with the goal of adopting practices that allow a quick flow of changes to a production environment while maintaining a high level of stability, reliability and performance in these systems.” The paper then goes on to state that DevOps is not a standard or tool but about “enabling communication and collaboration between departments.”
Roche 2013 speaks to DevOps as “DevOps isn’t really a job in that you don’t hire a DevOp per se but rather that the spirit of DevOps speaks to an emerging need in the modern software development and support landscape.”
Dyck et al. 2015 notes DevOps as “an organisational approach that stresses empathy and cross-functional collaboration within and between teams – especially development and IT operations.”
The best view I have found thus far in my opinion was a formal systemic literature review paper which brings all these differing definitions together adequately – ACM, 2016, Jabbari, Ali, Petersen, Tanveer What is DevOps? A Systematic Mapping Study on Definitions and Practices, defined DevOps as “A development methodology aimed at bridging the gap between Development and Operations, emphasizing communication and collaboration, continuous integration, quality assurance and delivery with automated deployment utilizing a set of development practices.”
Noting there are commonalities in these definitions being the increase in collaboration needed in bringing the two key areas of effective development together being development and operations. The Gartner definition starts to scratch the surface on the people and culture implied to have to make the development methodology work and in the implications for practice thread in this blog you will see how Gartner have developed frameworks to help understand all areas needing change in order to effectively embrace DevOps.
References:
- Gottesheim, W., 2015. Challenges, Benefits and Best Practices of Performance Focused DevOps. ACM 2015 978-1-45-3-3337-5/15/02.
- Roche, J., 2013. Adopting DevOps Practices in Quality Assurance. ACM 2013 1542-7730/13/0900.
- Dyck, A., Penners, R. and Lichter, H. 2015. Towards Definitions for Release Engineering and DevOps. ACM 978-1-4673-7070-7-2015.
- Jabbari, R. and Tanveer, B., 2016. What is DevOps? A Systematic Mapping Study on Definitions and Practices. ACM ISBN 978-1-4503-4134-9/15/05.
Interesting how the definitions differ. When was the term first used? Are there any papers that examine and compare different definitions?
The term DevOps was first coined by Patrick Debois in October 2009 when he was unable to attend a specific talk at the O’Reilly Velocity June 2009 conference given by John Allspaw and Paul Hammond named 10 deploys a day: Dev and Ops Cooperation. On posting a tweet stating that he could not make the conference, he had responses stating why did he not organise his own Velocity event in Belgium where he was based. In turn that is what Patrick did and coined the name DevOpsDays. Later on in a live InfoQ video interview in 2012 he stated the… Read more »
There are definately different views on how DevOps is defined by way of variations on what makes up DevOps. Some tend to focus more on the team aspects needed whilst others focus on the core original makeup of Dev and Ops. From an academic paper point of view the best paper I have noted around the various definitions thus far is from ACM, 2016, Jabbari, Ali, Petersen, Tanveer What is DevOps? A more practitioners view on the definition and its complexities can be found in an article from an interview held with the founder Patrick Debois: http://www.computerworld.com.au/article/533986/devops_definitions/
It looks like it continues forever. When does it stop for system review and audit?
Valid question Musa. In this aspect the system review by way of maintenance if i am understanding you correctly would be built in as part of the quality continuous automation. If indeed a need for a maintenance sprint is identified it would be done as such, in the normal flow. The importance in what i have read is that DevOps you build in security and quality to mitigate rework, maintenance sprints. In terms of audit – that would more than likely follow a traditional approach and time would have to be built in for teams to assist in this. It… Read more »
Dev Ops sounds like a new way of looking at the Agile Methodology. What are the key differences?
Hi Andrew
With increased competition in the market place, it makes sense to adopt the DevOps philosophy. I see this trend taking off.
Does the process of Plan>Code>Build>Test>Release>Deploy>Operate>Monitor, back to Plan usually follow all the way through? In practice, does it happen often that planning, coding, building and testing takes place but than the need to return planning becomes important?
Hi Thobeka – I believe your view is accurate in that the principle of fail fast and learn faster applies to DevOps – meaning that if you fail in coding or the build cycle you do go back to the previous steps and refocus and redevelop. The push in DevOps is that due to the continuous cycle and approach at each phase that you in turn close down on the feedback loop – so you bring the re planning, re-coding elements down due to far more increased feedback with the Ops, business teams and get to a point of being… Read more »
My view on this often asked and very good question – especially one to be prepared for when acquiring C-level and team buy-in – is as follows: Agile development is an element of DevOps in that DevOps formed from Agile as a base. The difference in my way of explaining this question when asked is on the views/lenses applied in the methods. So Agile has a great cycle of planning sprint 0’s and actively coming together as a development and IT team to work out stories and epics and break these work pieces down further into actual deliveries – all… Read more »