3 ms·

> having a team of 24 engineers across multiple countries trying to maintain a common set of bash scripts that work for 12+ unique services At the last place I

> having a team of 24 engineers across multiple countries trying to maintain a common set of bash scripts that work for 12+ unique services At the last place I worked that had a truly tight devops operation, it was 3 DevOps people maintaining infrastructure for 200+ unique services. And most that infrastructure was building really useful junk that I've never seen available elsewhere, like daily email reports telling me about every error that was logged on any services that my team maintained, and a cool little web UI that monitored our message bus and generated a visualization of which services (and instances) were listening to what. The actual deployment and process management infrastructure wasn't very complicated, either, based on what I saw from poking around in their source control. They were able to shave a whole lot of unnecessary complexity by enforcing rigid standards about how each process would be packaged and configured and whatnot, regardless of implementation language. It was up to the developers who wanted to take on $hot_new_langauge to figure out how make it behave right. And that gets to my real worry about Docker. It's a way of dealing with messes, not by cleaning them up, but by sweepi^H^H^H^H^H^H hiding it behind an abstraction. It's like that meme image that floated around a while back - "But it works on my machine." "Then we'll ship your machine." And that's how Docker was born. Which isn't to say that this is useless - I use Docker all the time, chiefly to do things like making sure I'll never have to manually futz around with managing multiple concurrent PostgreSQL installs ever again - but, at least in production, it still feels to me like high tech duct tape and chewing gum.

dariusj18 7y ago
I think docker/containers are the opposite of abstraction. It's a reduction of variables and creates true predictability across very disparate systems.
- mumblemumble 7y ago
  It's, at best, semi-consistent. In the Dockerized stack I'm working on right now, individual services are configured using a mishmash of environment variables, files you volume in (each one with a different format), shell scripts you volume in that will modify configuration files on startup, Dockerfiles that create derivative images that replace configuration files with instance-specific configuration, Dockerfiles with a bunch of RUN commands to handle more surgical modification of the configuration that was baked into some standardized base image. . . it's just crazy how variable it is. The obvious reply is, "Well, don't do that." And my general reaction to that idea is is, if you have the discipline to not do that with containers, you have the discipline to not do that without containers. Containerization is the stone in the soup. With a extra little side barb of, Docker doesn't really leave you any choice but to get messy. If you go troll through Docker issues, there are plenty of long-standing threads with community members requesting features to help them simplify and standardize their Docker situation, and Docker maintainers habitually rejecting the ideas on the grounds that they can already achieve what they want using some version of the abovementioned horrible mess of different ways to do things.
  - floriol 7y ago
    What's your opinion on Nix? Would that count as an improvement in determinism?
    - mumblemumble 7y ago
      Shrug. I'm a developer, so, in a professional setting, I really shouldn't be having much reason to think about system package management. From my perspective, the important things are that every single server should look identical to my applications, and there should be no room for confusion between me and devops about how to manage them, and their configuration should be standardized and straightforward and documented enough that devops actually owns the configuration, and isn't just acting as a sort of sock puppet for the dev team. I'm personally of the opinion that less is more: Every time you add a tool, you add more nooks and crannies and places for dust bunnies to collect. So, to that extent, I guess my question is, "How does Nix improve determinism in a way that (say) RPM doesn't?" If the motivation for the answer answer involves assuming that you've released a Lovecraftian horde of different languages and platforms that each have one or more of their own special snowflake package management systems all crawling all over each other to try and muck with the same global system environment, I'm gonna slam the lid back on that Pandora's box. I'm not gonna try letting them have their fun by hellbanning them to their own private parallel universes where they all get to think that they're mucking with the system environment. An insane asylum with locked doors is still an insane asylum. No, I'd rather kick that whole mess to the curb and instead say that only well-behaved applications that know how to color inside the lines get to run in the shared environments. Obviously this attitude doesn't work if you're a cloud platform or a smartphone OS or some other agent that isn't able to impose very many rules on the authors of the software that runs on your platform. Thankfully, I am not and have never been a Google, so the KISS principle remains an option for me. Yeah, I realize that this means I'm swimming against the current. My resumé would probably look a lot better to the (probable vast majority of) companies who are thinking, "Only 357,453 new hires to go until we're as big and complicated as Amazon, better start planning for it now!" if I changed my attitude. Perhaps I'm too old to learn new tricks.
      - 7y ago

dariusj18 7y ago

I think docker/containers are the opposite of abstraction. It's a reduction of variables and creates true predictability across very disparate systems.

mumblemumble 7y ago
It's, at best, semi-consistent. In the Dockerized stack I'm working on right now, individual services are configured using a mishmash of environment variables, files you volume in (each one with a different format), shell scripts you volume in that will modify configuration files on startup, Dockerfiles that create derivative images that replace configuration files with instance-specific configuration, Dockerfiles with a bunch of RUN commands to handle more surgical modification of the configuration that was baked into some standardized base image. . . it's just crazy how variable it is. The obvious reply is, "Well, don't do that." And my general reaction to that idea is is, if you have the discipline to not do that with containers, you have the discipline to not do that without containers. Containerization is the stone in the soup. With a extra little side barb of, Docker doesn't really leave you any choice but to get messy. If you go troll through Docker issues, there are plenty of long-standing threads with community members requesting features to help them simplify and standardize their Docker situation, and Docker maintainers habitually rejecting the ideas on the grounds that they can already achieve what they want using some version of the abovementioned horrible mess of different ways to do things.
- floriol 7y ago
  What's your opinion on Nix? Would that count as an improvement in determinism?
  - mumblemumble 7y ago
    Shrug. I'm a developer, so, in a professional setting, I really shouldn't be having much reason to think about system package management. From my perspective, the important things are that every single server should look identical to my applications, and there should be no room for confusion between me and devops about how to manage them, and their configuration should be standardized and straightforward and documented enough that devops actually owns the configuration, and isn't just acting as a sort of sock puppet for the dev team. I'm personally of the opinion that less is more: Every time you add a tool, you add more nooks and crannies and places for dust bunnies to collect. So, to that extent, I guess my question is, "How does Nix improve determinism in a way that (say) RPM doesn't?" If the motivation for the answer answer involves assuming that you've released a Lovecraftian horde of different languages and platforms that each have one or more of their own special snowflake package management systems all crawling all over each other to try and muck with the same global system environment, I'm gonna slam the lid back on that Pandora's box. I'm not gonna try letting them have their fun by hellbanning them to their own private parallel universes where they all get to think that they're mucking with the system environment. An insane asylum with locked doors is still an insane asylum. No, I'd rather kick that whole mess to the curb and instead say that only well-behaved applications that know how to color inside the lines get to run in the shared environments. Obviously this attitude doesn't work if you're a cloud platform or a smartphone OS or some other agent that isn't able to impose very many rules on the authors of the software that runs on your platform. Thankfully, I am not and have never been a Google, so the KISS principle remains an option for me. Yeah, I realize that this means I'm swimming against the current. My resumé would probably look a lot better to the (probable vast majority of) companies who are thinking, "Only 357,453 new hires to go until we're as big and complicated as Amazon, better start planning for it now!" if I changed my attitude. Perhaps I'm too old to learn new tricks.
    - 7y ago