In June 2017, Logz.io conducted their annual DevOps Pulse survey, responded to by over 700 engineers, system administrators, and people in similar IT positions from around the world. The Pulse survey full study was focused on understanding DevOps adoption, its culture and success. Some interesting conclusions were drawn:
- About half of the companies surveyed have adopted or were still in the process of adopting DevOps
- Difficulties of DevOps adoption revolve around changing company structure and processes
- The top problem is a lack of resources (time and expertise)
- Quality of the products has generally improved significantly, where adopted
- Employees feel like they’re being squeezed – causing fear of burnout
It seems like DevOps adoption faces the exact same challenges compared to any other paradigm shift introduced on the workfloor in the last few decades : organizational malfunctions. Although the technology itself is promising and largely effective when introduced successfully; it also calls for a complete re-haul of current Dev and Ops processes.
Find out 5 tips for a sucessful adoption in culture, infrastructure and procedures in a tech company to avoid commons pitfalls when adopting Devops.
Here are some commons pitfalls when adopting Devops
It turns out that DevOps adoption is no different from any other structural change, with the common pitfalls being the usual suspects:
- Responsibilities of Team and Individual Contributor are not clearly defined, leaving people guessing as to who is doing what and by when
- Contributors are not adequately trained on the tools and processes
- Communication between teams is not adapted to the new processes and tools
So how can we avoid common pitfalls when adopting DevOps ?
Find out 5 tips bellow to avoid common pitfalls when adopting DevOps.
1. Get everyone on board
Having a few system admins or developers set up a gitlab server integrated with mattermost, ansible, docker/kubernetes and a few gitlab-ci.yml templates is cool. However this does nothing to improve your product’s quality or reduce it’s time-to-market. Avoid team members being distracted by new technology – it has to be in line with the company strategy.
2. Define clear roles and responsibilities
Once everyone is on board, the target workflow, life-cycle management flow and architecture can be defined. One of the key challenges is to decide who does what – both in terms of people and in terms of tech. Gitlab is capable of doing many things outside of distributed version control but you know the saying – « Jack of all trades, master of none »? Avoid over-complexity and define clear hand-offs. When it comes to responsibilities – let the developers deal with the aspect of code organization (compiling/building/testing) and the System Ops deal with the aspect of infrastructure (systems/resources/integration/deployment). Here’s an article on they key roles of DevOps.
3. Pick a project
Once everyone has some idea of their role in the DevOps process and there is a basic DevOps infrastructure in place – kick the tires and select a single project. Avoid dependencies on legacy applications and databases, and start with realistic expectations. Those ansible playbooks will need to be refined a few times, gitlab runners upscaled, jmeter scenarios improved, feedback mechanisms put into place and everyone needs to warm up to the idea of automated deployment of multiple instances on a docker swarm. Rome was not built in a day.
Even when everything seems peachy in the Dev and Test branches – do not auto-deploy on Production unless all the complex projects work flawless and you’ve checked all the ins and outs in terms of security. Automated processes have a way of hiding complexity and associated system and security flaws. Better to have some delay on a delivery than to find out this new code is gobbling up resources faster than a speeding ticket. Some ideas about deploying in a production environment.
5. Implement monitoring
Web application monitoring is a critical business decision. With every commit popping up some test containers in the cloud and resources being dynamically re-allocated, snapshots and clones being created, test scenarios being executed and auto-cleanup scripts undoing failed scripts – it’s important to have a system that auto-discovers the current state of affairs and alert you when your CI/CD cycle is causing a sudden rise in slow queries on the shared database or a diminished resource availability problem. Even when the team is convinced that a certain project is contained, it is difficult to predict where a complex automated delivery might have a negative impact. To measure is to know, so you have to select your devops metrics for a successful adoption of this approach.
Contact-us to avoid common pitfalls when adopting DevOps !
At Syloe, we advise you on how you can implement a Devops processus and so how you can avoid common pitfalls when adopting DevOps. Contact us for more information.