Cloud Foundry en transición
Durante muchos años, el término Cloud Foundry ha sido sinónimo de una tecnología lista para la producción que permite crear grandes plataformas de aplicaciones. La experiencia "cf push" que se asocia indisolublemente a Cloud Foundry es una característica clave de esta tecnología.
Proporciona a los desarrolladores una interfaz cómoda para operar sistemas de aplicaciones por su cuenta. Al mismo tiempo, Cloud Foundry también permite a las grandes organizaciones operar de forma eficiente (Bosh) y establecer estándares corporativos (Buildpacks).
Mientras que la experiencia del usuario a lo largo de los años con un nivel relativamente alto de uniformidad y estabilidad favoreció la adaptación de la tecnología en grandes corporaciones, el funcionamiento interno de Cloud Foundry se encontró en constante cambio. Cuando surgieron las primeras conversaciones en torno a la combinación de Kubernetes con Cloud Foundry, la integración de Kubernetes como orquestador de contenedores era una opción obvia.
Sin embargo, la unión de Kubernetes y Cloud Foundry va más allá y no termina con la gestión de contenedores de aplicaciones. Para ilustrar las implicaciones, recuerde que la independencia de la infraestructura, la estabilidad y -para entornos grandes- los bajos gastos operativos no provienen de Cloud Foundry en sí, sino de su tecnología hermana Bosh.
Bosh es una tecnología poco utilizada e infravalorada que hace que la orquestación de máquinas virtuales con estado sea tan sistemática y fiable como Cloud Foundry lo es para los sistemas de aplicaciones sin estado.
La interfaz de usuario, sin embargo, es mucho menos sencilla y requiere cierta familiarización. Por tanto, con la llegada de Kubernetes, en un principio era concebible que la pila de Cloud Foundry no tuviera que cambiar mucho. El funcionamiento podría continuar con Bosh y Kubernetes se integraría como programador de contenedores (proyecto Eirini).
El tremendo impulso de Kubernetes no se detiene en la ejecución de aplicaciones sin estado, como mantiene Cloud Foundry. Con la introducción de StatefulSets, Kubernetes también es capaz de gestionar cargas de aplicaciones con estado.
Esto aumenta las aspiraciones de los antiguos entusiastas de OpenStack, que sueñan con una interfaz libre y estandarizada para orquestar infraestructuras virtuales (VM). La esperanza es que Kubernetes evolucione hacia esta tecnología genérica y se abstraiga así de las API de infraestructura imperativas y propietarias de los proveedores de nubes tanto públicas como locales.
El entusiasmo por ello es tan grande que, con fe inquebrantable, la gente también acepta desventajas, como el aislamiento significativamente menor que traen consigo los contenedores en comparación con las máquinas virtuales. Una desventaja que puede manifestarse en la coubicación de bases de datos en un nodo Kubernetes a través de interferencias mutuas.
Por tanto, no es de extrañar que Cloud Foundry siga adaptándose a Kubernetes. Un borrador de arquitectura de SAP, por ejemplo, aborda la cuestión de si un entorno Cloud Foundry basado en Kubernetes podría mapear los grandes entornos de la pila clásica 1:1, y más bien lo cuestiona. Las limitaciones por ambas partes son demasiado grandes.
En lugar de promover la gigantomanía de los entornos individuales, la atención se centra más bien en el federalismo. Separar el plano de control de Cloud Foundry, compuesto por la API y la interfaz de usuario, del subsistema de contenedores (Eirini) podría contribuir a hacer más esbeltos los entornos de Cloud Foundry y, por tanto, a reducir la barrera de entrada para los pequeños entornos de CF. Un Plano de Control de Cloud Foundry podría entonces, por ejemplo, servir a muchos clústeres Kubernetes o a diferentes clústeres Kubernetes con tareas dedicadas.
El tiempo dirá qué enfoques arquitectónicos se aplicarán y en qué medida serán adaptados por los usuarios. El arquitecto piensa, el usuario dirige. En cualquier caso, hay cambios apasionantes que observar.
