18

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?

Improve this question
4
  • 4
    Are you saying that your code quality is going down because you do other things, or your code quantity is going down.
    – Caleth
    Jun 7, 2016 at 10:37
  • 1
    Take your cards off the table, please. This just reads like a complaint as-is.
    – svidgen
    Jun 7, 2016 at 15:50
  • 7
    @svidgen If this question were purely a rant, that would be different but the OP is entitled to express their opinion as well as asking a perfectly valid question.
    – Robbie Dee
    Jun 9, 2016 at 7:31
  • 1
    @robbie sure. you'll notice I answered it anyway... but, the "opinion" portion of this question consumes over half the body, sandwiched between the same basic question reiterated, and it distracts from the potential purity of the basic question in this case. But yes. Still worth answering..
    – svidgen
    Jun 9, 2016 at 7:52

7 Answers 7

Reset to default
19

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.

Improve this answer
1
15

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.

Improve this answer
1
  • 4
    +1 - Because it is about the end user and not just the code.
    – JeffO
    Jun 7, 2016 at 11:03
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.

Improve this answer
10
  • 2
    I'm sure you know how hard hiring good software devs is. And now we need them to be good business analysts, interested in QA ceremony and worry about release processes. The number of people who meet the new bar will be vanishingly small.
    – 52d6c6af
    Jun 7, 2016 at 17:28
  • 2
    @Ben: There is no "and now"; these are things good developers were doing decades before someone thought DevOps was a new thing and coined the term. Your job as a developer is to solve problems that extend from someone's need for a solution to making sure the people who have to handle your code after you've written it don't have a hard time. Skimp on any of it and nobody is going to care how beautifully your square pegs are crafted if they need a ten-pound sledge to drive them into round holes.
    – Blrfl
    Jun 7, 2016 at 20:21
  • This seems like an argument against specialisation. That a person should be a jack of all trades master of none. That isn't suggested in any other industry, you don't have electrition-bricklayer-plumber-roofers trying to understand every tiny bit about building a house
    – Richard Tingle
    Jun 7, 2016 at 20:30
  • 2
    @RichardTingle: Nobody's saying you have to understand everything, but you do have to understand the things your product will touch when used. A plumber has to know enough about what electricians do -- or at least work with one -- to know that it's unsafe to run a cold water pipe through a breaker box even though there are knockouts available to do it.
    – Blrfl
    Jun 7, 2016 at 20:52
  • Doesn't even bother trying to answer the question. -1
    – RubberDuck
    Jun 8, 2016 at 23:28
2

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.

Improve this answer
3
  • -1 "are no longer clearly defined roles - everyone is a developer." That is not true at all. A scrum team is supposed to be made up of a diverse set of people, which includes developers, graphic artists, IT guys, etc. The roles don't go away, but the idea is now they are all on a single team, not separate departments.
    – Andy
    Jun 7, 2016 at 18:51
  • 1
    @Andy I'd suggest you read the scrum guide again: Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule. People do of course specialise but by its very nature, it is supposed to be a self-organising entity.
    – Robbie Dee
    Jun 7, 2016 at 19:33
  • Calling someone who's specialty is creating graphics in Photoshop, or someone who's role is translating, a developer is misleading as developer in software projects is universally understood to mean software developer. The scrum guide is simply wrong with that statement.
    – Andy
    Jun 9, 2016 at 1:14
0

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.

Improve this answer
0

"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.

Improve this answer
0

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..."

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.