One of the many advertised benefits of DevOps is to increase efficiency and decrease the timeline from production to deployment. At least, that is often the goal; and it’s also one of the cornerstone components of DevOps in our humble opinion.
However, making the transition isn’t always easy. In fact, a lot of companies struggle with this.
In a recent article by Mike Vizard of DevOps.com, he attempts to diagnose and prescribe a solution to these frustrations by suggesting a more consistent approach to tackling DevOps. With the help of some recently conducted surveys,
While we agree that DevOps can transform and level-up a company,
we see DevOps as a set of practices which focus on reliability and repeat-ability. It’s about much more than just consistency.
What is DevOps?
Unfortunately, many people have many different definitions of what DevOps is.
In the article by Mike Vizard, he refers to IT as “increasingly being seen as a team sport.” What exactly does that mean though?
Is it the automation of systems and practices? Is it the Development team and the Operational team forming a more holistic approach to technology? Or is it a product? Can I buy it? Do I have to grow it and tend it like a garden?
Honestly, what is it?
Ideally, DevOps focuses on the end to end value chain of technology. In our opinion, those of us in this field should set our goals toward connecting the dots between the individuals developing the software to those who are operating it daily.
In a perfect world, these people would be as close to, if not the same people, as possible. So we must ask ourselves, is IT a team sport? It really depends on how you’re defining “the team.” Who’s on it?
If your team only consists of developers and operations, sure… It’s a team sport. If you want a team of only forwards and goalies, that is. But this takes the notion of DevOps and whittles it down into the notion that DevOps is, and only is, a tech concern.
Leave it to the developers and the operations folks. They’ll take care of it and figure it out. Leave it to the programmers and the engineers. Let them work together.
Sure, that’s a team. However, we can’t just end there and expect this holistic approach to development to operations loop to be complete.
Far from it.
An Alternative View
We think that companies must/should think of DevOps in a broader sense to ensure that the individuals on this team are assisting with the entire life cycle of the product. And that means the “team” could (and we would say should) consist of more than just your IT department. That could consist of everything from development and operations; to business and other roles that need considering.
To square it further with the sports analogy, a “team” really consists of far more people than who you see on the field. Sure, the players are the focus. However, there are also managers and coaches. Training staff and grounds crew. Personnel directors and human resources. Marketing and advertising and operations and, well, the list goes on.
When all of these elements come together, you get a broader, more inclusive view of what truly makes up “the team.”
DevOps presents tremendous opportunities for organizations. There’s no question about it. However, to distill it down to, “how do we manage a production environment in a more clever manner” neuters this opportunity. It, again, makes this a tech problem rather than an organizational-wide initiative to implement a more efficient culture.
Just Checking Boxes Won’t Work
The underlying problem with companies trying to implement DevOps is assuming that just because you buy the tools and check the boxes, you are getting the benefits. It’s a shiny new toy. It’s high-tech. Of course it works.
And it does work. But, and here’s the important question that often isn’t asked: does it help? Too often, the question is “are we using it properly?” Or, “are we getting the most we can out of this?” Sometimes it’s even “why isn’t this working better? And too often the assumption is made that well, maybe we’re just not using it correctly.
To be clear, these are all fine questions, sure. But the underlying principal here is that not every shiny new toy needs to be purchased and in this case, not every tool needs to be implemented simply because it’s there.
Unfortunately, by doing this without making the necessary changes to leverage the system, companies are most likely causing more confusion and chaos.
“Change, of course, comes hard to any IT organization. It may take IT organizations years after acquiring new tools to define their processes.”
Mike Vizard, DevOps.com
Do We Have Years?
While we agree that changes can take years, we don’t believe it has to. And in the rapidly changing world of DevOps, IT, and tech in general: it probably shouldn’t. Drawing out and prolonging the transition to efficient DevOps processes is an implicit decision that in our opinion is born out of resistance to change.
Therefore, this a human problem. Not a technology problem. The solution isn’t more consistency, the solution is more decisive action that can yield the results you’re seeking.
Many in the DevOps field are attempting to push the most available bits of these processes into organizations, in an attempt to help these organizations level-up. This is a fine goal, but maybe a more radical change is needed.
Avoid Change for the Sake of Change
Is a consistent and “evolutionary approach” to DevOps really what is needed? DevOps presents an opportunity to revolutionize the tech industry, and for that to happen, we must consider taking an approach that has no sacred cows.
As we begin to evaluate the entire DevOps landscape, we notice that the whole concept of DevOps implementation is being distilled down and chipped away to make it “less scary.”
As humans, we find comfort in doing things that we find, well, comfortable. Until a few brave companies can come along and take up the banner for DevOps, we won’t see what its truly capable of doing.
Clearly, this is a cyclical trend we’ve seen many times before with many different types of technology. Initially, it’s terrifying, so many organizations dabble and get their feet wet until someone brave enough comes along and shows everyone else what’s possible.
We know how quickly technology evolves and the continuous learning required to keep up with it. Until humans can curb their instincts to be so “human,” the technology we create will be limited by our resistance to change.
Consistency can be a great thing. In baseball, you want a patient, consistent hitter.. But it can also be a curse as complacency sets in. True change and innovation is rarely brought about by those who “dare” to be consistent and complacent.