Moisés Navarro, Business Solutions Strategist para VMware Iberia
La frase no es mía, es de Kelsey Hightower (alguien a quien seguir por sus valiosas opiniones). Originalmente, en 2015, no se refería específicamente a Kubernetes, sino que aludía al contexto tan vertiginoso que había en ese momento alrededor de containers y plataformas de gestión de containers.
Por supuesto todavía a día de hoy seguimos inmersos en una vorágine, pero el vórtice se ha desplazado.
En la capa de container, las librerías de docker son las más usadas, aunque en la capa de runtime hay movimiento vía proyectos alternativos como CRI-O de Red Hat; gVisor de Google; Photon OS y vSphere Integrated Containers, ambos de VMware, que ofrecen las librerías de docker pero proponen diferentes capas de ejecución con la promesa de ser más estables, más seguras…
En cuanto a orquestación de contenedores se refiere, parece no haber mucha discusión: se hace con Kubernetes.
Para la capa de orquestación de containers, hay dos formas de consumir Kubernetes: o bien se consume on-premises o bien se consume en nube pública. Ok, nada nuevo.
Decíamos, en todo caso, que la vorágine continúa pero el centro de gravedad se desplaza, y es que a día de hoy esa vorágine está en el elevado número de proveedores que ofrecen Kubernetes porque, en plena fiebre del oro, ¡ay de aquel que no tenga una o incluso varias ofertas que incorporen Kubernetes!
Para el modelo on-premises hay muchas opciones disponibles. Considero que es una buena noticia para el usuario que exista esa amplia oferta (siempre conlleva una complejidad en análisis y selección, pero ¡mejor tener donde elegir!).
VMware aporta valor a los despliegues on-premises de Kubernetes de dos maneras. Una primera vía es a través de los módulos de VMware para infraestructura definida por software (cómputo, almacenamiento, red y seguridad) y a través de los módulos de gestión (monitorización de aplicaciones, automatización de operaciones…). Una segunda vía se basa en un empaquetamiento orientado al entorno empresarial bajo la figura de VMware Pivotal Container Service.
Se le conoce como PKS, e integra Kubernetes con otros proyectos open source como Kubernetes on BOSH(que juega un papel clave en la automatización del aprovisionamiento y en operaciones de día-2 como actualizaciones, auto-reparación, auto-escalado…), Harbor (registro de containers para uso empresarial por capacidades de gestión y seguridad) y Hatchway (almacenamiento persistente para containers). Y también integra la solución de VMware para software-defined networks (SDN), en este caso NSX-T Data Center.
Y de manera más reciente sí se ha visto una vez más el efecto de “fiebre del oro” con la secuencia de anuncios de servicios cloud ofreciendo Kubernetes as a Service.
Aquí tenemos un baile de acrónimos como GKE, EKS, AKS, donde VMware contribuye con VKE.
VMware Kubernetes Engine (VKE) es un servicio basado en suscripción para consumir clusters de Kubernetes. Arranca sobre AWS en diferentes zonas de disponibilidad en EE.UU. y Europa, y está previsto que también tenga presencia en Azure.
Aquí tenemos ya una primera diferenciación con respecto a los otros servicios citados anteriormente. Cada uno de ellos se centra en ofrecer Kubernetes en su nube; en el caso de VMware, ofreceremos ‘k8s aaS’ desde varias nubes, por lo que el cliente mantendrá la experiencia de consumo y gestión independientemente de la nube en la que decida desplegar.
Además de ser una diferenciación de VMware, liga con un tema bastante caliente en este momento: ¿se convierten en multicloud las aplicaciones por el mero hecho de correr sobre Kubernetes? Yo creo que la respuesta es ‘no’ para la inmensa mayoría de las aplicaciones que a día de hoy, aunque Kubernetes se pueda encontrar en muchas nubes, porque casi siempre se acaba haciendo uso de funcionalidades de las capas que hay por debajo de Kubernetes y eso resta movilidad a la aplicación.
Pero, el principal motivo de no ser multicloud por el mero hecho de correr sobre Kubernetes es porque el modelo de operaciones de Kubernetes no es igual en función de la nube en la que resida (sea en nube privada o en cualquiera de las múltiples nubes públicas con oferta de Kubernetes). Y es que la portabilidad de una aplicación es más que mover binarios entre entornos compatibles.
(Tomo nota; puede ser asunto a abordar en el blog)
Por eso, esa abstracción adicional que aporta VKE aporta su granito de arena en el camino hacia multicloud para aplicaciones. Muy recientemente hemos publicado en este blog sobre multicloud. Por si es de interés del lector: ‘¿Cómo puede VMware ayudar a sus clientes a superar la complejidad de los entornos multicloud?’ y ‘A vueltas con multicloud’).
Sin duda VKE trae algunas bondades más, que son también diferenciadoras.
Para empezar, abordar algo que los clientes deben tener muy en cuenta: esas aplicaciones (esos microservicios) que se quieran desplegar sobre Kubernetes no siempre cubrirán por sí solos todo lo que el servicio que implementan necesita. Ya hemos dicho en este blog que los proveedores de nube pública innovan mucho y muy rápido, y los clientes quieren (necesitan) hacer uso de esas innovaciones. De ahí que VKE se integra con los servicios nativos de alto valor añadido presentes en AWS para aportar así mayor valor a los clientes.
Cuidado, que nadie se lleve luego sorpresas innecesarias. Esos lazos desde nuestras aplicaciones a los servicios nativos de un proveedor de nube pública restarán movilidad a esa aplicación. Y eso pasará porque así lo quiere el cliente, dado el altísimo valor aportado por el servicio nativo del proveedor.
Bien; aclarado esto, vamos a por más capacidades diferenciadoras.
Operaciones.
Repito: operaciones.
Ay, que me lanzo: ¡OPERACIONES!
Sí, ya no nos da vergüenza decir bien alto ‘operaciones’. Ya no se nos tildará de poco modernos por levantar la mano y defender la importancia de las operaciones. En VMware España decidimos instaurar el 12 de enero como el día del “orgullo legacy” (porque “todos comemos del legacy”, seamos organizaciones con más o menos tiempo en nuestra actividad de negocio, seamos más o menos digitales, el core es nuestro legacy); así que también tendremos que buscar día para celebrar el “orgullo operacional”.
Y es que nuestros clientes saben de primera mano, basándose en la experiencia real, que las operaciones son vitales; ya sea para eso entornos que llamamos tradicionales, o para entornos nativos en cloud, o para entornos digitales, o…, o… Sea cual sea el entorno, las operaciones son vitales.
Desde el punto de vista del ciclo de vida de la aplicación, el cliente tendrá disponible sus clusters de Kubernetes en menos de 90 segundos. El cliente también tendrá a su disposición capacidades para monitorizar y operar el rendimiento y salud de las aplicaciones. Y todo ello aprovechando la automatización que hay por debajo, disfrutando de cifrado de datos tanto estáticos como en movimiento, elementos con versiones y parches actualizados, aislamiento entre entornos… sin necesidad de abordar esa gestión y su mantenimiento por parte del cliente.
Desde el punto de vista de gestión y operación de la plataforma, el cliente no necesita conocimientos de Kubernetes, y no obstante disfrutará de una plataforma que realiza de manera automatizadacomprobaciones del estado de los clusters de Kubernetes para tomar acciones de remediación cuando sea necesario, incluso reconfigurando tamaños (up-scaling / down-scaling de manera automatizada) en función de lo que demande la aplicación, y llegando incluso a aprovechar nuevos modelos de instancia de infraestructura que vaya anunciando AWS EC2. Todo esto redunda en un mejor rendimiento al mejor coste… sin que haya que abordar una operación por parte de cliente.
Intensa esta fiebre del oro de Kubernetes, ¿verdad?
