Containers Don't Solve Everything • Hacker News Board

Re: Containers Don't Solve Everything

#81

Post by throwaway894345 » Fri, Sep 10, 2021, 9:29 PM UTC

tracker1 wrote: post #77

throwaway894345 wrote: post #41

Earlier quoted context omitted.

Containers aren’t the final destination, but they’ve enabled polyglot orchestration i.e., an app developer can target Kubernetes without needing to manage the minutia of operating a bunch of Linux hosts. It seems like almost every company that isn’t using containers for SaaS software development ends up badly reinventing Kubernetes and sinking a ton of time and money into maintaining it, and as a “human person”, I’m…

For that matter, pushing for SRE roles that manage orchestrating the K8s environment and as a developer you can focus on a local docker-compose, and spend more time in testing (unit and integration). The Developer is responsible for Dockerfile, and the CI/CD build and test portions of the process. Considering the level of options from Kubernetes, heml, istio, etc can get complex, the developer can focus on the bounda…

I think that’s precisely the opposite of the SRE/DevOps model. The developers shouldn’t be managing their own clusters (istio, etc) but they should be able to define and maintain their own applications (not just the container code but also supporting infra).

Re: Containers Don't Solve Everything

#82

Post by mikewarot » Sat, Sep 11, 2021, 3:09 AM UTC

Virtual Machines gained popularity as are kludge to get around the remarkably horrible state of operating systems. The inability to reliably save and restore the state of a computer grew to be so costly that it became worthwhile to pay the performance penalty of a layer of emulation/virtualization to route around it.

Containers were the next logical step, as each virtual machine vendor tried to lock in their users. Containers allowed routing around it.

Both of these steps could be eliminated if a well behaved operating system similar to those in mainframes could be deployed, so that each application sat in its own runtime, had its own resources, and no other default access.

There's a market opportunity here, it just needs to be found.

Re: Containers Don't Solve Everything

#83

Post by encryptluks2 » Sat, Sep 11, 2021, 3:40 AM UTC

superkuh wrote: post #40

rualca wrote: post #21

Earlier quoted context omitted.

> I personally like the isolation they provide and generally prefer running services in containers, even if they are using the same dependencies as my OS. I would also not downplay the importance of Docker's support for software-defined networks and it's ability to arbitrarily configure networking at the container level. I firmly believe that networking doesn't pop up so often while discussing Docker because Docker s…

Have they fixed ipv6 support yet?

Yes they have, but there is also a plethora of other container daemons and tools now aside from Docker with IPv6 support.

Re: Containers Don't Solve Everything

#84

Post by tadfisher » Sat, Sep 11, 2021, 4:45 AM UTC

cormacrelf wrote: post #63

jzoch wrote: post #35

Earlier quoted context omitted.

What solution wouldn't require its own specification + quirks? Whether its a Dockerfile or nix package I don't see the difference besides people tend to be familiar with only 1 of the many options. Im not comparing whether Dockerfiles or buildpacks or nix packages are more ergonomic than one another but i do think your comment is...misguided. From what I have heard Nix is pretty wonderful to use and simplifies the pr…

Anyone can build their first Dockerfile and deploy it for Node.js or similar in like 5 minutes. The tricks that make images smaller later use the same concepts and syntax. There is a reason it took over the world so quickly. Nix ... I have so far spent about 10 hours learning it to manage my machine. I have forgotten about 98% of it and abandoned the project. You feel like you're sitting in the middle of a spider web…

Your compile_commands.json example is essentially what tools like node2nix produce. For saner build systems, e.g. cmake and meson, simply including the build tool package in `nativeBuildInputs` along with dependent packages in `buildInputs` suffices to build 90% of C/C++ packages with Nix, with the remaining 10% being Qt (I jest).

The real killer app for Nix is in testing now, and that's the "flakes" feature. Lots of this stuff will get way easier to use when you can throw "github:owner/repo" in an `inputs` set and get a working Nix builder for your project without needing to read through nixpkgs. I hope you give it a try again sometime, as it has changed my perspective on how software should be built, distributed, trusted, and deployed.

Re: Containers Don't Solve Everything

#85

Post by tadfisher » Sat, Sep 11, 2021, 4:50 AM UTC

mook wrote: post #55

MaxGabriel wrote: post #15

Earlier quoted context omitted.

This sounds like a lot of stuff that Nix solves, the multiple versions of libraries coexisting part at least

My understanding though is that nix tries to solve this globally (it manages your whole system, or your whole home directory, as opposed to docker, which has clearly demarcated separation between different images), and it doesn't reuse existing packaging (in particular the language, as in "apt install" etc.) There's definitely advantages that way, but there's also drawbacks.

There's NixOS, which you are describing, and then there's `nix` the package manager and build system. The latter is installable on any Linux or macOS system as a normal binary, and can be used standalone as a build tool. My company uses this to standardize (and cache!) development environments across a diverse set of hardware; the environments do double-duty as hermetic CI builders as well.

Re: Containers Don't Solve Everything

#86

Post by kaba0 » Sat, Sep 11, 2021, 5:52 AM UTC

superkuh wrote: post #3

