9 ms·

Opening line from their announcement blog post: >It is safe to say that our industry has decided that containers are now the chosen way to package and scale ap

by nstart 7y ago

Opening line from their announcement blog post: >It is safe to say that our industry has decided that containers are now the chosen way to package and scale applications. Curious how the HN community feels about that statement. Not so much about the truth of the statement but about the fact that containers are becoming the de facto method of packaging applications.

emptysea 7y ago
For application code the ecosystem around containers is pretty handy. For load balancers, databases, and other stateful stuff I still run the binaries on VMs.
deleted 7y ago
[deleted]
unlinked_dll 7y ago
You need to prefix "applications" with "web" or "cloud."
- zokier 7y ago
  Flatpaks and snaps, while maybe not as popular, are also containers
  - unlinked_dll 7y ago
    They're also pretty terrible ways to distribute a native application and can be crippled due to their containerization.
  - AnIdiotOnTheNet 7y ago
    Unfortunately, they're over-complicated as a means of application packaging and distribution, at least in my opinion. Now AppImage, that's pretty great. It doesn't really bring any of the security benefits of containerization, but that can be tacked on separately.
- akvadrako 7y ago
  Desktop and mobile is actually where you want containers most. Servers rarely run untrusted or semi-trusted code because everything comes from a trusted source, usually open source, or in house. But users want to run lots of shady apps, either that they find on random websites or places like the Google Play store.
  - alkonaut 7y ago
    It's also the rare case where you can't accept a 5% performance hit because that's 5fps in a game or 5 seconds on a 100 second render time or 5ms instead of 95ms wait in an interactive app. I find that the key to running desktop OS/apps is never use sensitive data and always be ready to wipe your machine and start over.
    - akvadrako 7y ago
      Containers don't have a 5% performance hit.
      - alkonaut 7y ago
        That sounds good but I’ll believe it when I see it. There aren’t many desktop container/sandbox implementations out there and most are “vm light” e.g the windows sandbox and sandboxie. I haven’t seen anything more lightweight that can run desktop apps (in Windows at least).
        akvadrako 7y ago
        Windows store apps are one example.
        alkonaut 7y ago
        Not sure if that changed since its inception but originally windows store was exactly this: no SLI/Crossfire, v-sync always on, no overlays. Basically it was isolated from using the driver properly.
