DevOps Zone is brought to you in partnership with:

Benjamin is an independent agile consultant and developer from London, currently working on Devops related projects in the banking and finance industry. He is the maintainer of the DevOps Friday mailing list (www.devopsfriday.com). Ben is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

Why DevOps Matters (To Developers)

12.12.2012
| 4680 views |
  • submit to reddit

DevOps stems from the idea that developers and operations should work more closely together – communicating, knowledge sharing, 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 of course 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 fire-fighting 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 likely 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 care 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 shouldn’t be just to deliver source code. Our goal should be to deliver a product or 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.

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 code base.  

DevOps Helps You Improve Your Site Reliability

If your application has downtime, customers won’t care if it’s due to a software bug, or a hardware outage, or a failed rollout.  They won’t care if it was a silly human error or some arbitrary combination of events that combined be predicted.  All they care about is that they can’t use the system as they intend.

This might be a product of the systems on which I’ve worked, but with good unit and integration testing and good QA testing, it is possible to catch and 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 real world.

For instance, we might find our code performs badly under real world load, that a disk fills up, or that a users users the application in a way which we didn’t anticipate at all – as they are prone to do!  This results in some system failure of degradation.

A DevOps oriented developer or team have a much more stringent focus on these issues and general site reliability.  They’ll not only test their code, but they will think about failure scenarios and mitigate them before code is even released.  They’ll think carefully about detailed testing of their features to minimise the risk of them impacting the broader production system.  They will plan and stage their upgrades to de-risk 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 center, and almost all developers will benefit from this mindset.

This focus on site reliability might mean that sometimes we churn out less 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 like 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 kind of ‘operationally aware’ decisions can lead to massive improvements in the net productivity of the team and the quality of their software.

It’s only by increasing communication with operations teams will we developers learn about these concerns and incorporate them into our designs and every day coding decisions.  Simple thing such as joint production incident post-mortems or the inclusion of operations staff in your early design process can help you to move in the right direction.

Again, these practises are core to the DevOps philosophy.

DevOps Improves Your Career Prospects

In additional to being a more well rounded developer with focus on production, Operations skills such as system administration, monitoring, scripting, change management, and the broader knowledge and experience 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, this will continue, i.e. that the best and most valuable developers will increasingly be those who are the most operationally aware – those who can both code, but also have the knowledge, skills and experience to reliably deliver a working production system over the long haul.

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

(I guess for some people, such as those in startups and small companies, it was ever thus, with developers pitching in on operations type stuff such as deployments and upgrades.)

DevOps Helps Developers To Own Their Platforms And Infrastructure

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 towards infrastructure as code and configuration management, developers are given the ability to own and bring under their control the infrastructure that their code runs on.

People often say that Apple computers are so reliable because they own the full hardware and software stack. Well, 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, because the development, test, and production environments should all be in line, and all infrastructure changes should also be versioned and tested alongside the code assets.

Doing this well removes so many unknowns and can lead to massive improvements in efficiency and 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 PAAS make the hosting environment much more fluid.  For instance, over time operations might want to use these platforms to their full potential and scale up and scale down capacity dynamically.  To do that, they will need to be working with development much more closely to work out how to support this in the applications.

Because of this, I would argue that developers today need to be more aware of the operational environments on which their applications will operate within.

Increasingly, we will also find that cloud infrastructure will be managed through software. For instance, the ability to provision new boxes via APIs or deploy applications onto a PAAS.  Managing large scale infrastructure in an automated fashion likely to start to 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 responsibility is to deliver good code’ to ‘my job is to deliver and operate a successful system’.  Others are about acquiring the skills that will actually allow you to do that.  With Operations staff then also actively moving towards more of a developer mindset and skillset, DevOps is likely to continue to grow in importance.

Published at DZone with permission of Ben Wootton, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)