Let's go up one abstraction layer from containers. Containers include everything required to run specific services as stateless, self-contained artifacts. However, the containers need to be orchestrated to run in the correct network, being able to communicate with other services and being started with the correct configuration, if required. The straightforward approach is to develop home-grown scripts that run the required containers. However, in order to realize a more flexible solution that also enables production-readiness such as zero-downtime, the use of container orchestration frameworks is advisable.
Container orchestration frameworks such as Kubernetes, DC/OS or Docker Compose are not only responsible to run containers, but to orchestrate, connect and configure them appropriately. The same motivations and principles apply that are true for container technologies as well: automation, reproducibility and IaC. Software engineers define the desired target state as code and let the orchestration tool reliably setup the environments as required.
Before going into a specific orchestration solution, let's have a closer look at the rough concepts.
Orchestration frameworks enable us to connect multiple containers together. This usually involves service lookup using logic names via DNS. If multiple physical hosts are used, the framework resolves IP addresses over these nodes. Ideally an application running in a container just connects to an external system using a logical service name that is resolved by the container orchestration. For example, a car manufacturing application using the vehicle database connects using the vehicle-db hostname. This hostname is then resolved via DNS, depending on the environment which the application runs in. Connecting via logical names reduces the required configuration in the application code, since the configured connection is always the same. The orchestration just connects the desired instance.
This is true for all offered systems. Applications, databases, and other servers are abstracted to logical service names which are accessed and resolved during runtime.
Configuring containers depending on their environment is another aspect that orchestration frameworks solve. In general it's advisable to reduce the required configuration in applications. However, there are cases where some configuration effort is required. It is the framework's responsibility to provide container configuration by dynamically injecting files or environment variables depending on the circumstances.
The production-readiness features that some of the container orchestration frameworks offer represent one of their biggest advantages. Ongoing development of an application triggers new project builds and result in new container image versions. The running containers need to be replaced by containers that are started from these new versions. In order to avoid downtime the container orchestration swaps the running containers using a zero-downtime deployment approach.
In the same way, container orchestration makes it possible to increase the workload by scaling up the number of container instances. In the past, certain applications ran on multiple instances simultaneously. If the number of instances needed to be increased, more application servers had to be provisioned. In a container world the same goal is achieved by simply starting more of the stateless application containers. The developers increase the configured number of container replicas; the orchestration framework implements this change by starting more container instances.
In order to run containers in production some orchestration aspects have to be considered. Experience shows that some companies tend to build their own solutions rather than using de facto standard technology. However, container orchestration frameworks already solve these issues well and it is highly advisable to at least consider them.