Ask HN: The Downsides of DevOps
Hi Everyone,
I am pivoting in my career from being an embedded developer (mainly C/C++) to being a DevOps product owner. I am currently reading Gene Kim's book on DevOps, which makes it all sound like wine and roses. I am experienced enough to know, not just believe, that there is "No Silver Bullet" like Fred Brooks says.
So, I ask you HN community: what are the downsides of DevOps? Any unkept promises? New problems that were exchanged for old ones? I want to know before I have one sip of the "Kool-Aid".
7 comments
DevOps is a culture but many companies just follow suite and put up a team called "DevOps" without getting into the heart of it.
I think there are a few questions you can ask, but in general there are only two that matter:
1- Does upper management support the team, or, does the company have good engineering culture?
2- Does the team lead have good knowledge, or, does the team gather requirements and other info before pushing out their "DevOps" projects?
BTW I have been thinking about engineering culture. Sometimes people think that a good culture just means a blank cheque, but I think it has to be good on both sides. Upper management should give some freedom but engineering team should also gather enough info and evaluates projects before execution. Sounds like common sense but ask yourself or your neighboring teams: Do you always gather enough info and validate your projects? Have you ever volunteerily turned down a proposal without fear?
I think there are a few questions you can ask, but in general there are only two that matter:
1- Does upper management support the team, or, does the company have good engineering culture?
2- Does the team lead have good knowledge, or, does the team gather requirements and other info before pushing out their "DevOps" projects?
BTW I have been thinking about engineering culture. Sometimes people think that a good culture just means a blank cheque, but I think it has to be good on both sides. Upper management should give some freedom but engineering team should also gather enough info and evaluates projects before execution. Sounds like common sense but ask yourself or your neighboring teams: Do you always gather enough info and validate your projects? Have you ever volunteerily turned down a proposal without fear?
Like a lot of things it depends a lot on the company. The label means nothing.
If you work for a company with a poor Engineering culture where tech is not valued "DevOps" means "get the nerds in the basement to fix my laptop". No one will care about you until there's an outage. Then everyone will care about you for 72 hours where they promise to prioritise all the things that were neglected in the last 5 years. And then they will forget about you until the next incident and the cycle will repeat indefinitely.
If you work for a company where Engineering culture is strong and tech is front and centre you can have a more fulfilling career.
If you work for a company with a poor Engineering culture where tech is not valued "DevOps" means "get the nerds in the basement to fix my laptop". No one will care about you until there's an outage. Then everyone will care about you for 72 hours where they promise to prioritise all the things that were neglected in the last 5 years. And then they will forget about you until the next incident and the cycle will repeat indefinitely.
If you work for a company where Engineering culture is strong and tech is front and centre you can have a more fulfilling career.
Most DevOps is classic Sys Admin with Ansible or Terraform, from what I've seen these days. SRE is the new hotness.
[deleted]
downside is that you'll always be on the support side of a company. it's the logistics in the form of tech; it's the most important thing when it's not running perfect, and when it's smooth, no one really pays attention as the main product/mission will be on top of mind.
To me the biggest problem is the same problem that always crops up: the people who sign the checks (the "business owners") don't fundamentally "get" this stuff, nor do they particularly care. And so there's a perpetual "impedance mismatch" where you may want to do things a certain way because you believe in (devops|agile|CMMI|OOP|function points|whatever) and the business people won't support you because they don't understand or care.
They just want results. They see IT/development as a "black box" where the internals can be ignored. It's usually only when you get companies founded by techies, or a handful of visionary types who really see the fusion of tech & business, that you get away from that.
So my take? Sure, go into DevOps. Read the books, read the blogs, watch the videos, learn the "received wisdom." But try not to be overly disappointed when you're unable to implement things exactly according to that wisdom in practice. Do the best you can and accept that there are some things you can't control. Or, start your own company where you can control them.
They just want results. They see IT/development as a "black box" where the internals can be ignored. It's usually only when you get companies founded by techies, or a handful of visionary types who really see the fusion of tech & business, that you get away from that.
So my take? Sure, go into DevOps. Read the books, read the blogs, watch the videos, learn the "received wisdom." But try not to be overly disappointed when you're unable to implement things exactly according to that wisdom in practice. Do the best you can and accept that there are some things you can't control. Or, start your own company where you can control them.
Technical founders help, but it's not required. Structured goal setting, call it OKRs if you want, is the secret sauce. Can't just cargo cult it. Has to be an entire company working together towards goals. That's where the dream of DevOps happens.
Best example I can give is the lore of SpaceX's spending policy. Every purchase was authorized, if it could get the company to Mars faster. True? IDK, I wasn't there, but it's the type of clarity most companies struggle to define. There is no DevOps without that clarity.
Best example I can give is the lore of SpaceX's spending policy. Every purchase was authorized, if it could get the company to Mars faster. True? IDK, I wasn't there, but it's the type of clarity most companies struggle to define. There is no DevOps without that clarity.