Live data from Hacker News

Confessions of a Full Stack DevOp

ansible.com

41–50 of 52 posts

Re: Confessions of a Full Stack DevOp

#41
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…

hmm, OpsDev sounds like sloppy dev who carelessly breaks stuff and says Oops!

Re: Confessions of a Full Stack DevOp

#42
post #20

Earlier quoted context omitted.

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.

Nice. Never seen that manifesto. Just pushed it out to all my devs.

It's worth taking to heart. It seems to have come out of Heroku-land, and it's baked into Heroku. Of course, that's an even more restrictive environment in some ways, but the underlying concepts are true for larger and more complex things than can be easily executed in Heroku.

Now all you have to do is get them to grok immutability...

Re: Confessions of a Full Stack DevOp

#43

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…

The "Let Them Eat Cake" antipattern, that is. Maybe no one has written it and I just made it up...

Re: Confessions of a Full Stack DevOp

#45
post #33

Earlier quoted context omitted.

Sure. I've met great ones who could too. I don't think deployment is part of the development job description. Or is it?

To me, it seems like it makes sense that a great developer should absolutely know how his code is running, how his changes interact with the production environment in which the code runs, etc.

You'd take a hit if you visit any big company that's not centered around IT.

It's quite common for the developers to be forbidden from knowing the details of the production environment, and usually they have no easy way to get that info. But don't mind, a DBA will think about the interaction between the several programs, and the ops people will think about performance.

Re: Confessions of a Full Stack DevOp

#46
post #43

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…

The "Let Them Eat Cake" antipattern, that is. Maybe no one has written it and I just made it up...

I don't get it. Google turned that up: http://robmyers.org/2009/09/21/free_software_debate_antipatt... and I don't get it either.

Re: Confessions of a Full Stack DevOp

#47

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

This is a really great point.

If you set up your systems right, they pretty much run themselves.

I've been doing systems contracting for a few years and contracting often turns out to be much better suited for this work than full-time employment (unless you're a company at significant scale).

My typical contract goes like this:

    - gain an understanding of their current systems
    - document *everything* that matters in their systems
    - simplify *everything* that matters in their systems
    - organize *everything* that matters in their systems
    - secure *everything* that matters in their systems
    - automate *everything* that matters in their systems
    - monitor *everything* that matters in their systems
    - train their engineering team on how to run the systems
That's it. If I've done my job right, they'll never need me again unless something exceptional happens.

The best sysadmins make themselves redundant as quickly as possible.

The best sysadmins put the power of the systems in the hands of the other engineers.

The best sysadmins are well rested because the systems they set up are so damn stable and boring.

How do you know you have a bad sysadmin?

    - they are a 'hero' that often rescues the company
    - no one understands the systems but them
    - they are a bottleneck for deploys
    - little is documented
    - little is automated
    - they work long hours
    - they're often frazzled and stressed
A big part of DevOps is saving developers from bad sysadmins. Fortunately, the last few years have been a renaissance for usability in systems tools (like Ansible for instance). This newfound usability for managing and automating systems has finally put the power of systems management within the reach of many more developers.

For more, see my posts on these topics:

Boring Systems Build Badass Businesses https://devopsu.com/blog/boring-systems-build-badass-busines...

Metrics that Matter for your Systems https://devopsu.com/blog/metrics-that-matter-for-systems/

Re: Confessions of a Full Stack DevOp

#48
post #43

Earlier quoted context omitted.

The "Let Them Eat Cake" antipattern, that is. Maybe no one has written it and I just made it up...

I don't get it. Google turned that up: http://robmyers.org/2009/09/21/free_software_debate_antipatt... and I don't get it either.

Basically, the idea is that if something is hard to automate, then automate it and then it won't be hard to automate. Peasants have no bread? Let them eat cake!

I've encountered this a lot in the enterprise. Baby-step automations aren't allowed because they don't contribute to a Grand Unified Theory of Automation that will Solve All Our Problems. Worse, you wind up babysitting antiquated automation that should be replaced, and you're not allowed to replace it because it's already there and already works.

Re: Confessions of a Full Stack DevOp

#49

Earlier quoted context omitted.

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

> And done. No sysadmin needed, Adam can now identify and fix his own problems. > Graphite, logship, nagios, and some development which pulls all of this data together can create some virtually magical systems. Who do you think pulls all that data together? DevOps/Sysadmins. I build and wrap together the tools that make your job easier. And I take pride in that. I'm also on call so you don't have to be. Relevant XKCD…

> Who do you think pulls all that data together? DevOps/Sysadmins.

That's what I was trying to point out. A devops engineer is involved in the creation of these systems, however she does not need to be involved at 3am when the problem is discovered, since Adam can identify his own problem and can verify his fix did what was necessary.

Re: Confessions of a Full Stack DevOp

#50

Earlier quoted context omitted.

> And done. No sysadmin needed, Adam can now identify and fix his own problems. > Graphite, logship, nagios, and some development which pulls all of this data together can create some virtually magical systems. Who do you think pulls all that data together? DevOps/Sysadmins. I build and wrap together the tools that make your job easier. And I take pride in that. I'm also on call so you don't have to be. Relevant XKCD…

> Who do you think pulls all that data together? DevOps/Sysadmins. That's what I was trying to point out. A devops engineer is involved in the creation of these systems, however she does not need to be involved at 3am when the problem is discovered, since Adam can identify his own problem and can verify his fix did what was necessary.

> That's what I was trying to point out.

Ouch, my mistake. In that case, I misread your post, and I apologize.

Post reply on HN