Imagine you're ill and you go to a doctor. But instead of letting her examine you, you start to tell her how she should do it, what tools should she use, what medical diagnosis should she give you.
Sounds ridiculous, doesn't it?
Actually, this is exactly the same kind of behavior many software developers nowadays present towards system administrators.
I have a long track record as a SysOp, so I remember the days before DevOps. It wasn't like that; developers were doing their job and relying on system administrators to do their own. There was trust and respect. Going both ways. Unfortunately after some time came the new generation of programmers - young, rebellious, arrogant even. But I don't blame DevOps, it's just a notion, by itself causes no action.
This is a buzzword really. People are fascinated with it since it looks like it brings something new, fresh. A very good writeup on what DevOps is meant to be was done by Klint Finley in his article
Personally I've never met two people having the same understanding of what DevOps is. For me it's a work methodology in which Devs and Ops operate together to achive a common goal, but doing that they remain separete and work in their own ways that are specific to them. This is how I remember my work as a sysadmin even before the birth of DevOps notion.
But nowadays what I see more and more is another interpretation in which DevOps stands more for a position description than for a methodology name. "DevOps guy" or even "DevOps" without any noun is a holy grail, someone to bow year head before, with skills ranging from coding through testing to system administration. And since this kind of thinking is getting quite popular there's a lot of usurpatory DevOps' being in fact Devs with the mission of telling Ops how they think we should do our job. Plague.
I have never come across an Op telling a Dev how to do coding, but as an Op I constantly have to face Devs telling me, how I should do systems administration.
This is wrong. Our worlds are different, there should be a clear line of communication between them and a constant exchange of thoughts should be going on, but it's impossible to make us into one position, to fit Devs and Ops into the same mindset. Usually when Devs are creating tickets for Ops or want us to do something, they don't tell us what they need but instead state what in their opinion should be done. Instead of describing the goal they describe the process. This is the total opposite of effective communication! Most requests formed this way are incomprehensible for Ops because ways of doing things differ a lot between us and Devs and when an Op sees Dev's way of doing some system administration task he usually shakes his head in disbelief and asks "Why...?!".
It's like Devs do not believe in our skills, it's like they think they know better, it's like we're there only to type what the Dev dictates us. Come on, you have your own keyboards, if you think you can do stuff better than us just go and do it yourselves. Or even better - actually apply for our jobs!
Just recently I "learned" from a Dev that bash scripts are bad, because... they're written in bash. Well, of course, for a complex script a proper interpreted language like perl would be a better choice, but the Dev was referring to a script written by a system administrator to automate system administration task. And the icing on the cake is that the Dev on a daily basis does his programming in... php. The point is that the decision how to do the job should be in the hands of person doing it, especially if the person is in a senior position. Advise is of course welcome, but not in the form of "I'm a Dev so I know better how to do programming". Any discussion how to do system administration tasks can only take place between system administrators.
Basically it doesn't make sense at all to hire smart people and then tell them what to do. You hire smart people so they can tell you what to do. That's actually a quote, but I don't remember by whom.
It doesn't matter that a Dev would do the script in a different way - we are capable of choosing our tools of trade, we have the skills to use them, we should be trusted with our tasks. Sometimes I get the feeling that Devs think that sysadmins are "just" Ops because they weren't good enough to become programmers. Actually we love what we do. Most of sysadmins that I know do not dream about becoming Devs and yet it seems like Devs think they should educate us and force their work methodology on us. Go away.
The more senior I get in my role as an Op the more I find myself listening. I guess that's natural, discussion and listening as a part of it becomes pretty important when you're expected to design highly available environment or automate a complex task. I'm open to new ideas, new tools. But to actually be able to do my job well I need the ability to choose myself. Brain storms are suppose to help, not to force something on you.
There's a reason why there are Devs and there are Ops. There's a reason why we work in different ways. There's a reason why this shouldn't change.
The main difference is probably that Devs get things done while Ops get things right. Of course it's totally possible to get things done and right at the same time, but we all know how it is with deadlines and this kind of stuff. Yes, agile approach proabably changed the landscape a lot, but in the end it's all about the mindset.
Why bother with FHS when you can just drop an app in
/home, who cares if you're using public addresses in your private network, why should you compress old log files and delete old docker images when you can just add more storage? Tracking down memory leaks? Mate, just increase RAM. Code refactoring? Haha, create another EC2 instance instead! This is getting things done. This is exactly why we shake our heads in disbelief.
Ops do not treat environments as playgroud where you can have fun, rather like a garden that you have to take care of. Ops do not play with each and every new toy, rather they use proven tools that they know and trust. We are meticulous. We care about details. We do a lot of things that may seem like l'art pour l'art, but they're not. It may look like we do not get many things done or that we're sometimes slow, but it's because we actually care about doing stuff the proper way, about getting things right.
Someone has to push the envelope and it's okay to do that. But someone also has to guard your apps from downtimes. I often see those self-proclaimed DevOps' declaring live, production environments their playgrounds and playing with their toys there. This is exactly why Ops are here - to tell you that putting into production a technology that came online like 2 weeks ago isn't really the best idea. And to not add your public key to root's
There's a lot talk right now going on about agile operations. This is closely related to what I'm trying to explain here, but I'll do another article on that.
I once attended a company meeting where our cheif IT security officer talked about how we should take care of our data, how we should adhere to IT security policies. And few minutes after the talk I overhead a group of most senior developers in the company chatting how they do exactly the stuff that he told them not to do on a daily basis. I might have understood if that was junior stuff, but they weren't. It's really frightening how sometimes Devs can despise us, the "hard IT" guys.
So to answer the question - the main thing that's wrong with DevOps from an Op's perspective are Devs thinking they can do Ops' job and telling Ops how they should do it.
All that being said I understand perfectly that we need each other. Systems would be useless without the applications and applications couldn't run without systems. We need to cooperate to achieve the common goal which is to deliver better experience to the end users. It would be really nice though if the effort wouldn't always be only on one side. It would be perfect if we - Ops - could do our jobs without constant hovering and commentary provided by Devs.
If you like this article please consider sharing it with your friends.