6 ms·

Isn't a core tenant of DevOps that your developers are the ones doing the Ops too? I keep hearing things like "Hiring DevOps" or "According to the Stack Overflo

Isn't a core tenant of DevOps that your developers are the ones doing the Ops too? I keep hearing things like "Hiring DevOps" or "According to the Stack Overflow survey there is 1 DevOps for every 30 developers.", and that feels like... an Ops role, right?

UK-AL 10y ago
Originally yes, it was about being more cross functional instead of separate silo's. However operations people had an issue with that(not in a bad way, just observing where stuff is going), and decided to obtain devops skills. So you ended up with pure devops people. A lot the first devops people were developers, who also knew about infrastructure issues and been in those roles. They were fairly rare.
- 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 ago
    I 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 ago
      What 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 ago
        No 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 ago
        I 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.
nilved 10y ago
I don't think the term is well-defined. At first, it was about liaising between developers and operations. These days it seems to be about infrastructure-as-code like Chef.
vidarh 10y ago
The day I see most developers doing ops well will be the days pigs fly. My background is development, yet I've always done ops too, but what I see from most developers is that exceedingly few of them even know the extent of what taking responsibility for ops includes. E.g. I strongly believe that one of the drivers for a lot of the extremely costly cloud solutions people use is that most developers these days have an acute lack of knowledge of hardware. But to do the ops side right you need to be able to choose cost effective solutions and you need to understand the trade-offs, or you may easily end up costing your business 10x as much in hosting for no good reason. Thinks like capacity planning, risk management related to the hosting, backup strategies, failover/ha are areas very few developers have much experience with. I spend a lot of the time I do consulting on mentoring development teams and/or providing advice in those areas, and most places are _very_ far away from having integrated teams that can safely and cost-effectively handle the ops side.
- xorcist 10y ago
  > exceedingly few of them even know the extent of what taking responsibility for ops includes When you don't know the extent of your ignorance, everything seems trivial. A.k.a. "how hard could it be?". I have a feeling the more ops-y things I do gets more in demand as organizations move towards the cloud. Measuring performance is not trivial in a shared environment and failure scenarios can get very complex. And every development decision suddenly affects the bottom line when billing gets granular.
  - vidarh 10y ago
    Yeah, I keep getting clients come to me because of the complexity of their cloud setups, and they invariably end up paying far more than the guys running stuff on dedicated hosting. Most of them also pay 2x-3x as much for the hosting itself... I think a lot of these setups grow by accretion because people are able to push things onto them within purchasing mandates they have because of monthly fees that can slowly grow through discrete approvals rather than having to justify large capital expenditures upfront, or even seeking approval for contracts for monthly payments vs. running up per-minuter or per-hour or per-GB charges... I suspect a lot of the enthusiasm for these services would vanish if more engineering teams actually had to produce cost estimate, budgets and after-the fact accounting of operational costs for the stuff they build... I think as a startup, though, offering these kind of platforms as open source is ingenious, because you get mindshare, but people soon enough will run into enough pain to want to offload the pain on someone else - either hiring devops/ops people, contracting it out, or coming to your startup begging you to run it for them. Certainly, it's great for people like me who do consulting part time that people don't know how to do this, as it's far easier to justify my rate when I can ask to see their hosting costs and be able to point out to them that the monthly cost savings they'll get will cover the fees in 3-4 months.
MattRogish 10y ago
DevOps is one of those terms, kind of like Agile or XP, that means different things to different people. To me, DevOps means Developers and Operations working more closely together, and walking a mile in each other’s shoes (you’ll hear the word empathy thrown around a lot). Developers should support their applications in production (including pager rotation!) and architect, design, and build applications with infrastructure supportability in mind, and Operations needs to engineer infrastructure using better development techniques: test driven development, automation, and with developer ergonomics in mind (providing a standardized, scalable platform and not just isolated snowflake systems).
stephenr 10y ago
> Isn't a core tenant of DevOps that your developers are the ones doing the Ops too? Im sure it means that to a lot of developers, and definitely some managers. The developers see it as "no more ops telling me that I need to use a TLS connection to the database because it's over a WAN", or "no more ops telling me I can't use the 0.0.0.1-pre-pre-alpha version of <insert runtime/framework/daemon> in production". The managers particularly see it as "we don't need those pesky ops people, so we've just saved ourselves $X per year". They don't tend to factor in the lack of relevant skills by their remaining developers, which tends to result in less efficiency (i.e. taking longer to do shit) and greatly increased risk. And then the developer says "hey we'll just use AWS because thats what HN all suggest and it's cheap" and you end up paying a heap of extra cash each month because they just run 10 on-demand EC2 instances 24x7 and a host of assorted services to deal with the lack of persistence on EC2 instances, when previously you needed just two servers in failover setup, with capacity to spare. I've seen what happens when developers "do ops", as I was leaving a company. When you're asked by someone "can you help, I'm trying to install this SSL cert on a server (for a soon to be production system) but I don't really understand how any of this SSL stuff works", there is just one realistic response. Run. Then run some more, hide, change your email and don't answer your phone. Because that shit is about to go down like the titanic.
- UK-AL 10y ago
  But web developers should know how SSL works anyway. Otherwise your probably not a great developer. I defiantly learned about SSL, and pki infrastructure through developer knowledge.
  - nickpsecurity 10y ago
    If library is done well, then you shouldn't have to know much about SSL to be able to use it. Just an abstract idea of it plus how to use the library. SSL from an ops perspective is quite different. That's why it's better to have pro's in each working together on it.
    - UK-AL 10y ago
