6 ms·

When Java came along I felt sad. I loved computers and software but I just didn't like Java. But this was the early 2000s and Java had taken corporate and web d

When Java came along I felt sad. I loved computers and software but I just didn't like Java. But this was the early 2000s and Java had taken corporate and web development by storm. Everything was Java. So I felt flat. Computing was diminished not because Java was inherently bad, but it just didn't appeal to me personally. As it is with Docker and containers. I'm sorry to go against accepted wisdom but I just don't like this technology. To me it is a complex kludge. I feel that it is simpler software technology that should succeed current overly complex technology. It's my personal subjective opinion but I just feel that docker and containers are a big complex mess and I'm saddened that this is the direction of the entire industry. Probably you love docker and containers. I don't knock that. It's just not to my preference.

pcnix 9y ago
I understand that it's your preference, but the namespacing of processes that's the root of container technology is not really that different from conventional wisdom, is it?
- hguhghuff 9y ago
  There's a string of words you've put together but I can't pull them into a sentence I understand sorry. Are these docker terms? If so then perhaps my despair is illustrated.
  - nine_k 9y ago
    If you understand cgroups, then namespacing of processes makes perfect sense. If you don't, chances are it's too early to produce conclusions about containers. Also, docker is not the only solution for Linux containers; rkt is also developing, and Intel had its own interesting approach.
  - deleted 9y ago
    [deleted]
  - raesene9 9y ago
    one of the most interesting things for me about learning Docker is how it's improved my understanding of Linux. Ultimately Docker is just a set of linux features bundled together in a nice package, so you can learn the underlying features (and their pros and cons) without having to actually use Docker, if you don't want to.
    - subway 9y ago
      Ultimately Docker is just a set of linux features bundled together in a nice package And that's where it gets kinda scary. In Zones/Jails, you started with as little shared as possible. A jail/zone is a fresh isolated environment. With Docker (and really all Linux container implementations) you have hack-and-slash isolation going on. It's a loosely coupled collection of namespacing mechanisms that relies on whatever spawns the container to coordinate all these mechanisms. By default, they all will happily put the process in a shared space.
  - monktastic1 9y ago
    You have this set of processes which can reference each other by PID, and that set of processes that can reference each other, and the twain shall (mostly) never meet?
  - cookiecaper 9y ago
    Docker's killer feature is the packaging mechanism. A Docker image is like a virtual machine image and contains an executable environment, sometimes sans kernel since the host's kernel is used. It always includes a userland, but usually stripped down to support the bare minimum (busybox-ish). A "container" is simply a process that has some extra annotations on it, which various systems understand to represent some type of "namespacing" or information about the domain in which the process is allowed to operate. In Docker, these are implemented via the Linux cgroups mechanisms, which offers these and various types of annotations, including annotations that the kernel understands to constrain resource usage, etc. I don't know the details of the kernels well enough to discuss this next part in detail, but Linux containers implemented via cgroups are generally considered a "weak" security barrier, i.e., there are ways in which the isolation leaks out. illumos calls containers "zones" and is understood to have a stronger security/process isolation barrier, and I believe the same is true for FreeBSD jails, etc. "Containers" are a very old idea. Docker is an attempt to dumb them down for the masses by pretending that they're actually virtual machines and making it easy to "push" or "pull" the zip files^W^WDocker images. This assumption has caused many terrible container-based deployments. Most of the people running around tooting the horn of Docker and Kubernetes no doubt maintain these misconceptions and very superficial comprehensions of what's happening under the covers, and that's why they believe it's so magical and simple. Engineers who are trying to solve actual problems in a consistent, repeatable, and reliable manner will avoid any unnecessary complications -- including Kubernetes and/or Docker -- unless they are truly warranted by the unique circumstances in play, rather than seeking them out because they need a new flashy bullet point on their resume.
    - zrm 9y ago
      > Docker's killer feature is the packaging mechanism. That seems to be its Achilles' heel. Instead of having packages maintained by dedicated people (as with package managers like apt), you get a program that comes together with a collection of dependencies and libraries that aren't maintained by anyone. The average developer maintains their own program but doesn't have the resources to backport every bug fix and security update to the specific version of every library they use, and neither does anyone else when every program is using a different version of every dependency.
  - lobster_johnson 9y ago
    This stuff isn't anything new or unproven, conceptually. Kernel-level namespacing has existed as a tool for decades (BSD jails, Solaris Zones, etc.) before Linux got it and Docker adopted it for use in Docker containers. It's hard to take seriously criticism when it comes from someone who doesn't even bother to read up on it enough to understand the terminology before commenting on HN.
