In the world of cloud computing, containers are not only a popular way to achieve cloud native architectures, but they are quickly becoming the standard with which to design microservices. However, there are some use cases where containers are not always suited, specifically using containers for multiple concerns. The concept of concerns, or focus areas of a component, is that each module or class should have responsibility over a single part of the functionality. In the case of containers, multiple concerns would mean having a web server and database running in the same container. Following the services approach, breaking down monoliths into discrete components will ensure the applications have a lower blast radius and are easier to deploy and scale independently. This is not to say that a container should only have a single thread, but that it should have only a single role. There are ways for containers to share persistent disks and intercommunicate, but putting multiple components or concerns on the same container is not the right way. Simply put, containers are not virtual machines.

Treating containers as virtual machines is not limited to deploying multiple concerns into a single container. Allowing SSH daemons (or other types of console access) on a container defeats the purpose of the container in the first place. Since containers are a discrete component, they should be set up, configured, and have their code deployed as part of the initial development phase. That in turn becomes the deployment artifact which is pushed to the repository and deployed via the orchestration tooling used. Allowing direct console access to the container means that modifications can be made, the container is no longer an immutable component, and the consistency of the contents can no longer be trusted. Instead, if the container needs an update due to a bug or enhancement, that should be done to the base container, tested through proper channels, and pushed to the repository for deployment.

If the application requires multiple concerns or SSH access, consider using cloud-instance virtual machines instead of containers. Alternatively, to become more cloud native, work on the application to decouple it or enhance the CICD pipeline to allow for faster and more consistent deployment processes.