Intro to DevOps for the Uninitiated
Those of you who know me professionally probably know that I’m a fan of DevOps. I dislike process for the sake a process and hate having to fight with gatekeepers in order to get my work done. Give me tools that work, processes that keep me productive, and the ability to deploy code I wrote (and tested) 5 minutes ago with fast feedback cycles. Do this and I am happy, don’t do this and I am sad.
What is dev ops and how does it differ from what a sysadmin traditionally does (e.g. provision and keep everything running)? — Jim Keener
Recently this question came up in an IRC channel which I frequent. At first I discarded it as a comment from an “old school sysadmin” who didn’t get it, but then I looked at the user’s handle and realized this was from a smart developer who has some pretty insightful views on technology.
I was a bit dumbfounded. Sure, a few years ago terms like DevOps were just as hipster (I hate that word to describe technology) as “Developing my software ecosystem using Node.JS with Mongo DB on a set of Heroku dynos”, but that feels like ancient history. DevOps is well established, proven to work, and well accepted! Or maybe we’re all wrong because many of us surround ourselves with others who have bought into this mindset.
I reflected on this question for awhile. I thought about the core goals of DevOps, how learning about this mindset influenced my life as a software developer, and how some of my friends have misinterpreted the ideas as being unnecessary or useless.
DevOps Makes People Better, It Doesn’t Replace Them
I feel like a lot of places view [DevOps] as a way to get rid of the ops roles. — Jim Keener
As the conversation continued, the following comment was brought up and it really made me think. I was worried that the DevOps movement was seen as a way to force (sub-standard) cross specialization and reduce overall staff. Some of my friends have worked in *ahem* less than stellar tech shops, and have expressed some significant frustration around “DevOps done wrong”.
The so called “DevOps Team” at my workplace mostly deals with provisioning Windows workstations. — Anonymous
No hate on people who work in Windows but… wat.
We have a pseudo DevOps team but they mostly write J2EE applications with Oracle databases. Server and storage provisioning still go through IT.— Anonymous
Again, I have nothing against these technologies but comments like this make my head hurt.
After getting back from a conference my manager is all about “the DevOps”. She bought us a Slack account and now all code changes have to go through PRs on Github. — Anonymous
I can’t even…
A company shouldn’t view DevOps as a way avoid hiring quality sysadmins, and force system maintenance and upkeep upon unsuspecting developers. I know myself well enough to admit that you definitely don’t want me setting up your servers. Sure I may do an minimally acceptable job but the cracks will show very quick. I’m no sysadmin but that doesn’t mean I don’t buy into DevOps.
DevOps isn’t about turning developers into sysadmins, nor is it about turning sysadmins into developers, it’s not a job title, it’s not a department. Get those thoughts out of your head now! Simply saying “We do DevOps” doesn’t instantly make it true. It is about increased collaboration, degrees of cross training, and improved productivity. Sure following it will eventually reduce costs but they should come from time/resource savings, not reduced staffing.
DevOps is a Mindset, Not a Job Title
Nobody in your company should be a “DevOps Engineer”. If this person exists (or you are this person) then a misunderstanding of the concept has taken place. Subscribing to the mindset is like subscribing to the mindset of Environmentalism. Yes it is a part of you but odds are it isn’t your job title.
DevOps (a clipped compound of “development” and “operations”) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably.
— Wikipedia https://en.wikipedia.org/wiki/DevOps
DevOps is a response to the rapidly changing landscape of Software Development. Gone are the days of the waterfall model, where releases are planned in spans of months or years. These days we have hundreds of releases every single day, so many that our users usually don’t even know they occurred. Since things are moving so fast we can’t rely on many manual processes to accomplish our day to day work. Sure some of these things feel counter-intuitive at first but ultimately they lead to high quality and stable software.
DevOps also gets into build automation things like continuous integration, continuous deployment, and artifact management. — Colin Dean
We need automation, we need tooling, we need collaboration, and we need as few barriers as possible. A developer should be able to deploy a critical hotfix at 3AM without waking up another team member. A sysadmin should be able to upgrade an application server without a 2 month notice and hours of downtime. A new application should able to be deployed tomorrow without half a dozen teams being involved from different departments. If we can’t do something in a small number of steps then we have an automation gap and an opportunity for the mindset of DevOps to improve our lives.
Build Smarter Tools, Kill Your Gatekeepers, and Fill in Your Trenches
[DevOps is made up of] developers and operations working in common. With each others priorities in mind.
— David Roberts
Think about your day-to-day processes and ask yourself a few simple questions. Even companies that have fully embraced DevOps sometimes aren’t proud of these answers. I know I’m not.
- What takes more than one step?
- What is something we do every day that is overly complicated?
- What is something that can only be done by one person?
- Has someone been working on a project for so long that only they understand it?
Think about these answers for awhile and remember that DevOps isn’t a job title, a process, a piece of software, etc. It is a mindset. How can this mindset help you to improve your work life?
For example:
- Automate common tasks. Aspire to make all processes one touch.
- Simplify, simplify, simplify. How much of your process is needless and only exists as a knee-jerk reaction to something that occurred years ago?
- Kill your GateKeepers (not literally you monster!). If a single person is required for a process to take place then you have a serious single point of failure. Automate or delegate their powers.
- Fill in your trenches. If a person has dug themselves deep into a piece of software or process they aren’t doing you our the business any favors. Cross train, document, reverse engineer, or just fill in their trench around them. People who insist on working like that aren’t team players and hurt everyone. Software should never be someone’s baby.
Who Cares About The Tools?
More often than I’d care to admit discussions about DevOps devolve into, what Jorge Castro once dubbed, Tool Wankery. This will stop your project in its tracks faster than just about anything else. In my younger and more hot-headed years I spent far too much time and effort focusing on the minor details rather than the big picture. My projects, both professional and personal, suffered as a result. Learn from my mistakes!
Slightly older and wiser me has adopted the mindset of “Who the heck cares about the tools?”. Use the tools that work best for you. If Chef works then use it, if Docker works then use it, if Salt Stack suits your needs than go with it. Are your applications written in PHP instead of Ruby/Go? Who cares!? All of this stuff still applies. Good tools are important but what matters is what you do with them.
Homebrew solutions are acceptable as well as long as you aren’t reinventing too many wheels. A collection of “simple bash scripts” quickly grows out of control and you find yourself in an absolute mess. Most tools have a bit of a startup cost but in the long run they will save you countless hours. Remember that learning new things is part of our jobs and if your company discourages this you should probably consider employment elsewhere.
What works for one organization may or may not work for you. Using a mixture of tools, like Ansible for bare metal provisioning and Chef for application configuration, is totally acceptable. Don’t let blog posts and HackerNews comments drive your decision making, do what is right for your environment. Full Disclosure: I have made this mistake far more times than I was willing to admit.
cd ./pub; more beer
While this list is not exhaustive I do hope it has been informative. This is by no means scientific but I have seen some pretty interesting patterns emerge during my interactions with various individuals within the tech industry.
Often times software developers, especially those in web-based development, are very quick to embrace what DevOps has to offer. We like things being easy and we hate things that get between us and solving problems. Our job is to build solutions, not to work around poorly designed and archaic processes that only serve to slow us down. Eventually we look for ways around the processes or find numerous “special cases”.
On the other hand more traditional systems administrators favor stable, predictable, reliable, and well understood systems and processes. Change carries large amounts of risk and major changes greatly increase the chance of downtime. Obviously good sysadmins want to avoid things like this as the uptime of these systems is often a reflection on their quality of work. Unfortunately this sometimes has the unintended side effect of technology getting stagnant and not being responsive to evolving needs.
While neither side is necessarily right or wrong, they both have a lot they can teach each other. Instead of sysadmins assuming developers are stupid and developers assuming sysadmins are lazy, perhaps we should learn to work together and understand the give & take process of building and evolving systems. We shouldn’t sit in our corners and give each other dirty looks, instead we should look to better understand what benefits we each provide to the organization and learn the basics of the other’s skill set.
We must understand when to embrace change and when to value stability. Both sides should understand and agree upon these decisions. Forcing decisions with the justification of “because I say so” only leads to resentment, which obviously isn’t great for team morale. Our deployment tools, programming languages, server configuration, or ability to write interesting blog posts don’t define our organization. The value that we provide does.
Special thanks to Jim Keener and Anna Hegedus for inspiring this post. Also thanks to Zack Zlotnik for listing to my ideas while sipping coffee at Crazy Mocha.
