This is post is a little rant, about the IT industry and how we grab onto the coat tails of terms and play buzz word bingo with job boards. The latest term that has me mildly annoyed is the term DevOps Engineer!
There is no such thing as a DevOps engineer. DevOps is a cultural change in attitude so shared ownership and collaboration are the common working practices in building and managing a service.
The culture change is especially important for established organisations.
DevOps is not a team or a person thing. It’s not something you can just inject into an organisation and overnight your organisation moves from being broken to fixed!
There is no such thing as a DevOps swat team, driving around in a black and red van and if you have a problem, if no one else can help , and if you can find them, maybe you can hire the DevOps team.
Transforming an organisation and implementing DevOps practices takes a lot more than parachuting is some guy who has skills in Puppet, Chef, ansible , docker or any other verb that became a tool.
Your organisation won’t be saved by a terminal wonder kid in a hoody churning awesome BASH scripts during his lunch break.
Changing your department names form Software Development and IT operations and moving them to a co-located zone with a pool & Ping Pong tables, open plan kitchen and bean bags and then calling them DevOps is not really going to make your customers any happier.
Your customers really don’t care about that fact, that your staff now look more like Canadian Loggers than they do log consuming coding units!
The truth is DevOps is about a lot more than just changing your build server, source control repositories and configuration management tools.
These tools may be a feature of DevOps but have nothing to do with the benefits. They solve a particular issues, but in reality your organisation may not be directly suffering from those issues, and the cause of your issues are manifested elsewhere.
It is the old adage that data counts. After all you can’t manage, what you can’t measure and your first step on the DevOps trail is about collecting data, and analysing your current working practices.
I’ve had issues in the past the rising popularity of bizaar job descriptions. A couple of these examples are Agile Developer , to me this paints a picture of some guy coding while seated in a lotus pose, snacking on Fava Beans and Wheatgrass smoothies!.
I don’t think it necessarily described a developer who knew a little about TDD and Stand Up meetings. The other term was Rockstar Developer, why would an organisation want to employ somebody who throws TV’s out of hotel rooms and die of a drug overdose in his mid 20’s!
Job descriptions on the Job Boards for the mythical DevOps engineer, primarily detail the skillsets of build and automation engineers, and nothing what so ever about transforming organisations to work adotping frictionless working practices.
In fact the majority of the job posts I read seemed to require nothing more than Linux, Security and Build with some exposure to working in Agile teams.
Jobs for DevOps engineers are nothing more than a sign that the industry has yet again adopted some cool buzzword and appended it to other keywords and now we have a whole new name for something! It now seems to describe something thats cool and hot, unfortunately in reality it doesn’t exist. The industry is still searching for the WordPress Ninja and the C++ Samurai!
What worries me most is that the DevOps engineers are required to work in the DevOps team! I don’t even know what a DevOps team is!
If an organisation has a DevOps team, comprised of DevOps engineers then what has happened to the multi discipline aspect of what DevOps is supposed to encompass?
If an organisation has actually implemented such a concept as a DevOps team, effectively all they would’ve done, is effectively renamed the IT Operations department to some more cooler and down with kids term! However, I fear that the organisation is still pretty much engaged in a game of over-the-fence-tossing!
It is human nature to attempt to compartmentalise things and organisations are built on the notion that we should box people into units or functions of work. Organisations are carved up into functional units of work, and managed by functional units of management.
It is due to the compartmentalisation of organisations that we believe work can easily be carved up into discrete packages and passed through production line process, whereby discrete units of work are passed between each functional unit. It may not be a perfect process, but in some respects, tends to work (pun not intended)
It is commonly believed that by following a process that we don’t need to communicate. It is that concept that brings about the problems. The major problem that DevOps ideology attempts to address is the breakdown of communication in organisations.
This all seemingly falls in place, until the organisation seeks to engage in project work. Project work in organisations is tough and one of the biggest challenges is that of finding and assigning adequate resources. Often projects maybe innovative in nature, and may revolve around the implementation of new services or products.
Organisations will often, try to use existing resources from various departments, and mix them into a project team. Project team members will be told that they are to rid themselves of their normal day to day business activities and their core focus over a period of time will be nothing but the project work!
The downside to this is that usually these team members maybe subject matter experts in particular business areas and maybe the defacto points of contact. Developers tend to fall into this catergory, usually because they may have been ones the develop the initial application. Database Administrators too, due to their role, as the name suggest is to Administrate the various databases.
IT operations guys maybe the defacto points of contact for networking related issues, due in part that they on a daily basis troubleshoot issues.
In fact instead of me droning on it’s probably a better choice to read The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win.
Although, a fictional tale, it describes situations I have all too often witnessed in organisations during my career as a freelance software developer.
So the long and the short of it is, sorting out the continuous delivery aspect of your project, is a very small component of what DevOps addresses. There is no one specific role required. DevOps is a collective sense of purpose of your project team.
DevOps is a belief, shared ideology and a cultural change which is at the core of an organisation. Just because some individual knows something about Puppet and Chef and can write Bash scripts to make coffee, does not necessarily make the DevOps Experts. They are IT automation professionals who may form part of the collective sense of purpose that the organisation aspires too.
The ideal DevOps implementation will include the integrations and collaboration of a number different resources. There is no magic tool, formula or wand waving wizard can fix it.
DevOps is about ensuring all friction points are eliminated, communication is clear, concise and open. This can only be done by ensuring you have a smooth flow data and clear interaction points. There are 4 Key Components of DevOps:
- Cross-functional team
- widely shared metrics
- Regular releases
Stop calling yourself or even refer to individuals as DevOps engineers. There is no such thing. If you need some sort of title or need some kind of title to identify your role call yourself Millenial Falcon Engineer , it sounds cooler and most people will be really impressed, while at the same time have no real idea of what you actually do!
A unique background as business owner, marketing, software development and business development ensures that he can offer the optimum business consultancy services across a wide spectrum of business challenges.
Latest posts by Gary Woodfine (see all)
- Happy 4th Blog Birthday – A blogging year in review - Dec 6, 2018
- Getting started with .NET Core and the Serverless Framework - Dec 3, 2018
- How to use the Abstract Factory design pattern in C# - Nov 18, 2018