Containers are often synonymous with microservices. This is due to their lightweight properties, containing only a minimal operating system and the exact libraries and components needed to execute a specific piece of business functionality. Therefore, applications, whether designed as new or a broken down monolithically, will be designed to contain exactly what is needed, with no additional overhead to slow down the processing. Microservices are made to be small and perform specific business functionalities, which are often designed by different teams, but deployed at the same time. Therefore, a small team could develop a specific service using containers, with their desired programming language, libraries, API implementation style, and scaling techniques. They are free to deploy their business function, via a container push to the registry and a CICD deployment without impacting any other service in the mesh of interacting services. Alternatively, other small teams could develop their own services, using their own style, and not have to worry about anything about the API of the other services.

The use of containers for microservices works well for keeping small groups agile and moving fast. It also allows for the architecture standards board to implement guidelines that all services must follow without impacting the agility of the design team. For example, a logging framework, security approach for secrets, orchestration layer, and the CICD technology could be mandated but the programming languages would be open to what the team wants to use. This would allow the composite system to be managed centrally and each service to be designed individually.