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.
Cross-posted from Following the White Rabbit