8 ms·

Is deploying a database binary and mounting a volume on a VM really the hard part? The nice thing about containers is that you are independent of the under

Is deploying a database binary and mounting a volume on a VM really the hard part? The nice thing about containers is that you are independent of the underlying infrastructure. Be it a VM or bare metal. I can easily spin up a Docker container on my laptop. Takes a second or so. Spinning up VirtualBox or something is so much more hassle.

evol262 4y ago
This falsehood needs to die. It's true for non-trivial cases, and exceptionally false for some things. Like databases. A lot of the sysctl tuning for large database environments has to be done on the host, either directly, allowing unsafe sysctls and restarting kubelet, running with privileges, etc. This is not "independent of the underlying infrastructure" or "the VM and my laptop have the same kernel tunables set". They don't. And it matters.
- JonathanBeuys 4y ago
  Only when your application depends on optimizing your database to the max. Most applications don't. And even if the application I work on does - then only in production. Not on my laptop. So on my laptop I will simply chose a docker image that resembles production as closesly as possible. I will not use a VM.
  - xorcist 4y ago
    Trivial use cases are generally trivial.
    - koolba 4y ago
      The vast majority of use cases for databases are trivial. For every esoteric, optimized to the max, bleeding edge kernel parameter tuned environment, you have 10,000+ CRUD apps that do little more than primary key look ups on vanilla btree indexes.
      - therealdrag0 4y ago
        I’ve worked at a half dozen companies most people have never heard of and they all had database complexity and performance issues. The whole “only FAANG has scale” meme needs to die. You’re probably right there’s a magnitude more tiny apps but who cares. A large number of us still are interested in and need to solve for non-trivial cases.
        Too 4y ago
        Most database performance issues are bad choice of indices, bad data model, bad queries, not enough RAM, missing pooling, unrealistic expectations and lack of pre-computed caches. None of these are solved by "optimize kernel-parameters to the max".
        therealdrag0 4y ago
        I agree! I must have misread or misunderstood the context.
        koolba 4y ago
        This is exactly what I was talking about.
  - deleted 4y ago
    [deleted]
  - KaiserPro 4y ago
    > Only when your application depends on optimizing your database to the max. Only when you don't need to store data for any length of time. The point of containers is that they don't store state. You have to manage that. And for some cases you can get away with it. But for most websites, keeping a single container up for many years isn't a great strategy. (Yes, I know there are ways around this. but they are not as simple as "docker run postgres")
- lrvick 4y ago
  This sounds like a good argument for firecracker or some other micro hypervisor wrapper around your container to give you more control. You should never ever touch the host OS of a production system.
