8 ms·

My personal long bet has been to completely ignore Docker etc. Seems that has bounced between plain ugly apathy and foresight.

RubenSandwich 9y ago
I personally think Unikernals will overshadow Containers in a few years. They just in my mind offer a model that is much more security and speedy. I give them a few years because Unikernals still need to figure out better tooling; debugging, producing and deploying them is currently difficult.
- tjbiddle 9y ago
  A few years is a lifetime in tech; why not learn what is new and see how if it's applicable to you and improves things now? You'll come out with more experience, can throw it on your resume, and very likely be more prepared for the next tech to come along.
- unilynx 9y ago
  It seems pretty unlikely that unikernels will ever replace containers. Containers allow you to run almost all of the past decades of software with no or little modification (and most modifications are done in bash), a unikernel is more like a new OS that applications need to be ported to, without the full POSIX API (eg, no subprocesses) - it's probably easier to port a multiprocess server (eg most SMTP servers) from Linux to the NT API than to port them to a unikernel
  - pjmlp 9y ago
    Not necessarily, on programming languages with nice standard libraries/runtimes it is just a matter of running them bare metal. A JEE application doesn't care if WebSphere is running on OS XYZ, bare metal or an hypervisor. In a way I consider POSIX C's runtime that should have been made part of ANSI C.
- pjmlp 9y ago
  I think it would be quite cool, but it needs to become the next fashion in order to go mainstream. After all we on Java world were already doing that with application containers, it would be just a matter of running them bare metal.
JonMR 9y ago
You're missing out in the meantime. Even just for a local development stack, it's extremely useful.
- geerlingguy 9y ago
  Or CI. Having easy environments for any OS or software tool imaginable makes it quick and simple to test my applications across 10 OSes and OS versions as needed.
koolba 9y ago
Putting aside deployment, Docker has been a sheer joy for local development. It provides a complete wrapper for the voodoo and tribal knowledge required to run packaged apps. Gone are the days of building a VM from scratch, following instructions for a previous version of the OS, installing 10 dependencies, installing the app, cursing when it fails half way through, installing another missing dependency, installing the app again, bouncing the server, and then having it all fall apart again because the app isn't registered to run as a service at startup (because you missed that step). All of this was possible before Docker through Vagrantfiles and the like but Docker made it much cleaner and significantly less resource intensive (i.e. no longer need a VM per item).
- jjawssd 9y ago
  Instead of writing a build script to put everything together from a solid foundation, Docker implicitly encourages you to perform a succession of random undocumented changes on the original foundation endlessly. Also known as "tribal knowledge." And this is all somehow "cleaner" than build scripts. "Putting aside deployment" means discouraging reproducibility and encouraging book burning.
  - amcca029 9y ago
    can you describe this solid foundation in more detail?
    - nur0n 9y ago
      I think depends on the project, no? You first specify your dependencies, then provide a way to use the dependencies to build the end project. If you don't have to specify the dependencies or the build process to the user, then you can get away with the build process not being well defined. Docker is a win for 'easy installation', but I wonder if it degrades the quality of projects which rely on it?
  - kenforthewin 9y ago
    No, putting aside deployment means he was talking about the benefits of Docker for local development instead of the benefits of Docker for deployment. As to your talk of a build script, this is what the Dockerfile is for, and it is heavily documented.
apple4ever 9y ago
Ditto. Docker seems interesting, but also a solution without a problem.
- thenayr 9y ago
  Keep ignoring it, at your own peril.