betaby 9y ago
That's the thing - docker deprived us from the containers. Containers were there long before docker and they were good. For example Solaris zones https://en.wikipedia.org/wiki/Solaris_Containers https://en.wikipedia.org/wiki/Solaris_Containers . Linux-vserver and FreeBSD jails were there even longer, but weren't that feature-rich. I also find docker is overly limiting and solving non-existing problems and personally use custom tools around systemd-nspawn.
- raesene9 9y ago
  I'm not sure how Docker deprived anyone from anything? All those other container technologies are still there and available for use. from jails to zones to LXC/D... Docker brought some useful additions to the ecosystem like Docker hub and also helped adoption of containers overall by making easy to use tools. There's absolutely nothing to stop people picking and choosing what parts of the container ecosystem they use, which is one of the nice parts about it. Just need to run a container image, use runc. Want a daemon to manage container lifecycle , use CRI-O or containerd. Want the additional features like network management and hub access, use Docker.
  - betaby 9y ago
    Marketing hype - no one sees anything behind Docker [or Docker-like re-implementation].
    - icebraining 9y ago
      As you wrote, containers have existed for many years before Docker appeared, yet barely anyone used them, so how can you blame Docker for people not using those container technologies?
tpaschalis 9y ago
> this is the direction of the entire industry. But is it really the direction of the industry? I think you'll agree that that the "industry" exists solely because software it is able to deliver "value" to individuals and companies, irregardless of tools used. Yes, we're on HN, and we're far more likely to be exposed to the latest and most shiny toys and buzzwords, but in the end, you just use the tools that you like, and can get shit done in an efficient way. One last thing. When I was studying Physics, not a semester passed where a professor wouldn't mention Occam's Razor [1]. Maybe as CS matures with time, people will start thinking in a different way. [1] https://en.wikipedia.org/wiki/Occam%27s_razor https://en.wikipedia.org/wiki/Occam%27s_razor
tyingq 9y ago
The popularity of docker in corporate environments is mostly because it allows developer teams to control the OS without dealing with sysadmins that are in a separate organization. Similar for cloud in general. I think many people don't see that a lot of the popularity is less about technology, and more about politics. "Devops", in general, is basically an organization change to move sysadmin's duties into the development team's domain. It has predictable upsides, and downsides.
- cookiecaper 9y ago
  Yes, microservices and containers are a way for developers to feel important and grant cover to an unabashed manifestation of Conway's Law. This particular fad is wreaking ridiculous havoc that is going to have the computing world in quite a mess soon. In the real world, distributed systems are a complication that is better left alone if they're not necessary for a problem space. You very likely don't need Kubernetes (watch out, this sentiment will get your HN account throttled; I've already been punished for it so it's safe for me to say). The reason Google et al push these distributed systems is because it gets you to buy more cloud instances. Very predictable and straightforward behavior there. Like all technology that proliferates, this is definitely more about politics than merit, but it doesn't really move the duties around practically; anyone who thinks that a group so undisciplined and lackluster as your average software developer will willingly take on new responsibilities is detached. As a sysadmin, you just get developers delivering garbage to your doorstep and expecting you to deal with it, same as always. It's just packaged in a stupid way now, that makes the developers say "Well I sent you a container, so this should be up and running in like, 5 minutes, right?" In practice, most developers won't even write their own Dockerfiles; my experience has been that they develop locally as they always have, and then expect the sysadmins/"devops" (now a term for sysadmins) to do all that mumbo-jumbo. But yes, we've been through this song and dance before. It's static v. dynamic linking. It's shared tenancy v. single tenancy. None of it is new, it just gets a different name and oscillates from position A to position B. It's an embarrassment and a testament against our industry that we continue to thrash wildly and be so thoroughly dominated by fads.
  - _jal 9y ago
bunderbunder 9y ago
I'm in a similar boat. I'm trying hard to convince myself that containers aren't just a particularly complex version of applications that bundle their own dependencies. Which is actually a fairly necessary thing, because, as is, many popular tech stacks simply don't have a built-in way to do this, and, even when they do, it's often not all that self-contained, and they all work differently. As a concrete example, I spent all of yesterday trying to get up and running with some sort of Spark/Scala notebook system running on my host machine, and it was an exercise in pure annoyance and frustration. This morning I gave up, rolled back that whole mess of packages and homebuilt binaries and environment variables and whatnot, and (re)installed Docker so I could give Zeppelin's Docker image a try. I've been working happily ever since. So, I'm grudgingly accepting it. I also wish we had something less hacky. But tech in general is so duct taped together at this point that I'm not even sure that's a possibility. It's the solution we need, not the one we deserve.

