1) How would you describe the relationship between DevOps, Agile and ITIL?
All three tend to borrow heavily from lean manufacturing principles and in that sense they're related, but DevOps is really an approach while the other two are methodologies that lend themselves well to supporting the goals of DevOps.
2) Can you describe what DevOps looks like when it’s ‘done’?
I don't think DevOps is ever truly "done". Part of DevOps is really about processes and intra-group collaboration and as new technologies and architectures are introduced, there are always new processes and groups, which must be integrated.
3) What do you think are the key metrics for DevOps?There are many metrics associated with DevOps today. Mean time to recover (MTTR), lead time to change, and deploy frequency are probably the most often cited as measurables applicable to DevOps. More important is to align the metrics being used with the goals of adopting DevOps in the first place. If your primary goal is improving time to market, then measure for that. If your primary goal is to reduce downtime then MTTR is the number you're watching. It may be that the goal is really application experience improvement that increases customer engagement. If that's the case then your metrics are all about APM, not deployment measurements. Before you start measuring anything you have to define what success with DevOps looks like to you, as a business, and then figure out what to measure.
4) What attributes constitute a culture embracing DevOps?
Communication and collaboration. These are not the same, by the way. Communication is sharing information, but collaboration is actually working together. Both are important, but increasingly we're forgetting how important the collaboration aspect really is, especially when new architectures are being deployed that can (and will be) impacted by operational decisions and network architectures. Getting together early in the design stages can help eliminate a whole lot of pain that occurs during deployment. That means communicating about new initiatives outside of development into ops and the network and then collaborating on how to design a proper architecture.
5) Is Continuous Delivery the ultimate goal of DevOps? How do other ‘Continuouses’ (continuous deployment, testing, improvement etc) contribute in a DevOps transformation?
I'll refer back to the measures and metrics question - that really depends on the goals of the organisation in the first place. A business whose model is based on software and engagement would certainly benefit from continuous delivery, but there are plenty of organisations - particularly enterprises - for whom that model would be disastrous and overkill. Yet other continuous efforts - like testing and improvement - would be beneficial to those organisations. Any "continuous" that doesn't reach outside dev isn't really helping with the transformation because it doesn't rely on communication and collaboration. Similarly, if the efforts don't reach beyond ops into security and the network, it isn't fully affecting the organisational level of transformation needed to fully adopt and benefit from DevOps.
About Lori: Lori MacVittie is a subject matter expert on emerging technology responsible for education and evangelism across F5’s entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organisations, in addition to network and systems administration expertise. Prior to joining F5, MacVittie was an award-winning technology editor at Network Computing Magazine. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University, and is an O’Reilly author.
Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5 click the button below.