Hacker News Reader

Comment by chrisandchris | Hacker News Reader

I think one aspect your reasoning does not properly respect is that running things in container is not all about scaling, but also about easy of deployment. A 10-user-app probably doesn't need k8s, but the advantage of packing it into a container and just starting that container (on a single machine) is very nice. It's so easy to have multiple apps with different languages (or even language versions) on a single host without worrying how to install 3 different PHP versions on that machine.

View on HN

Back in the day we used to call it EAR files, or static linking with resource files embedded.

Thank you. If I had a dime for every time I've uttered, how is this easier or more efficient than "deploy war", over the past 5-7 years I'd be a very wealthy man.

To me, it really comes back to how badly the Java system was managed with regard to the quality of its tools. Portability and security would always have been a draw for every other language but even the Java projects I know used containers for basically two reasons: Tomcat was unrewarding to use and the Java web stack had a lot of complexity which users were forced to deal with. If Sun had spent, say, 5% of their marketing budget on making the user experience better I don't think there would have been anywhere near the pressure to avoid it.

Somehow I get the feeling that most Java haters never had the pleasure to deal with CORBA and COM/DCOM or MTS.

So those newcomers never got the point why many of us actually enjoyed using Application Servers.

I did, actually, have the misfortune of using COM (and touched CORBA enough not to want to use it more).

I don’t hate Java but, having started using it in 1995, it felt like the community was prone to sweeping ambitions which exceeded the available time or appetite to improve further. One challenge is that while doing everything yourself allows the most control, it also means that improvements only come from within the smaller community of Java users.

Well I wouldn't call that community small, given that it grew to overtake C++ on enterprise distributed computing.

It's definitely not small but it's a subset of the entire development community. That's not wrong – maybe it allows iterating faster without supporting other languages, for example — but it can also reduce the number of people interested in working on something. Just as a simple example, a Python user can benefit to an improvement in Apache httpd made by a Java, C, PHP, etc. shop but that happens a lot less frequently with Tomcat.

That Python user can benefit from Jython and GraalVM.

Kind of, but in practice they probably aren't going to use those unless they're already committed to the Java world because they're slower, less compatible with the extensions they're probably using, and fewer people use them so you're more likely to find bugs or gaps in documentation. Again, I'm not saying that Java is terrible or that nobody uses it but simply that the community is smaller than the entire tech world — especially after Oracle's sales pressure — and that means that any given project has a greater chance of not having enough support unless a major company backs it.

Each community is tiny when measured against the whole tech world, not really getting the point.

A C++ shop couldn't care less about what a Swift shop is doing and so forth.

The point being that Java-specific things like WARs, Tomcat, etc. were almost exclusively used by Java shops whereas more general tools such as httpd are used across multiple communities. A C++ shop can host their app behind httpd/nginx/etc. the same as a Swift shop even if they don't otherwise use the same tools.

A C++ shop was most likely using COM or CORBA back in those days, I really don't get that insistence with httpd.

So, our startup created a mod_tcl similar to AOLServer, basically a TCL Application Server, no else got to use our tooling besides our customers.

My first job involved CORBA in Java. Tomcat was better, I guess.

Well, for one thing, Docker Hub now has a helpful web badge telling you whether or not each container contains a vulnerable copy of log4j.

I'm not sure why it's taking the J2EE containers so much longer to patch than the good 'ol PHP stuff or shiny new Go apps.

> I'm not sure why it's taking the J2EE containers so much longer to patch than the good 'ol PHP stuff or shiny new Go apps.

I was wondering what it'd look like if they used these badges for every language. Maybe like 5% of the outside containers I look at don't have significant unpatched CVEs, even for relatively popular projects.

I agree, yes. My history is less Java and more PHP.

...or a tarball, or a deb file or an rpm.

Perhaps as a result of incorrectly classifying K8S or K8SaaS as a PaaS when it’s very far from it. Heroku offers the same - or better - devex without the operational burden.

It’s worth noting that advantage (and in my belief the large adoption of containers generally) is only valuable to interpreted languages that dont allow static linking.

For statically compiled binaries I’ve not worried about different versions of libraries for my binaries for 20 years (and the technology is decades older than that).

I do appreciate the docker file format but largely because it’s become used for true virtualization systems like firecracker. Plain Linux “containers” largely offer me very little.

Containers are still valuable for statically-linked code, as ways of comprehensively namespacing resources. (In fact, the converse is true; containers are built on the resource-namespacing features of modern Linux, which in turn were inspired by Plan9 a distributed operating system building on *nix).

Right. But I’ve been able to use resource limits for my Linux processes for far longer than containers were popularized. With my processes anyway that’s the big win with namespaces.

That is to say, if you control the hosts and process then the container features are available with much less ceremony while if you are hosting someone else’s process (or they you) containers don’t provide enough isolation.

You're thinking of cgroups, which is what you gives you per-process group resource limits. Namespacing gives you quite a bit more than that. You can have all services running as the same user but still not able to see each other's data. You can have all services get a unique IP address even though they're on the same kernel. You can have them all listen on port 80. They can all read from the same socket file from their perspective but it won't actually be the same file. You can have them all use different DNS providers even though they're just delegating to /etc/resolv.conf. You can't do that with just static linking. Containers give you quite a bit more than incompatible dependencies being able to run on the same host, including features that can only be provided by a kernel, not a language runtime. They allow you to use arbitrarily many different languages. You can run third-party applications you can't rewrite in Java to get a WAR or force them to statically link.

I think the more fundamental advantage is on the dev side:

How do you reproducibly build that static binary in a dozen different developer's environments, and in CI?

In fact, containers kind of suck in prod environments.

For example:

- Kernel/binary mismatches break vDSO, and gettimeofday becomes 100x more expensive.

- Current apache can't run in Synology Docker any more, because they require a new kernel secure RNG (even for http).

- There's no reasonable built in story for persistent storage.

VM's and bare metal solved these issues long ago.

Worse, except for stuff like what was being done at Xerox, static linking was the only way for compiled languages.

Also on desktop systems, embedding resources into the binaries exists since the early 1980's, or just deliver every in the same directory like NeXTSTEP bundles, or what is called xcopy deployment on the PC world on homage how we used to do it on MS-DOS days.

Reply on news.ycombinator.com