api 9y ago
I thought I was the only one. A few years ago Devops conferences sounded like: "Docker docker Docker? Docker. Docker docker docker docker Docker docker docker. Docker, Docker docker Docker docker Docker." Now the hype seems to be wearing off and people are realizing that it's just a way of treating Linux installs like giant static binaries plus a whole lot of unnecessary complexity.
- dxhdr 9y ago
  I'm glad I haven't spent any time on it. "Docker is fantastic! You can run anything you want, easily. Except, uh, don't try to run a database or anything like that. Oh and here are a dozen different flow charts and tables explaining how to handle networking. And uh make sure you still do all of the same VM provisioning for security since containers don't give you any. Simple!"
  - atoko 9y ago
    Why can't you run a db server on a container?
    - rm999 9y ago
      Containers are designed to be non-persistent - if an instance of a container goes down you should be able to replace it with another instance with no loss in state. Most people want their databases to be persistent (unless it's just temporary local storage for your process), so containers are a bad idea here. What you want is some sort of external storage to store state. This also enables better horizontal scaling.
      - jcrites 9y ago
        I would say this might be a description of Docker or Docker containers specifically, but does not characterize Linux containers generally. Linux container technology, by which I mean the Linux kernel APIs used by Kubernetes, CoreOS rkt, and Docker, do not have an opinion about whether the processes that run as containers are ephemeral or persistent. Containers can be just as persistent as the host they're running on. For example, consider a Linux distribution using systemd. Systemd might launch regular processes upon system startup, and it might also launch containers where both types of processes are equally persistent on the parent host. See the documentation for systemd-nspawn [1] and machinectl [2]. The Arch Linux wiki has more details about how to use that distribution with nspawn [3]. Containers managed in this way are just like other system processes aside from being containerized. [1] https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html# https://www.freedesktop.org/software/systemd/man/systemd-nsp... [2] https://www.freedesktop.org/software/systemd/man/machinectl.html# https://www.freedesktop.org/software/systemd/man/machinectl.... [3] https://wiki.archlinux.org/index.php/Systemd-nspawn https://wiki.archlinux.org/index.php/Systemd-nspawn

RubenSandwich 9y ago

I personally think Unikernals will overshadow Containers in a few years. They just in my mind offer a model that is much more security and speedy. I give them a few years because Unikernals still need to figure out better tooling; debugging, producing and deploying them is currently difficult.

tjbiddle 9y ago
A few years is a lifetime in tech; why not learn what is new and see how if it's applicable to you and improves things now? You'll come out with more experience, can throw it on your resume, and very likely be more prepared for the next tech to come along.
unilynx 9y ago
It seems pretty unlikely that unikernels will ever replace containers. Containers allow you to run almost all of the past decades of software with no or little modification (and most modifications are done in bash), a unikernel is more like a new OS that applications need to be ported to, without the full POSIX API (eg, no subprocesses) - it's probably easier to port a multiprocess server (eg most SMTP servers) from Linux to the NT API than to port them to a unikernel
- pjmlp 9y ago
  Not necessarily, on programming languages with nice standard libraries/runtimes it is just a matter of running them bare metal. A JEE application doesn't care if WebSphere is running on OS XYZ, bare metal or an hypervisor. In a way I consider POSIX C's runtime that should have been made part of ANSI C.
pjmlp 9y ago
I think it would be quite cool, but it needs to become the next fashion in order to go mainstream. After all we on Java world were already doing that with application containers, it would be just a matter of running them bare metal.

JonMR 9y ago

You're missing out in the meantime. Even just for a local development stack, it's extremely useful.

geerlingguy 9y ago
Or CI. Having easy environments for any OS or software tool imaginable makes it quick and simple to test my applications across 10 OSes and OS versions as needed.

koolba 9y ago

Putting aside deployment, Docker has been a sheer joy for local development. It provides a complete wrapper for the voodoo and tribal knowledge required to run packaged apps. Gone are the days of building a VM from scratch, following instructions for a previous version of the OS, installing 10 dependencies, installing the app, cursing when it fails half way through, installing another missing dependency, installing the app again, bouncing the server, and then having it all fall apart again because the app isn't registered to run as a service at startup (because you missed that step). All of this was possible before Docker through Vagrantfiles and the like but Docker made it much cleaner and significantly less resource intensive (i.e. no longer need a VM per item).

jjawssd 9y ago
Instead of writing a build script to put everything together from a solid foundation, Docker implicitly encourages you to perform a succession of random undocumented changes on the original foundation endlessly. Also known as "tribal knowledge." And this is all somehow "cleaner" than build scripts. "Putting aside deployment" means discouraging reproducibility and encouraging book burning.
- amcca029 9y ago
  can you describe this solid foundation in more detail?
  - nur0n 9y ago
    I think depends on the project, no? You first specify your dependencies, then provide a way to use the dependencies to build the end project. If you don't have to specify the dependencies or the build process to the user, then you can get away with the build process not being well defined. Docker is a win for 'easy installation', but I wonder if it degrades the quality of projects which rely on it?
- kenforthewin 9y ago
  No, putting aside deployment means he was talking about the benefits of Docker for local development instead of the benefits of Docker for deployment. As to your talk of a build script, this is what the Dockerfile is for, and it is heavily documented.

apple4ever 9y ago

Ditto. Docker seems interesting, but also a solution without a problem.

thenayr 9y ago
Keep ignoring it, at your own peril.

api 9y ago

I thought I was the only one. A few years ago Devops conferences sounded like: "Docker docker Docker? Docker. Docker docker docker docker Docker docker docker. Docker, Docker docker Docker docker Docker." Now the hype seems to be wearing off and people are realizing that it's just a way of treating Linux installs like giant static binaries plus a whole lot of unnecessary complexity.

dxhdr 9y ago
I'm glad I haven't spent any time on it. "Docker is fantastic! You can run anything you want, easily. Except, uh, don't try to run a database or anything like that. Oh and here are a dozen different flow charts and tables explaining how to handle networking. And uh make sure you still do all of the same VM provisioning for security since containers don't give you any. Simple!"
- atoko 9y ago
  Why can't you run a db server on a container?
  - rm999 9y ago
    Containers are designed to be non-persistent - if an instance of a container goes down you should be able to replace it with another instance with no loss in state. Most people want their databases to be persistent (unless it's just temporary local storage for your process), so containers are a bad idea here. What you want is some sort of external storage to store state. This also enables better horizontal scaling.
    - jcrites 9y ago
      I would say this might be a description of Docker or Docker containers specifically, but does not characterize Linux containers generally. Linux container technology, by which I mean the Linux kernel APIs used by Kubernetes, CoreOS rkt, and Docker, do not have an opinion about whether the processes that run as containers are ephemeral or persistent. Containers can be just as persistent as the host they're running on. For example, consider a Linux distribution using systemd. Systemd might launch regular processes upon system startup, and it might also launch containers where both types of processes are equally persistent on the parent host. See the documentation for systemd-nspawn [1] and machinectl [2]. The Arch Linux wiki has more details about how to use that distribution with nspawn [3]. Containers managed in this way are just like other system processes aside from being containerized. [1] https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html# https://www.freedesktop.org/software/systemd/man/systemd-nsp... [2] https://www.freedesktop.org/software/systemd/man/machinectl.html# https://www.freedesktop.org/software/systemd/man/machinectl.... [3] https://wiki.archlinux.org/index.php/Systemd-nspawn https://wiki.archlinux.org/index.php/Systemd-nspawn