11–20 of 65 posts
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
We went from hosting on prem to directly azure web apps.
Something in between I think is where docker would be helpful.
Different languages get a different amount of boost here. Ruby is an example which strongly benefits from docker deploys. You don't need to worry about what version of ruby (if any) will be installed on the host. And you don't need to worry about getting your gem dependencies installed on the host or figure out how to bundle them into your app code.
I think older dot net apps required the runtime to be installed on the host. Docker would have helped then.
The other big draw of docker is uniformity in deployment (the shipping container metaphor). Deploying code of any language and third party apps can be very similar. This is a powerful enough idea that giant abstractions like kubernetes have come to exist. This would be much more fiddly if each application needed to be special cased.
System wide dependencies and settings become completely encapsulated. You can even run shell command lines repeatedly from the same system state with the "input" of the command being changed files in a mounted volume. DLLs don't solve those problems.
You can of course achieve this by using other tools, but you'd effectively de re-implementing a container runtime with that.
Docker does this for software. A docker image packaging an application has a well-defined interface to start/stop/configure/log the application, regardless of which language it was written in.
This way infrastructure tools (for example container orchestration like Kubernetes, docker-compose, swarm,... but also CI/CD tools and local development environments) can work with all sorts of applications in the same way. Docker (or containers) provide a uniform interface to all of these tools.
As a dev, containers allow you to care a lot less about what’s installed on the server and in which version. You’ve already solved that in a different way for your setup, which is fine. I’d say the trick in your case isn’t the DLLs specifically (I’m not sure why you focus on that aspect), it’s the fact that .NET allows you to create a standalone application, including (in modern times) the .NET runtime. If that’s all you need, you’ve already minimized your dependencies on the OS, and you’re unlikely to benefit from using containers.
However, if you need anything else on the server (another runtime, a database server, a mail server), Docker could still help. Having the whole tech stack pinned in version control is really nice, and having the ability to make any changes to one’s setup at whim is very liberating.
For admins, there’s a different advantage. Especially when multiple technologies are in use somewhere, containers are a standard interface to host any kind of server application the same way. You don’t need to know or care that one technology just copies a directory, the other one requires a specific configuration of Apache and the third one requires setting up an extra cron job — just start the container and you’re done.
But it’s always important to remember that there’s no shame in not using a technology that HN has deemed cool, particularly if it doesn’t solve a problem you have.
Becuase your solution is specific to your specific software. Then you have lads who use python who can use virtualenv, and then the ruby ones who use rbenv and then you have the CPP developers which are usually fine but on Tuesday Joe messed up the linker settings and all of a sudden we're not statically linked, thanks Joe. And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. The th…
That's just a sing for bad communication/practices/documentation and processes, and why don't the dev's test the application on the dev/test-environment?
BTW: Why can the JAVA-team even install something on the dev/test/prod-env? That's completely against the rules.
Don't blame yourself, it took me quite awhile to figure out the benefits as well.
Docker, or containerization in general is not a system that only helps you manage dependencies and isolation. It's about dependencies management, isolation (to a degree), fast and expectable deployment, automatic scaling and so on.
Now days, application backend are expected to run on multiple nodes. Sure, you can manually code your app to automatically deploy/update itself on multiple servers and so on, but that is a huge task, and the maintenance responsibility comes with it is even bigger.
Containerization platform such as Docker and Kubernetes provides a standard operating environment for operators and developers to manage the lifecycle of a scalable application, IMO that's where the gold is. Dependency management and isolation etc is just a natural part of that.
Of course, you're still responsible in creating a scalable application, but once you did that, deploying the application will be as simple as running a `git push`, then a remote system takes over, creating a container image according to your Dockerfile, and then deploy those containers onto necessary amount of servers. It all happens automatically, like a dream :)