3 ms·
No. Originally it was about operations and developers collaborating more closely, including cultural change (devs don't throw things over the wall to ops, ops
by meandor 10y ago
No. Originally it was about operations and developers collaborating more closely, including cultural change (devs don't throw things over the wall to ops, ops doesn't hide prod from devs), increasing automation (applying development methodologies to operations), improving learning between the ops and dev teams, and such.
These days it's sometimes used:
- to mean traditional ops
- to mean that devs do all of their own ops
- to mean that there's a separate silo between the dev and ops silos that make tools
- to mean the original thing about collaboration and a shift on the ops side to be more programmatic.
Your explanation is a complete and total myth, though. It's just some garbage from a programmer who didn't know what it meant and decided to be a huge jerk about it.
- UK-AL 10y agoI didn't realise I was offensive, sorry. If operations is moving towards being automated by software it's only natural to want to move more towards programming side. I'm not saying this a bad thing, only natural. If infrastructure people see traditional server management moving towards automated deployments/monitoring/automated server setup. Then a lot of them would want to move into those skills, which a lot did. Is there anything wrong in wanting to cross-functional? Most DevOps people are developers who automate infrastructure, or Infrastructure people who move into programming so they can automate. You need to have both to be really good at it. That's what crossfunctional means. Btw I am actually devops, and I've been working on it for a few years.
- toomuchtodo 10y ago> Your explanation is a complete and total myth, though. It's just some garbage from a programmer who didn't know what it meant and decided to be a huge jerk about it. Thanks, as an ops guy. I work hard every day to make the best tools available for our developers, and to ensure we have the highest levels of reliability.
- UK-AL 10y agoWhat a myth here, whats garbage? If you look at the early history of devops, a lot of it was developers who had previous infrastructure experience and roles writing software for automating deployment, and sever creation. It sounds to be me you have chip on your shoulder, any mention of programmer help makes you angry? When in reality programmers appreciate modern DevOps people. What makes you thing programmers dislike you? You seem to assume I am a programmer?
- toomuchtodo 10y agoNo chip on my shoulder, nor assumption you're a developer. You said: "Originally yes, it was about being more cross functional instead of separate silo's." Which strikes me as the continuation of requiring someone to be familiar with everything in the stack. So you get people who are mediocre at every skill they need, and not particularly good at any single task. Also, you said: "However operations people had an issue with that" Not in the slightest. As an ops person, I embrace the DevOps model. My problem is when someone like yourself makes a broad, unsubstantiated generalization such as this. Ops people want systems to run smoothly, and also want to have a life outside of work (I'm assuming? Perhaps another broad generalization). DevOps means I work with developers to ensure their code works as expected in production as it did in development and staging, and that they're not just throwing it over the fence to me and hoping for the best.
- UK-AL 10y agoI didn't mean issue with it in a bad way. Just that a lot operational people noticed it was trend occurring and adapted to it. They didn't avoid it. As a DevOps can you develop code to automate things, like deployment, builds, ci, server setup? Can you setup servers, networks, monitoring? If you can do all of these things your cross functional. Originally before devops, operational teams and developer teams were completely separate. Often separate rooms. At the company I'm at devops and developers are actually on the same team. Same room and attend the same stand up meetings. We have devops people that have helped create code, and we have developers that are on call for making sure that they are on duty in case their new code falls over. Skills gradually start to overlap. We also have people have switched their focus, developers who moved to more ops skills and vice versa. We aren't different groups of people. That' what I mean by not separate silos.