4 ms·

You make a good point that "doing devops" is a methodology that you can choose to use or not. There is no moral hazard in not using it. That said, having ops e

by alrs 10y ago

You make a good point that "doing devops" is a methodology that you can choose to use or not. There is no moral hazard in not using it. That said, having ops excluded from the architecture decisions that go into building containers is absolutely antithetical to "doing devops." As for your assertion that people know who is responsible for what in your model, I argue that devs are usually not thinking ahead that they're going to be the ones on-call to fix whatever breaks in production in the middle of the night, because they're the only ones who know what's inside the container. Ops can't be responsible for fixing whatever is inside an artifact that it had no role in creating. We're going to to have the inverse of the little-girl-smiling-at-the-house-fire meme. "Kubernetes is Running Fine, Dev Problem Now."

ErrantX 10y ago
DevOps isn't (just) Dev doing Ops and Ops doing dev, though. It's about understanding each teams domain and facilitating communication. Nothing about Docker limits that, per se. e.g: > I argue that devs are usually not thinking ahead that they're going to be the ones on-call to fix whatever breaks in production in the middle of the night That's not a Docker issue. That's just a DevOps culture that is incomplete.
shykes 10y ago
> That said, having ops excluded from the architecture decisions that go into building containers is absolutely antithetical to "doing devops". My point precisely. Just because there is clean separation of concerns doesn't mean anyone needs to be excluded. The methodology I've seen work best is one where people are not divided by skillset (dev/ops) but instead by area of responsibility (app/infrastructure). Then you embed people from different functional areas into app teams: devs of course, but also security engineer, operations specialist, and various domain experts. From the point of view of IT, you're influencing the development of the app before development to make sure it follows best practices. A second important point is that, just because you're running a container built by someone else doesn't mean you can't enforce good operations practices. For example, you can mandate that all the containers on your production swarm expose health information at a specific url prefix and pass CVE scanning - or they will not be deployed.

by alrs 10y ago

ErrantX 10y ago

DevOps isn't (just) Dev doing Ops and Ops doing dev, though. It's about understanding each teams domain and facilitating communication. Nothing about Docker limits that, per se. e.g: > I argue that devs are usually not thinking ahead that they're going to be the ones on-call to fix whatever breaks in production in the middle of the night That's not a Docker issue. That's just a DevOps culture that is incomplete.

shykes 10y ago

> That said, having ops excluded from the architecture decisions that go into building containers is absolutely antithetical to "doing devops". My point precisely. Just because there is clean separation of concerns doesn't mean anyone needs to be excluded. The methodology I've seen work best is one where people are not divided by skillset (dev/ops) but instead by area of responsibility (app/infrastructure). Then you embed people from different functional areas into app teams: devs of course, but also security engineer, operations specialist, and various domain experts. From the point of view of IT, you're influencing the development of the app before development to make sure it follows best practices. A second important point is that, just because you're running a container built by someone else doesn't mean you can't enforce good operations practices. For example, you can mandate that all the containers on your production swarm expose health information at a specific url prefix and pass CVE scanning - or they will not be deployed.