It seems like everybody’s talking about DevOps these days.
For a while now, it’s been one of those “next great thing” things. But in my role working in marketing, it’s not something I’ve really had to deal with, so I just mentally filed it under “some technical fad I don’t have to worry about” and ignored it.
That was until this week when we were reviewing our marketing collateral and realized that we don’t actually have anything that talks about the DevOps work we’ve been doing for clients here at Bleum. I decided it was time to shuffle the mental filing cabinet and move DevOps into the “you should really understand this” section.
Although I work in marketing now, I studied computer science at university, so I had a frame of reference to start from. I remember working on projects throughout my course and having to deal with what I assume is every developer’s least favorite thing in the whole world: code management.
What You Actually Do When You Write Software
To the non-technical folks, this is basically how writing software works:
- You write some code, let’s say, to add a new feature to an application.
- You test that it works as you expected it to. This is called unit testing.
- You test that it works with other parts of the code that it directly interacts with. This is called integration testing.
- You test that you haven’t accidentally broken something somewhere else in the system with your changes. So you test everything else, or at least the critical functions. This is called regression testing.
- You are now happy your code works happily with the system, so you release your code into the live (production) environment. Maybe these releases happen once a week, or once a month, or once a quarter, or “whenever everything is done”.
- If you didn’t manage to test completely (because you missed something or because your testing environment was a bit different from your production environment), there may be a defect. This means you might need to roll back your release to the previous version and go back to step 1 to fix it.
So, actually, a lot of the time was spent testing and building and deploying and not actually writing code.
If I’m honest, it’s one of the things that turned me off working as a software developer—the actual amount of time you spend doing the fun and mentally stimulating stuff can be surprisingly small, particularly at the start of your career.
Where Things Can Get Tricky
Now, obviously as you scale up the size of your development, things get more complicated. There are more interconnected pieces of the system, there are more surprising ways to break something that seems very unrelated to what you have been working on, and there are just more people all going through this process time after time trying to organize, collaborate, and not screw everything up for each other. You may have a team of developers, a team of testers, a team of network infrastructure guys, a team of people managing the databases, someone managing the builds and releases, and so on.
If this sounds like a recipe for problems, it’s because it is. And it’s not particularly surprising that a number of large and very expensive software projects have been a total failure. If you don’t manage this process well, you end up with a mess. Building complex software is hard.
A New Approach
DevOps seeks to create a new way of doing things by creating a collaborative process between developers, testers, system admins, DBAs, and anybody else who might be involved, and then streamlining that process. Implementing DevOps is about implementing both a culture and a toolchain.
One thing that DevOps loves is automation.
Look back at the steps above. What if you could automate steps 2-6 (and a number of other intermediate steps along the way, like creating a new build)? All that time spent testing and building and deploying could happen automatically. Sounds good, right? The diagram below shows an example:
As a developer, I’m pretty happy with how that sounds—less work for me.
As a systems engineer, I can spend more of my time working on optimizations and adding value, and less time on the monotonous release work.
As a tester, I can focus my efforts where I add value, not on doing the same tests over and over again.
With the automation comes another advantage: a dramatic reduction in the time taken to complete steps 2-5. And the reduction we’re talking about really can be dramatic.
Earlier I mentioned deploying weekly, monthly, or even quarterly, but DevOps lets you go faster. Much faster.
Amazon release code to their production environment every 11.6 seconds. This means that they perform more than 7,000 releases every day. Even Facebook, with the staggering breadth and scale of their global systems, release twice per day. That monthly release cycle feels pretty long now, right?
Making an Impact
But how does this change affect the activity going on earlier—the actual writing of code?
I asked our VP of Engineering, David Buck, to help me out by explaining his take on DevOps.
“The DevOps movement has afforded many positive changes for developers: fewer hours spent firefighting messy deployments to production, faster feedback on changes from the business, manageable check-in/build, less time wasted waiting for a downstream process, and far lower chance that a code change will become dependent on others’ code changes that may cause problems down the line. It’s no wonder that surveys show again and again that staff satisfaction and engagement levels are far higher when a company (truly) implements a DevOps program.”
David pointed me towards some research on this, so I went away and read the 2016 State of DevOps. You can get that here. It’s well worth a read at some point, so pop it on your Kindle or smartphone for your commute.
One of the statistics that jumped out at me from this report was not a technical statistic, but this one:
From the 2016 State of DevOps report
So when DevOps is implemented correctly, everybody involved in the process seems to be much happier. This makes sense to me; people spend more time doing interesting, stimulating work, and less time on the mundane.
DevOps in Practice
I wanted to know a little more about the practical impacts of a DevOps team, so I spoke to our Engineering Manager who manages a DevOps team on behalf of one of the biggest online retailers in the world. I was really keen to hear his take on DevOps in the wild.
“The most important thing to realize about DevOps is that it is a cultural shift; it is primarily a change in mind-set. It’s about optimizing and streamlining the release process from every perspective, and it can be a tricky thing to get started. You need to work across multiple streams in the organization and be prepared to challenge existing mindsets and approaches. A small improvement in one process can have a massive knock-on improvement further down the line, so it’s important to take a holistic view.”
And what benefits has DevOps had for this client?
“The most obvious benefits are in terms of release cycles, productivity and defect density.
Firstly, right now our development teams are releasing every 2 hours. Before DevOps, we were following a monthly release cycle.
Secondly, focusing on resourcing, our original WebOps teams (including System Admins, Network Engineers, Database Admins, Helpdesk, Monitoring, Release, Storage and InfoSec) was comprised of 250 engineers; now around 100 engineers are supporting an even wider scope than before.
And finally, as the releases have become smaller and more frequent, we see far fewer defects and the turnover impact is smaller for bad fixes.”
So, in summary, here are some things that DevOps can help bring you:
- More frequent deployments
- Significantly shorter lead-times
- Fewer defects
- Higher productivity
- Better quality assurance
- Happier employees
- Fewer sleepless nights
Sounds like magic, right? Obviously, with any paradigm shift, there are pitfalls, traps and implementation pain points, but it seems to me that by taking the time to do it right and truly embracing the changes, there are a lot of benefits to be unlocked from DevOps.
I’ve moved DevOps again in my mental filing cabinet after researching this article and talking to people across Bleum. It’s now in the “wow, this is pretty cool” section.
Mike has worked in various roles including data analyst, SAP specialist and training consultant over the last ten years. He has worked at Bleum since 2014 and currently works in marketing.
Connect with Mike on LinkedIn