tra3 4y ago
Is docker fast because you have other containers running already and you’ve got a vm up? Vagrant used to be a thing and it would spin vms up pretty quick. There are differences technically, between docker and vms, certainly, but conceptually they are the same, aren’t they? There’s no real
- JonathanBeuys 4y ago
  It's just fast. I have not used a container today. Let's use one: $ time docker run --rm debian:11-slim echo hello hello real 0m0.528s user 0m0.015s sys 0m0.023s
  - jiggawatts 4y ago
    VM platforms had the opportunity but not the motivation to achieve comparable startup times. There are a handful of examples out there like AWS Firecracker, but the majority out there are “full fat”. As a random example, Azure full-clones 127GB disk images by default. It takes over a minute to create a VM. Booting form a cold start is sluggish because there is no sharing with other tenants, hence no caching. Using the same hypervisor (Hyper-V) I can clone out a Windows server VM and boot it in about 3 seconds by simply using delta cloning. Subsequent boots of it or any of its siblings is just over a second! Containers and Kubernetes are throwing the gloves down and will force the competition to pick up the pace.
    - sofixa 4y ago
      Azure is the worst possible example and is invalid as a comparison outside of to show exactly how bad it is. AWS EC2s start within a couple of tens of seconds max. AWS Lambda, Google Cloud Functions, Google Cloud Run start within ms (Google Cloud Functions used to have a cold start problem where sometimes they'd take up to a few seconds to start, but that has been fixed). But overall, I'd say VM platforms are somewhat a thing of the past. Nobody cares about running an OS, what you need is the things inside (your application, database, etc.) so fundamentally a VM is an abstraction at the wrong layer, a means to an end. Don't get me wrong, they're still here and aren't going anywhere, but should no longer be the go-to outside of a few specific cases - bare metal, containers and "serverless" (running on bare metal) is where it's at.
KaiserPro 4y ago
I can spin up a Db on my laptop in a few minutes. The difference is my laptop doesn't provide any guarantees of stability, uptime or throughput. installing a DB is as simple as "apt install $db" > The nice thing about containers is that you are independent of the underlying infrastructure I mean you're really not. You're dependent on the machine, the OS, and the kernel version. Docker on windows is a VM, from what I remember. I assume OSX's docker is still VM based too.

evol262 4y ago

This falsehood needs to die. It's true for non-trivial cases, and exceptionally false for some things. Like databases. A lot of the sysctl tuning for large database environments has to be done on the host, either directly, allowing unsafe sysctls and restarting kubelet, running with privileges, etc. This is not "independent of the underlying infrastructure" or "the VM and my laptop have the same kernel tunables set". They don't. And it matters.

JonathanBeuys 4y ago
Only when your application depends on optimizing your database to the max. Most applications don't. And even if the application I work on does - then only in production. Not on my laptop. So on my laptop I will simply chose a docker image that resembles production as closesly as possible. I will not use a VM.
- xorcist 4y ago
  Trivial use cases are generally trivial.
  - koolba 4y ago
    The vast majority of use cases for databases are trivial. For every esoteric, optimized to the max, bleeding edge kernel parameter tuned environment, you have 10,000+ CRUD apps that do little more than primary key look ups on vanilla btree indexes.
    - therealdrag0 4y ago
      I’ve worked at a half dozen companies most people have never heard of and they all had database complexity and performance issues. The whole “only FAANG has scale” meme needs to die. You’re probably right there’s a magnitude more tiny apps but who cares. A large number of us still are interested in and need to solve for non-trivial cases.
      - Too 4y ago
        Most database performance issues are bad choice of indices, bad data model, bad queries, not enough RAM, missing pooling, unrealistic expectations and lack of pre-computed caches. None of these are solved by "optimize kernel-parameters to the max".
        therealdrag0 4y ago
        I agree! I must have misread or misunderstood the context.
        koolba 4y ago
        This is exactly what I was talking about.
- deleted 4y ago
  [deleted]
- KaiserPro 4y ago
  > Only when your application depends on optimizing your database to the max. Only when you don't need to store data for any length of time. The point of containers is that they don't store state. You have to manage that. And for some cases you can get away with it. But for most websites, keeping a single container up for many years isn't a great strategy. (Yes, I know there are ways around this. but they are not as simple as "docker run postgres")
lrvick 4y ago
This sounds like a good argument for firecracker or some other micro hypervisor wrapper around your container to give you more control. You should never ever touch the host OS of a production system.

tra3 4y ago

Is docker fast because you have other containers running already and you’ve got a vm up? Vagrant used to be a thing and it would spin vms up pretty quick. There are differences technically, between docker and vms, certainly, but conceptually they are the same, aren’t they? There’s no real

JonathanBeuys 4y ago
It's just fast. I have not used a container today. Let's use one: $ time docker run --rm debian:11-slim echo hello hello real 0m0.528s user 0m0.015s sys 0m0.023s
- jiggawatts 4y ago
  VM platforms had the opportunity but not the motivation to achieve comparable startup times. There are a handful of examples out there like AWS Firecracker, but the majority out there are “full fat”. As a random example, Azure full-clones 127GB disk images by default. It takes over a minute to create a VM. Booting form a cold start is sluggish because there is no sharing with other tenants, hence no caching. Using the same hypervisor (Hyper-V) I can clone out a Windows server VM and boot it in about 3 seconds by simply using delta cloning. Subsequent boots of it or any of its siblings is just over a second! Containers and Kubernetes are throwing the gloves down and will force the competition to pick up the pace.
  - sofixa 4y ago
    Azure is the worst possible example and is invalid as a comparison outside of to show exactly how bad it is. AWS EC2s start within a couple of tens of seconds max. AWS Lambda, Google Cloud Functions, Google Cloud Run start within ms (Google Cloud Functions used to have a cold start problem where sometimes they'd take up to a few seconds to start, but that has been fixed). But overall, I'd say VM platforms are somewhat a thing of the past. Nobody cares about running an OS, what you need is the things inside (your application, database, etc.) so fundamentally a VM is an abstraction at the wrong layer, a means to an end. Don't get me wrong, they're still here and aren't going anywhere, but should no longer be the go-to outside of a few specific cases - bare metal, containers and "serverless" (running on bare metal) is where it's at.

KaiserPro 4y ago

I can spin up a Db on my laptop in a few minutes. The difference is my laptop doesn't provide any guarantees of stability, uptime or throughput. installing a DB is as simple as "apt install $db" > The nice thing about containers is that you are independent of the underlying infrastructure I mean you're really not. You're dependent on the machine, the OS, and the kernel version. Docker on windows is a VM, from what I remember. I assume OSX's docker is still VM based too.