4 ms·

Unfortunately here in Germany the majority of “devops” is just a bunch of operations people who maintain terraform and ansible markup, no real dev involved. De

Unfortunately here in Germany the majority of “devops” is just a bunch of operations people who maintain terraform and ansible markup, no real dev involved. DevSecOps seems to just be plugging sonarqube into ci pipelines and installing siem/wafs. Is it really better anywhere else?

gonzo41 5y ago
Nope, we just use Jfrog Xray.
allendoerfer 5y ago
Can confirm and have a suspicion that OP is sitting right next to me.
jstx1 5y ago
What's bad about it? Apart from the name mismatch and that it could have been just "Ops".
- allendoerfer 5y ago
  At least in my organization, these Ops people did not get the whole point about DevOps. They are basically just administering servers and using Ansible to do it. E.g. if a services does not start after running a playbook, they are logging in and restarting it, instead of fixing the playbook. Ansible runs on a weekly schedule instead of provisioning based on application needs. They have their own playbooks for standard systems and doing custom modifications through SSH, if you have special needs. I could go on. They just totally missed the point of DevOps, it's just Ops with DevOps tools. You can compare it with how we/they are doing agile.
  - skywhopper 5y ago
    I would say your approach of blaming “them” for missing the point, misses the point. Think about your own responsibility. DevOps is not a single role in an org, but a way of doing business and collaborating between dev and ops teams. If your ops support is not sufficient for the devs’ needs, then the devs should be working with ops to fix it. If the devs are saying “oh, ops is no good at DevOps, so that’s why our deployment process sucks” then it’s as much the devs’ fault as the ops team.
    - allendoerfer 5y ago
      And I am trying to do so every day. This is not some small operation, where I can just go over to a different desk and talk about just doing it differently. I am talking about an organization with hundreds of thousands of employees. In this case Ops is literally a different legal entity. I have no say whatsoever over "them". If you want to change something, it's more about constantly begging and nagging. It is a very fine line, you risk to become difficult to work with. After all, sometimes you actually need "them" to do something for you. It also costs a lot of energy. At some point most people just stop trying and focus on more important things in life.
temp0826 5y ago
My last couple devops roles were somewhat this, involving mostly infra-type stuff. It's really a catch-all term for someone who keeps the "10000 foot view" of the product so the "real" devs can focus on their own little cog in the wheel. I usually absorbed all of the testing automation, centralized logging/metrics, "IT" (directory/ldap, backups), sane security and networking etc etc and ensured their was a coherent story soup-to-nuts. Wrote a lot of python/glue and "business"-oriented infrastructure management tools along the way. Had to be the point person for anything in the aws console, from dbs to vpns to docker containers to cdns etc etc and dealt with integrations to other saas/products as well
q3k 5y ago
It is, but it's difficult to introduce. Just hiring 'devops' people for your ops team, or giving developers access to AWS is missing the whole damn point. It requires reorganizing work in a way that makes a lot of people angry, as they now have to do things that so far they've just tossed over the wall to another team and then complained loudly when that didn't work. You have to convince developers that they're responsible for making software easy to deploy and debug, and get them to carry pagers during work hours. You have to convince them to make the product internals clear for everyone, including to operations people, and get them to do knowledge exchange with them. You have to enable them by providing insight into production deployments and providing a platform that unifies production/development as much as possible without tons of boilerplate required per project (common database interfaces, common logging interfaces, common CI, common release procedures, common development environment). You have to convince operations teams to write programs in something other than bash, and to generally follow good software engineering practices, to write operations-level code that is as testable as the application itself. You have to enable them by giving them the means to build a company-wide production platform where complexity is decimated by moving every product team onto the simplest possible setup. You have to let them build bespoke tooling and accept that these lines of code are as important as the application code itself. With all of this implemented well, the differences between ops and dev roles will begin to blur, people with different backgrounds will mingle within and across teams, and you will end up with a more platform/product split between teams rather than a development/operations split.
- chazu 5y ago
  This person gets it. Which is rare - do you want a job? :) But seriously, you hit upon something which is important, but very hard to communicate/admit - a big part of making the "DevOps Transformation" happen - which is a cheesy term but it conveys something better than just DevOps - is saying _no_ to devs and traditional SysAdmins and giving them a better alternative. Unfortunately this means that SysAdmin skillsets need to be supplemented or even supplanted by SWE skillsets. But the TL;DR is yes, doing DevOps often means putting the brakes on fun.
