5 ms·

I've been at events where Docker people were pushing this "separation of concerns" nonsense. Really? The devs build it, hand the black box to ops, and ops has

by alrs 12y ago

I've been at events where Docker people were pushing this "separation of concerns" nonsense. Really? The devs build it, hand the black box to ops, and ops has no say in how things are built or even knowledge of how to fix it? You're pushing to make it so that ops is powerless to fix your "tamperproof" container? I haven't met very many devs qualified to work as ops engineers, and I've met even fewer interested in jumping in to opsland and joining on-call rotation. Containers are cool. Docker's "separation of concerns" and "tamperproof" messaging, however, is ridiculous. Devops was supposed to be about communication and ditching silos. The vision that Docker is pushing is anti-collaborative and unrealistic. The technology is interesting, the sales pitch is horrible.

jacquesm 12y ago
It all depends on your use case. I can see some deployment situations where the ops people would be the ones asking for tamper resistance. If you're running a small shop with only few people and you're not in banking or some other branch of industry where mistakes are very costly then separation of concerns is probably not your main worry. But if you're operating with some auditor looking over your back then it can become a very powerful argument for using some technology over another. As with any tool: use it where it is appropriate. This all assumes that docker will make tamper-proof an option, not mandatory.
nickstinemates 12y ago
I don't mean that in an organizational way at all. My terse perspective be the cause of the negative reaction and for that I apologize. My fault for trying to respond while meeting with all of the awesome people at DockerCon. Edit to add that, I speak of a time where people know exactly what is running on their infrastructure, what version, who built it, any additional Metadata they want to track as a part of that. Built on top of those primitives you can create any sort of policy that you have a reasonable chance of enforcing. About our marketing, it's interesting feedback, because I'd say I agree with the premise of the points you make. Developers are not ops people. Ops people are not developers. And trying to make them the same is not a recipe for success.
parasubvert 12y ago
It's not about anti-collaboration, it's about making sure your infrastructure doesn't change unpredictably, so you can treat containers as the unit of deployment that matters. Removing tampering means that anyone (Dev/ops) fixes things in a predictable, orchestratable manner. It's the nail in the coffin on box-hugging syndrome ("oh I'll just telnet into Gandalf to fix that wrong IP address"). Nope - fix the fockerfile, mint a new container and chuck the old one. Same goes for "helpful" Puppet runs that actually bork up the broader system because of an undeclared / unmanaged dependency in your manifests. Of course there are exceptions to every rule, but immutable infrastructure, it's a thing.
- alrs 12y ago
  Go to a meetup, listen to what the Docker guys are saying. It isn't this. They are explicit that their vision is for developers to bake up a container, and for ops to mindlessly deploy it. They use the shipping container metaphor: ops dockworkers just slot containers in to place, only the devs get to see what's inside. Yeah, immutable is a thing. Docker messaging is something else entirely.
  - koffiezet 12y ago
    My current job is sysadmin, but I come from development, and what you say is rubbish. You can just as well say that the binary the devs gave you is a blackbox. The Docker images I have to deploy are built on the CI system, and I get them from there. In practice however, it's me writing the Dockerfiles, and the devs getting a better insight of it's best practices when deploying. I'm also involved from the beginning, because I am the Docker magician, and this helps to avoid a lot of problems. Things like "download, compile and deploy bleeding edge [stable version]+2" of some software in deploy documents will never make it beyond the fantasy of some junior developer. I have currently set up 2 projects to be completely docker based, one was a brand-new one, one was a conversion from a huge multi-component other project, and since the transition, things now already go a lot smoother deploying them to QA and test, than it ever did before, and the project is not even supposed to be deployed there yet, but it already works without a problem. The day they submit a service request and 5 minutes later are standing next to my desk to say "it urgently needs to be deployed" because there's a demo the next day, I don't have to stress out because I now I'm pretty confident I'll have it up and running in 5 minutes. There is one big prerequisite for all this to work: the developers have to use the docker images them-self, ALL the time. But that's just my experience.

by alrs 12y ago

jacquesm 12y ago

It all depends on your use case. I can see some deployment situations where the ops people would be the ones asking for tamper resistance. If you're running a small shop with only few people and you're not in banking or some other branch of industry where mistakes are very costly then separation of concerns is probably not your main worry. But if you're operating with some auditor looking over your back then it can become a very powerful argument for using some technology over another. As with any tool: use it where it is appropriate. This all assumes that docker will make tamper-proof an option, not mandatory.

nickstinemates 12y ago

I don't mean that in an organizational way at all. My terse perspective be the cause of the negative reaction and for that I apologize. My fault for trying to respond while meeting with all of the awesome people at DockerCon. Edit to add that, I speak of a time where people know exactly what is running on their infrastructure, what version, who built it, any additional Metadata they want to track as a part of that. Built on top of those primitives you can create any sort of policy that you have a reasonable chance of enforcing. About our marketing, it's interesting feedback, because I'd say I agree with the premise of the points you make. Developers are not ops people. Ops people are not developers. And trying to make them the same is not a recipe for success.

parasubvert 12y ago

It's not about anti-collaboration, it's about making sure your infrastructure doesn't change unpredictably, so you can treat containers as the unit of deployment that matters. Removing tampering means that anyone (Dev/ops) fixes things in a predictable, orchestratable manner. It's the nail in the coffin on box-hugging syndrome ("oh I'll just telnet into Gandalf to fix that wrong IP address"). Nope - fix the fockerfile, mint a new container and chuck the old one. Same goes for "helpful" Puppet runs that actually bork up the broader system because of an undeclared / unmanaged dependency in your manifests. Of course there are exceptions to every rule, but immutable infrastructure, it's a thing.

alrs 12y ago
Go to a meetup, listen to what the Docker guys are saying. It isn't this. They are explicit that their vision is for developers to bake up a container, and for ops to mindlessly deploy it. They use the shipping container metaphor: ops dockworkers just slot containers in to place, only the devs get to see what's inside. Yeah, immutable is a thing. Docker messaging is something else entirely.
- koffiezet 12y ago
  My current job is sysadmin, but I come from development, and what you say is rubbish. You can just as well say that the binary the devs gave you is a blackbox. The Docker images I have to deploy are built on the CI system, and I get them from there. In practice however, it's me writing the Dockerfiles, and the devs getting a better insight of it's best practices when deploying. I'm also involved from the beginning, because I am the Docker magician, and this helps to avoid a lot of problems. Things like "download, compile and deploy bleeding edge [stable version]+2" of some software in deploy documents will never make it beyond the fantasy of some junior developer. I have currently set up 2 projects to be completely docker based, one was a brand-new one, one was a conversion from a huge multi-component other project, and since the transition, things now already go a lot smoother deploying them to QA and test, than it ever did before, and the project is not even supposed to be deployed there yet, but it already works without a problem. The day they submit a service request and 5 minutes later are standing next to my desk to say "it urgently needs to be deployed" because there's a demo the next day, I don't have to stress out because I now I'm pretty confident I'll have it up and running in 5 minutes. There is one big prerequisite for all this to work: the developers have to use the docker images them-self, ALL the time. But that's just my experience.