The problem is not containerization per se, I run containers both in my personal systems and at work. If you extremely optimize for compilers, the performance difference can be trimmed down to 2%. I think for most of us, it's 5%-6% band, and it's OK for non-loaded servers.
My qualm is about trimming fairly standard features and offloading it to somewhere else.
A single HTTP service + traefik (or Apache/NGINX reverse proxy) is heavier than a single HTTPS service. Plus adds more moving parts for smaller installations. f I was running an API farm, I can add all kinds of bells and whistles, and it'll be lighter overall, but this is not a valid reason for stripping fairly simple features from applications which will be used by small teams on small hardware.
Plus, this additional layers can sometimes conflict (A requires B, C required D, where B & D are same thing but either one can't accommodate A & C at the same time), requiring a completely new system to run the service, which is wasteful, from my perspective.
> A single HTTP service + traefik (or Apache/NGINX reverse proxy) is heavier than a single HTTPS service.
How heavy are talking, and what would be the measured impact?
I have worked on small teams (3~4 people) where we had to use our own infrastructure for regulatory reasons. I also self-host a few things as a hobby. I don't think Nginx or Caddy were ever a bottleneck, and at the human level, they saved more resources than not using them. I don't remember the last time I exposed something to a network using their bundled http server directly rather than a reverse proxy. I don't like wasting computational resources of course, but % wise, 'optimizing' them by not using containers or a reverse proxy wouldn't net any visible gains - there's usually other low hanging fruit that gives you more for your time.
My qualm is about trimming fairly standard features and offloading it to somewhere else.
A single HTTP service + traefik (or Apache/NGINX reverse proxy) is heavier than a single HTTPS service. Plus adds more moving parts for smaller installations. f I was running an API farm, I can add all kinds of bells and whistles, and it'll be lighter overall, but this is not a valid reason for stripping fairly simple features from applications which will be used by small teams on small hardware.
Plus, this additional layers can sometimes conflict (A requires B, C required D, where B & D are same thing but either one can't accommodate A & C at the same time), requiring a completely new system to run the service, which is wasteful, from my perspective.