Database Containerization Platform Checklist
Containers are lightweight, fast and agile, and solve all dependency issues related to the applications. With such benefits, why aren’t we using containers for stateful apps? It certainly isn’t because of vendors not certifying their applications on containers. Oracle supports its RDBMS on LxC containers, while its entire middleware stack is available as Docker containers. Containerized DataStax Cassandra, Postgres, MySQL, Hadoop and many others have all been successfully deployed on various clouds, using various general purpose orchestrators. Why, then, haven’t containers gained mainstream adoption for stateful apps?
Stateful Applications are Like Pets
Most container platforms treat stateful apps just like stateless, often focusing just on initial provisioning, scale or failover. Unfortunately, to use the cattle-versus-pets analogy, stateful apps including databases, Hadoop, ELK and others are pets and not cattle. This means losing an instance of a database can lead to data loss; scaling them out is not simple; and restoring does not imply simply bringing up another instance on a different host. Containers were designed to simplify application development and deployment; hence, container platforms need to ensure that their solutions indeed address all aspects of application management, including consolidation, data management, node failures, scaling out (add instances) and scaling up (add resources).
Another aspect to stateful apps is predictable performance. This directly relates to storage, and the IOPS delivered by the storage volumes per container. Most container orchestrators either do not understand storage or indirectly deal with it via storage plugins. Unfortunately, this arms-length approach gives you limited control over data and IOPS and forces you to use expensive and archaic SAN storage arrays.
Making the Right Container Platform Choice for Stateful Applications
Based on the discussion so far, selecting a container platform that is right for stateful applications seems rather challenging. So to simplify the task, here is a checklist of features to look for in a modern application containerization platform:
| NO. | FEATURES | DETAILS |
| 1. | Multiple Container Formats | Support multiple container formats such as Docker, rkt, LxC and VM formats such as VMware and KVM for special cases. The application dictates the container format to use, not vice versa. Docker works for modern applications, while for traditional apps such as Oracle and SAP—which require ssh access or the ability to do in-place patching—LxC is a better choice. VMs would be required for cases that require changes to kernel parameters. |
| 2. | Application-Awareness | For long, application administrators have dealt with servers, storage, virtual machines, network switches and other technologies.
The next generation platform should be about applications and make infrastructure invisible. This includes all activities including provision, scale, backup, clone and failover. |
| 3. | Storage Volume Management | Provide in-built support for storage and volume management. This includes creation of multiple volumes per container, of different media types (SSD, HDD, Flash), with different levels of data protection, and also auto repairing any disk failures. |
| 4. | Snapshot, Clone, Time-Travel | Storage vendors typically provide these capabilities at the volume level, but this still leaves a lot to be done for the application administrators.
A modern platform should take into consideration that an application is comprised of multiple containers, and each container can have multiple volumes, each of different type and size. Ability to snapshot, clone and restore should seamlessly work across the entire application. |
| 5. | App-to-Spindle Quality of Service (QoS) | Predictable performance is key for stateful applications, especially when trying to achieve higher levels of consolidation.
While containers give you process isolation, the modern platform should provide performance isolation—all the way across compute, network and storage via mature QoS policies. QoS will allow you to run clusters with different load profiles and criticality all on the same infrastructure without impacting each other. Imagine running prod and test databases on the same server without impact. This is key to achieve consolidation goals. |
| 6. | As-Is Auto Failover | Unlike stateless applications, a failed container simply cannot be replaced with another container with a different IP address and volumes. Each node in a stateful app is critical, and a failover mechanism needs to ensure that a node, when recovered, has the same identity, data and configuration. |
| 7. | Networking | Network configuration is a vital function and can easily derail any application automation effort. Imagine having to contact your network admin for a static IP every time you deploy an app.
Modern platform should support features such as default DNS, IP-per-container, multiple subnets, VLAN tags, etc. Without network automation, your container story will easily fall apart. |
| 8. | Multi-tenancy support | Unless your cluster deployment is localized to a single team, most enterprises would like to use the same platform across multiple divisions. This implies support for multiple user tenants and the ability to choose between hard (dedicated) and soft (shared) isolation of resources. |
| 9. | Ease of Setup & Management | Last but not the least, the modern platform should be easy to deploy, patch, upgrade and back up. It should use a simple, single binary that includes all required packages.
It should also provide resiliency and HA by default. You only add unnecessary complexity by deploying numerous unrelated packages that follow their own update cycles. |
Containers are the right technology to use to achieve objectives, but they need to be tightly meshed, like connected gears that drive a machine, with appropriate storage, networking and orchestration (application and infrastructure) solutions—thus allowing administrators to focus just on the application while making infrastructure invisible. Simply taking a bunch of components and connecting them with volume or network plug-ins will not suffice and would only deliver a sub-optimal experience.
About the Author / Adeesh Fulay
Adeesh Fulay is Director of Products at Robin Systems. Prior to this he was a Product Line Manager, a Sr. Engineering Manager at VMware (IaaS & Software Solutions). He has also held positions at the director level at Oracle America where he introduced new Data Cloning feature ‘Snap Clone’, which enables creating space efficient copies of terabyte size databases in a matter of minutes. Prior to Oracle he was a Senior Professional Services Consultant at mValent Inc (acquired by Oracle America). Connect with Adeesh at LinkedIn and Twitter.