Why is it common to use the principle 'one container = one process' in microservice architecture?

This simplifies the management of the lifecycle of the process and container. Each container becomes an atomic unit of deployment and scaling. If only one process runs inside the container, stopping the container guarantees stopping the entire process, and vice versa. This reduces the complexity of monitoring and debugging, as metrics and logs are tied to a specific container and process. It also increases isolation, preventing the impact of a failure of one process from affecting others within the same container.

Example of a Kubernetes manifest for a service with a single container per pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-single-process-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-service
  template:
    metadata:
      labels:
        app: my-service
    spec:
      containers:
      - name: main-app
        image: my-repo/my-service-image:latest
        ports:
        - containerPort: 8080

This approach aligns with the microservices philosophy, where each service is responsible for a specific business function and can be developed, deployed, and scaled independently.

Comparison:

Principle	Advantages	Disadvantages (for microservices)
One container = One process	Simplicity of isolation, management, scaling, monitoring	Slightly higher overhead for container startup
One container = Multiple processes	More efficient resource utilization (if processes are closely related)	Complexity of isolation, management, scaling, monitoring