6 ms·

I disagree. I think this article nails some of the basic issues people have with docker. That is, your app is usually not entirely self-contained. One generall

I disagree. I think this article nails some of the basic issues people have with docker. That is, your app is usually not entirely self-contained. One generally needs to have a db, a cache db, some networking, something else, and dash of CI. To run a containerized app ecosystem, you either type a load of crap in the `docker run` statement or you annotate the heck out of the compose file/dockerfile. Either way, you pray it works... I know that I have to wade into logs and docker exec bin/sh because of some kind of silly-ness a lot more than I would like. The article is correctly, imo, pointing out there should be a better way to wire up basic containerized ecosystems.

mbrock 10y ago
Note that my only complaint is terminological, because I think "function call" signifies something completely different from "launching a long-lasting service".
- jdmichal 10y ago
  Yes. If starting a Docker instance is a "function call", then what is the analog for making a HTTP request to a Docker-hosted server? The analogy was fine for describing the idea, and perhaps it even holds if the Docker image is a processing step instead of a service. But if the Docker image is a service... We have a set of terminology (and technology!) already for services -- let's use those, rather than continue to force the analogy all the way down.
- monkmartinez 10y ago
  Noted. I think the intent is there... treat/use/consume containers like parts of your app. Ie. Call the DB container, do work, release the DB container, and so on. Not a completely separate "thing" that is a PITA to debug, prone to errors, and horrifically documented. Why can't my app's ORM function call the DB container and do stuff? Why do I have to wire them up twice (code and OS layer) or more?
recursive 10y ago
After a `function call` returns its result, it no longer exists.
- monkmartinez 10y ago
  Until the function is called again, no?
  - recursive 10y ago
    Sure. However, you can't say... (reasonably) record your customer information in a function, and then retrieve it using the same function. Maybe containers are like objects. Objects have state and multiple methods.

mbrock 10y ago

Note that my only complaint is terminological, because I think "function call" signifies something completely different from "launching a long-lasting service".

jdmichal 10y ago
Yes. If starting a Docker instance is a "function call", then what is the analog for making a HTTP request to a Docker-hosted server? The analogy was fine for describing the idea, and perhaps it even holds if the Docker image is a processing step instead of a service. But if the Docker image is a service... We have a set of terminology (and technology!) already for services -- let's use those, rather than continue to force the analogy all the way down.
monkmartinez 10y ago
Noted. I think the intent is there... treat/use/consume containers like parts of your app. Ie. Call the DB container, do work, release the DB container, and so on. Not a completely separate "thing" that is a PITA to debug, prone to errors, and horrifically documented. Why can't my app's ORM function call the DB container and do stuff? Why do I have to wire them up twice (code and OS layer) or more?

recursive 10y ago

After a `function call` returns its result, it no longer exists.

monkmartinez 10y ago
Until the function is called again, no?
- recursive 10y ago
  Sure. However, you can't say... (reasonably) record your customer information in a function, and then retrieve it using the same function. Maybe containers are like objects. Objects have state and multiple methods.