Understanding DevOps vs NoOps

You can't hide from the DevOps conversations going around in the IT world today.  Whether you're on Twitter, standing in the hallway at a technical conference, or in the office - everyone's talking about DevOps and its contribution to the agility and speed of software release from today's development organization. DevOps represents a fundamental shift in how applications are being delivered to the new 'web' via cloud, mobile and other channels. For the CIO, this shift means that their development teams not only write the code but deliver and maintain it in production as well - potentially revolutionizing go-to-market speed and agility for the organization.

 

Lately, however, there has been a bit of a ruckus over the NoOps concept.  NoOps, as some understand it, effectively spells the end of the formal silos built around development, operations and quality testing teams, but goes deeper to actually try to eliminate the operations and testing organizations altogether.  That is ... if you believe what some people are saying.

 

Let's take a step back for a moment.  At its core, DevOps is fundamentally about giving the people who are best suited to understand applications the ability to develop, test, release and monitor those applications throughout the rapid release lifecycle.  The capability to do this comes seemingly at the price of eliminating the formal operations teams that have been responsible for packaging, testing, deploying and monitoring enterprise applications up until now.  Or does it?

 

You see, many of the operations and testing specialists that I've talked to over the years are former developers who have simply chosen to move on in their careers and don't write code anymore.  This doesn't mean that they don't understand how applications are written, what makes them work, and how they break.  It simply means they're not the ones who write the code anymore.  On the flip side of that coin, I know there are many developers out there who wouldn't know the first thing about packaging, deploying and monitoring their enterprise code because they've never had to worry about that.  These two worlds are bound for a head-on collision.  It's unavoidable.

 

So what does NoOps add to this picture?  How can completely eliminating operations and testing teams possibly be good for an organization and the health of its applications?  Furthermore, what manner of effort would be required to make NoOps work?

 

After having some interesting conversation of the last couple of days trying to get a handle on the NoOps rush, it hit me.  Unless I'm completely missing the boat NoOps is just highly optimized and automated DevOps.  Am I right?  The only way it can be possible to achieve end-to-end release precision and accountability is through extremely tight automation and governance in your toolkit.

 

Now I'm asking what you think... Join Gene Kim and other industry insiders March 28th, at 9 a.m. Eastern for a lively discussion on Twitter, using the hashtag #ITPS ... don't miss the opportunity to voice your opinion.

Labels: DevOps| noops
Comments
Genefa Murphy | ‎03-27-2012 07:42 PM

I think you are raising some good points here….the customers I have spoken to about Dev Ops and No Ops all recognize the unique value that the different players in the application lifecycle bring to the table. No Ops and Dev Ops and Agile before it all made us think about some fundamentals of efficiency within our orgs, namely the value of communication, collaboration and as you mention the tremendous value that automation can offer.

 

The other thing we have to remember is just because something is the “Word of the Day” it doesn’t mean we have to go and run out and adopt it hook, line and sinker, instead we would be better served to look at No Ops, understand what it really means and then apply it where applicable in our processes, practices and organizations. There is no one size fits all here. Just remember, if someone was to say jump of a cliff, would you?.....

Roy Lyons | ‎03-28-2012 09:06 AM

In our organization, we recently went through a re-org that seems to mirror this attitude of breaking down silos and improving efficiency.  It is still brand new, so I can't comment on how well it works yet -- but I can say that it does address one of the largest issues facing IT today - COMMUNICATION.

 

The reality is that to achieve government compliance (at least in financial institutions), some separations of church and state (development vs quality assurance vs operations) need to be maintained.  This means that the expertise still needs to be "siloed" with certain individuals.  The reality is, therefore, that the testing and deployment is not really transferred to developers -- but the responsibility and accountability DOES transfer to the development organization as a whole.  This removes finger pointing and delay.

 

Rafal and I have loosely discussed some of the stronger security measures we have implemented regarding our intellectual property.  He playfully refers to them as draconian, however they really shine in this type of situation.  Since we cannot generalize a security model based simply on the group that they are in, we need to maintain a finer-grained control per-person.  I think the way to make that work is to automate the approval process as much as possible and try to implement the change in such a way that it can appear to be black box and transparent.  

 

As a whole, I am currently in approval of this approach.  Breaking down accountability and reporting walls to increase productivity, efficiency, and communication is a +1 in my book.  Just be careful not to throw the baby out with the bath water!

Gene Kim | ‎03-28-2012 01:35 PM

Raf, I I appreciate your efforts to poke where there's a lot of contention -- it's forcing the DevOps movement to better define the terms we use, the values and principles that underpin the movement, as well as the processes, procedures, daily work and improvement of the daily work that make it all happen.

 

We had a DevOps/Kanban meetup last week, where we had some of the leading thinkers in the space (check out the attendee list and some great pictures) talking about DevOps, how to integrate techniques like kanban, and even NoOps.  It was a remarkable meeting

 

John Willis (@botchagalupe) just wrote a blog post on why some of these questions are difficult for the DevOps community.  I suspect this will be the first of many as we all try to crystalilize definitions that the entire community agrees upon.

 

Keep up the great work!

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.