Discussion More Information • Sidecar Example • Design Patterns for Container-Based Distributed Systems • Prana: A Sidecar for your Netflix PaaS-based Applications and Services • Tin-Can Phone: Patterns to Add Authorization and Encryption to Legacy Appli‐ cations • The Almighty Pause Container 134  |  Chapter 15: Sidecar Previously we said that container images are like classes, and containers are like the objects in object-oriented programming (OOP). If we continue this analogy, extend‐ ing a container to enhance its functionality is similar to inheritance in OOP, and hav‐ ing multiple containers collaborating in a Pod is similar to composition in OOP. While both of these approaches allow code reuse, inheritance involves tighter cou‐ pling between containers and represents an “is-a” relationship between containers. On the other hand, a composition in a Pod represents a “has-a” relationship, and it is more flexible because it doesn’t couple containers together at build time, giving the ability to later swap containers in the Pod definition. On the other hand, composi‐ tions in Pods mean you have multiple containers (processes) running, health checked, restarted, and consuming resources as the main application container does. Modern  Sidecar  containers are small and consume minimal resources, but you have to decide whether it is worth running a separate process or whether it is better to merge it into the main container. From a different point of view, container composition is similar to aspect-oriented programming, in that with additional containers we introduce orthogonal capabilities to the Pod without touching the main container. In recent months, use of the  Sidecar pattern has become more and more common, especially for handling networking, monitoring, and tracing aspects of services, where every service ships  Sidecar  con‐ tainers as well.