4 ms·

"This is a Java app. It needs JDK 1.6 and at least 1GB of RAM. It expects to write logs at /var/log/foo.log. It needs a MySQL database and Redis and Elasticsear

"This is a Java app. It needs JDK 1.6 and at least 1GB of RAM. It expects to write logs at /var/log/foo.log. It needs a MySQL database and Redis and Elasticsearch at configured hostnames and ports... Wow, brittle. Can't Java use environment variables? And since when does development tell ops what hostnames a machine should have, not to mention how many instances to run? Sorry, don't mean to jump all over you, but your words apparently jumped all over me. :)

StevePerkins 9y ago
> since when does development tell ops [deployment details]? Not to be cheeky, but since "devops"! Docker, Kuburnetes, etc... all of these things live on the point of intersection between developers and operations. Some of the config artifacts (e.g. dockerfiles) typically live in source control, which is usually the domain of developers. But the values with which they're populated are typically set by operations. It is indeed a dance that the two groups have to work out among themselves, and different organizations will handle it differently. Ultimately, I think you find that it really isn't FUNDAMENTALLY different from the dance that they already do in the old school. There will always have to be a handshake, where dynamic values are stored someplace and code knows to point to that place. How you handle that handshake is ultimately a human process thing.
- rhizome 9y ago
  I'm familiar, thanks. Keeping both ops and app in the same repo is one thing, but combining parts of them in code is a pretty amateur Separation of Concerns flaw and will inevitably break. I'm not sure what you're defending here.
  - dalailambda 9y ago
    The app can still use environment variables and be completely independent (12 factor), but the Dockerfile/Kubernetes config still needs to provide those things, so there is a clear distinction between ops and dev, they're just more mingled than previously.
    - rhizome 9y ago
      I think maybe you didn't read the top-level comment in this branch of the thread?

StevePerkins 9y ago

> since when does development tell ops [deployment details]? Not to be cheeky, but since "devops"! Docker, Kuburnetes, etc... all of these things live on the point of intersection between developers and operations. Some of the config artifacts (e.g. dockerfiles) typically live in source control, which is usually the domain of developers. But the values with which they're populated are typically set by operations. It is indeed a dance that the two groups have to work out among themselves, and different organizations will handle it differently. Ultimately, I think you find that it really isn't FUNDAMENTALLY different from the dance that they already do in the old school. There will always have to be a handshake, where dynamic values are stored someplace and code knows to point to that place. How you handle that handshake is ultimately a human process thing.

rhizome 9y ago
I'm familiar, thanks. Keeping both ops and app in the same repo is one thing, but combining parts of them in code is a pretty amateur Separation of Concerns flaw and will inevitably break. I'm not sure what you're defending here.
- dalailambda 9y ago
  The app can still use environment variables and be completely independent (12 factor), but the Dockerfile/Kubernetes config still needs to provide those things, so there is a clear distinction between ops and dev, they're just more mingled than previously.
  - rhizome 9y ago
    I think maybe you didn't read the top-level comment in this branch of the thread?