Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Docker vs simple DLLs?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Ask HN: Docker vs simple DLLs?

#51

Post by codeflo »

pmontra wrote: post #41

Some dependencies are not DLLs. Actually docker needs a Linux kernel so there won't be any DLL, only .so, but that's basically the same thing. The point is that in a container we can encapsulate all libraries, files, other applications, etc, dump them in an image, ship, deploy and run them more or less as if they were in a VM of their own with no access to the rest of the system. I don't know if there is a comparable…

I agree.

Just FYI, for compatibility reasons, the .NET runtime uses the .dll extension for all libraries, even on Linux. Despite the extension, these files aren’t true Windows DLL files. They might have a stub PE header (not completely sure), but otherwise, they only contain what’s called Intermediate Language code that has to be JIT compiled by the runtime. The principle is similar to .jar files in Java, in case you’re familiar with those.

The .NET toolchain has a mode where it bundles all dependencies (.dll files) and your code (more .dll files) together with the runtime for the target platform (for example, Linux) into a redistributable directory. I think that’s what the OP is referring to.

Re: Ask HN: Docker vs simple DLLs?

#52

Post by bluehatbrit »

I'm going to use the word "container" because these days "docker" is really just a company that pushed them forwards but there are a bunch of different container types now.

Containers are really more about packaging and isolating applications in a standard way that is tech-stack agnostic. If your entire company runs .NET and the entire company deploys with DLLs in specific directories then you've got some of the benefits already. Containers take it a step further though, it's no longer something .NET, Python, Ruby, and Go developers all do differently - containers wrap around all of those.

Because containers are standard and agnostic to whats inside them you can also securely isolate without them even having to care about it. If your application writes files to a temp directory, you don't need to worry about another application also writing to that directory. If your application uses a particular port you don't need to worry about another .NET application also wanting to use that port. Suddenly you've gone from shipping oddly shaped boxes of different sizes and dimensions, and you've now just put everything from a car to 100,000 packets of M&M's into a standard package, the shipping container.

The ship doesn't give a crap what's inside each container, and the crew don't need to worry about figuring out the best way to fit everything in, they just know how many containers they can take, load them up, and go.

Whoever's responsible for your infrastructure no longer cares if you use .NET. You can decide to branch out into a bit of machine learning and use cobble together a model in python and all you need to do is create the container properly (Docker being a nice way of doing it). You hand the container to your infrastructure or infra team, request the right amount of resources, and it's there running very happily.

You also get some benefits around dependency management from this, such as deps are pulled in at container build time. Great! Now as long as that container image is around, you never have to resolve those deps again, there's no chance they will ever change under your feet for that container, and if they disappear you can still run the older versions of the containers as often as you like. That's not just the same for NuGet packages though, if you depend on an OS package like OpenSSL you don't need to worry that some other person will update it and it'll break your app.

Dependency management is almost a side-effect of the concept of containers, it's a great addition but the point was always standardising packaging and deployment of applications as a whole regardless of their technology.

Re: Ask HN: Docker vs simple DLLs?

#53

Post by tompazourek »

I think it's a similar pattern, but at a different layer.

You can compose methods, compose classes/instances (DI), compose libraries/assemblies, compose processes, microservices, or entire apps and multi-app systems. There are similar patterns of composition, just each is at a different level of abstraction of the whole thing.

Sometimes it makes more sense to compose it inside an app, sometimes it makes more sense to design it differently and compose on another layer. Sometimes it can be both or it's blurry and not clear...

Re: Ask HN: Docker vs simple DLLs?

#54

Post by jdthedisciple »

codeflo wrote: post #51
pmontra wrote: post #41

Some dependencies are not DLLs. Actually docker needs a Linux kernel so there won't be any DLL, only .so, but that's basically the same thing. The point is that in a container we can encapsulate all libraries, files, other applications, etc, dump them in an image, ship, deploy and run them more or less as if they were in a VM of their own with no access to the rest of the system. I don't know if there is a comparable…

I agree. Just FYI, for compatibility reasons, the .NET runtime uses the .dll extension for all libraries, even on Linux. Despite the extension, these files aren’t true Windows DLL files. They might have a stub PE header (not completely sure), but otherwise, they only contain what’s called Intermediate Language code that has to be JIT compiled by the runtime. The principle is similar to .jar files in Java, in case you…

Yes that's exactly what I am referring to.

Re: Ask HN: Docker vs simple DLLs?

#55

Post by Const-me »

I don’t do web development, but when I need something similar on Linux, I usually creating custom packages.

