From the Blogosphere
Taking Back IT - DevOps | @DevOpsSummit #DevOps #APM #Microservices
The Digital Transformation and the process that powers it
Mar. 13, 2016 12:00 PM
Part 1 - How do I get started making the transition to DevOps?
I am an ops guy. I have been in Ops since I started my career a long time ago. I still remember the glorious days of being the new guy on the Ops team and getting stuck with changing backup tapes. I remember moving servers in the wee small hours of the morning, upgrades that went horribly wrong with no prayer of reverting, and the joys and pains that went with being in operations, and really what we would call "Legacy IT" in general. It's like the opposite of "Cheers", because you want to be where NO ONE knows your name; if people know who you were in those days of IT, you were having a bad day.
It was around the year 2000 though that something finally broke lose. At the company I was at, Operations stopped just simply reacting to things that happened and decided to try and get in front of things. Not in a comprehensive, complex way, but through the simplest and most crucial tool for DevOps; we went and actually talked to the Dev team. It's not glamorous, or cool, it has no lights and fancy graphs and dashboards, and it most certainly isn't something you can buy, but your voice is the single most effective and powerful DevOps tool. As the lead of the server and operations team at the time, I went to the application team and asked them for a roadmap of what they were doing, and asked them if we could meet together and talk about upcoming stuff. Seems pretty simple, right? This was radical stuff though, back in prehistory, and while we didn't always get out of fire-fighting, we got a lot better and we made progress.
Fast forward 5 years and the company I am leading IT for is undergoing significant infrastructure changes to support increased Development of applications, and streamlined Operations. Sounds like DevOps! Except we had a problem; Dev and Ops were friends and we liked to talk and do great things. The problem is, we never bothered to tell anyone else in the company about all the great things we were doing. We had to fight the business to get approvals to make even minor changes because we had forgotten the most important tool for DevOps isn't just for Dev and Ops! So I did something "radical" again, and went and showed the business unit stakeholders (the head of the Peoplesoft team, the DBA group leads, the Finance department head, the head of HR) the data center, their equipment, and most importantly our plans for it and what they would get from it when we were done. Guess what? I never had to argue for downtime again and we were able to consolidate and optimize our datacenter and move to our new systems in record time. Why? I used the most important tool of DevOps and got the business to believe in what we were doing by showing them not just the what, but the WHY.
I am telling you this because as you embark on the journey to the Valhalla that awaits us in DevOps land, I want you to always remember the golden rule of DevOps: All the software, fancy hardware, unit and integration testing, performance monitoring, and overall execution metrics in the world mean exactly nothing to anyone if you don't talk about them first. That's not a small thing to ask of IT people; we shun the limelight and we tend to try and stay anonymous, but it will kill your DevOps initiatives faster than any outage ever could.
The steps to achieving DevOps are actually simple to map, but much harder to do:
1) Talk amongst IT and get them bought in to the shift to really being a DevOps shop, not just talking about, but DOING IT
2) Talk to the key business stakeholders and get them bought into the OUTCOME of the shift to DevOps in real terms (as an example, by us moving to virtualized infrastructure and systems, we could get Peoplesoft up and running in the event of a borked upgrade in under 30 minutes - that is a real and most importantly MEASURABLE outcome)
3) Go back to work and choose the tools and techniques that will make it the easiest to execute on the plan and achieve the agreed on outcomes
Notice how I didn't pick a tool until I got everyone to agree? That's because you can pick all the tools you want before you get the plan and the buy-in in place, but you are just wasting time; if the tools do not support the outcome, you are going to have to start over. So take the first step by talking and agreeing to the plan. Then like I have over the years, you will be ready to wade in and start thinking about the actual nuts and bolts of DevOps. Something we will be talking about in greater detail as we progress in this series of blogs.
Have any topics you want to know more about or see more on? Let me know either in the comments or via twitter: @charrold303
For the full series on IT Transformation and DevOps, visit my mini-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