From the Blogosphere
Taking Back IT - DevOps | @DevOpsSummit #IoT #DevOps #Microservices
Perfect is the enemy of 'good enough'
Apr. 13, 2016 06:00 AM
We have been indoctrinated in the last three decades of IT to believe that a system slowdown, outage, failure, change, or anything that has material potential impact is intrinsically bad. Yet, on the software side we have been told to "fail fast, fail cheap" to "develop in production" to release and iterate and build as fast as possible without fear of the potential failure. And why? Because its the only way to keep pace with the demands that the business, the market, the consumer, and our customers place on us.
I spent 20 years in traditional corporate IT, and during that time I built a reputation as a maverick or a cowboy; the one who was willing to try something new because it might work, not because it was guaranteed to. The only constant I wanted in my environments was change. Not just for the sake of change, but to give me room to grow and incorporate new and better things. This attitude was often met with frustration by those around me, but it always wound up for the better because I didn't want perfection all the time, I wanted it to be good enough so I could continually figure out ways to make it better. This renegade spirit is the beating heart of the DevOps shift and it is what is required for the true completion of a digital transformation.
The whole point of this series is to talk about DevOps as Dev and Ops together. My initial thought was that I was frustrated by the lack of the Ops side of the coin in DevOps discussion and really even into the tools and solutions. (They are catching up, but they do not have anywhere near the maturity of the Developer side of the equation). If you want to do all the things as a developer to make DevOps concepts of continuous delivery and the true agility that we all demand from our on-demand world, then your Ops team cannot take 3 months to provision the right resources for you. Simply put, as I stated before, all the shiny tools and integration tests and good intentions in the world don't make you a DevOPS shop because those are DEV only.
Why does this issue exist? Simply put, read the title again. Operations has one mission in the legacy IT mindset: Keep the lights on and things up and running smoothly within the accepted policies of the company's business need. To make this more simple:
There is no room for this in modern DevOps and it is a cancerous mindset that is thankfully changing, albeit too slowly for the needs of the Digital Business. How can you tell it is too slow to change? Because Amazon. If Ops could keep up with the demands of the digital transformation then there would be no need for something like Amazon, because the internal systems would have already handled it and there would have been no one rushing to outsource things. That ship has sailed of course, and cloud-based services are here to stay and have many extremely good uses in a full DevOps model, but they are not a surrogate for Operations as a whole.
They can never fully replace a truly integrated operations function, because there is still the small matter of controls. This is NOT about downtime or even about trust, it is about risk. The simple fact is that data is the new gold and everyone wants it. The reason operations has stayed around this long is that someone has to manage the security needs and the organization protection of the company. At the same time, they also need to innovate and develop alternative services for their customer (the end-user) to satisfy the "on-demand jones" that the digital revolution created. You simply cannot do that in a hyper-rigid, never-can-fail legacy IT mindset. The time has come for us to release our inner cowboy and crack-pot scientist a little to drive Operational innovation to meet up with the developer innovation that has already happened.
So it is that we come full circle in the discussion, and now must decide where to go next. I have a blueprint that I have been developing for some time and I will be sharing in the coming weeks as I continue to explore this topic more and deeper. We have laid a couple of fundamental mindset shifts on the table, communication of a radical and open nature, ___ as a service, and the idea that failure to transform is agreeing to die. Once we can all let go of the final mental block that 100% is the end-goal then we can actually start to move forward on the operations side in order to catch up with Dev. Thus the entire premise of my title, Taking Back IT - it isn't about making one subordinate to another, it is about taking back the rightful place of Operations as a full member of DevOps.
I said at the beginning of this series that DevOps isn't cheap, fast, or simple, but it IS worth it. The digital transformation movement will not slow down and it will not stop for those who are unprepared. So my friends, wax up your boards and let's get ready to ride some big ones, because this wave will carry anyone who's got the guts to go out and try and catch it.
What do you want to know more about in the DevOps landscape? Anything you want to see more on? Comment here or twitter: @charrold303 and tune in next week for another discussion on the continuing emergence of the DevOps mindset!
Read the full Taking back IT blog series on LinkedIn.
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week