Follow
( 4 Followers )
X

Follow

E-mail :

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:

  1. For practitioners by practitioners,
  2. An experience based movement,
  3. Selling of ones wares in this sphere doesn’t work,
  4. 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.