4 ms·

More generally, Kubernetes is an abstraction layer between your application and hardware/cloud that allows you to declaratively define what your app is, how it

More generally, Kubernetes is an abstraction layer between your application and hardware/cloud that allows you to declaratively define what your app is, how it runs, where it runs and what dependencies it needs. All in a standardized format that allows versioning and easy modification. As opposed to the old-school method of having to describe all that in words to an ops team (or not and just expecting them to figure it out): "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. We need to run at least 6 instances horizontally scaled behind a load balancer."

jalfresi 9y ago
Thats a pretty good explanation! Thanks!
rhizome 9y ago
"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?

jalfresi 9y ago

Thats a pretty good explanation! Thanks!

rhizome 9y ago

"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?