I recently did a deep dive into DevOps to create a DevOps Foundation training. I thought it would be an uneventful journey, but while doing some research to complement my own experience I uncovered something much bigger than what I was prepared for. As if there suddenly was this major unavoidable thing popping up in front of me (“this is no moon, this is …a space station!”).
It’s only common sense!?
Having worked with agile for quite a while, my view on DevOps was basically this: DevOps is about delivering the right service/product by shortening and improving the communication channels and feedback loops between the different units, teams and specialists in a value stream. In other words, e.g. “Infra” and “sec” must be involved from the start, operations engineers have as much excellent input from day one than any other application engineer and everyone must be involved to maintain and evolve the service/product.
Wake up! There is more a Stake here!
While this is true, what really surprised me was how much deeper the DevOps movement goes: DevOps is far more than an alternative mindset, it really encompasses the work culture you must adopt if you want to be successful in the cloud. And, as there is a cloud in your future (whether you like it or not), it means that you will be working with DevOps or you will not work at all!
This is how I see it: DevOps is the re-writing of the IT services development and maintenance handbooks so that the services can be fit for the cloud.
This is worth looking further into, so let me elaborate on that a moment.
From the Enterprise to the Cloud
To understand what is happening, I strongly recommend you watch Mary Poppendieck´s fantastic talk “The Future of Software Development” (Berlin’s GoTo Conference, November 2016). She summarizes the evolution of our industry from “the Enterprise” model (golden age in the 90’s) to Internet/“the Cloud”. Mary is always excellent, but this must be the most insightful talk I have seen about our industry, by large, go and watch it now! I have created two figures that try to summarize some of her key points (directly extracted from Aim 4 Knowledge’s “DevOps Foundation”).
Figure 1: the forces pushing for the cloud (click for larger)
Figure 2: DevOps as a reaction to these forces (click for larger)
These two figures summarize the forces behind the emergence of DevOps (Why DevOps?), and the DevOps main components as a result (Infrastructure as code, Micro Services, Cross-functional teams, automation, feedback, continuous delivery and resilience engineering).
In Figure 2 you only see the result (DevOps emerging), but it is interesting to understand how it came to be: the real engine of transformation has been the survival instincts of the people in Dev and Ops. The existing development and maintenance handbooks (ITIL, PM body of knowledge, etc.) were fit for the Enterprise model and cannot cope with the level of scaling, complexity, and speed needed in the cloud. This made it unsustainable for the people tasked to develop and maintain these services. Quite bluntly, they had to adapt and re-invent the handbooks or quit (utterly dejected in the process). So, they pulled in everything that could help: agile, lean, automation, modern management methods, etc. The result is an adapted handbook, and its appropriate culture, that is “fit for purpose” (effective and sustainable) for the cloud. We call it “DevOps”.
Wait, should I throw out everything I’ve learned because it is not fit for the Cloud?
Well, yes and no! I believe that the way the practices and taught and communicated are more at fault than their essence. Take for example the ITIL. The way ITIL is described, taught and implemented is very much anchored in the Enterprise model. Control is established by having many loosely-coupled processes, slow by design, implemented by-the-letter in silos. It is not surprising then that the very people that should be helped by these processes are the first to reject them once scale, speed and complexity are cranked up. Therefore, ITIL is proven to “not work” with DevOps. Well, on the contrary, we need it more than ever! But it should be reformed, adapted to better fit this new context we are rushing headlong into. We must change the way it is described, taught and implemented. Thankfully, there are efforts to make this happen, for example with Gene Kim staunchly defending ITIL for DevOps, or Pelle Råstock with his lightweight and service-centered TRIM model.
Re-write your own Handbook, Now!
Go and learn what DevOps is about, for real. Don’t go for tool vendor X’s “we have you covered” sales pitch. DevOps is much more than tools: it is about re-writing your service/product creation and maintenance handbooks. This requires new practices that are fit for the cloud. These require new ways of thinking and new mindsets: a new culture! As you can imagine this will take some time.
As everything accelerates, my advice to you is: start now!
One response on “Explaining the DevOps Hype”