DevOps, like any new technology or tech related movement that comes to the industry, has become a buzzword. Everyone talks about it, not everyone knows what it is all about and worst of all, many of those who claim to do it are doing a terrible job. There are some excellent examples of companies who have excelled and are at the leading edge of the DevOps movement – the often cited Etsy, Facebook and Netflix come to mind. But even here there is contention and debate as to what truly is the best approach to DevOps. Netflix says what they do is NoOps, with developers taking over Ops. Yet others counter that such a situation would lead to anarchy. I am not complaining. Such debate is expected as the industry defines what ‘DevOps’ and evolves different approaches based on each company’s risk-value-needs balance.
Over a series of posts I will explore and document what DevOps is all about; who the key players are; what are the different approaches that are evolving and most importantly, how can one implement DevOps in an Enterprise. As I am genetically incapable of not speaking up and making my opinion heard, I will also share my thoughts on DevOps. (In full disclosure, as IBM is my employer and I am one of the DevOps SME’s in the Rational field organization, I will definitely capture IBM’s DevOps vision.).
Part 1: Defining DevOps
Like anything new, there are as many definitions of DevOps or at least opinions of what DevOps really is, as there are blogs and tech journals out there. There is the perspective of DevOps where the Developer is king, DevOps where continuous testing is the driver, DevOps where it all hinges on the Cloud and you cannot have true DevOps without a Cloud; there is DevOps where DevOps == Continuous Delivery. So, instead of providing my own opinion (there are already too many out there), I am just going to document some good definitions of DevOps I have found and point you to some good source material you can read yourself.
Let’s start with the old standby Wikipedia:
DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and Information Technology(IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.
So, DevOps is the movement to bring Development and Operations closer – communicate and collaborate across Dev and Ops. Development here is inclusive of development and test.
IBM’s Enterprise Collaborative DevOps definition is right in line with this approach:
DevOps – designing processes for coordinating software development teams with IT operations teams.
Let’s reduce the gap that exists between Dev and Ops.
One of the best sources of introductory information on DevOps is a short eBook that O’reilly published recently. In this free eBook titled – What is DevOps? the author Mike Loukides does an outstanding job capturing the current state of DevOps and the ongoing debate on different views. A must read. Here is how Mike explains DevOps:
…modern applications, running in the cloud, still need to be resilient and fault tolerant, still need monitoring, still need to adapt to huge swings in load, etc. But those features, formerly provided by the IT/operations infrastructures, now need to be part of the application, particularly in “platform as a service” environments. Operations doesn’t go away, it becomes part of the development. And rather than envision some sort of uber developer, who understands big data, web performance optimization, application middleware, and fault tolerance in a massively distributed environment, we need operations specialists on the development teams. The infrastructure doesn’t go away – it moves into the code; and the people responsible for the infrastructure, the system administrators and corporate IT groups, evolve so that they can write the code that maintains the infrastructure. Rather than being isolated, they need to cooperate and collaborate with the developers who create the applications. This is the movement informally known as “DevOps.
And I cannot end this post without mention of a t-shirt that I told was seen at the O’reilly Velocity conference this summer:
DevOps – taking the SH out of IT!
Like to learn more about Adopting DevOps? Check out my new book – The DevOps Adoption Playbook.
Update: Adding a video I recorded explaining DevOps:
Related Posts
Understanding DevOps:
- Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
- Understanding DevOps – Part 3: The Battle of Dev vs Ops
- Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
- Understanding DevOps – Part 5: Infrastructure as Code
- Understanding DevOps – Part 6: Continuous Deployment
Adopting DevOps:
- Adopting DevOps – Part I: Begin with the Why
- Adopting DevOps – Part II: The Need for Organizational Change
- Adopting DevOps – Part III: Aligning Dev and Ops Teams
- Adopting DevOps – Part IV: Adopting Continuous Deployment
- Adopting DevOps – Where to start? (Video blog)
- DevOps vs Outsourcing
DevOps books I have written:
Other DevOps Posts:
- What is Water-SCRUM-Fall?
- Leveraging DevOps in a water-SCRUM-fall world
- Monetate’s 12-step program for Continuous Delivery
- The State of DevOps (by PuppetLabs)
- DevOps for Mobile Apps – Slides from IBM Pulse 2013
- Chef for DevOps – An Introduction
Home: sdarchitect.blog 
16 Comments Add yours