tupac_speedrap 5y ago
It's the opposite where I work. We are "DevOps Engineers" but we spend most of our time writing Java and we get by using Kubernetes, Docker and Ansible but I always feel like we are scratching the surface a bit.

gonzo41 5y ago

Nope, we just use Jfrog Xray.

allendoerfer 5y ago

Can confirm and have a suspicion that OP is sitting right next to me.

jstx1 5y ago

What's bad about it? Apart from the name mismatch and that it could have been just "Ops".

allendoerfer 5y ago
At least in my organization, these Ops people did not get the whole point about DevOps. They are basically just administering servers and using Ansible to do it. E.g. if a services does not start after running a playbook, they are logging in and restarting it, instead of fixing the playbook. Ansible runs on a weekly schedule instead of provisioning based on application needs. They have their own playbooks for standard systems and doing custom modifications through SSH, if you have special needs. I could go on. They just totally missed the point of DevOps, it's just Ops with DevOps tools. You can compare it with how we/they are doing agile.
- skywhopper 5y ago
  I would say your approach of blaming “them” for missing the point, misses the point. Think about your own responsibility. DevOps is not a single role in an org, but a way of doing business and collaborating between dev and ops teams. If your ops support is not sufficient for the devs’ needs, then the devs should be working with ops to fix it. If the devs are saying “oh, ops is no good at DevOps, so that’s why our deployment process sucks” then it’s as much the devs’ fault as the ops team.
  - allendoerfer 5y ago
    And I am trying to do so every day. This is not some small operation, where I can just go over to a different desk and talk about just doing it differently. I am talking about an organization with hundreds of thousands of employees. In this case Ops is literally a different legal entity. I have no say whatsoever over "them". If you want to change something, it's more about constantly begging and nagging. It is a very fine line, you risk to become difficult to work with. After all, sometimes you actually need "them" to do something for you. It also costs a lot of energy. At some point most people just stop trying and focus on more important things in life.

temp0826 5y ago

My last couple devops roles were somewhat this, involving mostly infra-type stuff. It's really a catch-all term for someone who keeps the "10000 foot view" of the product so the "real" devs can focus on their own little cog in the wheel. I usually absorbed all of the testing automation, centralized logging/metrics, "IT" (directory/ldap, backups), sane security and networking etc etc and ensured their was a coherent story soup-to-nuts. Wrote a lot of python/glue and "business"-oriented infrastructure management tools along the way. Had to be the point person for anything in the aws console, from dbs to vpns to docker containers to cdns etc etc and dealt with integrations to other saas/products as well

q3k 5y ago

It is, but it's difficult to introduce. Just hiring 'devops' people for your ops team, or giving developers access to AWS is missing the whole damn point. It requires reorganizing work in a way that makes a lot of people angry, as they now have to do things that so far they've just tossed over the wall to another team and then complained loudly when that didn't work. You have to convince developers that they're responsible for making software easy to deploy and debug, and get them to carry pagers during work hours. You have to convince them to make the product internals clear for everyone, including to operations people, and get them to do knowledge exchange with them. You have to enable them by providing insight into production deployments and providing a platform that unifies production/development as much as possible without tons of boilerplate required per project (common database interfaces, common logging interfaces, common CI, common release procedures, common development environment). You have to convince operations teams to write programs in something other than bash, and to generally follow good software engineering practices, to write operations-level code that is as testable as the application itself. You have to enable them by giving them the means to build a company-wide production platform where complexity is decimated by moving every product team onto the simplest possible setup. You have to let them build bespoke tooling and accept that these lines of code are as important as the application code itself. With all of this implemented well, the differences between ops and dev roles will begin to blur, people with different backgrounds will mingle within and across teams, and you will end up with a more platform/product split between teams rather than a development/operations split.

chazu 5y ago
This person gets it. Which is rare - do you want a job? :) But seriously, you hit upon something which is important, but very hard to communicate/admit - a big part of making the "DevOps Transformation" happen - which is a cheesy term but it conveys something better than just DevOps - is saying _no_ to devs and traditional SysAdmins and giving them a better alternative. Unfortunately this means that SysAdmin skillsets need to be supplemented or even supplanted by SWE skillsets. But the TL;DR is yes, doing DevOps often means putting the brakes on fun.

tupac_speedrap 5y ago

It's the opposite where I work. We are "DevOps Engineers" but we spend most of our time writing Java and we get by using Kubernetes, Docker and Ansible but I always feel like we are scratching the surface a bit.