everythingpossible - Fotolia

Do DevOps developers have to do it all?

Startup culture created a need for developers who could see a product from concept through launch. Now, these DevOps developers are a principal agent of DevOps culture.

DevOps seems like a win-win proposition: by integrating teams and fostering a community of collaboration, you produce higher quality work, get it to users faster, and it's better maintained. But in order to make DevOps work, developers now must possess a wider swath of knowledge that was previously spread out over multiple employees.

It makes sense, really. Many DevOps practices were pioneered by startups that were working with limited resources. With only so many people to hire, startups had to take a lean approach where each member of the team had to do what in a traditional setting multiple employees were doing. But this has since changed, on a greater scale, what companies look for in an ideal developer; many companies that aren't startups are looking to shift to DevOps by, among other things, seeking out these so-called "full-stack," DevOps developers.

For instance, with DevOps, companies are no longer embracing a "waterfall" approach to development where different groups exclusively handle QA and development. It could now fall on developers to assume the responsibilities of testing and maintaining release environments. Similarly, a DevOps developer could end up having to address a database issue when they find that they don't have a dedicated DBA team.

Now, some would argue that this hampers the ability of developers to, well, develop code. Putting automation technologies aside for the sake of argument, if a DevOps developer is busy fulfilling the DBA role because there is no dedicated DBA team, that means they're spending that much less time on development. Sure, they can do these other things, but should they?

The other side would posit that the demand for people with an expanded skillset shouldn't be so they can take on multiple roles, which could cripple efficiency. Rather, it should be so devs will better understand the other aspects of the systems development lifecycle, which can help strengthen relationships between what were previously separate, siloed teams. After all, integration and collaboration are at the heart of DevOps, and what better way to promote that than by having a team where everyone understands the nature of everyone else's responsibilities?

So perhaps there's a balance to be struck here. When it comes to DevOps, seeking out knowledgeable developers with these larger skillsets could be what you need – just so long as you use their knowledge to help increase collaboration, and not to force them to actually wear all those other hats.

Dig Deeper on Agile, DevOps and software development methodologies