7 ms·

DevOps is the intersection of three things. 1. Developers learning that running code is not the same thing as reliable code. Certain things must be put in at d

DevOps is the intersection of three things. 1. Developers learning that running code is not the same thing as reliable code. Certain things must be put in at design time to allow for operations. 2. Operations people supporting development by formalizing/streamlining the deployment process to have changes occur faster, safer, and more often. 3. Aligning goals and attitudes in such a way that prevents conflict between teams. Development doesn't get to shift the costs of outage prone unmaintainable code onto an ops team. Or that ops doesn't roadblock/veto all changes. In the bad old days, it was common for developers to act with little care for operational outcomes. The responsibility was far removed, and bugfixes didn't win many accolades. Managers want wish fulfillment and pushed developers to toss new features into the mix as fast as possible, resulting in tremendous pressure against ops teams to deploy despite increasingly crufty and debt laden code bases causing unpredictable problems. Ergo, ops teams who blocked all changes for trivial issues because they were judged only based on outages, not feature delivery.

eternalban 7y ago
DevOps is blue collar work. Software Engineering used to be white collar work. Think boiler room vs drafting room.
- scarface74 7y ago
  How is Devops "blue collar work"? Provisioning servers, databases, load balancers, etc and other resources use to involve someone driving down to the colo and installing hardware. Often now, it's a yaml file you run through Cloud Formation. Devops is just as much development and software engineering when you are working in a cloud environment -- it's an API call.
  - viklove 7y ago
    That's exactly the reason. Software engineering is about writing code, devops is about writing yaml files and keying into functionality that was implemented by software engineers.
    - bfrydl 7y ago
      Describing ops as “writing yaml files” is like describing software engineering as “typing.”
      - dwd 7y ago
        There seems to be an overvaluation of the time spent typing. Does anyone spend any time thinking, researching, planning, designing or communicating?
    - scarface74 7y ago
      So would you consider it more “software engineering” using AWS’s Cloud Development Kit and writing code to generate cloud formation files “software engineering”? I use to think that all “true” developers needed to know the ins and outs of assembly because every time I went to a new platform that’s the first thing that I did - learn assembly language (65C02, 68K, x86), but then I grew up..... CloudFormation takes a text file and generates API calls much like any code compiled down to assembly.
    - 0xEFF 7y ago
      > Software engineering is about writing code, devops is about writing yaml files and keying into functionality that was implemented by software engineers. This attitude is the ultimate reason for dysfunctional development teams and the source of the barrier between operations and development. It’s also toxic.
      - delian66 7y ago
        It is also true.
        z9e 7y ago
        And it’s also not true. There’s a spectrum with this title in the context of skill like any profession.
        weberc2 7y ago
  - eternalban 7y ago
    I provided what is imo a very clear and apples-to-apples analogy there for you: Drafting room vs Boiler room. (Replaces guages with graphs of alerts and logs and you'll get the idea.) Certainly, in other engineering fields, visits to the installation sites by (designing) engineers, or even running pilot programs to debug the system as designed and implemented is a norm. However, the notion that 'an engineers job is to be responsible for x-widget from design to operation' is entirely foreign to any notion of "Engineering" that I am familiar with.
    - scarface74 7y ago
      It’s a poor “senior” software engineer who doesn’t understand anything about the underlying architecture or how to at least troubleshoot the infrastructure and have at least some type of understanding of the ops part. How many hardware based Kickstarter projects have failed because they didn’t understand the complexity of actually manufacturing there product at scale. It’s analogous to software engineers who don’t appreciate ops. Writing software for a company is useless if you can’t ship it or deploy it. You can’t imagine the number of bright eyed bushy tailed “software engineers” I’ve dealt with that thought they were smart because they knew leetCode and learned algorithms who couldn’t troubleshoot performance issues or understand why they couldn’t get shipping products because they didn’t understand the ops side of things. Of course I am not diminishing the role of software engineering, I’ve been developing software actively professionally or as a hobby for over 30 years. But, I know enough in theory to talk to the ops guys for on prem/colo/hybrid architectures and I could easily be competitive on the ops side for jobs dealing with fully “cloud native” solutions for a small to medium size implementation.
      - eternalban 7y ago
        It would be a poor architect that didn't understand anything about building technology, but that doesn't require spending time laying bricks as a laborer. I think you are missing the point.
- whitecollarops 7y ago
  Imagine gatekeeping the type of work people do towards the guys who actually make your stuff work.
- Aloha 7y ago
  I guess the python, and bash I write doesnt count as code. I guess the architect work I do to do design implementations doesnt count either.
- deboflo 7y ago
  Labels like these are meaningless. I make more money as a DevOps Engineer than I did as a Google SWE, and I have significantly more responsibilities. The DevOps community is diverse. There are “DevOps” engineers who can’t write code (sadly) and those that write incredibly advanced serverless systems that scale massively.
ozim 7y ago
Yes, devops is not one person, but team is devops. It comes from standards, that developers should not have access to production data, so you need ops. But on the other hand you don't want to have dev and ops team people who throw shit over the fence. So basically it comes to having devs, test, ops, sec, persons in one team with common goal of delivering featuers. Because most friction was on boarders like dev | test | ops | security, all those people being on role specific teams would do what is important for their team. So test people would blame devs, sec people would blame ops, test or devs. When you are in one team that has common goal of delivering feature X and you are measured by delivering feature X, everyone is willing to take pragmatic approach instead of "code has to be perfect", "tests have to be perfect", "security has to be perfect". I read somewhere "magic happens if you seat testers and developers in the same room", I belive it was "Project Phoenix" book. But I despise from the start having those devs vs test people or test people beeing happy about finding bugs. They should be sad because what matters is delivering feature, so they should be happy when they don't find anything. That said, thay should do all they can to find bugs, because we have common goal: "working software".

eternalban 7y ago

DevOps is blue collar work. Software Engineering used to be white collar work. Think boiler room vs drafting room.

scarface74 7y ago
How is Devops "blue collar work"? Provisioning servers, databases, load balancers, etc and other resources use to involve someone driving down to the colo and installing hardware. Often now, it's a yaml file you run through Cloud Formation. Devops is just as much development and software engineering when you are working in a cloud environment -- it's an API call.
- viklove 7y ago
  That's exactly the reason. Software engineering is about writing code, devops is about writing yaml files and keying into functionality that was implemented by software engineers.
  - bfrydl 7y ago
    Describing ops as “writing yaml files” is like describing software engineering as “typing.”
    - dwd 7y ago
      There seems to be an overvaluation of the time spent typing. Does anyone spend any time thinking, researching, planning, designing or communicating?
  - scarface74 7y ago
    So would you consider it more “software engineering” using AWS’s Cloud Development Kit and writing code to generate cloud formation files “software engineering”? I use to think that all “true” developers needed to know the ins and outs of assembly because every time I went to a new platform that’s the first thing that I did - learn assembly language (65C02, 68K, x86), but then I grew up..... CloudFormation takes a text file and generates API calls much like any code compiled down to assembly.
  - 0xEFF 7y ago
    > Software engineering is about writing code, devops is about writing yaml files and keying into functionality that was implemented by software engineers. This attitude is the ultimate reason for dysfunctional development teams and the source of the barrier between operations and development. It’s also toxic.
    - delian66 7y ago
      It is also true.
      - z9e 7y ago
        And it’s also not true. There’s a spectrum with this title in the context of skill like any profession.
      - weberc2 7y ago
- eternalban 7y ago
  I provided what is imo a very clear and apples-to-apples analogy there for you: Drafting room vs Boiler room. (Replaces guages with graphs of alerts and logs and you'll get the idea.) Certainly, in other engineering fields, visits to the installation sites by (designing) engineers, or even running pilot programs to debug the system as designed and implemented is a norm. However, the notion that 'an engineers job is to be responsible for x-widget from design to operation' is entirely foreign to any notion of "Engineering" that I am familiar with.
  - scarface74 7y ago
    It’s a poor “senior” software engineer who doesn’t understand anything about the underlying architecture or how to at least troubleshoot the infrastructure and have at least some type of understanding of the ops part. How many hardware based Kickstarter projects have failed because they didn’t understand the complexity of actually manufacturing there product at scale. It’s analogous to software engineers who don’t appreciate ops. Writing software for a company is useless if you can’t ship it or deploy it. You can’t imagine the number of bright eyed bushy tailed “software engineers” I’ve dealt with that thought they were smart because they knew leetCode and learned algorithms who couldn’t troubleshoot performance issues or understand why they couldn’t get shipping products because they didn’t understand the ops side of things. Of course I am not diminishing the role of software engineering, I’ve been developing software actively professionally or as a hobby for over 30 years. But, I know enough in theory to talk to the ops guys for on prem/colo/hybrid architectures and I could easily be competitive on the ops side for jobs dealing with fully “cloud native” solutions for a small to medium size implementation.
    - eternalban 7y ago
      It would be a poor architect that didn't understand anything about building technology, but that doesn't require spending time laying bricks as a laborer. I think you are missing the point.
whitecollarops 7y ago
Imagine gatekeeping the type of work people do towards the guys who actually make your stuff work.
Aloha 7y ago
I guess the python, and bash I write doesnt count as code. I guess the architect work I do to do design implementations doesnt count either.
deboflo 7y ago
Labels like these are meaningless. I make more money as a DevOps Engineer than I did as a Google SWE, and I have significantly more responsibilities. The DevOps community is diverse. There are “DevOps” engineers who can’t write code (sadly) and those that write incredibly advanced serverless systems that scale massively.

ozim 7y ago

Yes, devops is not one person, but team is devops. It comes from standards, that developers should not have access to production data, so you need ops. But on the other hand you don't want to have dev and ops team people who throw shit over the fence. So basically it comes to having devs, test, ops, sec, persons in one team with common goal of delivering featuers. Because most friction was on boarders like dev | test | ops | security, all those people being on role specific teams would do what is important for their team. So test people would blame devs, sec people would blame ops, test or devs. When you are in one team that has common goal of delivering feature X and you are measured by delivering feature X, everyone is willing to take pragmatic approach instead of "code has to be perfect", "tests have to be perfect", "security has to be perfect". I read somewhere "magic happens if you seat testers and developers in the same room", I belive it was "Project Phoenix" book. But I despise from the start having those devs vs test people or test people beeing happy about finding bugs. They should be sad because what matters is delivering feature, so they should be happy when they don't find anything. That said, thay should do all they can to find bugs, because we have common goal: "working software".