It depends on the context, I don't know about corporate persons with profit incentives but if we're talking human persons then containers don't solve anything. They're just the symptom of the disease that is future shock. The underlying libraries we depend on just change too fast now and no devs care about forwards compatibility so we end up with all OS/Distros having libs that stop working in about a year (or more l…

Nix (and guix) does solve this issue novelly, and for some reason it doesn’t get the recognition it rightfully deserves.

The problem doesn’t start with virtualization, that is indeed a side-track.

Re: Containers Don't Solve Everything

#87

Post by kaba0 » Sat, Sep 11, 2021, 5:55 AM UTC

titzer wrote: post #58

superkuh wrote: post #3

It depends on the context, I don't know about corporate persons with profit incentives but if we're talking human persons then containers don't solve anything. They're just the symptom of the disease that is future shock. The underlying libraries we depend on just change too fast now and no devs care about forwards compatibility so we end up with all OS/Distros having libs that stop working in about a year (or more l…

> They're just the symptom of the disease that is future shock. Yes, absolutely, and I hope you mean that in the capital-F "Future Shock", Alvin Toffler sense, because there is a lot he wrote that hasn't even been carried over and digested. Software is an endlessly disorienting sea of change, getting faster and thus worse as time progresses, and it's frankly madness at this point. It seems absolutely no one is commit…

That’s ingenious to write off Java as not backwards compatible. The only change they did was closing the doors to the internals of the JVM because those are implementation-dependent anyway (meaning those programs wouldn’t have worked on anything not OpenJDK) and are likely to change. You can still absolutely run a class file compiled to Java 1.0 on a JDK 16.

Re: Containers Don't Solve Everything

#88

Post by kaba0 » Sat, Sep 11, 2021, 5:57 AM UTC

cormacrelf wrote: post #63

jzoch wrote: post #35

Earlier quoted context omitted.

What solution wouldn't require its own specification + quirks? Whether its a Dockerfile or nix package I don't see the difference besides people tend to be familiar with only 1 of the many options. Im not comparing whether Dockerfiles or buildpacks or nix packages are more ergonomic than one another but i do think your comment is...misguided. From what I have heard Nix is pretty wonderful to use and simplifies the pr…

Anyone can build their first Dockerfile and deploy it for Node.js or similar in like 5 minutes. The tricks that make images smaller later use the same concepts and syntax. There is a reason it took over the world so quickly. Nix ... I have so far spent about 10 hours learning it to manage my machine. I have forgotten about 98% of it and abandoned the project. You feel like you're sitting in the middle of a spider web…

You can’t really leverage what is fundamentally broken. To live up to Nix’s claims it has to heavily patch software. But this is a self-fulfilling thing, once it caters to enough people, other tools will natively support nix.

Re: Containers Don't Solve Everything

#89

Post by kaba0 » Sat, Sep 11, 2021, 6:25 AM UTC

tyingq wrote: post #33

superkuh wrote: post #3

It depends on the context, I don't know about corporate persons with profit incentives but if we're talking human persons then containers don't solve anything. They're just the symptom of the disease that is future shock. The underlying libraries we depend on just change too fast now and no devs care about forwards compatibility so we end up with all OS/Distros having libs that stop working in about a year (or more l…

Java running in a container is somewhat amusing because of this. So you have a several solutions to the problem of agnostic packaging (java/jar/ear/war/etc) running inside another whole solution for agnostic packaging.

That’s just Java EE (now Jakarta) and Spring (when deployed to an application server). And indeed, these were containers before they were cool, with DB connections, pooling, it can connect to messaging services, etc. plus gives an environment where classes can easily do dependency injection, transactions, concurrency and many other things.

Re: Containers Don't Solve Everything

#90

Post by cormacrelf » Sat, Sep 11, 2021, 7:18 AM UTC

tadfisher wrote: post #84

cormacrelf wrote: post #63

Earlier quoted context omitted.

Anyone can build their first Dockerfile and deploy it for Node.js or similar in like 5 minutes. The tricks that make images smaller later use the same concepts and syntax. There is a reason it took over the world so quickly. Nix ... I have so far spent about 10 hours learning it to manage my machine. I have forgotten about 98% of it and abandoned the project. You feel like you're sitting in the middle of a spider web…

Your compile_commands.json example is essentially what tools like node2nix produce. For saner build systems, e.g. cmake and meson, simply including the build tool package in `nativeBuildInputs` along with dependent packages in `buildInputs` suffices to build 90% of C/C++ packages with Nix, with the remaining 10% being Qt (I jest). The real killer app for Nix is in testing now, and that's the "flakes" feature. Lots of…

Nix is still trying to be a thing that replaces other build tools. The generated nix file is a recipe for doing what “npm publish” does when it builds a tgz. Every single language has a different way of doing this, and will require its own *2nix to be maintained alongside changes to eg package.json, Cargo.toml, Package.swift. The 2nix bit is the hard part; every package manager has to be re-implemented.

Docker does not have this problem at all. Every build tool on earth works with it, with zero configuration.

Compile_commands.json may have similar output to node2nix etc, but it infects nothing, replaces nothing. It works with all the different makefile alternatives with no additional effort. The closest similarity is with Docker: Docker builders intercept at the file system layer, covering every build system ever; compile_commands at the standard GCC-compatible shell arguments layer, covering ~all C build systems and compilers. Nix does not intercept anywhere, it asks you to use a new tool to do everything from scratch in a Nix-compatible way, covering no build systems.

That’s not to say it isn’t great when you have already built a Nixified package manager replacement for your specific language ecosystem. But it’s not going to take over the world like Docker and compile_commands did. Imploring people to give it a shot is the only way, unfortunately. I will remain open to it, especially if someone can figure out a force-multiplier for these 2nix implementations.