Pet peeve: this URL is incorrect. When you're linking to an article on a blog, it's important to use the permalink for the specific entry (in this case it's <a href="http://www.ansible.com/blog/confessions-of-a-full-stack-devop" rel="nofollow">http://www.ansible.com/blog/confessions-of-a-full-stack-devo...</a> which admittedly wasn't easy to find - you had to click the heading on the article which lacks any clear visual way to tell that it's a link).<p>If you link to the blog homepage e.g. <a href="http://www.ansible.com/blog" rel="nofollow">http://www.ansible.com/blog</a> then in a few weeks time this post on Hacker News will no longer link to the correct content.
<i>The last time I looked for a senior sysadmin -- less than a year ago -- I didn't get anyone who was comfortable programming in Perl/Python/Ruby until I started using the term DevOps.</i> [1] via TFA<p>Ah, now I understand DevOps. Well, the sysadmin who can personally automate his job through programming--this is very productive person.<p>[1] <a href="https://news.ycombinator.com/item?id=7593681" rel="nofollow">https://news.ycombinator.com/item?id=7593681</a>
This is a much better, more sensible article than yesterday. My good takeaway here is that DevOps means whatever you think it means - it's a lot of different things to a lot of different people. That's a much more positive spin on my frankly negative opinion that it's devolving into a meaningless buzzword to attach to resumes, recruiting, and PowerPoint presentations for management.<p>I know I came in to DevOps (the word, not the job - I've been doing the job since the mid-1990s) with a strong opinion of what it <i>ought</i> to mean - cross-org cooperation between development and operations. This article has me rethinking that a bit.
Here's my unsolicited opinion:<p>Dehaan is pretty much spot on. Knupp's post seemed to first latch onto the idea that devops is about devs doing ops works. To add, I think Knupp should do a rewrite after listening to some devops cafe and food fight podcasts, if he really believes in what he wrote.<p>It's somewhat an unfair comparison though. If you're the author/creator of ansible you surely have spent a lot of time thinking and understanding what devops means. To be frank, I cannot tell if Knupps post is just link bait to sell his book.<p>The concept (and value) of the devops mindset & culture is less debatable in 2014 than in the past 5 years. Those who latch onto the totem pole model will simply get left behind while the rest of the industry moves on... or at least that's what they tell me!
Knupps idea of the totem pole rubbed me the wrong way too. I've met great developers who didn't have a clue about how to scale or monitor their software outside of their framework. How to properly deploy across DEV, UAT and PROD without making code modifications. How to keep these environments clean and flexible to enable these deployments. Nor should they have to. Call me a Dev because I read and write code. Call me Ops because I do deployments and fix production issues. At the end of the day I solve problems and just plain make stuff work. With or without so called DevOps tools.
> <i>When done correctly, automation tools are giving [developers] time back — and helping out of this problem of needing to wear many hats.</i><p>I've found this to be the case both in my full-time job (enterprise/healthcare industry) and in my larger side projects. Using some simple tools to make sure both server environments and deployments are uniform/repeatable/known in a good state has given me much more time to focus on actually <i>developing</i>.<p>Additionally, there are times when certain features (especially surrounding performance and scalability) <i>requires</i> a deeper knowledge of part of your stack. Being a good developer requires you to be a specialist (in your primary language/tools) and generalist (in almost all other areas) at the same time.
I would also add that you just don't automatize stuff. Because the more you add layers, the more you'll have to dig into at 3AM with the customer screaming at you on the phone. It's using the complete stack and using the least technology required to do the task at hand. While having access to the whole picture.<p>I have heard too many times that something is complicated then we can automatize it. But automatization has to be debugged, so, if the task is not complex per se, try to find a simpler tool, try to limit your intervention in the config files, try to limit the number of tools etc. But you can make those tradeoff across the whole stack. And suddenly you're balancing between adding a library to the code or a program on the machine, or a function package in the DB. You have a wider view, and you have the pressure to do the right thing because your phone is connected to new relic.
This is pretty much a good article on DevOps. In my words i see DevOps as a bridge spanning the kernel, systems, networks, qa, packaging, and deployment. for a highly optimal system all these need to be planned for with care and attention. DevOps is a tough and long learning to be good at.
Great post. While I agree with this, "Automation shouldn't be about spending all your time with a tool ..." I wonder if employers are pressured to push you into more and more Ops work by this paradox? <a href="http://en.wikipedia.org/wiki/Jevons_paradox" rel="nofollow">http://en.wikipedia.org/wiki/Jevons_paradox</a><p>This kind of situation, specifically (relative to other work): <a href="http://upload.wikimedia.org/wikipedia/commons/b/b8/JevonsParadoxA.png" rel="nofollow">http://upload.wikimedia.org/wikipedia/commons/b/b8/JevonsPar...</a>
Back when I thought I was going to be a Mechanical Engineer, I had a summer course that included surveying along with machine design and robotics. I felt the latter were more relevant to me, but had I gone on to work in oil fields in SE Asia I probably would have appreciated my time tromping around campus taking measurements.<p>I see all of this as just 'engineering' work, but it's easier to delegate certain things than others. When I ask someone new to configure Postgres for secure remote administration, script or otherwise automate backups, and rough out a schema for some tool we're thinking about, they'll likely accomplish at least a subset those tasks. The remainder is an opportunity for discussion. Someone else might just ask me to build something, and we'll talk about usability when he's done with the physics side of things.<p>But if I leave, what does that physicist look for in a new hire? The skillset of an 'engineer' is frustratingly broad and vague from a hiring point of view. Getting so-called DevOps out of the way might give another new hire the chance to develop as a programmer, and vice versa. Hopefully one or both of those two will eventually develop into an engineer.
I am a horseshoe crab. I am a sysadmin.<p>I can code, I do code, but I'm a much better sysadmin, mainly because I've been doing it as a dayjob. You want networking? I'll do that. you want multi gigabyte a second storage arrays? I'll do that. You want monitoring? I'll do that.<p>You want me to recompile python 3.3, naaa you can do that. I can, but you'll do better at it
DevOps and "full stack" and Agile and the flamewars around them are just bikeshedding. None of this gnashing of teeth actually matters.<p>You know what matters? Writing code and making it work. Solving problems. Helping people. If the right way to do that is for me to make a system more reliable, then I'll do my best even if I'm not interested in being "an ops guy". If the best thing for me to do is read machine learning papers, then I'll do that.<p>The real problem: technology companies have terrible leadership. You know how small towns in the Midwest used to send their genetically unfortunate to San Francisco, where there'd be more social services and a warmer climate? Well, that's what the business world does with its rejects, too. Buses 'em to San Francisco. Except, in tech, they end up making $400k as VPs of HR at startups and get to boss nerds around.<p>"Agile" won't fix that. Nor will "DevOps". These terms mean too many different things to different people, and ultimately fail to address the real, core issues with technology.