Why DevOps Matters To Developers

DevOps stems from the idea that developers and operations should work more closely together: communicating, sharing knowledge and collaborating to increase the quality of the systems that we build and operate.

Though DevOps is an idea that is finding a lot of success and adoption, most of the enthusiasm and thought leadership appears to come from the operations side of the fence.

This is understandable. With operations teams being on the front line and talking to end users daily, they have an obvious motivation not to upset customers through downtime, and an obvious personal motivation to avoid firefighting issues in favour of working on higher value projects.

However, as a developer who has always worked at this intersection of the two teams, I feel that developers should also sit up and give more credence to what is coming out of the DevOps community. By opening up communication paths and adopting operations like skills and mindsets, we can all benefit, both as individuals and as teams, and in the quality of software that we deliver.

Here are some of the reasons why I think this is the case.

DevOps increases the focus on production

Though software teams might divide themselves into development, QA and operations, these can be slightly arbitrary distinctions. The business who are paying for all of this only cares about the net output of what those three teams deliver: the value that the finished production software is bringing to the organisation.

Our goal as developers should not be just to deliver source code. Our goal should be to deliver a product, a feature or a system that is in production and that people are reliably using and gaining business benefit from. Though we might personally get our motivation from cutting code, it is all for nothing if the work we do never makes it to production, or if the users of the application have a bad time once the work hits the real world.

To my mind, the operational focus on production and delivery espoused by DevOps is a good thing which usually leads to much more net value being created for the business. DevOps oriented development teams have a focus on value and their user base, rather than their codebase.

DevOps helps you improve site reliability

If your application has downtime, customers will not care if it is due to a software bug, a hardware outage or a failed rollout. They will not care if it was a simple human error or some arbitrary combination of events. All they care about is that they cannot use the system as they intend.

This might be a product of the systems on which I have worked, but with good unit and integration testing and good QA testing, it is possible to catch most software bugs that would impact a large percentage of the user base. However, where things more typically go wrong is when the system comes into contact with the wider world.

For instance, we might find that our code performs badly under real load, that a disk fills up, or that a user uses the application in a way we did not anticipate at all, as they are prone to do. This results in some system failure or degradation.

A DevOps oriented developer or team has a much more stringent focus on these issues and on general site reliability. They will not only test their code, but will think about failure scenarios and mitigate them before code is released. They will think carefully about detailed testing of their features to minimise the risk of them impacting the broader production system. They will plan and stage upgrades to remove risk from releases, and always have a rollback strategy. They will talk regularly with operations to ensure that they are fully taking into account their experience with keeping the site available. In short, DevOps rightly places site reliability front and centre, and almost all developers will benefit from this mindset.

This focus on site reliability might mean that sometimes we produce fewer pure lines of code in a day, but it means that we move forward more slowly, predictably and reliably, keeping the system stable and available.

DevOps helps you build better software

By being more operationally aware of the production context that our code lives within, developers will also design and build better software.

It might be something simple such as choosing to add that additional logging statement that you know will make troubleshooting easier later on, or something more complex such as designing a component for horizontal scalability for future growth scenarios. These kinds of operationally aware decisions can lead to massive improvements in the net productivity of the team and the quality of their software.

It is only by increasing communication with operations teams that we developers learn about these concerns and incorporate them into our designs and daily coding decisions. Simple things such as joint production incident postmortems or the inclusion of operations staff in your early design process can help you to move in the right direction.

Again, these practices are core to the DevOps philosophy.

DevOps improves your career prospects

In addition to being a more well rounded developer with a focus on production, operations skills such as system administration, monitoring, scripting, change management and the broader knowledge required to maintain and run complex systems are genuinely useful for developers to acquire.

In most of the software teams and hiring decisions I have been involved in, a developer with this profile would have been more attractive and more valuable than someone with superior coding skills but without the same degree of production awareness.

I believe that as a result of DevOps and other trends, the best and most valuable developers will increasingly be those who are the most operationally aware. They can code, but they also have the knowledge, skills and experience to reliably deliver a working production system over the long haul.

This is particularly true in tough and resource constrained economic times. With fewer people having the luxury of saying it is not my job, the generalist will get ahead.

DevOps helps developers own their platforms

A big element of the DevOps movement is the idea of infrastructure as code. This is the idea that we can define our infrastructure and configuration in descriptive files and metadata, and then be able to test and repeatably deploy that infrastructure and our applications on top of it.

This is such a compelling idea with many benefits, and yet developers do not always embrace and own configuration management tools as much as our operations colleagues.

By moving toward infrastructure as code and configuration management, developers are given the ability to own and control the infrastructure that their code runs on.

People often say that Apple computers are so reliable because Apple owns the full hardware and software stack. With infrastructure as code and repeatable deploys, developers also get to develop and deploy and own the whole platform on which their software is deployed.

It worked on my machine, or it worked in QA, should be a thing of the past in a mature DevOps team making use of tools such as Vagrant and Puppet. The development, test and production environments should all be in line, and infrastructure changes should be versioned and tested alongside the code assets.

Doing this well removes so many unknowns and can lead to massive improvements in efficiency and the quality of software development.

DevOps helps you manage modern infrastructure

DevOps has emerged at a time when cloud hosting, infrastructure as a service and platform as a service are also reaching widespread adoption.

Cloud and platform services make the hosting environment much more fluid. Over time operations might want to use these platforms to their full potential and scale capacity up and down dynamically. To do that, they will need to work with development much more closely to work out how to support this in the applications.

Because of this, developers today need to be more aware of the operational environments in which their applications will run.

Increasingly, cloud infrastructure will be managed through software. The ability to provision new machines via APIs or deploy applications onto a platform will make large scale infrastructure management look more and more like development work. Development and operations will increasingly start to look like one and the same role.

So these are just a few of the reasons why I think developers need to look at DevOps in a lot more detail. Some of this is about a broadening of mindset from my job is to deliver good code to my job is to deliver and operate a successful system. Other parts are about acquiring the skills that will actually allow you to do that. With operations staff then also actively moving toward a more developer like mindset and skillset, DevOps is likely to continue to grow in importance.

If you want to go deeper, read how to do rollback well, my notes from day one at GOTO Copenhagen, or the companion piece on metrics driven development.