3 ms·

You can absolutely build your app once, tarball it up, and distribute it, and some people do/did it this way. But you will have to write that system yourself,

You can absolutely build your app once, tarball it up, and distribute it, and some people do/did it this way. But you will have to write that system yourself, and there are some challenges involved. For example, if you have binary dependencies (either executables or shared libraries — even if you use an interpreted language like Ruby or Node.js, third-party packages often pull in shared libs), you will have to make sure they're (1) included, and (2) either statically linked, or that your servers are running the exact things they depend on (things like libc), and (3) that the architecture is the same (probably moot in these 64-bit days). It might be possible to write a little script that finds all binary dependencies and includes them in the tarball. That said, packaging and distribution is the more trivial aspect of all of this. Running an app is the hard part, and that's where Kubernetes really shines.

aprdm 8y ago
Hmm I would argue that both are equally challenging problems, that said, RPM for example has solved this problem for a while. If you're going to deploy on say a RHEL7 distro, you can package your software in an RPM, declare its dependencies and have it run in a VM alone... Or if you want to be even fancier you can use something like the Nix package management. I don't think Docker solves at all the problems with dependencies, it just creates an isolated environment to run something. You will occur the cost of virtualization at runtime which is higher than a container and maybe managing the VMs through something like vSphere but I still think it's much easier to manage than something like Kubernetes. Lot easier to hire for as well. That said, if I could use the cloud I would probably use managed K8S by GKE :), on premises, gotta evaluate the trade offs.
- lobster_johnson 8y ago
  I've heard of a few people using RPM for app deployment, but the fact that it's not a widespread solution shows that it's not ideal. It has several issues. For example, it ties your apps to a very specific distributions. Depending on how liberal and flexible (e.g. Nix is probably much better than RPM here) your package system is, conflicts can also be problematic. One package specifying Ruby 2.1 might conflict with another specifying 2.2. I don't know RHEL specifically, but on Ubuntu, tracking concurrent versions of things like Ruby and Node.js has historically been a pain, often requiring the installation of third-party packages that are designed to allow concurrent versions to live side by side without conflict. Conflicts can also occur at the system level. One app might want a certain libxml2 or libreadline or whatever, and that happens to be used by some system software that breaks on the version that the app wants. In other words, a single app now can break an entire node. The only way to fix these things is isolation. Again, packaging is the least interesting problem. After all, if you have Docker or jails or whatever, you can package your app and then manually start it. But orchestrating code in a declarative, self-healing way is what makes Kubernetes such a powerful system. The isolation you get from Docker is a foundational concept, but the way it's done is mostly an implementation detail.
  - aprdm 8y ago
    Yep that's why I mentioned one vm per service. Is more isolated than Docker. When you say it's not widespread I am not sure what you mean? There are 1000s of RPM packages available including things like elasticsearch.
    - lobster_johnson 8y ago
      There are RPMs for all sorts of general purpose software, of course, but it's rare to deploy one's own apps (as in the one that runs your product or whatever) via RPM.
      - aprdm 8y ago
        I don't think it is. Redhat and centos are very common server platforms. Maybe in startup world it is but older companies have been deploying own apps with rpms for a while. You can download RPM for multiple paid software apps today. I am very surprised when I want to install an app and don't see it to be honest. When I use RPM for my own apps I think of it as a self contained blob of data that has everything required to run an application . Basically a tarball on steroids which let's you version, upgrade and list dependencies. For example of you are doing a django app it's a decent way to not depend on pip and/or the external world to deploy your software and achieve immutable builds.

aprdm 8y ago

Hmm I would argue that both are equally challenging problems, that said, RPM for example has solved this problem for a while. If you're going to deploy on say a RHEL7 distro, you can package your software in an RPM, declare its dependencies and have it run in a VM alone... Or if you want to be even fancier you can use something like the Nix package management. I don't think Docker solves at all the problems with dependencies, it just creates an isolated environment to run something. You will occur the cost of virtualization at runtime which is higher than a container and maybe managing the VMs through something like vSphere but I still think it's much easier to manage than something like Kubernetes. Lot easier to hire for as well. That said, if I could use the cloud I would probably use managed K8S by GKE :), on premises, gotta evaluate the trade offs.

lobster_johnson 8y ago
I've heard of a few people using RPM for app deployment, but the fact that it's not a widespread solution shows that it's not ideal. It has several issues. For example, it ties your apps to a very specific distributions. Depending on how liberal and flexible (e.g. Nix is probably much better than RPM here) your package system is, conflicts can also be problematic. One package specifying Ruby 2.1 might conflict with another specifying 2.2. I don't know RHEL specifically, but on Ubuntu, tracking concurrent versions of things like Ruby and Node.js has historically been a pain, often requiring the installation of third-party packages that are designed to allow concurrent versions to live side by side without conflict. Conflicts can also occur at the system level. One app might want a certain libxml2 or libreadline or whatever, and that happens to be used by some system software that breaks on the version that the app wants. In other words, a single app now can break an entire node. The only way to fix these things is isolation. Again, packaging is the least interesting problem. After all, if you have Docker or jails or whatever, you can package your app and then manually start it. But orchestrating code in a declarative, self-healing way is what makes Kubernetes such a powerful system. The isolation you get from Docker is a foundational concept, but the way it's done is mostly an implementation detail.
- aprdm 8y ago
  Yep that's why I mentioned one vm per service. Is more isolated than Docker. When you say it's not widespread I am not sure what you mean? There are 1000s of RPM packages available including things like elasticsearch.
  - lobster_johnson 8y ago
    There are RPMs for all sorts of general purpose software, of course, but it's rare to deploy one's own apps (as in the one that runs your product or whatever) via RPM.
    - aprdm 8y ago
      I don't think it is. Redhat and centos are very common server platforms. Maybe in startup world it is but older companies have been deploying own apps with rpms for a while. You can download RPM for multiple paid software apps today. I am very surprised when I want to install an app and don't see it to be honest. When I use RPM for my own apps I think of it as a self contained blob of data that has everything required to run an application . Basically a tarball on steroids which let's you version, upgrade and list dependencies. For example of you are doing a django app it's a decent way to not depend on pip and/or the external world to deploy your software and achieve immutable builds.