How 'DevOps' Is Killing The Developer
jeffknupp.com
How 'DevOps' Is Killing The Developer
1–10 of 219 posts
Re: How 'DevOps' Is Killing The Developer
#2I don't really think a good developer can replace a good sysadmin. The reverse is true too, this is not a flamebait! :P
I don't see "DevOps" as a way to replace some roles - but as a way to make everyone work better together. Instead of living each in their own bubble (and in my - pretty limited I admit - experience it always) everyone has to know, at least a little, what someone else does. It really helps everyone at the end of the day. And the developer can keep coding without me screaming at him because he placed the database connection string in a configuration file that sits inside a .jar that sits inside a .war and so on.
Re: How 'DevOps' Is Killing The Developer
#3The market is maturing. Take a look at a market that is similarly structured. Look at construction.
You have general contractors and then you have subs that work under them. A general contractor is a jack of all trades, master of none. Exactly what a full stack developer is.
This isn't the end of specialization. It's the beginning of project management steered by developers who intimately understand all of the work involved, even if they aren't as competent as the specialists.
Having a team consist of all full-stack developers is just stupid. Having a full-stack developer as the head on a project, with specialists on the team, is a great idea.
Re: How 'DevOps' Is Killing The Developer
#4"If you are a developer of moderately sized software, you need a deployment system in place. Quick, what are the benefits and drawbacks of the following such systems: Puppet, Chef, Salt, Ansible, Vagrant, Docker. Now implement your deployment solution! Did you even realize which systems had no business being in that list?"
I'm not understanding this, you can deploy with Puppet, Chef, Salt, Ansible, Vagrant and Docker. With Vagrant you can deploy a bare image and use Chef (or one of the others) or you can just deploy a fully setup box file (like with Docker).
Re: How 'DevOps' Is Killing The Developer
#5I found it very interesting that Facebook apparently hired programmers for all its roles in the early days - even e.g. the receptionist. I think the point that this article misses is that a 'devops' person - that is to say, someone with both sysadmin and development skills, whichever side of the fence they originated on - can do the job better than someone who is "just a sysadmin" and incapable of programming. When you look at modern ops infrastructure like Puppet, you're looking at programs, written in programming languages, and it's foolish to pretend otherwise. So like it or not, you need to hire someone who can program to manage it. If you imagine you can get a cheaper non-technical ops person to handle this and save money, you're going to get inferior results.
I think this is going to happen to more and more careers. Already a profession like surgery or piloting a modern airliner is starting to require some of the skills we think of as programming. Software is eating the world - that doesn't make domain expertise irrelevant, but it means you need people with domain expertise and programming skills. That applies to non-programming roles in the software industry just as it applies to other industries.
Re: How 'DevOps' Is Killing The Developer
#6This is an interesting rant. I had never seen DevOps as being "for" developers. My impression has always been that it is sysadmins quest for a high degree of automation and streamlining that allows them to manage hundreds of systems without waking up in the middle of the night sweating. And when you're looking for a sophisticated tool to control something, you inevitably find yourself writing software.
Re: How 'DevOps' Is Killing The Developer
#7In my own experience I don't think developers were ever pushed to become devops (as the article asserts).
Instead, about 40% what was called 'sys admins' were pushed to become devops. The 'sys admin who knew cfengine' became a 'devops person who knew ansible'. Deploys and cloud APIs just became another thing to automate.
The bottom 60% - the shit ones who got paid 120,000GBP to copy paste commands they didn't understand from word documents into Solaris 8 boxes in 2010 because they couldn't actually automate anything - left the industry.
Re: How 'DevOps' Is Killing The Developer
#8I don't really think a good developer can replace a good sysadmin. The reverse is true too, this is not a flamebait! :P I don't see "DevOps" as a way to replace some roles - but as a way to make everyone work better together. Instead of living each in their own bubble (and in my - pretty limited I admit - experience it always) everyone has to know, at least a little, what someone else does. It really helps everyone a…
It really helpful to have developers know at least a little systems administration, and vice versa. When doing web development at least there's a fair number of problems that you should just let a web server, caching server, database server or even the operation system handle for you. If developers no nothing about systems administration they sometimes solve non-problems.
I'm just a guilty as anyone else in try to write code to fix a problem that's better handled by existing infrastructure and servers. I worked on a project to deliver invoices to customers in downloadable form. In the end pretty much very thing was thrown out and I just need to write the authentication part, because the sys admins pointed out that the existing StringRay boxes could handle everything else (http://www.riverbed.com/products-solutions/products/applicat...).
It's not that it doesn't make sense to have dedicated developers and systems administrators, as the developer you just need to know enough to be able to talk to and understand the admins position and thoughts.
Re: How 'DevOps' Is Killing The Developer
#9The OP makes a relatively uncontroversial point (that people will be specialized, and better, at a finite set of skills)...so I think "killing the developer" is a little dramatic.
However, I think as with most things that involve computational thinking and automation, this is not a zero-sum game. A developer who can apply deterministic, testable processes to server-ops may be able to reap an adequate amount of benefit for significantly lower cost than a specialized sysadmin. In addition, the developer is augmenting his/her own skills in the process. Yes, that dev was not able to focus all of their time on...whatever part of the stack they are meant to specialize in...on the other hand, the time spent studying dev ops is not necessarily a sunk cost.
For my own part, I've tried to stay away from sys-admin as much as possible...but when I've been pushed into it, I've gotten something out of it beyond just getting the damn server up. For example, better familiarity with UNIX tools and the importance of "text-as-an-interface"...which does apply to high-level web development...nevermind the efficiency you gain by being able to stay in the shell when most appropriate (rather than, say, figure out how to wrangle server commands in a brittle capistrano script).
But hell, even the end product itself, just being able to deploy a server with some confidence...is kind of empowering. For me, it opens up new ways to run scripts and jobs...It sounds dumb and maybe it's just the way my brain poorly functions, but the concepts of server-oriented architecture become so much clearer when you can spin up different machines to play with and experiment with delegation.
Re: How 'DevOps' Is Killing The Developer
#10I think DevOps is very much a web-application thing (where web-application includes intranets, ... basically anything that speaks tcp). I seriously see the need there. I still remember the days when developers would build an application that worked on their system and then handed it off to Ops, hoping to never hear back from it. I interviewed developers that could not tell me which webserver or application server their company was running in production, even though capabilities and performance characteristics differ wildly. The DevOps role is trying to bridge the gap, it's the jack of all trades, that knows enough of every piece of the system to debug issues that happen at those boundaries. Is this DB problem a machine issue, do we just need new hardware? Is it an application problem (n+1 queries) and where could those be? How can I structure my stack in a way to hand of tasks to the place where they can be solved efficiently. The implementation of those solutions can be handled by domain experts, but someone needs to keep all those pieces from breaking apart at the seams. In the web world, that's the DevOps.