We all know about the DevOps revolution, a lot of us have read the Phoenix Project and the new book the Unicorn Project by Gene Kim and friends. Two books about a mythical American company and their process transformation to a DevOps culture and how it saved their company from disappearing from relevance. This may seem a bit over the top, but in today’s technology market, you cannot afford to wait 6 months for a product to finish its development cycle. Your company can not afford to wait 6 weeks for a new server or service to be provided to them. Today the mantra is “deliver at the speed of need” and this is what DevOps at its purest delivers to an organization.
So how do you as an organization move from where you are to a DevOps operation? Or move your development team from waterfall methodology to an agile or DevOps culture.
Definition of DevOps
Firstly we need a couple of statements about what is and what is not DevOps. With a lot of different definitions floating around, the following is part personal opinion, part fact.
What is DevOps?
It is collaborative – people need to work together to get things done, It will need buy in at the highest levels in your company to move to a DevOps culture, for example Finance will need to be flexible on equipment purchase, this brings us to our second tenant,
It is flexible – the need to move at the speed of need requires a tactic change in thought process and business processes, budgets need to move from quarterly cycles to monthly allowances or even smaller timescales to allow flexibility in acquisitions and cash flow. Work needs to be flexible in that roadmaps need to be defined more granularity, work needs to be defined better, workflows need to be better understood which leads us onto our third tenant.
It is cross-functional, one of the biggest hurdles in developing a cogent DevOps practice is breaking down silos, the past 20 years has been about building up empires, we have storage teams, network teams, server teams, desktop teams, helpdesk, DBAs etc. each with their own priorities. Squaring to box, ie traversing the management stack to move requests to other teams, slows to process down to much, this leads up to our fourth Tenant
It is agile – DevOps is about Speeding up the delivery point of work, by taking out the delay out of decision making, it is breaking work up into smaller more manageable chunks, it is about building cross functional teams focused on delivery of work, integrated testing, feedback pipelines. Continuous deployment and improvements integrated security – not bolted on.
What is DevOps not?
It is not a product you can buy, it is not Puppet, Chef, Terraform, Vagrant or Ansible it is not Docker or Kubenetes. Although these tools are often used in companies that ‘do’ DevOps, DevOps is a State of Mind and process changing paradigm.
How to move from where you are to a DevOps focused entity.
Your path to DevOps can be a long journey. But as they say every Journey begins with the first step. Again as they say the first step in any journey is often the hardest, and this is true from the perspective of moving to a DevOps culture.
Step 1 – Mindset change
This is often the most difficult, it is hard to teach old dogs new tricks. Managers like to see defined timelines – product managers expect road maps, Finance expect quarterly budgets etc. shareholders like understandable reports.
The move to a DevOps culture seems easy. Get in Puppet and Ansible or Terraform move everything out to the cloud and that’s it. But no. It is about process and administrative change at all levels of the company. Managers are going to loose their fiefdoms, silos are going to be collapsed to speed up decision-making processes.
Decision-making is going to move from a top-down approach to a bottom-up approach. The teams closest to the work will become responsible for making the right decisions, autonomously.
Step 2 – Training
This means that personal will need training, why? Processes will change. How a virtual machine is deployed will change, new technologies will be introduced to fill in gaps and processes. New technology will need to be learnt. And new way-of-work will require behaviour to change, albeit slowly. Both of these require training, coaching and external expertise to kick-start the learning process.
Step 3 – Leverage Automation
Repetitive tasks will be automated, and those automated tasks will be improved upon in a continuous feedback loop. This will lead to more automation as low hanging fruit are tackled. This is scary as people think that their jobs are being replaced, this is not the case. It is an opportunity to grow. Learn new things and improve. Automating your deployment of Virtual Machines, moving to Infrastructure as Code as a deployment methodology. Automated application deployments leads to you being able to move away from continuous break and fix works as the human element is removed from deployment.
Step 4 – forget this is how we’ve always done it
This is the next major pain point. Forget about this is how it has always been done here. It is a fact that things change. The “This is how we’ve always done it” movement is the cry of those that are scared of change. Without change, we would not have moved on from cave living. From a technology perspective, we would still be in a mainframe world with 3270 Terminals over thicker-net with Vampire drops (ask your Grandad). Your skills will be utilized in different ways.
Stage 5 – Celebrate failures and learn from them
Communicate regularly, this does not mean more meaningless meetings about meetings but focused discussions. Weekly meeting to discuss what needs to be done, prioritise and discuss failures. The discussion of failures is important, not so that blame can be apportioned but as an opportunity to learn. Foster a culture of no blame. This cannot be given enough emphasis. People need to be able to freely admit what went wrong, to enable the organization as a whole to improve their processes and procedures. What went wrong is as if not more important than what went right.
Stage 6 – Foster Collaboration
Teams will change. Silos will be broken down. Teams will be dynamic based on requirements rather than organisation charts. Engineers will need to be enabled to make decisions without fear of getting into trouble. If a team needs a DBA it will have one, same with networks, storage, and compute, and any other application stack member, they will be empowered to drive their work stream. Testing and security will be built into their work-stream from the start. Testing allows fast failure, quick communications allows faster feedback into the next integration. Work pieces will be small and discrete.
Stage 7 – Integrate tools
The correct tools for the job at hand will be used. This will be an ongoing process. Remember the feedback loop. Test, test, test, iterate and test again. Do not be afraid of dropping a tool if it is not fit for purpose. There is no defined set of tools for DevOps and you should develop your own practices and procedure, but that being said. Remember that things change and improve all the time this leads on to the next tenant.
Stage 8 – Stay flexible
DevOps is all about continuous Improvement, which leads to continual deployment, a properly functioning DevOps based operations team will be able to push out application updates and improvements at the speed of need. Why because their testing methodology is tested and trusted. The production environment is the same as their staging environment, which is based off the testing environment, their build methodology is slick, and quick, they have no failure points, why because their CI/CD pipeline as improved to the point that they have been designed out.
Flexibility is key the ability to manage a high change environment is scary the first time that a change is pushed into production during core work hours is a terrifying moment, but the freedom it gives is well worth it.
Stage 9 – Concentrate on the End Zone not the intermediate steps
Your road-map becomes your bible. Your weekly meetings define the work to be carried out, each step in the journey actually delivers something tangible to the user. If you are a development house you are freed from the prison that is minor and major program releases. If you are an operations department you are freed from the pain that is major program updates.
By the time you have reached stage nine you should as a department be freed to concentrate on delivering true value to your customers. For example: employee on-boarding. When you can deliver a new laptop to your end-users without issues on the day that they start their role, or the service desk being able to deliver a replacement device and not loose any of their data or settings, or application patching is seamless and results in no unplanned outages or even planned outages – you start to see the benefits of DevOps. You are freed to elevate your thinking and understand your users pain-points and concentrate on improving those areas, rather than having to deal with yours.
Summary
I hope that I have shown that simply setting up a GitHub repository and learning Terraform and Puppet is not enough to become a DevOps focused Operations team. DevOps is a state of mind and as process driven a paradigm as Waterfall is to development or PRINCE2 is to Project delivery. For a move to DevOps to be successful buy-in from the whole company will be needed and things may appear to get worse before they start to improve.
