New SAP solutions are mostly built on containers. Does this make sense, and what are some common use cases associated with container technology?
Adopting new technologies follows the same pattern in all companies. A group of evangelists see the new technology as the ultimate answer to every problem, conservatives see some potential with many downsides. The developers have to live with the unintended consequences.
For a few years now, new SAP solutions have mostly been built on container technology. The goal of this article is to look at use cases and what could go wrong.
Containers
A container feels like a small-scale Linux operating system with an application installed. Such a container is delivered as a file image and runs on a host computer as a virtual server. In contrast to VMware-like virtual machines – where even the operating system itself is part of the image – the container’s operating system is just redirecting the system calls to the host computer.
As a result, the application performance inside a container is identical compared to installing the application directly on the host computer, which is not true for virtual machines.
Rule #1: Do not install software, deploy containers
One view of containers could be that it is a very convenient way of installing software. It is a matter of seconds. The command “docker pull imagename:latest” installs the software, the command “docker run imagename” starts it. Way simpler than running a custom installer, where you have to wait half an hour for it to complete the task, and then wonder why the installation worked on one server but not the other. Everybody who installed a larger software package can relate, I assume.
Example: To install Hana, a command line tool exists, but also a docker image. With the command line tool, the prerequisites of the server need to be met, the installation allows for many different options and takes 30 minutes. In contrast, the docker image just works.
Rule #2: No configuration information in the container
One consequence of the aforementioned instances is that all configurations need to be done at container start. The container image itself is user and customer agnostic. The concept of containers goes even further than that: it always starts with the same image files. In other words, all changes made within the running image are lost as soon as the image is shut down.
Example: The container image is a webserver, the webserver writes logs and when the image is shut down, all created log files cease to exist. That is the reason why a Hana image asks to create a directory on the host server and mounts the directory into the image at the start. When Hana creates the database and the tables, it writes into the same directory within the image as before, but because it is mounted, the changes are actually made in the host file system.
Rule #3: Isolation
An important aspect of containers is the intrinsic security this model provides. Everything a container should do is either inside the container itself or done by calling other network services.
All containers work 100 percent independently from each other; they do not even know of each other. An SQL application container can execute a select statement against a Hana database and this database might be another container. It should never use low-level calls to bypass the container isolation.
Rule #4: Container size
One important break point to watch out for is the container size. An increasing size of a container has multiple negative side effects.
There is security: The more services a single container exposes, the larger its attack surface becomes. A container should expose a single service only, if possible.
Examples: A webserver container exposes one network port. The Hana container should only expose the SQL port.
Summary
Concerning containers, I seem to be more on the evangelist side. Yes, containers should be used for every service because at least the installation is much easier – if nothing else. They have no performance downside, are easier to manage and upgrade. However, as shown, there are some things that can go wrong during the implementation.