Disagree whole-heartedly, but upvoting because it’s an interesting discussion.
I think the author has missed the point by a mile here. DevOps is not about making the developer into a 5-man team on 1-man time, it’s about getting the old sys-admins to step up into a development world with operations automation and more development (and less swapping dead hard drives, though still necessary).
Agree with you here.
Our DevOps group (in collaboration with stakeholders on engineering groups) helps to build a thin layer of PaaS to help facilitate automated deployment, scaling, logging, etc. in a self-serve manner, rather than requiring their intervention for all new deployments.
Right now, it takes ~10 minutes to put a brand new service in production, assuming you didn’t screw up the settings. That kind of hybrid platform/operational work is what I term DevOps.
I think as deployment of services becomes more complicated (DB layer, cache layer, middleware, client-side rendering layer, etc.), deploying solutions and keeping data consistent in more complicated systems makes the role of the traditional sysadmin feel a bit dated. DevOps is rising to meet the need of these more complicated services.
Speaking as someone who bills and performs as a “Full-stack” developer who tends to end up doing a lot of Devops, there is some truth, and some falsehood to this article. I can’t give scientific data, but in my experience I will say I wear a lot of hats – I work in a team making the slow transition from a waterfall-style to agile methods, so I end up being the de facto agile coach. We’re making a transition to using Ruby, replacing Java. As the guy with the Ruby experience, I’m the de facto (and to some extent de jure) Ruby coach. I’m the liason to the IT/Ops department, and a primary mover in the ‘script all the things’ department. It’s true, I don’t get to do anything for a long time, I would say that I’m a jack-of-all-trades, and though I would say I’m not a master-of-none, I wouldn’t say that I’m nearly as masterful as I could be, because of my split focus.
The falsehood here, or at least the fallacy – is the assumption that being a jack-of-all-trades is bad. Every team needs masters, but it also needs people who can effectively play the field. I’m the sweeper (like the soccer position), I’m the guy who runs all over the field to apply the extra oomph needed to get something done. We have a ton of very smart developers on our team, and each have mastery over different parts of a large and complex codebase. The problem is load balancing – new requirements effect different parts of the codebase, and having few masters covering each section, the workload spikes for different people at different times. It’s my job to help pick up the slack and make their jobs easier.
Is it true that it leads to burnout? Sure, but so does mastery – burnout isn’t caused by a kind or variety of work, it’s caused by a large quantity of work applied constantly. Without someone to help balance the load, the few people who work in a specific area will burn out. Rather, allowing the so-called ‘full-stack’ developer to jump in and help minimizes the burnout for everyone, including me.
Burnout, furthermore, is not something that can be avoided by less variety – indeed, I’ve found that it’s precisely the opposite, more variety keeps the work interesting, free from drudgery, and that helps to mitigate the effects of burnout.
Burnout can’t be ‘solved’ by simply focusing on less or more variety, it can’t be solved by any one person on the team, it has to be a collaborative effort. Your managers need to recognize burnout and react to it, your teammates have to come to support your efforts when your workload spikes, you need to concentrate on keeping the machine working smoothly via the use of automation and good working standards. That is to say, avoiding burnout is a team effort, Software development is a team sport.
Like any good team, not everyone can play the sweeper, or the goalie, or whatever. Everyone plays different positions and building a good team doesn’t mean hiring a bunch of sweepers, it means understanding how the different specialties of each team member will interact and produce the most value at the lowest cost – both monetary and personal.
In short, I don’t agree that DevOps is killing me personally, nor do I agree that it kills developers in general; but since I have no evidence, you have only my word for that – and since OP has no evidence, you’ve only his word too.
I agree with everything you said. I consider myself a “full-stack” developer and I love it. We recently moved a medium sized property to AWS and I’m having a ball reworking things to operate in the cloud.
Am I good at writing code? Sure, but I’m not the best programmer out there. Is my SQL passible? Yup, but there are plenty of others that are better than me. Can I design an API? Absolutely, but it won’t be perfect on the first try. However, I can do all of those things (and more) much better than most people. I’ve spent years studying networking, database scheme design, programming languages/patterns, deployment systems, hardware, messaging protocols, and a thousand other things that make a complete system work and I’m not burnt out yet.
There are new things constantly being developed that excite me and make me yearn for the future. In the beginning of my career it was client/server GUI programming (Powerbuilder). Several years later it was large EAI systems, then it was building RESTful interfaces, then cloud services came on the scene. The future holds other exciting things like modular deployment (docker, linux containers) and mobile development. I can even see “gaming” technologies making inroads to my development process. Things like Oculs-Rift and Leap Motion might change the way we build software and/or manage resources. Can you imagine deploying new code by picking it up out of a Github repo and dropping it onto AWS?
The point is that being a “full-stack” developer gives me the freedom to move quickly and do something different every day. Sure I can’t concentrate all my energies into becoming a guru DBA or rock star programmer, but I think the tradeoff is well worth it.
As an employee of Amazon, which is probably the biggest offender when it comes to making developers performs ops roles, I’d like to explain the reasoning behind the decision.
Making engineering teams responsible for managing their code in production gives engineers an incentive to write code that is fault-tolerant and easy to deploy. You are less likely to write code that may cause issues in production and shove the problems off to the ops team if you are also on the ops team. Being a developer also helps you perform the ops tasks better, since you have worked on the codebase and are therefore more likely to find the root cause of problems. Also, issues discovered while working operations drives improvements to the software to mitigate those issues.
I’m a developer that has been on teams where developers were not allowed to touch production systems, and it is absolute hell. Do I want to touch production systems all the time? No. Do I sometimes need to get onto a production system and look at something (logs, memory usage, etc.)? Yes.
In my experience barring a developer from production systems gives them license to create things that are less supportable. We would build stuff and throw it over the wall; if there was a problem with something, it wasn’t my concern. I could prove that it worked in dev, QA but since I couldn’t see production, I couldn’t help. That was a toxic environment and I’m glad I’m no longer subjected to it.
Devops can be a double-edged sword. The positive side is a work environment where it’s not the same old thing everyday. Too much responsibility and not enough support will cause anyone to flame out.