You’re never safe in Enterprise IT. Just when you feel you’ve gotten a handle on the last hot topic you’re hit with another. SOA, BPM, Agile, ITIL; You feel like screaming “Enough!” but you know resistance is futile. Gartner have said it’s important so you know full well that you’ll be asked to “do” it by management.
The latest buzzword in IT is DevOps. DevOps is more philosophy than process. It is a recognition that the relationship between developers and operations staff was broken. Developers are expected to ship more code, more frequently. Change is their friend. Ops are expected to keep everything running smoothly, to protect uptime. Change is their enemy. Something had to give.
At its core, DevOps is simply about improving collaboration between development and operations teams. As an extension of Agile, it means including system administrators in the agile development process. In practice, DevOps has also come to be associated with various tools such as infrastructure automation, automated testing, CI/CD and monitoring tools.
You’re in the Enterprise though. Where do you start with DevOps? As most Enterprises these days run on ITIL processes, this is a pretty good place to start. Despite the rumours, DevOps doesn’t mean the end of ITIL. DevOps should be seen as a means of ITIL process improvement. By using ITIL processes as a basis for a DevOps initiative, you can greatly simplify and focus your efforts.
I recently wrote an eBook aimed at Enterprises explaining a methodology for using ITIL as a basis for their DevOps implementation. Here are some of the highlights:
If your change process is a bottleneck then chances are it’s because that’s all it is to your Enterprise, a process. You’ve followed all the advice of ITIL and have appropriate prioritizations, approvals and stakeholders, but guess what? You’ve taken the human element out. Email approvals are handy, but people are much more likely to reject approvals when they haven’t been consulted appropriately and are not face to face with the person responsible.
So, the best “DevOps” initiative we can implement within change may not really feel like DevOps at all. It’s simply good practice to improve collaboration between stakeholders in the process. The main goal is to make consultations between groups proactive, not reactive.
Release & Deployment Management
This is an area where the automation side of DevOps really comes into play. Automated deployment, automated testing and continuous integration are key.
When managing environments and moving applications through them, consistency is what you want. The first step towards that is consistent builds. Automated deployment tools are a must. No PM wants to hear that it will take 3 days to get UAT ready for testing. Tell them it will be deployed, validated and ready to go in a matter of minutes and you’ll be assured of a seat at the project completion lunch.
How about keeping it that way? Automated testing, both functional and configuration, will help maintain consistency (or prevent the promotion of issues in the case of functional testing). One sign of an advanced IT shop is the implementation of monitoring solutions earlier in the process. Proactive identification of problems and inconsistencies is the key.
Painful code merges and unecessary scheduling delays can be mitigated by the use of continuous integration tools, where all development branches are regularly merged into an integration branch. Also, automated tests are run with each merge to catch conflicts early and reduce regression testing requirements when it is time to go live.
Like the Change Management process, the Incident Management process will naturally receive flow on benefits in the form of reduced incident numbers when initiatives in other areas such as automated testing, deployment and continuous integration are put into action.
Perhaps the best example of how a DevOps mindset can assist the Incident Management process is the practice of making sure that development staff also go on call. The benefits from this are twofold. Firstly, seeing development staff playing their part and standing on the front line improves the camaraderie with the operations team. Secondly, an understanding of the impact their code has on supportability makes developers better coders as well
Automation is the key here. Whether a deployment, a test or an approval, each time you automate something you are effectively capturing knowledge. ITIL may disagree with this definition but it is the only practical one.
Get Started Today!
By using your ITIL processes as starting points for analysis of potential benefits, an Enterprise DevOps implementation is given greater focus. Identify pain points that could benefit from greater collaboration and automation. Prioritise them based on potential benefit and estimated effort. Get started today though. otherwise your business will most like certainly be left behind.
It’s been really interesting to watch the dramatic uptick in activity around the automation space the last year or two. I don’t need to go into too much detail on the benefits that automation offers here, consistency and scalability are two of the more prominent that come to mind. What has struck me though is that it feels like the way that companies are going about it is missing a key step.
In the Enterprise we are used to hearing about maturity models. The Capability Maturity Model (CMM) for processes (originally software processes) being one of the most common. One of the key things you learn with maturity models though is that when progressing along them it is critical that you don’t skip levels. That is the point of it being a “maturity” model. You grow through each stage, building on what you already have. You can move quickly through a stage but if you try to skip one you are destined for failure.
When looking at an IT automation implementation at a high level you can argue that it is simply a case of moving from manual deployment of systems to automated deployments. For a fuller picture though I believe that you need to take validation, or testing into account. If I were to illustrate the maturity model, or roadmap if you will, for IT automation I would do it like this:
So why automate testing before automating your deployment? Think about it this way. What do you need to do before you start automating your systems? You need to gather your requirements for automation. Now you can gather them the classic way in a document of some sort but how much utility do you get from collecting them this way? Take a leaf from the book of software developers and test driven development and gather your requirements as tests instead. Why? There are multiple benefits:
- If your requirements are executable you have test driven automation and you can track your progress with your automation implementation. How are we doing? Well how many tests are passing?
- Your tests live on and become the safety net for your automations ongoing. Remember, automations are code too and they will have bugs. If you support them with separate tests then you can guarantee their quality.
- You reduce vendor lock in for your automations. It is a much less risky task to switch from Puppet to Chef, for example, if you have an independent set of configuration tests to validate your migration.
So, not only is automated configuration testing a natural step on the road to full automation, it has multiple additional benefits.
How you automate your configuration testing is up to you. If you are comfortable with a particular scripting solution or testing framework (cucumber nagios for example) then that is fine although portability and collaboration can suffer. Remember, configuration is something that multiple teams have a stake in, from development, operations, security and even testers themselves. If you are serious about bulletproofing your automations through testing you may want to consider a more fit for purpose configuration testing solution.
However you implement though the mere exercise of doing so prepares you for automation. Whilst tempting to ignore it is always time well spent.
In case you missed it, Puppet Labs this week released their State of DevOps report. Whilst a healthy degree of skepticism is never a bad thing when reviewing vendor surveys they did gather responses from 4000+ DevOps professionals (IT Ops and developers) in 90+ countries for it. Highlights of the report include:
- 26% increase in adoption of DevOps
- Demand for DevOps skills is growing rapidly
- Keeping in mind that they are an automation company they listed source control and automation as the two clear delineators between low and high performing companies.
- High performing organizations deploy code 30x more frequently and have 50% lower failure rate
As mentioned, the automation focus is understandable coming from Puppet. I do feel that configuration testing automation is an oversight here though. OK, full disclosure is that this is an area I’m focussed on but it’s a notion that I’ve had confirmed by multiple people within the DevOps space. Automating your testing is an excellent preparation for automation as it represents requirements gathering in the form of executable documentation. This effectively allows you to use a test driven approach to rolling out automation.
There is also a disappointing lack of depth in the report’s coverage of the cultural aspects to DevOps. Perhaps this element is as hard to report on as it is to implement but I feel an opportunity was missed to gather real world examples of techniques to get IT staff in general, and devs and ops in particular, to work together more effectively.
A visual summary of the report can be found in the below infographic.
2013 State of Devops Infographic | Puppet Labs2013 State of Devops Infographic
Those of us who haven’t worked in the Enterprise probably don’t know a lot about ITIL. ITIL may even be a great source of amusement for them. Show them a picture of the ITIL books and they may well even laugh out loud. C’mon, they would say, how much practical use can you get from a methodology that is defined through a set of books that is actually referred to as a “library”?
To the generation of IT professionals who align themselves to DevOps ITIL processes can still appear draconian, more the enemy of efficiency than its enabler. To argue flatly for one approach or the other in any situation though is ridiculous. More ridiculous still would be attempting to force DevOps methodologies into a large Enterprise in the same way that ITIL processes were forced in over the last 5 – 10 years. Putting in ITIL where before it was the Wild West is one thing, applying DevOps principles where the order and structure of ITIL reigns is an entirely different, and far more risky, proposition.
Can Enterprises benefit from DevOps methodologies? Of course they can. They simply need to be judicious in the way that they implement them. The following is a simple, yet effective, approach to identify and prioritize your DevOps initiative in an Enterprise where ITIL rules. The key is to identify the areas where you will get the most bang for buck through improved collaboration and automation.
There are a lot of ITIL processes and if you have defined how each one of them should work in your organization then that’s no mean feat. It’s not helpful here though. Pick out the three that are used most (most instances per week), involve the most teams (cross functional) and whose failure/inefficiencies cause the highest impact (money/time). Based on my last Enterprise role would choose Change, Release and Configuration Management.
I know, I know. No more meetings, right? Well, this one is important. Make it a single workshop, not a weekly get together. Give it a set time and don’t go over. Getting something out is what matters, not making things perfect.
Where is time wasted? Where are the handovers? What costs the business the most money when things go wrong?
This is the key. Stop thinking about “DevOps” as a high level concept or methodology and focus on what it means. It may be a simplification but thinking of it in terms of collaboration and automatio
Getting developers and operations staff working in perfect harmony may not be easy but getting them talking is relatively cheap and can have immediate impact if done right. Implementing continuous delivery for a legacy banking system is neither easy nor cheap. This is not an exact science but do your best to list each “DevOps” opportunity and prioritize them in terms of likely ROI.
That’s it. Don’t fret any more about what DevOps is and isn’t. You have a prioritized list of DevOps initiatives. Treat them like you’d treat any other work but don’t let them get buried. You’ll never learn what works for your organization until you get started. If you have buy in from each team from the start though your chances of success are greatly improved.