According to a recent State of DevOps report, organizations that adopt a DevOps culture have 60 times fewer failures than those not implementing a DevOps approach. Here Alex Knol, NearForm’s Director of DevOps and David Gonzalez, DevOps Consultant at NearForm share some of their observations on how organisations approach DevOps, what to do and what not to do to make DevOps a success within your company.
1) DevOps is hyped – in the wrong way.
Right now there is a tremendous amount of interest in DevOps – and it’s a buzz word in IT around the globe. However, despite their best intentions, too many organisations are getting their implementation of DevOps wrong. Successful DevOps is about ensuring a set of processes can be used effectively by the right teams of people – this can be tricky, and it can take some time. Deciding to use DevOps is not as easy as recruiting the right people and the right set of tools. It’s a deeper change in culture that can be achieved if approached correctly.
2) DevOps requires the full picture.
Sometimes organisations have a greenfield situation where they can implement DevOps without having to deal with legacy baggage or historic team structures, and the implementation is done successfully. But in reality, most companies have an element of transformational change that is required. Silos need to be taken down; holistic views of the organization are necessary; an understanding is needed of processes from the very beginning right through to the end; software updates and the way they are rolled out should be reviewed; all of these will contribute to gaining a complete picture of how the customer or end-user will use the software.
3) Know where you are going before you start.
Often, developers talk about security or testing in a way that requires ‘shifting left’. We need to understand how software is delivered, and know the entire life cycle right to the end after development is done. Only then can we incorporate those lessons early on in the process, so that we’re catching potential problems earlier on in the development cycle. The process can be turned upside down using techniques like design thinking.
4) Development and operations should not be “two sides” to the business. They should all be working together.
If developers don’t have access to the right skills, or the right level of access to maintain production, they will meet bottlenecks and in that case, (hopefully) complaints will surface. This is a common sign that your culture needs to shift. If you are involved in software, you should be able to maintain it, design it, and build it. If you are trusted to build it, you should be able to run it. Developers and management need to discuss and communicate. There should be a shared responsibility, and the culture should not allow people to blame others for problems but take responsibilities as a collaborative team to create solutions.
5) Just hiring people and calling them ‘DevOps’ doesn’t work.
We have seen this approach everywhere. Management decides they want to create a DevOps group so they hire with that job title, but sometimes they end up sitting in yet another silo. In other instances, companies grow by acquiring other companies or teams. The understanding of DevOps in those teams can be vastly different and it can be troublesome for them to integrate. Sometimes the people called DevOps should actually be called Platform Engineers because they should have a shared responsibility for the project’s success, across both design time and run time.
6) Automation in CI / CD is an essential part of DevOps.
You need to enable teams with self-service capabilities. Automation tools can show you how your software will be deployed across all different platforms. Automation is there to provide that self-service capability to teams. That being said, automation is a powerful tool, but if you don’t use it correctly by shifting your culture, it won’t be a help.
7) DevSecOps may be another buzzword, but it’s a powerful tool that should be used correctly.
What happened with Equifax’s enormous data breach? An attacker was able to execute criminal code because they were using an old version of a software platform. The organization had deemed it too risky to update or it wasn’t deemed the right time to update, and the result was a cyber attack. One of the main jobs of DevOps is to ensure patching is kept up to date. Automation can help organisations maintain their patching schedule, and vulnerable versions of libraries should be detected early on before they hit production.
8) Security is a benefit of a proper DevOps implementation.
Information should flow freely between management and development – DevOps, when done correctly, should enable this. If a culture of collaboration is embraced, DevOps enables lean/agile principles, a reduction in failures, and increased productivity. Crucially, it also paves the way for more secure software platforms.
9) If you were confident, you could deploy on Friday.
There is a mantra in software development: never deploy on Friday. But we’re a Devil’s Advocate. If you’re confident that what you are deploying is going to work, then you can deploy on Friday without worrying no one is around to fix any problems. That’s a main benefit of DevOps – giving teams confidence in what they are building.
10) In the long run, DevOps is cheaper than traditional software development
If you remove friction from any process, that will translate into revenue and growth. Successful implementations of DevOps will positively impact the bottom line.
If you enjoyed this, we recommend that you listen to our podcast “DevOps – Is it a culture, or a magic set of tools?” with Alex Knol and David Gonzalez.
Some other post you may like:
- 7 Reasons to Automate Security in your Pipelines
- Virtual Coffee With NearForm Director of DevOps, Alex Knol
- How to run a Public Docker Registry in Kubernetes