4 ms·

It makes more sense in the context of the criticism that Docker gets. It's a counter to the inane "Docker isn't stable enough, Docker isn't secure enough, Docke

by curun1r 10y ago

It makes more sense in the context of the criticism that Docker gets. It's a counter to the inane "Docker isn't stable enough, Docker isn't secure enough, Docker isn't whatever enough to use in production" critique that some obstinate old ops person will throw up because they'd rather keep their job comfortable than try to accommodate a need beyond their own. I don't read it as Docker does all those things so much as Docker is used to do all those things and diseases are getting cured, planes aren't falling from the sky, soldiers aren't getting unnecessarily blown up and financial networks are only crumbling due to their own internal negligence. If it can be used in all those situations, it will probably work for your crappy pool-of-app-servers-on-top-of-a-database webapp.

jsmthrowaway 10y ago
> obstinate old ops person will throw up because they'd rather keep their job comfortable than try to accommodate a need beyond their own Oh, come on. This is why I hate Docker. Right here. It's like a heat seeking missile that looks for the friction points between engineering and operations, then explodes in a fireball of "do we really need operations? They're just old and obstinate and in the way of progress," without even really stopping to ask what progress is from the perspective of operations. Some of us like to think of legitimate technical reasons to push back on Docker in our own circumstances and deployments (some of us even read code to help make that determination), but I suppose your dichotomy would be fun to navigate for everyone involved. I've definitely been in environments where one side characterizes operational pushback as change reticence, which immediately personalizes the discussion. That's a tough environment in which to argue, especially when you're arguing with people who will not be on call for the crap they are trying to deliver to you. The casual ageism in your comment is, sadly, expected. I'm growing accustomed to HN considering it acceptable to go after "old" and "operations" with equal vigor, which speaks more broadly to worrying trends in our industry. I'm 31 and have devoted my career to operations, and I already have an exit plan. That should say something about the industry, and I think this comment is a fine microcosm of that.
- derefr 10y ago
  To me, "old" as a prejorative has about as much to do with age as "gay" as a prejorative has to do with homosexuality. The meaning people use the word to get at is "from another time when problems were solved differently, and staid in their opinions toward new solutions vs. those from the previous era." I've heard myself called an "old man" online for liking SQL stored procedures. I was 23 at the time. :)
- curun1r 10y ago
  For what it's worth, I'm older than you and started in ops. If it helps to put things into context, I spent a ton of 1997 using a chisel to shave a bit off standard RAM to help avoid Sun's near 10x markup. The startup I worked at was provisioning around 20 Sun boxes per week and we had to patch together tools to manage infrastructure of that size before off-the-shelf tooling to do that really existed. I wrote a lot of expect in 97-98. Where I get frustrated with ops is when they forget that they're in the service business. They're there to serve application developers in the same way that the application developers are there to serve customers. An application developer pushing back at a customer ask with the line, "without really stopping to ask what progress is from the perspective of developers" would be rightly lampooned. And yet somehow there's people that think the ops mindset is reasonable. In my view, "no" is not a valid viewpoint. Application developers are telling you they want the kind of functionality that Docker offers. That makes it your job to figure out how that happens, not if it happens.
  - Karunamon 10y ago
    Where I get frustrated with ops is when they forget that they're in the service business. They're there to serve application developers in the same way that the application developers are there to serve customers. In my view, you've got that completely backwards. Both departments serve customers in a roundabout way. Dev is responsible for turning user stories (generated either by other devs, focus groups, and so forth - which may, but doesn't necessarily involve an actual paying customer) into code, ops is responsible for keeping that code running. If dev screws up, user gets bugs, or the app goes down. Same for ops - it's just the class of bugs are different. Application developers are telling you they want the kind of functionality that Docker offers. That makes it your job to figure out how that happens, not if it happens. As long as me and my ops team are the primary people with skin in the game (read: getting 3AM wakeup calls), me and my team will maintain a say in what tech stack we're responsible for the care and feeding of. The dark days of dev throwing code over the wall to ops is long gone - I am gobsmacked that you'd suggest that this is for some reason improper. What dev often forgets, and the cause of much strife, is this justification. If you want a team of n people to learn this new thing and its new ways of operating, then you need to do an honest, dispassionate cost/value analysis. And show your work, dammit. When this never happens, it conveys an "Oh great, Dev is on one of their 'Ooh, shiny!' kicks again" mentality to the rest of the team, especially those that aren't politically connected enough in the org to know any different. I know it's because you're busy and have insane deadlines to meet. Meanwhile, the phones ring at 3am, and the message is lost. The result is a strained and adversarial relationship, often to the customer's detriment.
