[DandyDev]

How is this any different from the various packaging mechanisms that exist for all the different programming languages out there? You make it sound like this is a new kind of problem that started with Docker.

When I add some dependency to the Maven pom of my legacy Java EE app, I'm exposed to exactly the same kind of risk.

In short: research any dependency you pull in, whether it is a library for your favorite language or a module for your infrastructure automation tool of choice.

[eropple]

It's a difference-of-kind problem when you're working on infrastructure. You unwind a bad dependency in your app by removing the dependency. You unwind a bad dependency in your infrastructure by destroying large whacks of it.

[secstate]

Whether it's true or not, I think there's a perception of a more cavalier attitude around Docker that things will "just work" if I make my whole build system and production deployment depend on a random lady's docker file.

Also, a lot of developers don't spend the time they ought to learning (or hire the people who already know) how a proper tech stack works to be resilient.

Tools like Docker and Terraform make it seem magic, which it's not. PyPI, Gems and NPM don't make Python, Ruby and Javascript seem like magic, as most devs are deep enough in the code to see a terrible library before building their app around it.

[eropple]

Agreed, and the perception here matters. The cult of the five minute demo is real and people pick tools outside of their areas of expertise based on "well, it looked okay and there are blogs about it". The likelihood of bad stuff (whether bad through ignorance, malice, or lack of maintenance) is much, much higher when using these artifacts that are opaque not (just) in terms of source--because, yeah, most people won't audit it--but in terms of functionality (because the adoptee doesn't know the topic well enough to know what's going on).

You solve infrastructure problems with code, but infrastructure is not code and infrastructure requires a depth of understanding nobody's going to make disappear based on "magic." As you go downstack, the damage you can do increases. Depending on J. Random Dockerfile is problematic, as you're exposing your compute surface to the predations of a malicious update. Depending on J. Random Terraform Module opens you up to way deeper issues. These issues can only be solved by really understanding your stack, and five-minute-demo culture does not value understanding.

[dasil003]

> The cult of the five minute demo is real

This is unfortunately necessary as code eats the world, and the number of programmers, tools and ecosystems proliferates. Popularity is necessary for infrastructure tools to get enough eyeballs and resources to achieve stability. It's not enough for experts with decades of experience to design really solid but arcane tools, because the flood of new startups with young engineers coming in saying "do we really need that?" will overwhelm than faster than all the failures can be pointed out.

Ultimately, the quality of the tools is orthogonal to the presentation. My perception is Hashicorp has done much better in this regard than Docker, so there's that at least. Only time will tell how it really shapes up over time, but I believe Hashicorp tools are seeing massive uptake for more reasons than just good marketing.