Enfuse Guide: DevOps and Why it Matters
What is it?
DevOps is a movement, anew way of thinking about what 'good practice' is for IT operations and development. This entails changes to how IT Dev and Ops functions use technology, how teams are structured, and how teams act and think.
It's a new way of thinking because, in the past, good practice for Dev and Ops was considered in silos. The Dev engineers used their toolsets and operating processes, the Ops guys theirs. Each had different metrics they measured success against. Dev was all about getting code out. Ops was about safeguarding the production environment which often meant throttling the speed and scale of new software into the live environment. Good practice in the past was about a 'healthy' friction between the Dev and Ops teams, each challenging the other.
Now with DevOps there's a focus on radically overhauling that model to have Dev and Ops folks working collaboratively. This means changes to the end to end flow of development to production. Books like the PhoenixProject have pushed this point. IT is the factory of the modern day business, and so it is paramount that a smooth supply chain exists from development to production as this is vital for digital product speed to market and customer quality.
What does DevOps look like?
DevOps features lean IT production lines. There is a collaborative culture. Dev and Ops teams have access to one another’s environments with a greater level of trust involved. There is prolific automation of software development, testing and release, with the same tools being used by Dev and Ops engineers. There may be automation architects/engineers to support this. Dev and Ops share performance metrics -each understands the need for speed to market and ensuring the software is supportable once live. Continuous Delivery is in place - large, big bang releases are to be avoided. Agile and Extreme Programming are the norm. Organisation structures between Dev and Ops will be focused on enabling closer collaboration between the two, rather than creating two silo towers.
One point to note (and see our watchpoints on this one) is that DevOps doesn’t automatically mean combining Dev and Ops teams into one. People often make this mistake. It’s about getting the two areas to work seamlessly together, sharing objectives, not necessarily making them into a distinct single team.
Why you should care
If Enfuse Group had to sum up its definition of DevOps, we’d say it is about the good practice of Dev and Ops teams working collaboratively together to produce quality, high-value working software. DevOps is now the best practice standard for how IT should develop and operate. Companies who are embracing DevOps are reporting higher outputs, less downtime and over time reducing costs thanks to higher automation. So in short, moving to more of a DevOps model is becoming a bit of a no brainer.
Watch points with DevOps
Adopting DevOps because everyone’s doing it – We see this one more than we care to admit! Be clear on what you want to achieve, what DevOps means and what ‘flavour’ is right for you. It isn’t always right for everyone.
Thinking DevOps is simply about combining Dev and Ops teams –If only it were this simple. Combining teams helps but just moving the deckchairs is not enough. For instance, combining teams might not reduce or simplify your number of touchpoints/ handovers, as these can happen within a big team just as easily as they previously occurred between teams.
Treating DevOps as a technology thing – No, no and no. DevOps is about people, process and technology. If anything, the people/culture elements are the most critical challenges.
Positioning DevOps as a single team’s responsibility – DevOps is everyone’s responsibility.That is the point of DevOps. A DevOps team (or project) can help you kick start your adoption of DevOps through coaching and support, but should not be a bottleneck or another silo.
Trying todo DevOps big bang style – It’s 2017 and it’s all about iterating. You can’t just create a DevOps environment overnight. Start slowly and learn what works. Target your high return value streams/ products.
Ignore security and Audit teams – Security and audit needs can pose challenges for DevOps ways of working. For this reason it is very tempting to simply ignore it and hope it goes away. After all, that’s kind of what happens in that DevOps book, The Phoenix Project, right? However, in our experience you are best to involve Security and Audit teams early on. It’s painful but will get you the best results in the end.
Doing it on a shoestring – Let’s be honest, you rarely get anything good for cheap. To get to the benefits of DevOps you will need to invest. This should see savings in the longer term, but don’t assume the savings will come immediately and provide the funding (again, we see this mistake a lot). Even if the benefits come quickly, you can rarely get hold of the savings to spend on yourDevOps investment.
Reverting to type when it doesn’t go right – When things go wrong we typically revert back to what was working. When your DevOps push hits a bump, try to stay the course and keep to your convictions. Make sure you have senior buy-in in advance and that they too are ready for the bumps.
Thinking DevOps is a silver bullet – DevOps benefits are real and for many organisations it is an obvious move to adopt DevOps at an enterprise scale.However, it’s not going to solve all your problems and will even create new ones. Go into DevOps with your eyes open. Don’t set expectations on the DevOps hype – go to real companies who are doing this and understand the real pros and cons.
Measuring DevOps success with traditional IT metrics – This is likely to tell to do the wrong thing. Traditional metrics in IT are typically inward facing. They rarely get at business value, or give a real sense of quality or velocity. Cost saving metrics are quite popular with IT, and these can deter investment in the necessary areas (for example, investment in DevOps experts to supplement your teams). Carefully think through what metrics you really need to drive the right outcomes like increased releases, productivity, speed to fix etc.