zer00eyz 10y ago
> Isn't a core tenant of DevOps that your developers are the ones doing the Ops too? This isn't how it started. "deliver a seminal talk known as “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” The talk is an energetic presentation in which Allspaw and Hammond basically act out the classic “fingerpointy” conundrum of Dev versus Ops—“It’s not my code, it’s your machines!” (and vice versa)—to a roomful of developers. They make the case that the only sensible way to build, test and deploy workable new software is to make development and operations transparent and integrated. Read more at http://rewrite.ca.com/us/articles/devops/a-short-history-of-devops.html#CHg4UHoQS6FCg8oo.99"* http://rewrite.ca.com/us/articles/devops/a-short-history-of-... From: http://rewrite.ca.com/us/articles/devops/a-short-history-of-devops.html http://rewrite.ca.com/us/articles/devops/a-short-history-of-... Honestly if you go back to the early 2000's Operations and Engineering were often playing the blame game if not at outright war. I can't tell you how many SA's told me to "file a ticket" when asking for basic factual information (not changes). The idea of a "full stack" engineer is mostly a myth. If your starting out small hiring a generalist who can do it "all" is probably a good thing. The issue is finding folks who can do everything well is HARD. Once you hit a certain scale, you need people dedicated to each JOB (Front end, back end, operations, database, networking). When you get to the level of having a lot of specialists, having someone do "DevOps" to act as a bridge, to speak able to speak to specialists and convey issues can be vital.
biot 10y ago
To avoid confusion, I assume you mean "tenet" as in principle, not "tenant" as in "occupying someone else's property", which could get confusing when talking about containers, cloud computing, and using some provider's resources.

UK-AL 10y ago

Originally yes, it was about being more cross functional instead of separate silo's. However operations people had an issue with that(not in a bad way, just observing where stuff is going), and decided to obtain devops skills. So you ended up with pure devops people. A lot the first devops people were developers, who also knew about infrastructure issues and been in those roles. They were fairly rare.

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 ago
  I 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 ago
    What 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 ago
      No 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 ago
        I 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.

nilved 10y ago

I don't think the term is well-defined. At first, it was about liaising between developers and operations. These days it seems to be about infrastructure-as-code like Chef.

vidarh 10y ago

The day I see most developers doing ops well will be the days pigs fly. My background is development, yet I've always done ops too, but what I see from most developers is that exceedingly few of them even know the extent of what taking responsibility for ops includes. E.g. I strongly believe that one of the drivers for a lot of the extremely costly cloud solutions people use is that most developers these days have an acute lack of knowledge of hardware. But to do the ops side right you need to be able to choose cost effective solutions and you need to understand the trade-offs, or you may easily end up costing your business 10x as much in hosting for no good reason. Thinks like capacity planning, risk management related to the hosting, backup strategies, failover/ha are areas very few developers have much experience with. I spend a lot of the time I do consulting on mentoring development teams and/or providing advice in those areas, and most places are _very_ far away from having integrated teams that can safely and cost-effectively handle the ops side.