- antonvs 7y ago
  Unless you want to roll the traditional telecom industry under the "web" or "cloud" label, you have to add "telecom" to the list as well. Containers have been gaining ground in telecoms since at least 2015 (https://www.sdxcentral.com/articles/analysis/telecom-opens-up-to-containers/2015/10/ https://www.sdxcentral.com/articles/analysis/telecom-opens-u...). Network function virtualization solutions rely increasingly on containers.
hardwaresofton 7y ago
As far as I'm concerned, this is an obvious truth. Linux containers are processes with better sandboxing -- who would not want this? As kinks in the kernel support and tech get worked out, and OSs deepen support I can't imagine that it will ever make sense to say something like "I could have run the process with cgroup and namespace isolation but I chose not to, choosing to make a new user-level isolation or run everything as root instead". Arguments against containers as the future based on the complexity may have weight but not for long.
- arianvanp 7y ago
  The runtime and packaging format are orthogonal things . Containers the package format (docker) is completely rubbish in my opinion
- sourcesmith 7y ago
  "I could have run the process with cgroup and namespace isolation"... using systemd.
  - kchr 7y ago
    Or skip the million non-container related dependencies introduced by systemd and focus on a container centric init system...
- merb 7y ago
  > Linux containers are processes with better sandboxing simply not true: https://github.com/google/gvisor#why-does-gvisor-exist https://github.com/google/gvisor#why-does-gvisor-exist
  - hardwaresofton 7y ago
    The word "sandbox" is a bad choice -- "isolation and resource limiting" might have been a better term to use, but the idea that containerization does not sandbox at all is not a fair characterization. It's not a good sandbox, but if we are pedantic about the definition of a sandbox, it fits, especially when we think of the benefits of namespacing (effectively removing access to resources like networks, filesystems, etc). gVisor is a more focused on sandboxing processes specifically, so it's relevant but gVisor is not relevant to the wider discussion about a packaging format -- unless you're suggesting to run gvisor'd processes instead of containerized ones and containerization is still beneficial in that scenario.
StreamBright 7y ago
We rarely use containers for our deployments because you can get the same features that containerization provides by other means. The biggest issue with containers is the stability of Docker both the operational stability of containerd and the API stability with the tooling (like to rename command-line switches). As far as Kubernetes goes, my problem is visibility. I have very limited knowledge about what the containers are doing, the provided metrics that you can access are much less than I need to try to operate a k8s cluster. Once you need to look at the actual host-level metrics (CPU, IO, mem, ...) you need to have a map of what runs where. One of the reasons people are pushing for k8s is that you do not actually need to know what runs where. As far as complexity goes, I would much rather have a nodes where a single application is running and using 100% of resources (instead of having containerd or k8s services running) and do simple autoscaling, having access to host-level metrics that I can map back to applications easier than use Docker, k8s & co. Maybe is it only me, but I care about efficiency. Why waste energy? The counter-argument is that developer time is more valuable than setting up clusters or autoscaling groups. Well, this breaks down when you have SRE team(s) maintaining the k8s clusters (literally every company I worked for). If you already have SRE people either embedded into your dev teams or separately then you can just build out a CI/CD pipeline that produces that production setup based on blueprints. We usually use Terraform and Ansible with tempalte variables (stage = test|qa|prod, cluster size = x, version = y) that makes it easy for everybody to provision clusters on their own. Does this mean more work than k8s deployments? Yes. Does this mean we have less complexity we need to care about? Yes. In my experience containerization is a development tool to make it extremely easy to achieve fast development cycles but right now the accidental complexity to take that with you to production is not worth it. There are very nice projects like LXC/LXD that I would consider using for security separation and resource management but we usually have clusters where 100% of resources go to a single services. Example: Hadoop cluster, Elasticsearch cluster, Web application (mostly API) clusters. I need to care about the underlying hardware because of financial reasons (what is the cheapest node type I can use to run workload X). k8s would not help here. To sum it up: I do not think that the industry has decided on this. I also think that we are in the era of wasteful computing which will be finished soon because of reliability and unnecessary CO2 production reasons. Running containers has to be much less fragile and efficient to be considered the way to scale applications. I personally think that Firecracker is a step in the right direction in this while Docker & k8s in the wrong direction.
AnIdiotOnTheNet 7y ago
It's about damn time? I, for one, do not like having to deal with shared library hell, conflicts, and compiling from source because some unpaid repo maintainer is responsible for integrating code into my system. Not to mention the security enhancements. The only thing that would make them better is if we stopped over-complicating them and made them portable [0]. [0] As in, could be moved to different disks and run from there without a bunch of hoop-jumping.

by nstart 7y ago

emptysea 7y ago

For application code the ecosystem around containers is pretty handy. For load balancers, databases, and other stateful stuff I still run the binaries on VMs.

deleted 7y ago

[deleted]

unlinked_dll 7y ago

You need to prefix "applications" with "web" or "cloud."

zokier 7y ago
Flatpaks and snaps, while maybe not as popular, are also containers
- unlinked_dll 7y ago
  They're also pretty terrible ways to distribute a native application and can be crippled due to their containerization.
- AnIdiotOnTheNet 7y ago
  Unfortunately, they're over-complicated as a means of application packaging and distribution, at least in my opinion. Now AppImage, that's pretty great. It doesn't really bring any of the security benefits of containerization, but that can be tacked on separately.
akvadrako 7y ago
Desktop and mobile is actually where you want containers most. Servers rarely run untrusted or semi-trusted code because everything comes from a trusted source, usually open source, or in house. But users want to run lots of shady apps, either that they find on random websites or places like the Google Play store.
- alkonaut 7y ago
  It's also the rare case where you can't accept a 5% performance hit because that's 5fps in a game or 5 seconds on a 100 second render time or 5ms instead of 95ms wait in an interactive app. I find that the key to running desktop OS/apps is never use sensitive data and always be ready to wipe your machine and start over.
  - akvadrako 7y ago
    Containers don't have a 5% performance hit.
    - alkonaut 7y ago
      That sounds good but I’ll believe it when I see it. There aren’t many desktop container/sandbox implementations out there and most are “vm light” e.g the windows sandbox and sandboxie. I haven’t seen anything more lightweight that can run desktop apps (in Windows at least).
      - akvadrako 7y ago
        Windows store apps are one example.
        alkonaut 7y ago
        Not sure if that changed since its inception but originally windows store was exactly this: no SLI/Crossfire, v-sync always on, no overlays. Basically it was isolated from using the driver properly.
antonvs 7y ago
Unless you want to roll the traditional telecom industry under the "web" or "cloud" label, you have to add "telecom" to the list as well. Containers have been gaining ground in telecoms since at least 2015 (https://www.sdxcentral.com/articles/analysis/telecom-opens-up-to-containers/2015/10/ https://www.sdxcentral.com/articles/analysis/telecom-opens-u...). Network function virtualization solutions rely increasingly on containers.

hardwaresofton 7y ago

As far as I'm concerned, this is an obvious truth. Linux containers are processes with better sandboxing -- who would not want this? As kinks in the kernel support and tech get worked out, and OSs deepen support I can't imagine that it will ever make sense to say something like "I could have run the process with cgroup and namespace isolation but I chose not to, choosing to make a new user-level isolation or run everything as root instead". Arguments against containers as the future based on the complexity may have weight but not for long.

arianvanp 7y ago
The runtime and packaging format are orthogonal things . Containers the package format (docker) is completely rubbish in my opinion
sourcesmith 7y ago
"I could have run the process with cgroup and namespace isolation"... using systemd.
- kchr 7y ago
  Or skip the million non-container related dependencies introduced by systemd and focus on a container centric init system...
merb 7y ago
> Linux containers are processes with better sandboxing simply not true: https://github.com/google/gvisor#why-does-gvisor-exist https://github.com/google/gvisor#why-does-gvisor-exist
- hardwaresofton 7y ago
  The word "sandbox" is a bad choice -- "isolation and resource limiting" might have been a better term to use, but the idea that containerization does not sandbox at all is not a fair characterization. It's not a good sandbox, but if we are pedantic about the definition of a sandbox, it fits, especially when we think of the benefits of namespacing (effectively removing access to resources like networks, filesystems, etc). gVisor is a more focused on sandboxing processes specifically, so it's relevant but gVisor is not relevant to the wider discussion about a packaging format -- unless you're suggesting to run gvisor'd processes instead of containerized ones and containerization is still beneficial in that scenario.

StreamBright 7y ago

We rarely use containers for our deployments because you can get the same features that containerization provides by other means. The biggest issue with containers is the stability of Docker both the operational stability of containerd and the API stability with the tooling (like to rename command-line switches). As far as Kubernetes goes, my problem is visibility. I have very limited knowledge about what the containers are doing, the provided metrics that you can access are much less than I need to try to operate a k8s cluster. Once you need to look at the actual host-level metrics (CPU, IO, mem, ...) you need to have a map of what runs where. One of the reasons people are pushing for k8s is that you do not actually need to know what runs where. As far as complexity goes, I would much rather have a nodes where a single application is running and using 100% of resources (instead of having containerd or k8s services running) and do simple autoscaling, having access to host-level metrics that I can map back to applications easier than use Docker, k8s & co. Maybe is it only me, but I care about efficiency. Why waste energy? The counter-argument is that developer time is more valuable than setting up clusters or autoscaling groups. Well, this breaks down when you have SRE team(s) maintaining the k8s clusters (literally every company I worked for). If you already have SRE people either embedded into your dev teams or separately then you can just build out a CI/CD pipeline that produces that production setup based on blueprints. We usually use Terraform and Ansible with tempalte variables (stage = test|qa|prod, cluster size = x, version = y) that makes it easy for everybody to provision clusters on their own. Does this mean more work than k8s deployments? Yes. Does this mean we have less complexity we need to care about? Yes. In my experience containerization is a development tool to make it extremely easy to achieve fast development cycles but right now the accidental complexity to take that with you to production is not worth it. There are very nice projects like LXC/LXD that I would consider using for security separation and resource management but we usually have clusters where 100% of resources go to a single services. Example: Hadoop cluster, Elasticsearch cluster, Web application (mostly API) clusters. I need to care about the underlying hardware because of financial reasons (what is the cheapest node type I can use to run workload X). k8s would not help here. To sum it up: I do not think that the industry has decided on this. I also think that we are in the era of wasteful computing which will be finished soon because of reliability and unnecessary CO2 production reasons. Running containers has to be much less fragile and efficient to be considered the way to scale applications. I personally think that Firecracker is a step in the right direction in this while Docker & k8s in the wrong direction.

AnIdiotOnTheNet 7y ago

It's about damn time? I, for one, do not like having to deal with shared library hell, conflicts, and compiling from source because some unpaid repo maintainer is responsible for integrating code into my system. Not to mention the security enhancements. The only thing that would make them better is if we stopped over-complicating them and made them portable [0]. [0] As in, could be moved to different disks and run from there without a bunch of hoop-jumping.