DevOps, put simply

posted May 10, 2017 | about 7 minutes to read

I know I’m late to this party, and to be honest, Jon Hendren already said it a lot better than I could ever, but I wanted to write this - at the very least, to cut to the core of the hundreds of DevOps conferences and the thousands of mid-level managers throwing around the term like it’s the new buzzword-equivalent of “synergy”. It’s also a good opportunity to correct some misunderstandings that I’ve seen in the wild about what DevOps is, so that’s nice too.

What DevOps Isn’t

Let’s start with what it’s not, as that, at least in my mind, is the biggest concern off the bat. I’ve had developers pitch DevOps to me as the equivalent of full-stack development, just extended to also the server layer too. This…is not correct. Part of the reason development and operations were separated in the first place - and the entire reason that I’m largely a hobby developer and don’t make it my main job - is because they’re wildly different layers of expertise. Technologies like Chef (more on this soon) or Ansible, sure, yeah, they’re talking about the idea of “architecture/infrastructure as code”, but at the end of the day you still need someone who can effectively secure and optimize a system to be the architect here. I definitely view these tools as things that can make a system architect’s life easier, but in no way can they stand in for a system architect’s skill set. Similarly, you wouldn’t hire a sysadmin to develop a website, even if they dabbled in PHP or whatever - it’s awfully likely that they won’t be able to, say, effectively prevent all possible SQL injection vectors. A developer will, because they’ve spent their career focusing on that.

Similarly, on the support end, it’s probably not a good idea to combine your development and operations support teams. It’s going to be far more efficient, when a problem is presented, to have some kind of log aggregation so that developers can review application logs and sysadmins can review server logs than to have one guy trying to figure out how to fix a part of the stack that really isn’t part of their area of expertise. I’m not saying there won’t be overlap, and I’m not saying that it’s a bad thing to have some knowledge of the application that’s running on your servers as a sysadmin or some knowledge of the underlying server architecture as a developer, but after a certain amount of time in your chosen career path you will necessarily be better at one of these things than the other.

Further, DevOps is not an excuse to make your sysadmins give administrative server access to your developers. This ties back in pretty heavily to the separation-of-concerns argument - the justification, as stated, is that “developers need to be able to get in and make changes quickly”, but at the end of the day this is a recipe for configuration drift and undocumented changes, which is exactly the opposite of what your automation and infrastructure management tools are designed to help you do. You’re going to be much better served by setting up a well defined change management, testing, and deployment process, and then automating the hell out of it - so if something goes wrong, it’s easy to revert through the process, not by making emergency changes to your environment.

What I’m trying to get at here is that it’s easy to subscribe to DevOps as a philosophy, but if you market yourself as a “DevOps Professional” or something similar, the only thing that you should be doing in your day-to-day job is consulting on implementing DevOps, not trying to fill two jobs by yourself.

Whew. Okay.

With that out of the way, let’s talk about what DevOps is, because while I’ve gone on for a while about the negatives, there absolutely is a serious benefit to most companies in implementing a DevOps philosophy.

What DevOps Is

There are two real core principles that define what you need to do if you’re going to embrace DevOps. The first is - put simply - make sure your developers are effectively communicating with your operations folks. This may seem super obvious, and truth be told, that’s probably because it is super obvious. That said, there are a lot of places that don’t implement this well! Building a wall between development and operations had kind of been the way of things for a long time before we started talking about how this works, and it can be hard to change. There are a lot of collaborative tools to make this easier these days - the rise of workplace chat programs like Slack, Mattermost, HipChat, Microsoft Teams, and so forth has been a key driver in being easily able to open a dialogue - it’s a lot easier to reach your ops people if they’re just a chat channel away versus behind a ticket system or in another building.

I should stress, though, that those tools are just that - tools. When I used the word “philosophy” to describe DevOps, I didn’t choose that word lightly. It requires a shift in the way that your ops folks and your developers think about their interactions. There are a lot of horror stories about departmental warfare between developers and operations - how ops might perceive developers as reckless, or developers perceiving operations as holding them back from being able to move forward. Both departments can benefit from some insight into the situations that the other faces. Developers may not be aware that there could be security concerns preventing implementation of some technology, or the operations folks might not understand why a new technology is required for a new application. Even that little bit of communication can go a long way towards getting to that fully open dialogue I touched on earlier.

The second part of DevOps is where we start to delve into the realm of true collaboration and changing the way people do their jobs, and that is “implement CI/CD and/or automate things”. In a lot of the discussions I’ve had with people about DevOps, they like to jump directly to this part of it because it’s the part where you see immediate return - “oh, look, we’ve reworked our deployment process and now we can deploy every time we commit!” That’s great - and it’s certainly the end goal, in a very real sense - but this goes back to what needs to happen in the case of an emergency, if something goes wrong. You have to build up that communication and collaboration between your teams before you go to the extent of implementing something like this, or else you run the risk of finger-pointing and a circular firing squad as soon as your first crisis hits. Sure, automation is a great visible benefit, but behind the scenes, you’re going to gain a lot more from getting your teams working in tandem first and foremost.

So, what’s the big takeaway?

This is always the big question, right? I’ve just thrown a ton of words at you, and there’s gotta be some way to sum it all up and make sense of it, and translate it into easily actionable items that you can take and implement in your own company and make things better. So if I had to pick one thing to say about DevOps, something that you could take away and implement without spending thousands of dollars on meaningless conferences and buzzword-filled talks, it’d be this:

Get your teams to communicate better.

It’s really that simple. The big shiny automation and continuous delivery tools and what have you will come later, once your teams are working on solutions from both ends and not pulling against each other or being purely reactive.