Al iniciar en el terreno de Containers lo primero que buscamos es utilizar esta herramienta para ejecutar todo lo referente a Stateless, o en síntesis el/los cliente de la base.
Tuvimos un tiempo donde la base era una gran caja en algún lugar. A medida que confiamos en la virtualización trasladamos algunas bases dentro de VMs. Dependiendo la magnitud de las aplicaciones es probable que siga habiendo una gran caja con una base de datos y varias bases más pequeñas en VMs dentro de mi ambiente. Esto es lo que vemos hoy como normal con la virtualización.
Podemos pensar en que en lugar de una VM, la Base sea un Container. Nada nos impide pensar eso. El Container puede vivir en una VM o en un server físico por igual. Dejando por un rato de lado que pasa con el licenciamiento (digamos, no sea que venga Oracle y nos diga.. ah, un container en un nodo de 4 vCPUs en Azure??.. tenés que pagar por todos los cores que tiene Azure en ese Datacenter) ejecutar base de datos en un Container pasa a ser una ejecución casi nativa, es decir si el servidor es físico funcionará como si hubiera instalado localmente en dicho servidor. (ej: SAP HANA TDI, Oracle DB Enterprise, SQL Server for Linux).
Como fuera, creemos que el mayor beneficio lo encontraremos en soluciones modernas como MongoDB o Cassandra, incluso en “sharding” de MySql con Vitess, MariaDB…o Confluent/Kafka, del cual somos parnters. Desde el punto de vista de arquitectura estas soluciones nos darán la libertad de brindar datos en Microservicios con verdadero Scale Out, pero esto requerirá un cambio mayor en nuestras aplicaciones.
Ahora bien, los datos ubicados dentro de la imagen, los filesystems montados desde ahí durante el inicio del container trabajarán en una modalidad que se llama “copy on write”, donde las modificaciones sobre esos filesystem desaparecen al eliminarse el Container. Para que los datos perduren aún cuando el Container se elimine o se re-instancie en otro nodo por decisión de Kubernetes, necesito crear volúmenes persistentes.
De la misma manera que en un Cluster tradicional de Unix/Linux/Windows en el que dos Servers comparten una LUN, deberíamos trasladar esta problemática al Container (Docker) o al Orquestrator (Kubernetes). Para facilitar esta tarea existen los plugins.
Inicialmente estos plugins residían en la herramienta de container (Docker), pero hoy la tendencia es que residan en el orquestador (Kubernetes). VMware, Nutanix, etc.. tienen plugins, pero si este plugin lo ofrece la solución de almacenamiento, nos independizamos de Hypervisor y podemos pensar en ambientes físicos o virtuales por igual.
Hay un estándar emergente y en desarrollo que se llama CSI (Container Storage Interface (CSI) for Kubernetes). Purestorage tiene un esquema de solución para integrarse con Kubernetes mediante este estándar que se denomina Pure Service Orquestrator o PSO. En un ambiente muy grande, con varios racks, varios Storage y Servers por rack, PSO ofrece la funcionalidad mediante políticas de ubicar los datos y workloads acorde a la ubicación en el datacenter. (Pure Service Orchestrator).
En nuestra búsqueda de productos para entornos de microservicios en containers, vimos a Purestorage como un aliado de valor.