7

Please bear with me as this might get a bit deep. I’ve been reading though some documentation of a error logging SaaS I’m using in an application I’m building.

Quite a few times they gave me the impression that DevOps is sort of the responsibility of all Developers. E.g it’s something someone implements as part of a project, vs DevOps being a title/role in a business... I’d akin it to... Imagine, me as a developer having to write a micro-service because it’s required to be effective, vs another guy walking around calling himself a “Micro service” doing only micro services.. sounds a bit strange right?

I can see merits to both and if anything I know the lines are pretty blurry at the best of times in all dev fields anyway... my best guess is maybe a DevOp would be more specialized?

Question Based on the above...

What is the expected role of a DevOps person then, vs say a Developer, if going by the school of thought that DevOps is the responsibility of all devs?

... like what’s there left to do then for a DevOp then?

2
  • 1
    @030 he is referring to developers vs DevOps "if going by the school of thought that DevOps is the responsibility of all devs" Commented Dec 13, 2017 at 21:57
  • @Pierre.Vriens your answer on that question makes a lot of sense to me. Just hope I don’t prefer it because it seems to support my argument. It’s difficult being unbiased sometimes :P. Commented Dec 14, 2017 at 5:12

3 Answers 3

7

There are two strongly connected but still a bit controversial things in the industry that makes this kind of question being asked all the time since 2010.

First one is a nature of DevOps methodology itself. It was born all around idea of better collaboration between different parties of software delivery process. This involves a lot of non-technical aspects, like shared responsibility, better communication, knowledge sharing. Another improvement that was aimed - was product delivery itself, starting from designing software and up to deployment and operating live systems. So it brought us technical improvements as well. There was nothing new, actually, as all those things you see in majority of “DevOps job openings” like CI/CD, configuration management, log management, monitoring, whatever – were existing for decades, before even term DevOps was used for the first time. So DevOps as methodology just put all this bits to one plate.

And here comes the second thing: hype. Popularity of the methodology arisen - as it was intended to solve problems that majority of industry players had more or less. So some people started to see non-existent “silver bullet” here. Some magical potion, which simply could solve issues they have. So we got high demand here. And as a result – supply started to grow as well. And obviously businesses were looking for someone who could implement “DevOps” for them. How do you usually initially identify someone who could work with some tool/methodology/whatever? I bet - the answer is - by looking for appropriate badge in their CV:)

People realized, that being badged as DevOps engineer, not simply being a sysadmin or developer – makes them more unique and valuable on the market by that time. That is how market works overall - you make offering and advertise what demanding person is looking for, so he prefers you as a supplier, not the other guy.

And somewhere here we got that focus shifted from whole methodology to technical side of it. I have no exact answer, why this happened, probably because majority of market players missed the key point of DevOps ideas, and understood only those which could be measured easily.

Do we have Jenkins running now? Tick! Do we use Chef/Puppet? Tick!

It is way harder to make same kind of measurement for collaboration between team members, communication improvements, whatever. And higher management usually looking for kind of measurable results, rather then ephemeral ones.

So you are absolutely right – DevOps should be done by everyone in a team, just because it is about team itself, not some person who makes changes, and everyone and everything else remain old-fashioned.

1
  • 1
    This is an awesome answer and should have 15 upvotes by now. Part of my frustration with the industry, ah heck, corporate America, is the mentality that DevOps is a set of tools, like you said, we got Puppet, tick, we got Jenkins, tick. I have done DevOps work without the title and did not need the laundry list of DevOps tools to do it. kudos Serhii.
    – Daniel
    Commented Mar 9, 2019 at 4:40
6

DevOps these days...

DevOps is known/meant to be more of a culture than a job title, but we also cannot ignore the fact that a vast amount companies all across the world have "DevOps engineers" employed.

What Wikipedia says:

"The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives."

Answer (my perspective ):

As a DevOps engineer myself(opens a can of worms), I realize that I am more of a support role to development teams.

  • Aiming to facilitate and create useful systems/tools that I as well as the developers can easily manage and use.

  • Automate any manual work being done and creating streamlined CICD pipelines ensuring the developer's code gets tested and then deployed to production with ease.

  • Ops and Monitoring to notify us and the developers of any issues so they can be resolved ASAP.

Making all of the "DevOps" responsibilities easy to "share" and deal with from all the technical and sometimes even non-technical teams or individuals of a company.

1
3

The role of DevOps is still being formed so the responsibilities can be different between organizations. Also, this was the developers responsibility not too long ago.

What is DevOps

I would say DevOps is encompasses managing source control, managing the build pipeline such as CI/CD and managing tests(unit tests, integration test...), managing the infrastructure including managing the cloud service being used(if any). With the tools that are being offered to teams, there is added complexity. The increase complexity required more time for a team to setup correctly. So what would happen was that one or two team members would gain experience in setting up all the necessary tools. These team members would need to spend more time with the operations side of development and these team members became the DevOps.

All developers should have some knowledge in the operations side of development, but it has grown to the point that it its too much to ask all developers to have sufficient knowledge current operations and the development work they need to know (how all components are tied together, any frameworks that are needed...)

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