(I did not receive the original message with your question. JRH) 

Might I ask why you might be opposed to containerization on VMs?

There are a number of reasons, none of which is a show stopper, and I don't want to hash out the whole discussion at the disk right now.  My primary argument is simplicity.  I think containers are a great feature in a development environment, where the developer has complete control of the platform, and has the ability to re-spin the machine if something breaks.  For a production system where constancy and reliability are higher priority than agility I think it's another layer of performance, an additional attack target, and an additional point of failure.
 
As a sysadmin, I am NOT popular with developers.
 
Both containers and VMs have a number of overlapping features, and no matter how tiny, anything that consumes resources and duplicates efforts can be a hit at scale.  (See my other posts for the argument that scale is hardly a factor for this project.)
 
I'm not mortally opposed to it.  It doesn't match my goals for a production system of building the absolute minimum system that will support the code, with NO other features that do not serve that purpose. Any versatility, agility, and ease of modification belongs on the dev and test systems.  Among other "rules" is that there should never be a compiler on an exposed production server.
 
I really don't want to argue it out on this project, if the guys doing the work don't agree it won't hurt my feelings if they go ahead and follow their own standards.
 
 
 

 

On 02/21/2026 4: 42 PM CST Chris Bier <chris. bier@ cymor. com> wrote: This sounds pretty good to me, but I don't like the idea of containers on a VM. One or the other. I think that traffic management (round robin) is a bit ambitious. We really

 

 

On 02/21/2026 4:42 PM CST Chris Bier <chris.bier@cymor.com> wrote:

This sounds pretty good to me, but I don't like the idea of containers on a VM.  One or the other.

 

I think that traffic management  (round robin) is a bit ambitious.  We really don't need it for a site with a few dozen users at best.  It gives us fallback if a node goes down, but it also increases maintenance and points-of-failure.  I have seen distributed/fallback systems fail more often than  they work. 

 

If some kind of Linux bomb drops and suddenly end users are overflowing the system we can easily expand.

 

--

Jonathan

 

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
_______________________________________________
KCLUG mailing list -- kclug@kclug.org
To unsubscribe send an email to kclug-leave@kclug.org
https://kclug.org/mailman3/postorius/lists/kclug.kclug.org/
 
_______________________________________________
KCLUG mailing list -- kclug@kclug.org
To unsubscribe send an email to kclug-leave@kclug.org
https://kclug.org/mailman3/postorius/lists/kclug.kclug.org/
 
--
Jonathan