xorcist 10y ago
> exceedingly few of them even know the extent of what taking responsibility for ops includes When you don't know the extent of your ignorance, everything seems trivial. A.k.a. "how hard could it be?". I have a feeling the more ops-y things I do gets more in demand as organizations move towards the cloud. Measuring performance is not trivial in a shared environment and failure scenarios can get very complex. And every development decision suddenly affects the bottom line when billing gets granular.
- vidarh 10y ago
  Yeah, I keep getting clients come to me because of the complexity of their cloud setups, and they invariably end up paying far more than the guys running stuff on dedicated hosting. Most of them also pay 2x-3x as much for the hosting itself... I think a lot of these setups grow by accretion because people are able to push things onto them within purchasing mandates they have because of monthly fees that can slowly grow through discrete approvals rather than having to justify large capital expenditures upfront, or even seeking approval for contracts for monthly payments vs. running up per-minuter or per-hour or per-GB charges... I suspect a lot of the enthusiasm for these services would vanish if more engineering teams actually had to produce cost estimate, budgets and after-the fact accounting of operational costs for the stuff they build... I think as a startup, though, offering these kind of platforms as open source is ingenious, because you get mindshare, but people soon enough will run into enough pain to want to offload the pain on someone else - either hiring devops/ops people, contracting it out, or coming to your startup begging you to run it for them. Certainly, it's great for people like me who do consulting part time that people don't know how to do this, as it's far easier to justify my rate when I can ask to see their hosting costs and be able to point out to them that the monthly cost savings they'll get will cover the fees in 3-4 months.

MattRogish 10y ago

DevOps is one of those terms, kind of like Agile or XP, that means different things to different people. To me, DevOps means Developers and Operations working more closely together, and walking a mile in each other’s shoes (you’ll hear the word empathy thrown around a lot). Developers should support their applications in production (including pager rotation!) and architect, design, and build applications with infrastructure supportability in mind, and Operations needs to engineer infrastructure using better development techniques: test driven development, automation, and with developer ergonomics in mind (providing a standardized, scalable platform and not just isolated snowflake systems).

stephenr 10y ago

> Isn't a core tenant of DevOps that your developers are the ones doing the Ops too? Im sure it means that to a lot of developers, and definitely some managers. The developers see it as "no more ops telling me that I need to use a TLS connection to the database because it's over a WAN", or "no more ops telling me I can't use the 0.0.0.1-pre-pre-alpha version of <insert runtime/framework/daemon> in production". The managers particularly see it as "we don't need those pesky ops people, so we've just saved ourselves $X per year". They don't tend to factor in the lack of relevant skills by their remaining developers, which tends to result in less efficiency (i.e. taking longer to do shit) and greatly increased risk. And then the developer says "hey we'll just use AWS because thats what HN all suggest and it's cheap" and you end up paying a heap of extra cash each month because they just run 10 on-demand EC2 instances 24x7 and a host of assorted services to deal with the lack of persistence on EC2 instances, when previously you needed just two servers in failover setup, with capacity to spare. I've seen what happens when developers "do ops", as I was leaving a company. When you're asked by someone "can you help, I'm trying to install this SSL cert on a server (for a soon to be production system) but I don't really understand how any of this SSL stuff works", there is just one realistic response. Run. Then run some more, hide, change your email and don't answer your phone. Because that shit is about to go down like the titanic.

UK-AL 10y ago
But web developers should know how SSL works anyway. Otherwise your probably not a great developer. I defiantly learned about SSL, and pki infrastructure through developer knowledge.
- nickpsecurity 10y ago
  If library is done well, then you shouldn't have to know much about SSL to be able to use it. Just an abstract idea of it plus how to use the library. SSL from an ops perspective is quite different. That's why it's better to have pro's in each working together on it.
  - UK-AL 10y ago

zer00eyz 10y ago

> Isn't a core tenant of DevOps that your developers are the ones doing the Ops too? This isn't how it started. "deliver a seminal talk known as “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” The talk is an energetic presentation in which Allspaw and Hammond basically act out the classic “fingerpointy” conundrum of Dev versus Ops—“It’s not my code, it’s your machines!” (and vice versa)—to a roomful of developers. They make the case that the only sensible way to build, test and deploy workable new software is to make development and operations transparent and integrated. Read more at http://rewrite.ca.com/us/articles/devops/a-short-history-of-devops.html#CHg4UHoQS6FCg8oo.99"* http://rewrite.ca.com/us/articles/devops/a-short-history-of-... From: http://rewrite.ca.com/us/articles/devops/a-short-history-of-devops.html http://rewrite.ca.com/us/articles/devops/a-short-history-of-... Honestly if you go back to the early 2000's Operations and Engineering were often playing the blame game if not at outright war. I can't tell you how many SA's told me to "file a ticket" when asking for basic factual information (not changes). The idea of a "full stack" engineer is mostly a myth. If your starting out small hiring a generalist who can do it "all" is probably a good thing. The issue is finding folks who can do everything well is HARD. Once you hit a certain scale, you need people dedicated to each JOB (Front end, back end, operations, database, networking). When you get to the level of having a lot of specialists, having someone do "DevOps" to act as a bridge, to speak able to speak to specialists and convey issues can be vital.

biot 10y ago

To avoid confusion, I assume you mean "tenet" as in principle, not "tenant" as in "occupying someone else's property", which could get confusing when talking about containers, cloud computing, and using some provider's resources.