Why (not) Containers?

Why?

1. Containers serve as commonly agreed upon deployment unit between Dev teams and Ops teams. This eliminates the possibility of missing artifacts when a Dev team hands over a program to the Ops team for deployment.
2. Containers allow Dev teams to package any software required by the program to be deployed. This eliminates the need to provide a list of required software to the Ops team when providing the program for deployment.
3. Containers allow Dev teams to test the deployment of programs independent of the Ops team and the actual deployment environment.
4. Containers allow Dev teams to test the program as a deployed unit independent of the Ops team and the actual deployment environment.
5. Containers allow Dev teams to decide how the program uses the available resources without worrying about interference from other programs, e.g., conflicting environment vars, conflicting file locations.
6. Containers allow Ops teams to manage the deployments by treating deployment units as black boxes (with very few constraints).
7. Containers allow Dev teams to use a rich set of tools to define applications (= program + required software) and build container images for deployment. [See Cloud Native Landscape]
8. Containers allow Ops teams to use a rich set of tools to deploy and operate containers. [See Cloud Native Landscape]
9. Specification (Code) and tools enable automation of tasks associated with packaging, deployment, and operation of containers. This enables automatic detection of issues; possibly before execution of the tasks.

Why not?

1. Dev teams have to deal with installation nuances associated with software required by their program.
2. Dev teams have to identify and provide resource requirements along with deployment units, e.g., compute, memory, storage capacity, storage bandwidth.
3. Ops teams have to ensure optimal resource utilization in the data center while satisfying the resource requirements of the deployed units.
4. Ops teams have to manage/eliminate interference between containers via the shared host (execution) environment.
5. Specification/Code and tools enable automation of tasks associated with packaging, deployment, and operation of containers. This amplifies issues due to incorrect specification/code.

How has container technology influenced software development?

The evolution of cloud computing from resource renting to container-driven automation has clearly influenced how we develop and deploy software.

The primary factor driving this influence is the specification/codification of requirements and tasks associated with packaging, deployment, and operation of containers. This factor has reduced ambiguity by the adding rigor in the form of structure/syntax and semantics to the information exchanged between Dev teams and Ops teams. The resulting clarity and precision has expedited the identification and fixing of issues in both process and practice. In turn, this has helped improve the last leg of the software development process.

In short, container technology has served as a tool to help with process management in software development.

While the above opinions are informed, they may be flawed, limited, or might have overlooked some aspects. If so, please point out the flaws, limitations, or overlooked aspects by leaving a comment.

P.S.: I have (ab)used the term “containers” to mean the current container technology and the execution entities. Sorry!

[Originally posted here.]