pcnix 9y ago

I understand that it's your preference, but the namespacing of processes that's the root of container technology is not really that different from conventional wisdom, is it?

hguhghuff 9y ago
There's a string of words you've put together but I can't pull them into a sentence I understand sorry. Are these docker terms? If so then perhaps my despair is illustrated.
- nine_k 9y ago
  If you understand cgroups, then namespacing of processes makes perfect sense. If you don't, chances are it's too early to produce conclusions about containers. Also, docker is not the only solution for Linux containers; rkt is also developing, and Intel had its own interesting approach.
- deleted 9y ago
  [deleted]
- raesene9 9y ago
  one of the most interesting things for me about learning Docker is how it's improved my understanding of Linux. Ultimately Docker is just a set of linux features bundled together in a nice package, so you can learn the underlying features (and their pros and cons) without having to actually use Docker, if you don't want to.
  - subway 9y ago
    Ultimately Docker is just a set of linux features bundled together in a nice package And that's where it gets kinda scary. In Zones/Jails, you started with as little shared as possible. A jail/zone is a fresh isolated environment. With Docker (and really all Linux container implementations) you have hack-and-slash isolation going on. It's a loosely coupled collection of namespacing mechanisms that relies on whatever spawns the container to coordinate all these mechanisms. By default, they all will happily put the process in a shared space.
- monktastic1 9y ago
  You have this set of processes which can reference each other by PID, and that set of processes that can reference each other, and the twain shall (mostly) never meet?
- cookiecaper 9y ago
  Docker's killer feature is the packaging mechanism. A Docker image is like a virtual machine image and contains an executable environment, sometimes sans kernel since the host's kernel is used. It always includes a userland, but usually stripped down to support the bare minimum (busybox-ish). A "container" is simply a process that has some extra annotations on it, which various systems understand to represent some type of "namespacing" or information about the domain in which the process is allowed to operate. In Docker, these are implemented via the Linux cgroups mechanisms, which offers these and various types of annotations, including annotations that the kernel understands to constrain resource usage, etc. I don't know the details of the kernels well enough to discuss this next part in detail, but Linux containers implemented via cgroups are generally considered a "weak" security barrier, i.e., there are ways in which the isolation leaks out. illumos calls containers "zones" and is understood to have a stronger security/process isolation barrier, and I believe the same is true for FreeBSD jails, etc. "Containers" are a very old idea. Docker is an attempt to dumb them down for the masses by pretending that they're actually virtual machines and making it easy to "push" or "pull" the zip files^W^WDocker images. This assumption has caused many terrible container-based deployments. Most of the people running around tooting the horn of Docker and Kubernetes no doubt maintain these misconceptions and very superficial comprehensions of what's happening under the covers, and that's why they believe it's so magical and simple. Engineers who are trying to solve actual problems in a consistent, repeatable, and reliable manner will avoid any unnecessary complications -- including Kubernetes and/or Docker -- unless they are truly warranted by the unique circumstances in play, rather than seeking them out because they need a new flashy bullet point on their resume.
  - zrm 9y ago
    > Docker's killer feature is the packaging mechanism. That seems to be its Achilles' heel. Instead of having packages maintained by dedicated people (as with package managers like apt), you get a program that comes together with a collection of dependencies and libraries that aren't maintained by anyone. The average developer maintains their own program but doesn't have the resources to backport every bug fix and security update to the specific version of every library they use, and neither does anyone else when every program is using a different version of every dependency.
- lobster_johnson 9y ago
  This stuff isn't anything new or unproven, conceptually. Kernel-level namespacing has existed as a tool for decades (BSD jails, Solaris Zones, etc.) before Linux got it and Docker adopted it for use in Docker containers. It's hard to take seriously criticism when it comes from someone who doesn't even bother to read up on it enough to understand the terminology before commenting on HN.

betaby 9y ago

