Marcin: /* CG Sez */

2025-07-11T16:30:00Z

CG Sez

← Older revision		Revision as of 16:30, 11 July 2025
Line 10:		Line 10:
	This comment reflects common criticisms of Docker in certain production or enterprise environments, especially when used without discipline or when compared to more minimal, custom-built deployments. Let’s break it down point-by-point and provide a fair response or rebuttal where appropriate:		This comment reflects common criticisms of Docker in certain production or enterprise environments, especially when used without discipline or when compared to more minimal, custom-built deployments. Let’s break it down point-by-point and provide a fair response or rebuttal where appropriate:

	“More fragile long-term”		🔸 “More fragile long-term”
	Concern: Docker can abstract too much or add complexity layers that obscure problems until they break in production.		Concern: Docker can abstract too much or add complexity layers that obscure problems until they break in production.

Line 19:		Line 19:
	Fragility typically comes from poor image hygiene, outdated dependencies, or misconfigured orchestration—not from Docker itself.		Fragility typically comes from poor image hygiene, outdated dependencies, or misconfigured orchestration—not from Docker itself.

	“More human hours to maintain (therefore more expensive)”		🔸 “More human hours to maintain (therefore more expensive)”
	Concern: Containers can drift from host realities or require DevOps knowledge to manage images, registries, etc.		Concern: Containers can drift from host realities or require DevOps knowledge to manage images, registries, etc.

Line 28:		Line 28:
	But in practice, Docker allows you to automate infrastructure, use immutable builds, and share standardized environments—reducing devops time over the long run if done correctly.		But in practice, Docker allows you to automate infrastructure, use immutable builds, and share standardized environments—reducing devops time over the long run if done correctly.

	“Harder to optimize (e.g., with Varnish) for scalability”		🔸 “Harder to optimize (e.g., with Varnish) for scalability”
	Concern: Container networks and abstraction layers may interfere with advanced caching or network-level optimization.		Concern: Container networks and abstraction layers may interfere with advanced caching or network-level optimization.

Line 39:		Line 39:
	🔸 “Costs more to scale”		🔸 “Costs more to scale”
	Concern: Docker may incur higher overhead or force use of orchestration systems like Kubernetes, which require expertise and infrastructure.		Concern: Docker may incur higher overhead or force use of orchestration systems like Kubernetes, which require expertise and infrastructure.

			Response:

			This can be true for small/simple apps deployed on bare metal or a single VPS.

			For complex/multi-service systems, Docker reduces costs by enabling modular scaling, container reuse, and dynamic provisioning.

			With tools like Docker Compose, scaling dev/test/staging environments is extremely cost-effective.

			🔸 “Enormous security risks”
			Concern: Containers can expose hosts if improperly isolated, especially with root containers or insecure base images.

			Response:

			Valid if you run as root, don’t scan images, or allow unchecked container interaction.

			However, Docker can be more secure than traditional VMs if you use:

			Non-root containers

			Read-only filesystems

			Image scanning (e.g., Trivy, Clair)

			Minimal base images (e.g., Alpine)

			Namespaces and seccomp profilesConcern: Docker may incur higher overhead or force use of orchestration systems like Kubernetes, which require expertise and infrastructure.

	Response:		Response:

Marcin: Created page with "=MA Sez= I think you'll find that a docker-based solution is going to be more fragile long-term, require more human hours to maintain (therefore more expensive), is harder to optimize (eg with varnish) for scalability, costs more to scale, and it introduce enormous security risks. =CG Sez= This comment reflects common criticisms of Docker in certain production or enterprise environments, especially when used without discipline or when compared to more minimal, custom-..."

2025-07-11T16:29:36Z

Created page with "=MA Sez= I think you'll find that a docker-based solution is going to be more fragile long-term, require more human hours to maintain (therefore more expensive), is harder to optimize (eg with varnish) for scalability, costs more to scale, and it introduce enormous security risks. =CG Sez= This comment reflects common criticisms of Docker in certain production or enterprise environments, especially when used without discipline or when compared to more minimal, custom-..."

New page

=MA Sez=

I think you'll find that a docker-based solution is going to be more
fragile long-term, require more human hours to maintain (therefore more
expensive), is harder to optimize (eg with varnish) for scalability,
costs more to scale, and it introduce enormous security risks.

=CG Sez=

This comment reflects common criticisms of Docker in certain production or enterprise environments, especially when used without discipline or when compared to more minimal, custom-built deployments. Let’s break it down point-by-point and provide a fair response or rebuttal where appropriate:

“More fragile long-term”
Concern: Docker can abstract too much or add complexity layers that obscure problems until they break in production.

Response:

True in poorly managed environments. But when used with proper CI/CD, version pinning, monitoring, and health checks, Docker can increase long-term stability by making environments reproducible and easier to migrate.

Fragility typically comes from poor image hygiene, outdated dependencies, or misconfigured orchestration—not from Docker itself.

“More human hours to maintain (therefore more expensive)”
Concern: Containers can drift from host realities or require DevOps knowledge to manage images, registries, etc.

Response:

This can be true if you're constantly reinventing your container stack or lack automation.

But in practice, Docker allows you to automate infrastructure, use immutable builds, and share standardized environments—reducing devops time over the long run if done correctly.

“Harder to optimize (e.g., with Varnish) for scalability”
Concern: Container networks and abstraction layers may interfere with advanced caching or network-level optimization.

Response:

Docker can introduce additional layers, yes—but these are controllable. Varnish and other edge caches work fine with Dockerized apps if network planning is intentional (e.g., exposed ports, static IP mapping, reverse proxies).

Kubernetes and Docker Swarm can actually improve scalability when paired with ingress controllers or service meshes.

🔸 “Costs more to scale”
Concern: Docker may incur higher overhead or force use of orchestration systems like Kubernetes, which require expertise and infrastructure.

Response:

This can be true for small/simple apps deployed on bare metal or a single VPS.

For complex/multi-service systems, Docker reduces costs by enabling modular scaling, container reuse, and dynamic provisioning.

With tools like Docker Compose, scaling dev/test/staging environments is extremely cost-effective.

🔸 “Enormous security risks”
Concern: Containers can expose hosts if improperly isolated, especially with root containers or insecure base images.

Response:

Valid if you run as root, don’t scan images, or allow unchecked container interaction.

However, Docker can be more secure than traditional VMs if you use:

Non-root containers

Read-only filesystems

Image scanning (e.g., Trivy, Clair)

Minimal base images (e.g., Alpine)

Namespaces and seccomp profiles

Docker - Revision history

Marcin: /* CG Sez */