ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Conatainers (Docker) vs VMs - When and Why?

    IT Discussion
    docker containers virtualization vms
    5
    19
    1.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • scottalanmillerS
      scottalanmiller @IRJ
      last edited by

      @IRJ said in Conatainers (Docker) vs VMs - When and Why?:

      So thinking about it, you could have 5 different application services separated in containers on a single VM that you can scale if needed.

      If one container failed, you could easily redepoly without affecting other services.

      True, but VMs allow for that, too.

      1 Reply Last reply Reply Quote 0
      • scottalanmillerS
        scottalanmiller
        last edited by

        A HUGE factor is that VMs allow for multi-OS options, containers have to share a kernel. But containers are lighter. So you want containers when you can, but you often can't.

        1 Reply Last reply Reply Quote 0
        • scottalanmillerS
          scottalanmiller @Emad R
          last edited by

          @Emad-R said in Conatainers (Docker) vs VMs - When and Why?:

          Have you ever used snaps ?

          I like Snaps, but they aren't real containers. They are non-containers that act like people assume Docker acts, so they call them containers quite often.

          Traditional containers, Type-C virtualization, like LXC is pretty far from Snaps. Docker acts like Snaps in some ways, but is build like LXC under the hood.

          1 Reply Last reply Reply Quote 0
          • scottalanmillerS
            scottalanmiller @Emad R
            last edited by

            @Emad-R said in Conatainers (Docker) vs VMs - When and Why?:

            Ubuntu host OS running ubuntu container image with LAMP installed , you will not leverage the power of containers

            Sure it would.

            1 Reply Last reply Reply Quote 0
            • scottalanmillerS
              scottalanmiller @Emad R
              last edited by

              @Emad-R said in Conatainers (Docker) vs VMs - When and Why?:

              No more snapshotting VMs and exporting and importing, and wiping free space to reduce size.

              Those are things you can easily do without containers simply by using statically linked code. Containers enforce this, sure, but it's not an intrinsic issue with non-containers.

              1 Reply Last reply Reply Quote 1
              • scottalanmillerS
                scottalanmiller @JaredBusch
                last edited by

                @JaredBusch said in Conatainers (Docker) vs VMs - When and Why?:

                @Emad-R said in Conatainers (Docker) vs VMs - When and Why?:

                No more snapshotting VMs and exporting and importing, and wiping free space to reduce size.

                If anyone was doing this, they were doing things wrong anyway.

                Right, this is something we already solved without containers.

                1 Reply Last reply Reply Quote 0
                • scottalanmillerS
                  scottalanmiller @JaredBusch
                  last edited by

                  @JaredBusch said in Conatainers (Docker) vs VMs - When and Why?:

                  There is not point in it, as you will never scale a database server up as multiple copies.

                  You can, I've been in shops that did this. Rare, and we didn't use containers, but rather VMs, but containers would have worked.

                  JaredBuschJ 1 Reply Last reply Reply Quote 0
                  • JaredBuschJ
                    JaredBusch @scottalanmiller
                    last edited by

                    @scottalanmiller said in Conatainers (Docker) vs VMs - When and Why?:

                    @JaredBusch said in Conatainers (Docker) vs VMs - When and Why?:

                    There is not point in it, as you will never scale a database server up as multiple copies.

                    You can, I've been in shops that did this. Rare, and we didn't use containers, but rather VMs, but containers would have worked.

                    Duh, never is always assumed as "never"

                    1 Reply Last reply Reply Quote 0
                    • ObsolesceO
                      Obsolesce
                      last edited by

                      Are there many use cases in the SMB outside of Dev?

                      JaredBuschJ 1 Reply Last reply Reply Quote 0
                      • JaredBuschJ
                        JaredBusch @Obsolesce
                        last edited by

                        @Obsolesce said in Conatainers (Docker) vs VMs - When and Why?:

                        Are there many use cases in the SMB outside of Dev?

                        Not even in dev really for the SMB. Just use a single VM to do the work. SMB rarely needs to scale.

                        Other than as you stated, the solution is presented that way. Like UNMS.

                        scottalanmillerS 1 Reply Last reply Reply Quote 2
                        • scottalanmillerS
                          scottalanmiller @JaredBusch
                          last edited by

                          @JaredBusch said in Conatainers (Docker) vs VMs - When and Why?:

                          @Obsolesce said in Conatainers (Docker) vs VMs - When and Why?:

                          Are there many use cases in the SMB outside of Dev?

                          Not even in dev really for the SMB. Just use a single VM to do the work. SMB rarely needs to scale.

                          Other than as you stated, the solution is presented that way. Like UNMS.

                          Even enterprise rarely need to scale that way. It's more for hosting companies than anything.

                          1 Reply Last reply Reply Quote 0
                          • 1 / 1
                          • First post
                            Last post