This is a guest post by Dinshaw Gobhai of Constant Contact based on a talk he gave on campus
To a developer, operations can seem overwhelming, mysterious, and sometimes just boring. ‘DevOps’ is everywhere, but what people are referring to? Is it tools? Is it culture? Is it something one can learn?
The answer is yes.
How did we get into this mess?
At the dawn of the computer age, there was no distinction between dev and ops. If you developed, you operated. You mounted the tapes, you flipped the switches on the front panel, you rebooted when things crashed . Dev and ops started to separate in the ’60s, when programmer/analysts dumped boxes of punch cards into readers, and “computer operators” scurried around mounting tapes . The operators pulled printouts from line printers and shoved them in labeled cubbyholes, where you got your output filed under your last name . The arrival of minicomputers in the 1970s and PCs in the ’80s broke down the wall between mainframe operators and users, leading to the system and network administrators of the 1980s and ’90s. That was the birth of modern “IT operations” culture.
Where did DevOps come from?
2007 Ghent, Belgium, Patrick Dubois was making an effort to work in every capacity that an IT contractor could. Professional experience in both development and operations gave him a clear view of a conflict of interests within all established IT infrastructure:
Development’s job is to introduce change. Operation’s job is to keep the site stable and fast.
Dubois is credited with informally inciting the DevOps community by initiating conversation around this paradox.
Slide from Flickr: Dev vs Ops
Fast-forward to 2009 at O’riliey’s Velocity Conf and the now famous talk: 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr. John Allspaw (operations) and Paul Hammond (development) were the first to publicly call out the rift between dev and ops. We, as an industry, had created two job silos with contradictory goals. An ‘us vs them’ mentality had created mistrust and disrespect between dev and ops, and it was self-perpetuating: the better each side did at their job, the worse they made things for the other. Allspaw & Hammond described what they needed to solve this problem with a single slide:
Sadly, Patrick Dubois was not able to attend Velocity Conf ‘09. But while lamenting his situation over social media, friends suggested that he hold his own conf. So he did, and DevOps Days 2009 was born. The conference included Introducitng Kanban in Operations, Continuous integration pipelines and deployment, and Building agile infrastructure with Puppet, all familiar concepts today, but ground breaking at the time. DevOps Days was a hot topic on Twitter where the ‘Days’ was dropped, the term coined, and the movement galvanized.
DevOps stood out from the best-practices of the time because, instead of being another vendor-to-the-enterprise-set’s million dollar solution, this was from practitioners, for practitioners. DevOps was a grassroots movement against legacy tools and culture. It was not a spec, a product, a standard, or a job title. It was a lot of smart people collaborating on a complex set of common problems.
What’s the problem?
The problem that DevOps addresses, to sum it up, is the hand-off from Dev to Ops. When developers ‘throw’ their code over the proverbial wall to Ops, and it breaks, the cliché response is ‘Well, it worked on my machine… it must be your fault’. When software works in one place (dev environment) and not in another (test, stage, prod, etc) people get defensive, tensions rise, and cooperation becomes harder just when we need it most.
Our software gets more complex every day. The more complex our software gets, the more fragility creeps into our systems and, to quote Gene Kim:
“Critical systems cannot be fragile.” Gene Kim, a DevOps evangelist, gives his Why We Need DevOps Now talk all over the place. If you haven’t seen it live, watch a recording. It is inspiring and informative.
What’s the solution?
At the heart of the DevOps ideal is an acknowledgment that Dev and Ops can no longer be separate responsibilities. Awareness of how code travels from development to production and how it will be deployed must be a part of the process from the start. Developers must understand their production systems, and inevitably own the uptime of the code that they write.
Our healing comes in two forms: Culture, and Tools.
Culture
Developers will need to learn about their production environment. This learning will likely come from someone in operations. Healing the divide between dev and ops, and fostering communication in the archetypal IT organization is the goal of DevOps culture.
Tools
There are many tools that can be labeled ‘DevOps’, and many more arrive each day. Victory is not choosing the perfect tool, but implementing common tool-chains across teams. When everyone is using the same tools we achieve transparency across teams. This fosters communication and appreciation of what our colleagues are doing, and ultimately (hopefully!) respect. It also enables us to work with each other with ease. Version control (we use Git), CI (we use Jenkins), and infrastructure automation (we use Puppet) are all good examples of tools that should be common across an organization.
Getting Started
TDD (skip to Automation if you already do TDD): You can’t automate any part of your code promotion until you can programmatically verify your work.
Automation: Starting down the read of automation can be daunting. Start with something small. Here are a couple suggestions for noobs:
-
Make your editor clean trailing whitespace on save
-
Create a .dotfiles repo
-
Use Puppet or Chef to automate the configuration of your developer machine
-
Use Vagrant or Docker to simulate your production env on your local machine
Have a cup of coffee with your closest ops person. Make friends, you are on the same team! Ask them about Puppet or Chef or what they do all day.
Much like everything else in the world, if this seems hard at first it will get easier!
