What are the motivations behind containers, container orchestration, and cloud environments? Why do we see such momentum in this area?
Traditionally, enterprise application deployment worked something like the following. Application developers implemented some business logic and built the application into a packaged artifact. This artifact was deployed manually on an application server that was managed manually as well. During deployment or reconfiguration of the server, the application usually faced a downtime.
Naturally, this approach is a rather high-risk process. Human, manual tasks are error-prone and are not guaranteed to be executed in the same manner each and every time. Humans are rather bad at executing automated, repetitive work. Processes such as installing application servers, operating systems and servers in general, require precise documentation, especially for future reproducibility.
In the past, tasks for operation teams typically were ordered using a ticket system and performed manually. By doing so, installation and configuration of servers held the risk of transforming the system into a non-reproducible state. Setting up a new environment identical to the current one required a lot of manual investigation.
Operational tasks need to be automated and reproducible. Installing a new server, operating system or runtime should always execute in exactly the same manner. Automated processes not only speed up the execution but introduce transparency, revealing which precise steps have been executed. Reinstalling environments should produce exactly the same runtime including all configuration and setup as before.
This also includes deployment and configuration of the application. Instead of manually building and shipping applications, Continuous Integration servers are in charge of building software in an automated, reliable, and reproducible way. CI servers act as golden source of truth for software builds. The artifacts produced there are deployed on all involved environments. A software artifact is built once, on the Continuous Integration server, and then verified in integration and end-to-end tests, until it ends up in production. The same application binary that is deployed to production is therefore reliably tested upfront.
Another very important aspect is to be explicit in the software versions that are being used. This includes all used software dependencies, from the application server and Java runtime, down to the operating system and its binaries. Rebuilding or reinstalling software should result in exactly the same state each and every time. Software dependencies are a complex subject which comes with a lot of possibilities for potentials errors. Applications are tested to work properly on specific environments with specific configurations and dependencies. In order to guarantee that the application will work as expected, it is shipped in exactly that configuration that has been verified before.
This aspect also implies that test and staging environments which are used to verify the application's behavior should be as similar to production as possible. In theory this constraint sounds reasonable. From experience the used environments vary quite a lot from production in terms of software versions being used, network configuration, databases, external systems, number of server instances, and so on. In order to test applications properly these differences should be erased as much as possible. In section Containers we will see how container technology supports us here.