We are delighted to have been invited to present on May 3rd at the AppD Summit Europe. Taking place in London at InterContinental London – The O2, Steve Thair of DevOpsGuys will talk about “Automation: The good, the bad and the ugly” as part of a track focused on modern software technologies and practices.
The track host at AppDynamics, Director of Product Marketing Justin Vaughan-Brown recently interviewed Steve ahead of the event:
To what degree are DevOps and automation interlinked?
DevOps and automation are linked but it’s not a symmetrical relationship – you can do a lot of Automation and still not be doing DevOps (despite what some organisations might think!).
However, if you are doing DevOps you will inevitably end up harnessing the power of Automation to do some of the heavy lifting, reduce manual errors etc. That said, your DevOps journey doesn’t have to start with Automation – we’ve seen customers get great outcomes by focussing, for example, on the Culture and Lean aspects of the DevOps CALMS (Culture-Automation-Lean-Metrics-Sharing) model well before they moved onto investing in Automation.
Is it wise to automate everything that can be automated?
Automation, like many other things, is subject to the Pareto principle (aka the 80/20 rule) – you’re going to see your biggest benefits in the 20% of the initial effort that gives you 80% of the benefits IF you’re spending your effort in the right place to start with! After that it’s set of diminishing returns, edge cases, nice to haves and so on. The key of course is knowing the “right place” to start, which is where Lean thinking like “theory of constraints” comes in to help you identify the best places to start.
That said, if it’s a mission critical system to your business I think it’s vital to be able to recreate a working, verified application and its associated environment dependencies “from scratch” (from source control) with the absolute minimum amount of manual intervention.
How have you seen DevOps evolve since its arrival on the scene?
It’s evolved enormously so it would take a multi-page essay to probably answer this question but I give 3 quick ones:
- Understanding the role and importance of DevOps in the wider Digital Transformation agenda – DevOps is the “engine room” of Digital Transformation
- The emerging body of case studies about Enterprise DevOps transformation has proven that DevOps isn’t “just for unicorns” and we are starting to see patterns and practices emerge to help with large-scale transformations
- Understanding the importance of digital leadership in DevOps Transformation – almost every successful DevOps case study I’ve read has had some pretty inspiring leadership component.
What are the three biggest pains customers tell you they experience when adopting DevOps across the enterprise?
- People. Change resistance. The “corporate immune response”. 70% of organisational transformations of any type fail. Because changing people’s behaviours is hard. Extremely, frustratingly, hair-pulling hard.
- Trying to use DevOps as a sticking plaster for poorly implemented Agile. If you don’t have really strong foundations of Agile to build upon (or you don’t create them) as part of your DevOps Transformation then you are never going to get benefits we see promoted in things like the State of DevOps report.
- Lack of senior leadership support. Grass-root DevOps initiatives eventually fizzle out without “top down” support.
How do you think the insights provided by APM technologies help drive DevOps goals?
APM tools are fundamental to the 3 Ways of DevOps:
- The First Way – Systems Thinking. I can remember the first time I ever saw the AppDynamics Flow Map dashboard and I can honestly say (as an Ops person) that that was the first time I ever really understood the application I was responsible for as a holistic system. It was integral to me developing a system thinking mind-set!
- The Second Way – Amplify feedback loops. You can’t have feedback loops without measurement and metrics and APM tools give you those metrics. Some of them even allow you to automate those feedback loops e.g. to trigger auto-scaling based on Business Transaction Performance.
- The Third Way – creating a culture of Continual Experimentation and Learning – Again, you can’t have true scientific experimentation without accurate measurement of your variables. APM tools will create that baseline that you can measure the success (or failure) of your experiment against. For example, I’ve used AppDynamics extensively during load testing, which is in essence an experiment of “How does my application perform under load”. The ability to compare metrics to baselines and to compare transaction snapshots was incredibly powerful. We once made a telematics application 52x faster in a single day of load-testing because we were able to test, measure, diagnose, fix, re-deploy and re-test multiple times in a day due to the data we were getting out of AppDynamics.
What’s the biggest myth associated with DevOps? How would you explode it?
I think the biggest myth is still that DevOps is just all about Automation. It’s like saying that the team in Formula 1 that has the best engine will win the series, period, ignoring driver, chassis, aerodynamics, brakes, tyres etc. Automation is only one part of the DevOps equation.
And if anyone’s interested in the research the equation kinda looks like this:
THE ROLE OF CONTINUOUS DELIVERY IN IT AND ORGANIZATIONAL PERFORMANCE Nicole Forsgren & Jez Humble
Book your place now to hear Steve Thair and other thought leaders from The Economist, WIRED, Forrester and more at this free to attend (Day One) event.