johnbrodie 10y ago
The reality is, as far as I can see, there's just not much benefit in using Docker in a crappy (read: small) pool-of-app-servers-on-top-of-a-database webapp. I've had a lot of newer devs pushing to use Docker. I haven't had these newer devs give a solid reason why relatively low-volume, simple web apps need an additional layer of complexity over an easier-to-manage VM setup with automated provisioning.
- deleted 10y ago
  [deleted]

by curun1r 10y ago

jsmthrowaway 10y ago

> obstinate old ops person will throw up because they'd rather keep their job comfortable than try to accommodate a need beyond their own Oh, come on. This is why I hate Docker. Right here. It's like a heat seeking missile that looks for the friction points between engineering and operations, then explodes in a fireball of "do we really need operations? They're just old and obstinate and in the way of progress," without even really stopping to ask what progress is from the perspective of operations. Some of us like to think of legitimate technical reasons to push back on Docker in our own circumstances and deployments (some of us even read code to help make that determination), but I suppose your dichotomy would be fun to navigate for everyone involved. I've definitely been in environments where one side characterizes operational pushback as change reticence, which immediately personalizes the discussion. That's a tough environment in which to argue, especially when you're arguing with people who will not be on call for the crap they are trying to deliver to you. The casual ageism in your comment is, sadly, expected. I'm growing accustomed to HN considering it acceptable to go after "old" and "operations" with equal vigor, which speaks more broadly to worrying trends in our industry. I'm 31 and have devoted my career to operations, and I already have an exit plan. That should say something about the industry, and I think this comment is a fine microcosm of that.

derefr 10y ago
To me, "old" as a prejorative has about as much to do with age as "gay" as a prejorative has to do with homosexuality. The meaning people use the word to get at is "from another time when problems were solved differently, and staid in their opinions toward new solutions vs. those from the previous era." I've heard myself called an "old man" online for liking SQL stored procedures. I was 23 at the time. :)
curun1r 10y ago
For what it's worth, I'm older than you and started in ops. If it helps to put things into context, I spent a ton of 1997 using a chisel to shave a bit off standard RAM to help avoid Sun's near 10x markup. The startup I worked at was provisioning around 20 Sun boxes per week and we had to patch together tools to manage infrastructure of that size before off-the-shelf tooling to do that really existed. I wrote a lot of expect in 97-98. Where I get frustrated with ops is when they forget that they're in the service business. They're there to serve application developers in the same way that the application developers are there to serve customers. An application developer pushing back at a customer ask with the line, "without really stopping to ask what progress is from the perspective of developers" would be rightly lampooned. And yet somehow there's people that think the ops mindset is reasonable. In my view, "no" is not a valid viewpoint. Application developers are telling you they want the kind of functionality that Docker offers. That makes it your job to figure out how that happens, not if it happens.
- Karunamon 10y ago
  Where I get frustrated with ops is when they forget that they're in the service business. They're there to serve application developers in the same way that the application developers are there to serve customers. In my view, you've got that completely backwards. Both departments serve customers in a roundabout way. Dev is responsible for turning user stories (generated either by other devs, focus groups, and so forth - which may, but doesn't necessarily involve an actual paying customer) into code, ops is responsible for keeping that code running. If dev screws up, user gets bugs, or the app goes down. Same for ops - it's just the class of bugs are different. Application developers are telling you they want the kind of functionality that Docker offers. That makes it your job to figure out how that happens, not if it happens. As long as me and my ops team are the primary people with skin in the game (read: getting 3AM wakeup calls), me and my team will maintain a say in what tech stack we're responsible for the care and feeding of. The dark days of dev throwing code over the wall to ops is long gone - I am gobsmacked that you'd suggest that this is for some reason improper. What dev often forgets, and the cause of much strife, is this justification. If you want a team of n people to learn this new thing and its new ways of operating, then you need to do an honest, dispassionate cost/value analysis. And show your work, dammit. When this never happens, it conveys an "Oh great, Dev is on one of their 'Ooh, shiny!' kicks again" mentality to the rest of the team, especially those that aren't politically connected enough in the org to know any different. I know it's because you're busy and have insane deadlines to meet. Meanwhile, the phones ring at 3am, and the message is lost. The result is a strained and adversarial relationship, often to the customer's detriment.

johnbrodie 10y ago

The reality is, as far as I can see, there's just not much benefit in using Docker in a crappy (read: small) pool-of-app-servers-on-top-of-a-database webapp. I've had a lot of newer devs pushing to use Docker. I haven't had these newer devs give a solid reason why relatively low-volume, simple web apps need an additional layer of complexity over an easier-to-manage VM setup with automated provisioning.

deleted 10y ago
[deleted]