Archive for February, 2017

Not DevOps

I am seeing around me that lots of people have a serious misconception about what is DevOps and what it is actually not. So today let us try to figure out what is not DevOps.

Not NoOps

It is not “They are taking our jobs!”  Some folks think that DevOps means that developers are taking over operations and doing it themselves.  Part of that is true and part of it is not.

It is a misconception that DevOps is coming from the development side of the house to wipe out operations – DevOps, and its antecedents in agile operations, are being initiated out of operations teams more often than not.  This is because operations folks have realized that our existing principles, processes, and practices have not kept pace with what is needed for success.  As businesses and development teams need more agility as the business climate becomes more fast paced, we have often been providing less as we try to solve our problems with more rigidity, and we need a fundamental reorientation to be able to provide systems infrastructure in an effective manner.

Now, as we realize some parts of operations need to be automated, that means that either we ops people do some automation development, or developers are writing “operations” code, or both.  That is scary to some but is part of the value of the overall collaborative approach. All the successful teams I have come across have both people with deep dev skill sets and deep ops skill sets working together to create a better overall product. And I have yet to see anyone automate themselves out of a job in high tech – as lower level concerns become more automated, technically skilled staff start solving the higher value problems up one level.

Not (Just) Tools

DevOps is also not simply implementing a set of tools.  One reason why I feel that a more commonly accepted definition of DevOps is needed is that having various confusing and poorly structured definitions increases the risk that people will pass by the “theory” and implement the processes or tools of DevOps without the principles in mind, which is definitely an anti-pattern. Automation is just the exercise of power, and unwise automation can do as much damage as wise automation can bring benefit.

Similarly, Agile practitioners would tell you that just starting to work in iterations or adopting other specific practices without initiating meaningful collaboration is likely to not work out real well. Sure, a tool can be useful in Agile (or DevOps), but if you do not know how to use it then it is like giving an assault weapon to an untrained person.

But in the end, fretting about “Tools should not be called DevOps” is misplaced. Is poker planning “Agile” in the sense that doing it magically gets you Agile?  No.  But it is a common tool used in various agile methodologies, so calling it an “Agile Tool” is appropriate. Similarly, just because DevOps is not just a sum of the tools does not mean that tools specifically designed to run systems in accordance with a DevOps mindset are not valuable.

Not (Just) Culture

Many people insist that DevOps “Is just Culture” and you cannot apply the word to a given principle or practice, but I feel like this is overblown and incorrect. Agile has not helped thousands of dev shops because the work on it stopped at “Culture,” with admonitions to hug coworkers and the lead practitioners that identified the best practices simply declaring it was all self-evident and refusing to be any more prescriptive. We might be able to figure out all those best practices ourselves given the cultural direction and lots of time to experiment, but sharing information is why we have the Internet.

Not (Just) Devs and Ops

In the end, it’s not exclusionary.  Some people have complained “What about security people!  And network admins!  Why leave us out!?!”  The point is that all the participants in creating a product or system should collaborate from the beginning – business folks of various stripes, developers of various stripes, and operations folks of various stripes, and all this includes security, network, and whoever else.  There are a lot of different kinds of business and developer stakeholders as well; just because everyone does not get a specific call-out (“Don’t forget the icon designers!”) does not mean that they are not included. The original agile development guys were mostly thinking about “biz + dev” collaboration, and DevOps is pointing out issues and solutions around “dev + ops” collaboration, but the mature result of all this is “Everyone Collaborating”. In that sense, DevOps is just a major step for one discipline to join in on the overall culture of agile collaboration that should involve all disciplines in an organization. So whoever is participating in the delivery of the software or service is part of DevOps.

Not (Just) A Job Title

Simply taking an existing ops team and calling them “The DevOps Team” does not actually help anything by itself; neither does changing a job title to “DevOps Engineer.” If you do not adopt the values and principles above, which require change at an overall system level not simply within a given team, you would not get all the benefits.

However, I am not in the camp that rails that you cannot have DevOps in a job title. It is often used in a job title as a way to distinguish “New style DevOps-thinking, Automation-first, Dev-collaborating, CI-running, System Admin etc.” from “grouchy back room person who aggressively does not care what your company does for a living.” Some people find value in that, others do not, and that is fine.

Not Everything

Sometimes, DevOps people get carried away and make grandiose claims that DevOps is about “Everything Everywhere!” Since DevOps plugs into the overall structure of a lot of lean and agile thinking, and there are opportunities for that kind of collaboration throughout an organization, it is nice to see all the parallels, but going and reengineering your business processes is not really DevOps per se.  It is part of an overall, hopefully collaborative and agile corporate culture, but DevOps is specifically about how operations plugs into that.  Some folks overreach and end up turning DevOps into a super watered down version of Lean, Agile, or just love for everyone. Which is great at the vision level, but as you march down the hierarchy of granularity, you end up mostly dealing with operational integration – other efforts are worrying about the other parts. But there are still a lot of unsolved problems around the delivery of software and maintenance of services and making it fast, reliable, secure, et al. – if someone wants to use what they have learned from DevOps to go be a larger scope corporate consultant that is fine, but most people involved in DevOps are technical practitioners who are looking for better ways to do their job, not someone else’s.  In Agile there is “Agile Software Development” and then there is the larger Agile organization work. I think DevOps is best defined as “Agile Software Delivery and Operations,” which should similarly work in concert with others working on larger organizational initiatives, but without losing sight of its primary value proposition for the organization.


Read Full Post »