3 ms·

I disagree. DevOps was intended to break the organizational mindset of having this group of people here doing this set of activities and this other group of peo

I disagree. DevOps was intended to break the organizational mindset of having this group of people here doing this set of activities and this other group of people over there doing that set of activities when in reality both groups of people are needed to work together and deploy software. It was about breaking down those organizational silos. Anybody creating a dedicated "DevOps" team was way off the mark, unless that team was a coaching team whose job it was to help other teams become self-sufficient. Unfortunately the fact that an engineering team had responsibility for their software from implementation, to deployment, to operations was a news flash to large organizations having traditional IT staff. The DevOps mindset has led to much better operational excellence. The DevOps mindset has also led to the Internal Developer Platform this article discusses. Honestly, I don't see how traditional IT organizations are going to easily arrive at such a platform without having adopted the DevOps mindset first. So DevOps isn't bullshit, but it's not the end goal either. It's a necessary step needed on your journey for getting somewhere better.

ozim 4y ago
I think that was not mentality. Maybe after years of working that way it turned out into mentality. That was employee utilization approach where you hire 1 DBA and he runs all DB stuff because hiring DBA for each team does not make financially sense as there is not enough day to day work for DBA specialist on a project/product. Other stuff is that DBA/SysAdmins have to have access to customer - company data so you still need separation of duties (no devs access on prod systems) and it is easier to make guy part of "OpsTeam" and give him access across all systems than get "Ops" person configured per project\product. So why "DevOps" if you get operational overhead and you cannot "utilize employee 100%"? Because in most companies delivering new features is more important than making Joe Dbaer closing tickets like in factory because we learned it actually is not efficient when "important feature X" is delayed because Joe was doing his job fine but feature X was in queue.
- taylodl 4y ago
  Good things happen when developers are involved in Ops. Most developers would prefer to develop and not focus so much on Ops, and so they take the steps to automate the Ops as much as possible and essentially make the problem go away. Dedicated Ops staff won't do that because that would put them out of work.
  - kazen44 4y ago
    in my opinion, the ops folk who are good at their jobs do automate the boring stuff. (because doing grunt work is uninteresting) I highly doubt ops will ever go away considering someone has to think about maintaining stability in a production environment. This is usually a different way of thinking a lot of developers are simply not aligned to do.

ozim 4y ago

I think that was not mentality. Maybe after years of working that way it turned out into mentality. That was employee utilization approach where you hire 1 DBA and he runs all DB stuff because hiring DBA for each team does not make financially sense as there is not enough day to day work for DBA specialist on a project/product. Other stuff is that DBA/SysAdmins have to have access to customer - company data so you still need separation of duties (no devs access on prod systems) and it is easier to make guy part of "OpsTeam" and give him access across all systems than get "Ops" person configured per project\product. So why "DevOps" if you get operational overhead and you cannot "utilize employee 100%"? Because in most companies delivering new features is more important than making Joe Dbaer closing tickets like in factory because we learned it actually is not efficient when "important feature X" is delayed because Joe was doing his job fine but feature X was in queue.

taylodl 4y ago
Good things happen when developers are involved in Ops. Most developers would prefer to develop and not focus so much on Ops, and so they take the steps to automate the Ops as much as possible and essentially make the problem go away. Dedicated Ops staff won't do that because that would put them out of work.
- kazen44 4y ago
  in my opinion, the ops folk who are good at their jobs do automate the boring stuff. (because doing grunt work is uninteresting) I highly doubt ops will ever go away considering someone has to think about maintaining stability in a production environment. This is usually a different way of thinking a lot of developers are simply not aligned to do.