full_stack_devops

In an interesting post from Jeff Knupp, he laments the increasing tendancy for development and operations roles to merge into one:

Rather than temporarily taking on a single role for a short period of time, then transitioning into the next role, they are meant to be performing all the roles, all the time. And here's what really sucks: most good developers can almost pull this off.

Now I'll strongly disagree with one major part of that blog post -- that developers are a "totem pole" above operations and QA -- but it's a thought provoking article.

There's often a strong need for seperate ops roles -- a skilled operations professional knows all the ins and outs of how an EC2 load balancer scales up, how to orchestrate upgrades, how to best suggest caching strategies, how to respond to system failures, and what things need to be monitored.  He or she has a tuned intuition about how software behaves at scale and has passed the bar of understanding Murphy's Law.  Specialization of ops also lets developers focus more by spending more time with their software.

I understand the frustrations when one specialization is asked to do the role of another, when financial or market pressures encourage crossing the streams, as they increasingly do.   However, I disagree with Jeff's assertion that automation is taking time for developers to help them "play ops". When done correctly, automation tools are giving them time back -- and helping out of this problem of needing to wear many hats.  Though I'll go on to say how wearing many hats is a great thing, but we need powerful tools to allow us to operate in these environments.  Naturally, all things in moderation.

Back to the article, the comments on Hacker News are particularly interesting -- and very dissimilar. And yes, I think it could be said that the 15% of the internet that is not composed of cat pictures is at least half composed of discussions about what DevOps means.  Here's a few:

A DevOps person isn't someone who develops, and who does Ops. It's someone who does only Ops, but through Development.

The last time I looked for a senior sysadmin -- less than a year ago -- I didn't get anyone who was comfortable programming in Perl/Python/Ruby until I started using the term DevOps. 

There are companies where the developers are responsible for creating the automation scripts to deploy their code into production as services and expected to keep in running in production.

DevOps is about developer empowerment. It's about creating the systems and tools that give developers more control over the operation of their applications.

Saying "DevOps person" is like saying "Agile person". I think it's a fundamental misunderstanding. DevOps is about getting development and operations to communicate directly and work cooperatively, without impediments beyond inherent complexity.

Back when I was doing Cobbler in the mid 2000's, it was quickly labelled a "DevOps" tool.  Early on, "DevOps" was a label for more advanced approaches to automation than simple scripting.  Later on, it became another label for either culture change or applying agile principles to operations settings.  Nobody knows what it means.   That's ok.  I'll get to that.
 
Regardless of what we define DevOps to be, the phrase is most effective as a rallying banner to get like-minded developers and operations folk together to talk about a wider variety of topics, such as with our local group, Triangle Devops.  It's cool because it's run by an employee by a competitor and we can all get together and do the "Good Morning, Sam, Good Morning Ralph" thing, and talk about technology.
 
So, DevOps -- whatever the definition -- is a Rallying Banner, for a lot of ideas, you can pick and choose what apply what fit.  Some of these include:
  • Getting developers to understand production more
  • Getting operations to understand code running in production more
  • Using automation tools to eliminate repeated tasks (see our favorite blog post of all time, DevOps is Ruining My Craft)
  • Applying development style practices towards automation (such as using source control) - commonly described as "infrastructure as code" (or in our case, infrastructure as data), to enable branching, auditing, and review.
  • Researching new operations technology such as new cloud or monitoring software
  • Applying agile practices typically applied to software to IT operations (such as Kanban)
  • Reducing the politically-imposed communication barriers that come from competing departmental goals to make development and operations groups work better together
  • Seeking continuous improvement, as established from for example, Japanese auto manufacturing
  • Viewing the product not as code or the servers, but code running on the servers, in production
  • Focusing on the customer rather than battling business units
  • Setting up more discussions between "technology" and "business" units of a company, in addition to healing apparent divides between development and operations.
Going back to the original post, Jeff writes that he is frustrated by the need for the developer to wear operations hats.  Frankly, I was to.   That's why Ansible was actually written.  I realized that if I didn't automate myself out of the operations roles I was required to perform, I would have less time for other projects I did want to perform.  For a developer, that can mean writing new code and researching new frameworks.  For a operations expert, that can mean designing new topologies, planning some upgrades, or researching new solutions.
Automation shouldn't be about spending all your time with a tool -- it is about saving time for the things you really want to do, because typing in upgrade commands surely is not where you want to be spending time.  
 
Similarly, if you are a Developer, realize DevOps isn't a thing trying to take away your coding time, it's a collection of ideas about seeking improvements, that you should want to be a part of.  
 
Analytical, hardcore DevOps guys are probably more aware about how to make process improvements than most MBAs.  And that itself is empowering.   It's about breaking down walls.   But should you have seperate operations folks?  As you get large enough to need them?  Yes.  But the principles that are often applied to the phrase "DevOps" are still things you'll want to persue. 
 
The landscape of IT is changing -- not only are cloud tools making development both simultaneously more easy and more complicated (replacing known tools with others at a very fast pace), we're in the middle of a Cambrian Explosion of new computer languages, technologies, and practices.  
 
Concepts labelled as "DevOps" allow what used to be the "worker echelon" of a business to completely transform a business. It's the wearing of all the hats and looking at things holistically that enables this.  DevOps meetups feel great because they are empowering and the culture of how we look at development and operations, together or seperately, is changing. 
 
How will you survive this Cambrian Explosion of ideas and technology?   Maybe you'll evolve into a Full Stack Devop. That wouldn't be so bad.

Topics: Continuous Delivery, devops, philosophy, simple, configuration management, orchestration

COMMENTS