6 ms·

This is a hot take. The reason that you need to do things the ops way is because ops knows how to run applications in production. There's a reason the meme "wo

This is a hot take. The reason that you need to do things the ops way is because ops knows how to run applications in production. There's a reason the meme "worked in dev, ops problem now" exists. You need to meet all of the requirements of an app that's running in production from a technical, availability, security, and policy point-of-view. It's not easy and that's why this will never work. Software is hard, it's just that a lot of developers used to cut their code, run it on their laptop, and let someone else worry about it. It's different these days (although not as much as I'd like). We don't make you use these tools because we want to, we use these tools because we're required too. No one cared about ISO27001, SOC2, or PCIDSS compliance for your crappy PHP app you ran on your cpanel. They didn't care back then you were using md5 hashes to "secure" passwords. The world is fundamentally different to what it used to be 10-15 years ago, and the requirements from business are astronomically different. Edit: and to people saying "oh you could just run it on a single server", no you can't because certifications like ISO27001 require certain levels of availability and DR. You're not going to be able to guarantee that with a single server running in a rack somewhere.

deleted 4y ago
[deleted]
dhzhzjsbevs 4y ago
> This is a hot take. I'm assuming you mean your comment, not the post itself. > The reason that you need to do things the ops way is because ops knows how to run applications in production Stability in production is one metric. Ops overindexing on this metric is exactly what causes the friction with developers. Developers are trying to ship value to customers. Uptime is only one part of that equation and for most businesses, it's not even a very important one. The author points this out near the end. DevOps can't convince devs to use ops techniques if all the reasons for using those techniques are based on the flawed assumption that development velocity isn't important.
- gonehome 4y ago
  > “Developers are trying to ship value to customers.” I’ve also seen this be fairly rare. Devs shipping nothing - not even aware if what they're merging will turn on. They write something they haven’t really tested, merge it, and call it done - a user may never see it and they don’t have any knowledge about how the thing actually gets built and shipped. Obviously this is worst-case, but in my experience this is a common default. The complaints about friction are because they’re actually forced to reason about how the machine works in order to ship something beyond merge.
  - Aeolun 4y ago
    > They write something they haven’t really tested, merge it, and call it done This is a problem of incentives. For all intents and purposes, the dev organization ceases to care the moment something is merged. Nobody is rewarded for making sure everything is fine all the way to production. Now if you ship two extra Jira tickets this sprint however...
  - dhzhzjsbevs 4y ago
    I don't generally make a habit of basing my software development lifecycle methodologies on the lowest common denominator engineering org. Some shops ship value to customers with tests and metrics every day.
- dragonwriter 4y ago
  > DevOps can’t convince devs to use ops techniques If “DevOps” is the name of a role, and part of the funtion of that role is “convince devs to use ops techniques”, then I feel like the concept of DevOps is lost. Devs need to own ops, including its costs, which is what convinces them to use ops-appropriate techniques, not some outsider jawing at them.
  - dhzhzjsbevs 4y ago
    > ops-appropriate techniques The true DevOps.
skjoldr 4y ago
Certifications are a very good point because afaik ISO 27001 is now far more achievable for far more companies of smaller sizes with not that many IT staff. Sometimes even 3 good engineers can set up everything needed to pass ISO in a small company in like half a year or something.
jen20 4y ago
> You're not going to be able to guarantee that with a single server running in a rack somewhere. The way most “enterprises” deploy distributed systems, I’d be surprised if a single server didn’t typically result in better uptime to be honest.

deleted 4y ago

[deleted]

dhzhzjsbevs 4y ago

> This is a hot take. I'm assuming you mean your comment, not the post itself. > The reason that you need to do things the ops way is because ops knows how to run applications in production Stability in production is one metric. Ops overindexing on this metric is exactly what causes the friction with developers. Developers are trying to ship value to customers. Uptime is only one part of that equation and for most businesses, it's not even a very important one. The author points this out near the end. DevOps can't convince devs to use ops techniques if all the reasons for using those techniques are based on the flawed assumption that development velocity isn't important.

gonehome 4y ago
> “Developers are trying to ship value to customers.” I’ve also seen this be fairly rare. Devs shipping nothing - not even aware if what they're merging will turn on. They write something they haven’t really tested, merge it, and call it done - a user may never see it and they don’t have any knowledge about how the thing actually gets built and shipped. Obviously this is worst-case, but in my experience this is a common default. The complaints about friction are because they’re actually forced to reason about how the machine works in order to ship something beyond merge.
- Aeolun 4y ago
  > They write something they haven’t really tested, merge it, and call it done This is a problem of incentives. For all intents and purposes, the dev organization ceases to care the moment something is merged. Nobody is rewarded for making sure everything is fine all the way to production. Now if you ship two extra Jira tickets this sprint however...
- dhzhzjsbevs 4y ago
  I don't generally make a habit of basing my software development lifecycle methodologies on the lowest common denominator engineering org. Some shops ship value to customers with tests and metrics every day.
dragonwriter 4y ago
> DevOps can’t convince devs to use ops techniques If “DevOps” is the name of a role, and part of the funtion of that role is “convince devs to use ops techniques”, then I feel like the concept of DevOps is lost. Devs need to own ops, including its costs, which is what convinces them to use ops-appropriate techniques, not some outsider jawing at them.
- dhzhzjsbevs 4y ago
  > ops-appropriate techniques The true DevOps.

skjoldr 4y ago

Certifications are a very good point because afaik ISO 27001 is now far more achievable for far more companies of smaller sizes with not that many IT staff. Sometimes even 3 good engineers can set up everything needed to pass ISO in a small company in like half a year or something.

jen20 4y ago

> You're not going to be able to guarantee that with a single server running in a rack somewhere. The way most “enterprises” deploy distributed systems, I’d be surprised if a single server didn’t typically result in better uptime to be honest.