It's the Ranger4's #DevOpsFriday5 series and this week's answers are courtesy of Chris Prowse. He's DevOpstastic!
1) How would you describe the relationship between DevOps, Agile and ITIL?
DevOps and Agile, despite common misunderstandings, are not inextricably linked; I’ve worked on more traditional projects that have still seen significant benefits from adopting DevOps thinking. However, they’re incredibly complimentary in the way that they work.
Traditionally, we saw the Business, Development and Operations all working in silos. This meant that requirements were sent from the Business into the Development teams, where they were interpreted (often incorrectly), but didn’t reappear again until the end of the project when they were given back to the Business as a product that may or may not satisfy the Business’ needs. It was often at this point that the Operations team got sight for the first time of the product too; meaning they had a battle to deploy and support something new.
Agile thinking brings the Development and Business teams closer together, using regular feedback and engagement to keep the product in-line with the Business’ expectations, and ultimately delivers something that is useful to the Business. Throughput is therefore faster; but the Operations team are often still the last to see the product, and face similar challenges.
By bringing DevOps ways into the project lifecycle, the Operations team are also engaged early on. Ideally, their requirements are fed into the project from the start (deployment approach; monitoring hooks; logging standards etc), combined with physical engagement (swapping team members around; involvement in post-mortems etc), leads to fast product creation that is then easily deployment, monitored and maintained within an Operations function.
In an ITIL environment, failure is feared, and rigorous processes are deployed to try and prevent failure. Focus is very much on stability over agility. DevOps approaches can help to streamline some of these processes, through automation and validation; but the mind-set is different – failure is to be embraced and learned from at every opportunity, instead of avoided.
The other key component of ITIL is compliance – processes and tools that are “ITIL compliant” can’t be easily changed, if the organisation wants to remain compliant. Compliance is embedded throughout ITIL, and therefore to adopt DevOps practices safely in this environment, any new DevOps processes will need to go through the relevant reviews and assessment to make sure that they don’t breach, but do support, the compliance activities – and the ITIL compliance should be realigned to the new processes if possible. Everyone should always try to improve on existing processes – making them as lean as possible, automating where feasible, and removing the risk of human error at all stages. Regularly used processes are less likely to be messed up after all!
Finally, focus on continual service improvement – often the least considered ITIL volume, but in reality, the one that makes your organisation more efficient.
2) Can you describe what DevOps looks like when it's 'done'?
DevOps is a cultural, collaborative approach to working; it is never “done”. It’s important to have a vision when starting on a DevOps journey – not a specific end goal, but instead clarity of direction that everyone is moving in. This allows everyone to pull together – from the leadership teams providing the right environment for everyone to be successful, down to those implementing processes and tooling.
A balance of stability and agility is the best result for any organisation – being able to make rapid change safely to products and systems means an organisation can remain competitive and get the best return on investment possible, whilst keeping their customers happy. This in itself will continuously evolve throughout an organisation’s lifecycle.
On the flip side, don’t make changes just for the sake of making changes. In particular, tooling and automation – deploying “yet another new tool” is unlikely to make the teams more efficient!
3) What do you think are the key metrics for DevOps?
It’s easy to measure and report on “too much”, but this creates a scenario where the important information is missed when it matters, as it isn’t clear. The best approach is to make sure that, as per the Second Way, the right information is available to the right people at the right time. This will vary by organisation, but as with any KPIs and metrics, it’s important to focus on the ones that you expect to impact with changes – if you think you’re improving a process, then you need to have clear measurements in place that demonstrate any improvements (or not), to enable learning.
Reports and dashboards should be automated, so that no effort is expended in creating them. Users should be able to tweak what they want to see in “their” report.
From a system perspective, monitoring should be at the heart of everything. Retro-fitting monitoring tools is much harder than building in the right hooks and functions from the start. Including things like heartbeat checks into new systems and interfaces allows the Operations team to quickly add them into the overall monitoring solution. Additionally, think about full-transaction monitoring in addition to component monitoring – it’s important to understand which systems are up or down; but it’s even more valuable to understand the impact that has on the business processes – “what can a user no longer do due to this outage?”.
Don’t only use monitoring tools in Production – every Test environment is someone’s Production environment after all, if that’s where they spend their days. Monitoring tools and scripts are products themselves, and need to be tested – do this by deploying them everywhere, just like any other code. And keep them in source control!
4) What attributes constitute a culture embracing DevOps?
Alignment with the Three Ways becomes obvious for cultures embracing DevOps – rapid flow from left to right; regular and valid feedback; and an environment where people and processes learn and evolve. Open, transparent teams enable learning through sharing and collaborating. Teams don’t hold on to valuable information themselves, but share it around – be it learning from failure, feedback on new products, or new techniques and tools.
Ultimately, the organisation moves towards both better agility/pace in the creation and maintenance of products, as well as improved stability of systems. There should be “no surprises”; teams shouldn’t be given products to build/maintain/support that they aren’t aware of.
The 2016 State of DevOps report shows us that employees of organisations embracing DevOps are significantly happier and more likely to recommend their place of work. So, putting people first, a culture embracing DevOps should have happier employees!
5) Is Continuous Delivery the ultimate goal of DevOps? How do other 'Continuouses' (continues deployment, testing, improvement etc) contribute in a DevOps transformation?
All of these are important; but technology is an enabler of DevOps, not the complete answer. Looking at CALMS, automation is only one front. The risk of making CD (or any other Cx) the goal creates real focus on tooling, ahead of people and processes. Focus instead on how the teams work together, and efficiencies within processes. Standardise where possible, and you’ll be in the best position to move ahead with continuous integration and beyond.
Each organisation has different needs; it doesn’t make sense for everyone to deploy to Production at the same rate that Amazon do. Understand what is important today, and work towards that – review this regularly to make sure that you’re focusing on the right things.
One item that must be included is security – there are some great blogs on Continuous Security; but regardless of name, DevOps does not excuse good security practices – in fact, they can make security better due to the fast-paced ability to fix problems. If there is a divide between the Security function and any other teams, focus on removing that and bringing everyone on the journey.
Chris Prowse is a senior manager at Baringa Partners – a business and IT consultancy with a difference. Chris is highly proficient, PRINCE2 certified, DevOps certified, Development Architect, with 12 years of experience across Environment Management, Configuration Management, Technical Support, Capability Development, Release Management and Project Management. A big fan of DevOps, Chris was one of the first 20 people to be certified in the new DevOps Foundation certification.
Chris is part of the Development Operations (DevOps) function within the Technology Transformation holds a BSc in Computer Science, which makes him very keen on exploring the world of IT.