A bad thing about them, they are distro-specific: Debian is using deb packages, Alpine is using apk packages. Not just the installer other things are also substantially different between them. If deploying some services, some distros are using systemd but Alpine uses openrc. Firewalls are different as well.

At least in my experience it’s not terribly bad. On servers and embedded these environments are stable, people don’t usually switch randomly between unrelated distros.

A good thing about the approach is little to no overhead for runtime performance, management complexity (the installer infrastructure included in the OS makes it trivially easy to upgrade/remove these packages), and binary size.

These Linux repositories are huge, there’s very high chance whatever runtime support one might possibly need is already there, tested carefully by the maintainers of the distro. When that’s the case, a dependency becomes a single line in the package manifest, such as “libsomething (>= 12.34)” for a Debian package.

Re: Ask HN: Docker vs simple DLLs?

#56

Post by speedgoose »

dnndev wrote: post #12

I had the same issue and we ended up skipping docker all together. We went from hosting on prem to directly azure web apps. Something in between I think is where docker would be helpful.

I personally think that proprietary solutions that want to lock you in their infrastructure rank lower than standard software containers.

It probably makes sense for your business though.

Re: Ask HN: Docker vs simple DLLs?

#57

Post by busterarm »

mschuster91 wrote: post #47
oneplane wrote: post #40

Earlier quoted context omitted.

Not really; if you have a few servers vs. a few containers the patch is the same with the difference that the server one is probably "live" patching on a running system and the docker one is patching it in the docker file and re-deploying which makes it an atomic change. It also really makes a difference if you are combining some tasks and ownership in a DevOps concept where it's not just developers handing off some…

The problem is, most ops-focused people don't have much knowledge of the boatload of different application-side tooling, and most devs (especially those out of "coding bootcamps" or practical academia) don't have a single ounce of knowledge about OS management or even how basic UNIXoid fundamentals work. DevOps has always been more about companies attempting to "save" money by shoe-horning together roles that require…

> and most devs (especially those out of "coding bootcamps" or practical academia) don't have a single ounce of knowledge about OS management or even how basic UNIXoid fundamentals work.

I have to vehemently disagree with this statement. I had 10 years in IT before I did my bootcamp and quickly found myself in deployment engineer roles by accident. Most of my bootcamp cohort ended up at smaller companies wearing many hats and learning quickly where a good half of them are in deployment type roles by necessity.

After an additional 10 years in this industry, I'm finding invariably that it's the FAANGs and companies hiring fresh grads out of the best schools where engineers aren't learning anything about the underlying systems. It's the feature factories where people put their headphones on, the heads down and code like their life depends on it.

They do things like write microservices that implement basic functionality of opensource loadbalancers, because they've never heard of nginx or haproxy before, don't know how it solves their specific problem and wouldn't know how to configure it. When all you do is write code, every problem looks like it should be solved by writing code.

Re: Ask HN: Docker vs simple DLLs?

#58

Post by chlorion »

Faaak wrote: post #7

How to you deal with resource allocation (memory limits, cpu limits, etc.) ? How to give a different IP address to each application ? What if an application fails and starts filling your disk space and thus impacts others ? Docker, and the tools on top of that, can make these problems easier

You can do resource control with cgroups. With systemd based distros you can use "systemd-run" and pass various flags that define the exact limits. Non systemd distros can use libcgroup or use the sysfs cgroup interface directly.

The IP address situation can be handled with the "unshare" and "ip" commands. Unshare allows putting a process in a new namespace and ip allows configuring the interfaces and moving them between namespaces.

Both of these solutions do not require any container runtime which is a big advantage efficiency wise!

I am not saying that using docker for these purposes is bad though, I just wanted to mention some lightweight alternatives in case anyone was interested.

Re: Ask HN: Docker vs simple DLLs?

#59

Post by arwhatever »

I think answering the initial question might benefit from a lot of context.

I've worked on quite a few teams who built atop dotnet core (cross-platform) and also have access to auto-horizontal-scaling PAAS solutions (such as Azure App Services) and who tend to reach for Docker well before they need it.

Now we all have to manage port mappings, env var mappings, file path mappings etc., the better part of a full OS-worth of abstractions when all the abstraction that we need is provided by the technologies I mentioned prior to adding Docker.

Re: Ask HN: Docker vs simple DLLs?

#60

Post by partialzero »

Ports.

Others will probably provide some other good reasons, but to me, Docker is multiplexing the global shared resource that is typically singular on a machine (at least a cloud/vm) - network ports. Of course you can easily stand up multiple services (of varying or same software platform) but you will need to carefully negotiate and manage and proxy ports. Docker provides an abstraction that does this for you, where services are hosted under unique internal host names which are easily addressable.

Post reply on HN