For distributed development in SAP, ABAP developers would require their own SAP systems.
Containers are a way of solving this infrastructural challenge. Containers sit on top of a physical server and its OS and share the kernel, binaries and libraries whereas VMs require their own OS. They are exceptionally “light” and startup very quickly.
Figure: Docker is by far the most popular containerization platform.
Two examples of possible uses of Containers within SAP:
1. Multiple development systems can be created, and the code refreshed from a Git repository.
2. A QA system container image could potentially be quickly deployed multiple times to create sprint team test systems.
A Volume is where Containers store permanent data. This might be a folder, an Amazon volume or something else. You would typically not want any part of the application to be in volumes, only the permanent data.
Volumes typically live longer than the containers and can be shared by multiple containers.
In the context of SAP, an SAP system could use a volume for the database, another for the transport files and another for the logs. Or put all permanent data in a single one. As such, it would be perfectly fine to stop the container, delete it and start a new one with the same volumes (i.e. to change port mapping, upgrade,…). If properly done the instance would barely notice.
An Image is a blueprint for a container, and contains every file it needs to run except permanent and volatile data.
A stateless application, like a web application, can be replicated from an image almost instantly, and will run independently from each other.
Images can be stored in repositories and downloaded/upgraded as needed.