Ops for teams with no dedicated Ops

DevOps practices are being increasingly adopted in the industry. However, in many development teams DevOps is also becoming synonymous with developers and quality engineers getting saddled with performing Ops duties. I have been part of such teams, and I can assure you that it is not a very happy place for developers.

If yours is such a team, here are few things to remember to ensure success in adopting DevOps without a dedicated operations person on your team:

  1. Developers are not versed in Ops tasks: Developers typically are not exposed to operations related things like creating dev/test/staging/prod environments for deploying applications, adding HTTPS support for your application’s endpoint, setting up SSL termination, provisioning and setup of infrastructure resources required by your application (databases, queues, load balancer, etc.), correctly configuring load balancers and DNS, performing blue-green deployments and canary deployments, etc. When starting to perform Ops tasks, developers can get overwhelmed with these concepts, even though they might know about them.
  2. Training developers on Ops tools is essential: You have to train your developers with the required Ops tools such as Chef, Puppet, Ansible, etc. Asking developers to learn them through online resources is not an option. Invest in proper in-person training. If you think the training is costly, keep in the mind that the cost is still a fraction of the cost of hiring full-time Ops person, or even hiring a short-term Ops consultant. Also, remember that it is going to take developers some time to learn these tools and start using them effectively for your team’s Ops needs.
  3. Increase in developer workload needs to be acknowledged: Development managers and team leaders need to understand that their team’s productivity is going to suffer due to developers performing Ops tasks. Not only developers will not get enough time to develop more product features, they will also have hard time switching back and forth between developing features and performing operations duties. Many teams follow a strategy of rotating Ops role between team members every sprint. This is not an optimal strategy as it breaks the mental flow of both – the developer who was performing Ops duties in the current sprint and the other person who was developing features in current sprint but will be taking over Ops duties in the next sprint. It is better to keep the Ops role with the same person for at least couple of sprints (or for a month). Also, having two developers tag team in performing Ops duties can help with spreading Ops knowledge and sharing the load.
  4. Effect on team dynamics and team moral: If your team used to have a dedicated Ops person but is transitioning to one without (with developers and QE sharing Ops duties), be aware that it is not going to be a smooth transition. In such setups, the Ops person is typically supporting multiple teams and hence cannot be dedicated to any one team. Management thinks that it will be possible to keep making progress if developers can pick up some of the Ops duties with the main Ops person overseeing the work and helping out whenever needed. We will warn you that this will create resentment in the minds of developers. They may think that if the Ops person needs to come in and help debug their scripts and Chef recipes anyways, then would it not be better to just have the Ops person write those scripts in the first place? I have seen several developers get very frustrated in such setups.

What can management do to help?

Invest in robust tools that make it easy for developers to perform operations tasks. Such tools should be easy to use by both developers and operations people, who may occasionally need to step in. If your application is going to be deployed on public clouds like AWS, checkout DevOps related services offered by the cloud platform. If your organization has operations folks, work with them to build a curriculum suited for developers and create opportunities for developers to train with your Ops team members using such a curriculum. Most importantly, know that developers are generally eager to learn new things. They will happily take on Ops responsibilities as long as management stands firmly behind them through investment in proper tools, providing appropriate training opportunities, and adequately acknowledging the additional work that they are taking on.