If you work in technology, it should come as no surprise when I say DevOps adoption is on the rise. Almost three-quarters of organisations surveyed globally have already adopted DevOps in some way, and the past year has only seen this increase as businesses look to do less with more – often using DevOps and automation as the tools for this efficiency. Between late April 2019 and late April 2020, there was over 40% year-on-year growth in open source project creation per any active user, according to GitHub, with a big spike just after the first lockdown.
But while there’s plenty of businesses diving into DevOps, there are still widely-held misconceptions that hold them back from reaping the true rewards. There’s no one way to do DevOps and each organisation has its own unique approach. When done right, it can provide value to organisations by improving software quality and stability while reducing production lead times. For developers, it makes their lives easier! DevOps reduces complexity and gives them the processes and tools they need to get work done well. Above all, the right DevOps approach holds strong business benefits for those that adopt it correctly.
So what are the big misconceptions holding businesses back? Here are the four I see the most:
1. Tools and automation are everything
It’s easy to get caught up in the shiny new toys of DevOps. But while tools are important and automation can be powerful when used right, these alone are not enough to create a successful DevOps approach. We often hear teams say they’re using a tool, so they’re ‘doing’ DevOps. Just like how using a microwave isn’t always cooking, automation and tools are the means, not the method, of DevOps.
DevOps should always start with people, then be put into practice with your team’s nuances in mind. I always refer to the Three Ps – products, people and process. Without one, the approach breaks down and fails to deliver results. Normally, our goal is to help developers accelerate their code building process and this is where automation comes into play, such as automation development workflow for CI/CD. Given the majority of vulnerabilities remain unpatched even past 30 days, it’s important to use integrations that don’t just identify vulnerable dependencies but fix them automatically. Automation not only increases the time developers spend on code, but also improves job satisfaction because they can keep distractions at bay and focus on work driven by creativity and collaboration. Create a culture with people at the centre of your process and you’re on the right track.
2. There’s only one way to do DevOps
You wouldn’t take the same supply chain approach for a hardware shop and a grocery store, so why should DevOps be one-size-fits-all? No two organisations build software in the same way; their CI/CD best practices differ but so too do their broader business processes. DevOps is a way to deliver high-quality software quickly and in support of business goals. Each business has their own goals so their starting point will naturally differ; while there are common DevOps principles and practices, each approach should also consider an organisation’s strengths, limitations, and talent.
What does this look like in action? Take the example of automating beyond your CI/CD processes. This can extend to other parts of your software lifecycle – team notifications, identifying security breaches, or GitOps – to build greater velocity. Every business will have unique processes so there’s little value in trying to carbon copy what someone else is doing. Instead, focus on how your organisation can benefit most from automation and improved asynchronous collaboration. Standardising and automating your infrastructure, application deliveries and code will help you adapt quickly. After all, the big picture is about finding ways to ship better software, faster.
3. There’s no place in DevOps for security
There is a very important place in DevOps for security – and it’s not being bolted on. Rather than being the icing on top, it needs to be baked into the cake itself – if the cake is software development. Taking a DevSecOps approach means baking security into every step of the production cycle. IDC anticipates that by 2024 DecSecOps will drive half of all new applications in Asia-Pacific, with security testing introduced from the outset. What is concerning, though, is the half that won’t be. We often see challenges adopting the right DevSecOps approach; the relationship between security and development teams is usually reactive or incident driven. Fixing vulnerabilities at the production stage is far more expensive and time consuming than during the build or test process.
In some instances, teams will have the tools but not necessarily use them. Some even revert to inefficient and risky methods like emailing code scanning results! Security is vital to effective DevOps and DevSecOps amplifies the contributions of security experts via automation and shifting security left. Integrating security as part of the software development life cycle, at every stage, means it is a priority and not an extra add-on at the end.
Whatever stage of the DevOps journey you are at, developers should be at the core. The most sophisticated automation isn’t effective without supporting the right people. Whichever tools or processes suit your business, DevOps is a people-first approach that aims to bring great minds to collaborate, improve development, and ultimately meet business goals. Like everything in technology – or involving humans for that matter – DevOps tooling and practices will naturally evolve and change. That’s why, above all, embracing a culture that celebrates teams and their achievements is important to the success of DevOps. If you keep that at the heart, the rest will follow.
