In this blog Martijn Wallet, our Manager Consultancy and Training, discusses what containerization is, what the pros and cons are and when it's better to stay away from it.
A container is a logical packaging mechanism that allows applications to be separated from the environment in which they are run. All code, configurations and dependencies are packaged as a unit so that the application can run quickly and reliably, without dependence on the environment, whether on-premise, public or private cloud, or even bare-metal. Because you can run multiple containers directly on the operating system, the setup is a lot simpler than that of a virtual machine. Thanks to container orchestration platforms, such as Kubernetes, clusters of containers are automatically launched and their lifecycle is managed. This makes it a lot easier to roll out containers on a large scale. Without such platforms, containerization would not have taken off.
Driving factors for containerization
Ever since 1960 we have seen a movement towards virtualization and abstraction, such as COBOL and Java Application Servers, but also the emergence of virtual machines. Nowadays we see more and more born-in-the-cloud applications, serverless microservices that are rolled out within a serverless architecture, and also cloud-native technology is completely hot. The abstraction of apps from operating system and infrastructure brings unprecedented agility and flexibility. Moreover, containers launch much faster than virtual machines and are more scalable. Not to mention the cost savings in the application lifecycle and the much lower hypervisor license costs. Container platforms are standard open source platforms, which is by no means always the case with VM platforms. From the point of view of the developer and the DBA, a big advantage is that containers run exactly the same in both the development environment and in production.
Working with database containers also has some challenges. Databases require a lot of bandwidth and low latency, and Docker - the framework with which you can package an application in a container - does not offer this standardly. Large amounts of disk space make database containers less agile and more difficult to move. Databases are standard stateful and durable, containers are stateless and ephemeral and, finally, databases have many - dynamic - configuration parameters. However, the latter is also a challenge with virtual machines. Configuration drift is namely a common problem on virtual machines.
Containerized databases are characterized by a number of things. These are mainly small databases that fit a microservices architecture. In combination with an orchestration platform, they are equivalent to existing clustering solutions for databases. Their elasticity offers more flexibility, compared to costly planning the capacity planning beforehand. By separating storage from processes, you are dealing with independent storage performance and capacity. Software-defined containerized databases are currently often still the missing link for fast DevOps cycles. When containerized databases are sufficiently embraced, there will be a seamless collaboration between development and operations.
Virtualization versus containerization
- Virtualization maximizes resource utilization, containerization maximizes security and flexibility.
- Virtualization has a lifecycle from months to years, containerization has a lifecycle from minutes to days.
- With virtualization you deal with vMotion VMs between hosts, with containerization the pod-placement is managed by container-orchestration platforms such as Kubernetes.
- Virtualization has a slow start-up, containerization starts up very quickly.
- Virtualization supports Windows and Linux, containerization is mainly a Linux technology.
- And finally ... virtualization offers advantages for IT Operations, containerization for the end user and his application.
What good is containerization?
Containerization supports microservices and CI/CD pipelines with multiple instances, such as Dev, Test and Prod. It maximizes security and enables automatic scalability. Containers are the (multi-) cloud. It makes it easier to streamline software updates and to disable virtualization (VMWare, KVM, RHEV, etc.). Thanks to containerization we can treat databases as replaceable and minimize the impact of downtime.
In which case does it take effort to opt for containerization?
There are both technical and human reasons why it can be difficult to choose for containerization. If you are dealing with monolithic applications or support of legacy applications, containerization is less suitable. Containerization will result in larger numbers of database instances that can scare you off because of a higher number of outages. A more traditional mindset and the comfort zone can be human obstacles to opt for containerization.
Want to know more?
Want to know more about containerization? Feel free to contact us, we like to think along with you.
More interesting blogs about this subject: