In my last post I spoke about the concept that Operations needs to understand and embrace the ____ as a service model (viewable here). The concept is difficult, but the reason it has to happen is that it is the most core tenant of DevOps, and it is the only way organizations will be able to truly drive digital transformation.  This matters more than ever, because in the new digital wasteland we live in,  failing to transform is agreeing to die.

Transform or Die
That sounds a bit heavy handed, but it has a lot of logic behind it for the operator and for all of us trying to take back IT. Transform or Die developed from a presentation  I gave last year a Strata+Hadoop in Singapore for their inaugural Pecha Kucha session on opening night, that I called "Get out of your developer's way". My basic premise was that the digital revolution has already happened and now we find ourselves adrift in the Digital Wasteland, which I naturally equated to the movie Mad Max. My key salient point was that without DevOps, digital transformation is impossible and therefore you are doomed to die in the digital wasteland, consumed by the competition as they overtake you and leave you lost and adrift. You can see the presentation in all its iPhone recorded glory here. Since it is Pecha Kucha it is literally 5 minutes long. (side note: Pecha Kucha is an absolutely amazing type of event - the US analog are the Ignite events and there are chapters in every major city. I would encourage you to look one up and attend sometime, they are fascinating.)

Alongside this point about the digital transformation was my assertion that, while there have been many articles in recent years about the digital transformation of business and the rise of Big Data and analytics and how this will make or break many companies, I think this is only the surface of the story. I think any organization can benefit from data analytics, but not always for direct action with customers a-la Amazon, Facebook, Netflix, etc. who have become the "poster children" for information-driven businesses. The way that companies are going to stay relevant is by being able to capitalize on what the information they are analyzing tells them, and the only way to do this is by being as nimble as their customers expect them to be.

The simple truth is that DevOps enables digital transformation because without it organizations will struggle under the back-breaking, burnout inducing IT of the olden days. In fact, the term "shadow IT" is born from this frustration with Ops's inability to hold up their end of the DevOps bargain. All the fancy tools in the world don't mean a thing if it takes me 6 weeks to get a server to load them on. Remember the "load an app on your phone analogy in the last blog? (you can see it here if you didn't) Don't think for one second that developers don't have the exact same expectation of "push button get ___". The reason the cloud has gained so much popularity is that it is simple; the cloud is the savior of the impatient Dev because it completely bypasses the "sluggish and unresponsive operations team" and gets Dev what they need right now. In doing so however, it is the bane of Ops because it also completely circumvents traditional controls that Ops maintains, like policy controls and security.

One of my readers asked after my last post if Dev needs to be more or less aware of infrastructure in this new world, and it is worth pointing out that as we progress into the truly Developer-driven, digitally transformed business model that DevOps implies, Dev needs to be equally aware of the basics of Operations (something they have frankly ignored for a long time) just as Operations needs to be more aware of common development practices and methods. This isn't a battle for power and there isn't a need for it to be. DevOps at it's heart is a cultural shift first and a process change second. In order to successfully maintain the balance both sides have to be equal.

To paraphrase my friend Bill Schmarzo: "you don't need a DevOps Strategy, you need a business strategy that includes the use of DevOps to achieve the business' goals." Simply using agile, running continuous testing, or doing more frequent releases does not mean you have implemented DevOps; if you are not equal partners then you are not doing it, and saying it doesn't make it so. To illustrate my point about this, I met with a customer some time ago where everyone from IT introduced themselves as "DevOps", but sure as I'm writing this, after the meeting the "DevOps" (who were clearly developers) wanted to find out all about how to make the other "DevOps" (who were clearly Operations) much more responsive and deliver infrastructure components faster. The other "DevOps" wanted to find out how to get the first "DevOps" to respect the need for process and procedure so they did not overwhelm the systems and cause issues that could impact customers.

This is also not a condemnation of a developer-led strategy by any stretch, and it isn't about the risks of Shadow-IT (using cloud without the controls of IT in place) because that risk is just as bad for on premise data as we've seen in the last few years. It is about people potentially doing things with data they shouldn't and creating a bigger surface area for an external actor to engage with and potentially cause damage. This is 100% a process problem though, and there is one maxim I have lived by for twenty years: "You can't fix process problems with technology." In fact, I firmly believe that the cloud is the role model from which Operations should take their guidance for DevOps, but there needs to be an agreement between peers in place (and again, why communication becomes critical) so that the risk is mitigated and the solutions are used in the right way for the right things.

So why is the cloud the role model? Simply put, one of the key concepts behind the "transform or die" idea, is that just like Dev, Ops should be seeking to "release" the platforms and environments they support, mark that point in time to iterate forward from, and start working on the next version to find the next point in time "release" of the environment. Sounds crazy, right? And yet, that's the goal of so many operational infrastructure systems - snapshots, point-in-time-copies, virtualization, containers, and every M&O tool ever built, and indeed what the cloud is designed for as well. To make an environment something that can be released and reverted, upgraded without fear of failure, and moved forward in time. That's not to say you have to do it all cloud, or all in-house, because there is definitely good uses for both technology sets, and we will explore that in a future post. The point in all of this is that there is no single answer; as I say over and over again, you don't buy a DevOps. DevOps is many technologies and many processes working together to achieve a dynamic and continuously adapting platform.

So why aren't more organizations really attacking this and taking it to the next level? Why shouldn't we be retooling our platforms in Ops so that it is now treated like software, and the concept that everything we deliver in our DevOps world is now a service? It really isn't out of reach, the tools exist to do it right now and are maturing faster than any other single technology innovation I've seen in my 20 years in the field. So why isn't everyone just doing it? It can be summed up in a simple phrase: "Perfect is the enemy of good enough".

This is the topic of our next post and we will talk about what's holding operations back from truly implementing DevOps. Agree? Disagree? Want to see more/less/different? Share your thoughts here or on twitter: @charrold303

• Taking Back IT - DevOps | @DevOpsSummit #DevOps #APM #Microservices
• Taking Back IT - DevOps: Part 2 By @CHarrold303 | @DevOpsSummit #DevOps

• Taking back IT - DevOps: The ____ as a Service mindset
• Taking Back IT - DevOps: The Digital Transformation and the Proc