That's the thing - docker deprived us from the containers. Containers were there long before docker and they were good. For example Solaris zones https://en.wikipedia.org/wiki/Solaris_Containers https://en.wikipedia.org/wiki/Solaris_Containers . Linux-vserver and FreeBSD jails were there even longer, but weren't that feature-rich. I also find docker is overly limiting and solving non-existing problems and personally use custom tools around systemd-nspawn.

raesene9 9y ago
I'm not sure how Docker deprived anyone from anything? All those other container technologies are still there and available for use. from jails to zones to LXC/D... Docker brought some useful additions to the ecosystem like Docker hub and also helped adoption of containers overall by making easy to use tools. There's absolutely nothing to stop people picking and choosing what parts of the container ecosystem they use, which is one of the nice parts about it. Just need to run a container image, use runc. Want a daemon to manage container lifecycle , use CRI-O or containerd. Want the additional features like network management and hub access, use Docker.
- betaby 9y ago
  Marketing hype - no one sees anything behind Docker [or Docker-like re-implementation].
  - icebraining 9y ago
    As you wrote, containers have existed for many years before Docker appeared, yet barely anyone used them, so how can you blame Docker for people not using those container technologies?

tpaschalis 9y ago

> this is the direction of the entire industry. But is it really the direction of the industry? I think you'll agree that that the "industry" exists solely because software it is able to deliver "value" to individuals and companies, irregardless of tools used. Yes, we're on HN, and we're far more likely to be exposed to the latest and most shiny toys and buzzwords, but in the end, you just use the tools that you like, and can get shit done in an efficient way. One last thing. When I was studying Physics, not a semester passed where a professor wouldn't mention Occam's Razor [1]. Maybe as CS matures with time, people will start thinking in a different way. [1] https://en.wikipedia.org/wiki/Occam%27s_razor https://en.wikipedia.org/wiki/Occam%27s_razor

tyingq 9y ago

The popularity of docker in corporate environments is mostly because it allows developer teams to control the OS without dealing with sysadmins that are in a separate organization. Similar for cloud in general. I think many people don't see that a lot of the popularity is less about technology, and more about politics. "Devops", in general, is basically an organization change to move sysadmin's duties into the development team's domain. It has predictable upsides, and downsides.

cookiecaper 9y ago
Yes, microservices and containers are a way for developers to feel important and grant cover to an unabashed manifestation of Conway's Law. This particular fad is wreaking ridiculous havoc that is going to have the computing world in quite a mess soon. In the real world, distributed systems are a complication that is better left alone if they're not necessary for a problem space. You very likely don't need Kubernetes (watch out, this sentiment will get your HN account throttled; I've already been punished for it so it's safe for me to say). The reason Google et al push these distributed systems is because it gets you to buy more cloud instances. Very predictable and straightforward behavior there. Like all technology that proliferates, this is definitely more about politics than merit, but it doesn't really move the duties around practically; anyone who thinks that a group so undisciplined and lackluster as your average software developer will willingly take on new responsibilities is detached. As a sysadmin, you just get developers delivering garbage to your doorstep and expecting you to deal with it, same as always. It's just packaged in a stupid way now, that makes the developers say "Well I sent you a container, so this should be up and running in like, 5 minutes, right?" In practice, most developers won't even write their own Dockerfiles; my experience has been that they develop locally as they always have, and then expect the sysadmins/"devops" (now a term for sysadmins) to do all that mumbo-jumbo. But yes, we've been through this song and dance before. It's static v. dynamic linking. It's shared tenancy v. single tenancy. None of it is new, it just gets a different name and oscillates from position A to position B. It's an embarrassment and a testament against our industry that we continue to thrash wildly and be so thoroughly dominated by fads.
- _jal 9y ago

bunderbunder 9y ago

I'm in a similar boat. I'm trying hard to convince myself that containers aren't just a particularly complex version of applications that bundle their own dependencies. Which is actually a fairly necessary thing, because, as is, many popular tech stacks simply don't have a built-in way to do this, and, even when they do, it's often not all that self-contained, and they all work differently. As a concrete example, I spent all of yesterday trying to get up and running with some sort of Spark/Scala notebook system running on my host machine, and it was an exercise in pure annoyance and frustration. This morning I gave up, rolled back that whole mess of packages and homebuilt binaries and environment variables and whatnot, and (re)installed Docker so I could give Zeppelin's Docker image a try. I've been working happily ever since. So, I'm grudgingly accepting it. I also wish we had something less hacky. But tech in general is so duct taped together at this point that I'm not even sure that's a possibility. It's the solution we need, not the one we deserve.