DevOps means developers now take responsibility for infrastructure and release - but what are the drivers behind this change?

Question

DevOps means developers now take responsibility for infrastructure and release - but what are the drivers behind this change?

I'll put my cards on the table: I am a developer and having worked in both "DevOps" and non- cultures. Having to worry about infrastructure and releases and QA and the associated ceremony is a huge distraction from writing good code.

But the industry is moving in this direction, so what are the reasons for this? What problems did the "old" model of role specialisation engender?

Answer 1

The main reason is the cloud.

It used to be that your code got shipped on floppy disk, and then CD, and then it got deployed to a server, and then it got deployed to two servers (for resiliency)... And all of that deployment could be manually done by a human, so humans were trained in doing it.

Today, your code is often going to dozens or hundreds of servers. Provisioning, configuring, and deploying to those servers cannot be realistically done manually by a human. You need your sys admins to know enough scripting to automate that process, since you're now using Chef or its kin. But frankly, there weren't enough sys admins who could do that. So devs were pulled in to pick up the slack.

And yeah, adding more skills to the ever growing requirements of devs is naturally going to reduce their competency elsewhere. The idea is that allowing the dev insight to the build/release process, they can anticipate problems better, or have the autonomy to improve it. The idea is that the quality of everything increases since the release wins overtake the code-writing losses.

I am skeptical that the trade off is worth it as often as people make it out to be.

Answer 2

There are lots of different reasons for various organisations to move to DevOps.
I'll try to list the ones that come up often.

Reduce time to change cycle
There is often a long time between making a request for change and it actually being deployed and used in the organisation. First it is planned in one of the development cycles by the developers and after it is delivered it is planned in one of the release cycles of operations. Both cycles include testing and in case of problems found, both cycles reset. By integrating development and operations departments, we can streamline both processes.

Software vs Hardware issues
Remember the Bugs Bunny cartoon where Bugs and Daffy are arguing whether it is duck season or rabbit season? Now imagine we instead made it with developers and operations where developers argue it is a hardware issue and operations argue it is a software issue. To the end user this is a distinction without difference. They just want it fixed.
By bringing developers and operations together they'll have to fix the issues. And it may turn out it was a software and hardware issue.

Us vs. Them
In a lot of companies the distance between testers and developers was growing because they were seperate departments and the development cycle was getting more and more formalised and standardised.
With the coming of Agile, developers and testers have been working closer together and we've started seeing each other's point of view on the development cycle and maybe even come to respect it.
Something similar needs to happen between developers and operations, because as both fields mature and processes further formalise and standardise, the distance between these departments is growing. So one of the issues with the traditional model is that it seems like "us" vs. "them" for developers and operations alike. Both not completely understanding the difficulty of the other's responsibilities.

Expectations/Upsides
With DevOps both specialties will learn some of the skills traditionally performed by the other. Noone will expect a system administrator to become a software engineer or a developer to become a network engineer, but both are expected to take on some of the other's responsibilities. This means that when you really need some extra hands, they are there.

And there are some definite upsides for developers: you now have more control over your test environments, you will find it easier to have software deployed to the users and have more people in your organisation to share your love of the craft with.

Answer 3

Writing quality code is just not enough. You're either part of the problem or part of the solution.

For many programmers, you're writing software that is being paid for by some end user. Writing quality code is a good thing, but it's also something clients/managers assume you should always be doing and doing fast. It's like saying a carpenter cuts boards accurately, but are you actually building something someone wants to pay for?

DevOps gives the developers more control over and hopefully forces their code to be in line with the end result. Who is best suited to automate the operations process? End user satisfaction is the major measuring stick. Not only must you write quality code, but it has to satisfy the customer. Sorry, but no one is going back to using lines of code. They don't care if you built your own ORM framework from scratch just like the average home buyer doesn't care if you chopped down the tree and made your own boards. Does anyone want to redo all of their config files because your "upgrade" sets them back to the default?

You want to show-off your developer chops? Build something people want to buy and that includes the entire user experience. It's great that you're writing quality code, but unfortunately, you may not get a bonus if it is not getting released to the paying client's satisfaction. Feel free to blame QA, but your company still doesn't have enough money to pay you more.

Answer 4

It is something that has gone hand in hand with Agile & Scrum. There are no longer clearly defined job roles - everyone is a "developer".

And it isn't just ops. Developers often have to take on business analysis, testing, database administration & build manager roles - the list goes on.

At the heart of the problem was what you might call churn. As the number of different roles involved in a project increased, the more meetings, misunderstandings & resource clashes there were. Getting software in front of the users quickly is the end game and anything that can conceivably get in the way of that has gone by the wayside somewhat.

This isn't entirely a bad thing. Your average developer expands their skills although the jam is getting very thin now. It also heads off arguments between coders and server admins as to where problems lie when deployments go the way of the pear. Devs often want to push out solutions with cutting edge technology and the server admins often have no idea what this means from an admin POV until they're presented with the install set.

The brighter and more forward thinking companies are finally starting to realise that T-shaped people are a good thing. However, there is a difference between thinking they're a good thing and expecting this to just magically happen where a traditional culture had previously been adopted.

Answer 5

I'm sure there are more than a few good reasons for developers to also manage operations and quality control (sometimes). Here are three of them:

• Interest
  Some developers actually want to work all aspects of the product. If they're good at it, and if they're filling a void on the team or providing good support to existing team members in other roles, there may not be any reason to stop them.
• Cost
  Big companies can afford specialized employees. Small companies sometimes can't. Some of these places can hire 1 or maybe 2 or 3 developers who need to be able to simply get working stuff out the door.
• Project Size
  Not every project is a many-person project. If you're building a "small" application, it may simply be overkill to have more than 1 person work it to completion. More to it, small projects with many individuals working specific roles are scary. No one has enough work to do -- even if you can afford to keep them all around to twiddle their thumbs for 6 months, the good ones won't stay. If they don't get bored, they'll get scared, or you'll realize you're paying quite a bit for nothing. Either way, your good employees will be leaving and telling everyone to stay away from you.

... And other reasons, I'm sure.

Answer 6

"Having to worry about infrastructure and releases and QA and the associated ceremony is a huge distraction from writing good code"

At its heart, I think DevOps says that worrying about infrastructure and releases and QA IS writing good code.

In previous roles operating in non-DevOps cultures, I've had numerous issues which, arguably, a DevOps culture could have prevented; performance issues relating to code that was developed on non-representative platforms, character-encoding issues where developers were ignorant of the character-encodings used by a client, deployment instructions that were hand-coded and insufficient for the Ops team without some degree of guess-work.

Now you could argue that increased specialization on both the Dev and Ops sides allows us to overcome some of these, but still lots can only be resolved through some sharing of knowledge and work between our teams.

Answer 7

DevOps doesn't have to mean "Dev now do also Ops". The term originally meant "Dev and Ops people work together tightly in one team". It does mean that the Ops people need to become more like Devs, because automating things requires some sort of programming, and the old manual way doesn't cut it (see the other answers for more detailed elaboration on this point).

From Wikipedia:

DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes

So in my opinion actually if you as a Dev have the same old responsibilities and additionally now Operations responsibilities, that seems a miscalculation on the management part. By automating things it is quite possible that you will need less Ops people and so there are actually cost savings. But DevOps certainly doesn't mean "Let's get rid of all the Ops people and let the Devs to the additional work".

As so often with Buzzwords, a Semantic Diffusion happens, and suddenly people think "Let us make Devs do Ops as well, and I guess we can save money..."