Nigel Kersten is vice president of ecosystem engineering at Puppet. Last week Techerati sat down with Nigel to discuss how DevOps and automation are forcing companies to rethink their move to the cloud. Read our Q&A below to learn how to exploit DevOps approaches while avoiding common mistakes
Cloud adoption has been massive amongst enterprises, but there’s still an awful lot of legacy IT out there. What should enterprises do with it and how does a DevOps approach help?
A large customer I’ve been working with lately refers to its legacy environment as “heritage” which I really love. That’s the IT that still runs the business (often making money) and while it can feel like a big hairy mess and be operationally expensive, that perceived mess is likely to have been caused by years of real-world use, resulting in workarounds for bugs. The right answer might be to replace the stack entirely, but it’s often better to incrementally apply automation while taking a close look at existing processes, particularly approval steps that cross organisational boundaries.
DevOps doesn’t just mean setting up infrastructure-as-code or CI/CD (continuous integration/continuous development). It’s critical to aim for increased autonomy and to speed up feedback cycles. Approval steps in processes are often instituted due to a highly visible failure in a world of manual configuration and deployment. An application team pushes a change that exposes an infrastructure bug, then a rancorous blame game of finger pointing ensues, and the organisational response is to increase the weight of the change process, requiring approval from the application team leads, the infrastructure leads and a neutral change control board that only meets once a week.
Examine these processes, and look for places where automation can replace real-time human meetings. Instead of describing changes in the form of prose, start using an infrastructure-as-code automation solution and replace these meetings with asynchronous code review. The code is the documentation. Instead of having your experts in resilience examine changes and look for potential issues, get them to express this expertise in the form of tests, and run your automation changes through a CI/CD pipeline.
Not only does this approach improve speed and reliability, it increases trust across teams and removes the often antagonistic relationship between teams that forms in change control meetings.
What pitfalls should enterprises be aware of with large scale DevOps initiatives?
We know from our research in the Puppet State of DevOps Report 2018 that the easier it is for employees to cross organisational boundaries to get work done, the more successful your DevOps initiatives will be, and that this holds true at all stages of the journey. The most common issue I see with enterprise DevOps initiatives is that they primarily focus on technical capabilities and fail to address the cultural and organisational issues that stand in the way of progress. It’s essential that you don’t just create a grassroots technical plan, or just create a top-down executive plan, but that you collaboratively build both of these things together with a highly engaged middle management layer. Middle management is where your strategic plan needs to interface with your technical plans, and it’s too often ignored.
Another major pitfall to avoid is the creation of a “DevOps Hero Team” which is considered the guardians of all things DevOps in the organisation. Change has to be pervasive and democratic and creating a silo, where the whole organisation is dependent upon a small team’s approval, won’t get you the results you need.
How does the adoption of DevOps methodologies change the way businesses approach security and compliance?
Let’s distinguish between the two. Security is about securing your IT assets with processes, internal policies and technical controls, whereas compliance is about ensuring your organisation complies with laws and regulations that cover risk, including IT risk.
We’ve seen in our research that the most evolved DevOps organisations have automated security policies, and have fully automated responses to malware and intrusions, including network modification, provisioning clean service instances and archiving compromised services for later analysis. A strong DevOps approach to your infrastructure improves the consistency of your infrastructure overall, and radically improves your ability to patch and deploy changes, improving your security posture significantly.
Regulatory compliance can also be significantly improved with a DevOps approach, but only if you spend the time to examine your existing procedures, and look for ways to implement the required controls and traceability within an automated system. This usually involves ensuring your automation processes are all repeatable, documented, and logged; enforcing revocable points of control around system-to-system access; and regularly examining your code repository permissions. It’s still critical to keep your code read-only accessible to as much of the organisation as possible, which almost certainly requires the deployment of a secret storage system.
What other challenges arise with an increased focus on automation?
I’ve briefly mentioned CI/CD systems already, but the more you deploy automated systems that can make large scale changes, the more critical it is to have a system in place that enables automated testing and validation before deployment. In fact, we often recommend that organisations initially deploy a “walking skeleton” empty CI/CD platform for all deployments, just so that the framework is in place to attach tests to, as problems are discovered. Automated testing is the safety net that lets you automate with confidence and speed.