Live data from Hacker News

Confessions of a Full Stack DevOp

ansible.com

11–20 of 52 posts

Re: Confessions of a Full Stack DevOp

#11

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. [1] via TFA Ah, now I understand DevOps. Well, the sysadmin who can personally automate his job through programming--this is very productive person. [1] https://news.ycombinator.com/item?id=7593681

In my personal opinion this is what DevOps is, in fact "OpsDev" might even be a better word for it in most cases.

It's about carrying out what are traditionally "Operations" tasks (Provisioning, Configuration, Orchestration, Monitoring, ect) using tools and workflows with are traditionally used by Developers (Version Control, Automated Testing, ect)

In large companies this work is often carried out by operations people who have expanded their skill set to include things previously limited to developer roles. In startups this work is often carried out by developers, as in the original rant, who are tasked with maintaining infrastructure as well as developing.

Re: Confessions of a Full Stack DevOp

#12
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.

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 ought to mean - cross-org cooperation between development and operations. This article has me rethinking that a bit.

Re: Confessions of a Full Stack DevOp

#13
DevOps and "full stack" and Agile and the flamewars around them are just bikeshedding. None of this gnashing of teeth actually matters.

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.

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.

"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.

Re: Confessions of a Full Stack DevOp

#14
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.

Re: Confessions of a Full Stack DevOp

#15

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. [1] via TFA Ah, now I understand DevOps. Well, the sysadmin who can personally automate his job through programming--this is very productive person. [1] https://news.ycombinator.com/item?id=7593681

Perhaps even more important is the ability to give developers, and managers, visibility into things which were only visible to System Admins in the past.

Why is this server running slowly? The graph shows a spike in disk IO usage. What's the process? The database. What changed at the spike? Adam's production push. Why? The explain plan for the new front page query shows a table scan against a 5m row table.

And done. No sysadmin needed, Adam can now identify and fix his own problems. The management can now watch the graphs of application response time go back down in response to Adam's fix, and everyone's happy.

This isn't theory, it's the example I saw demonstrated at a database convention a few weeks ago. Graphite, logship, nagios, and some development which pulls all of this data together can create some virtually magical systems. Casting devops as a side project for "real" developers limits what could be done to facilitate the creation of real agile development environments.

Re: Confessions of a Full Stack DevOp

#16
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.

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.

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.

Re: Confessions of a Full Stack DevOp

#17

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…

You've met great developers who couldn't deploy code?

Re: Confessions of a Full Stack DevOp

#18
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.

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.

Re: Confessions of a Full Stack DevOp

#19
post #11

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. [1] via TFA Ah, now I understand DevOps. Well, the sysadmin who can personally automate his job through programming--this is very productive person. [1] https://news.ycombinator.com/item?id=7593681

In my personal opinion this is what DevOps is, in fact "OpsDev" might even be a better word for it in most cases. It's about carrying out what are traditionally "Operations" tasks (Provisioning, Configuration, Orchestration, Monitoring, ect) using tools and workflows with are traditionally used by Developers (Version Control, Automated Testing, ect) In large companies this work is often carried out by operations peop…

In the traditional development/operations divide, developers often have no access to and little insight into the production environment where their code will be run. As such, they cobble together whatever makes it work, and then "throw it over the wall" to operations, where it has to run in a very different environment. This makes for hellish manual deployments, done on multi-day phone calls with ops staff who don't understand how the code works talking to developers who don't understand the rules and procedures of ops.

If you see places where production code has to run in WebSphere or Weblogic because it's "enterprise", but want developers working in Tomcat to save money, run away.

This leads to situations where operations starts providing "developer resources" in terms of servers, dba support, maven repositories, etc, that turn into a tar pit where development gets stuck in incomprehensible bureaucracy, and "hack" around the system in order to actually get anything done. And then security or someone else in ops finds some little skunkworks dev system and has a fit because developers don't understand what they're playing with - or worse, they find out about the skunkworks because they get pulled in to fix what developers screwed up, with their own managers howling about who's gonna pay for it...

So to me, the beauty of DevOps is getting dev and ops working together in concert from the start to create a consistent development/production environment, where the same automation can be used to maintain both. This is a win for everyone.

Re: Confessions of a Full Stack DevOp

#20

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…

Nothing like finding urls (and even passwords) hardcoded in the source, huh? :)

I try to make any developer who will listen to reason at all read the Twelve Factor App manifesto.

Post reply on HN