Intro

¿Docker? ¿Kubernetes?

Todo el mundo hace un tiempo viene hablando de Kubernetes... hasta Dilbert:

En Chile también está de moda. Al menos podemos decir que suena moderno e inteligente, 😂 ¿Pero de qué se trata?

Contenedores 👉 Docker 🐋

Cualquier aplicación moderna debe ser posible encapsularla en un contenedor. Docker fue el pionero y es la solución que lidera la construcción y alojamiento de contenedores, pero también existen otras herramientas Podman y ConteinerD.

Un contenedor, es de modo muy básico, una alternativa a una máquina virtual. La gran diferencia es que en el caso de las máquinas virtuales, cada una necesita su propio sistema operativo (Guest OS en la imagen) y sus propios recursos de CPU y memoria RAM. Los contenedores en cambio, comparten el sistema operativo base (Host OS en la imagen), y por lo mismo, comparten los recursos de CPU y RAM. Luego un contenedor es mucho más pequeño que una máquina virtual, y eso lo hace mucho más flexible y eficiente de mantener. La siguiente imagen ilustra las diferencias entre una máquina virtual y una solución con contenedores:

Gestionar los servicios y aplicaciones con contenedores tiene sólo beneficios para la empresa. Algunos de ellos son:

• Menores tiempo de implementación y/o habilitación. ¿Se necesita desplegar la solución en otro Data Center? Bueno, con contenedores sólo debería ser cosa de minutos.
• Estandarización del ambiente entre los equipos de desarrollo. Sin contenedores cada desarrollador debe habilitar las mismas versiones de programas en su ambiente local, lo que muchas veces no ocurre. Con contenedores, los ambientes se levantan en los equipos de los desarrolladores en cosa de minutos.
• Mayor facilidad en la implementación de las prácticas de Continuous Deployment.
• En comparación las máquinas virtuales, los contenedores son más eficientes ya que comparten los recursos de CPU y memoria con la máquina base (host). Es decir, con contenedores se requiere menos costos de infraestructura.
• La estandarización de las aplicaciones en contenedores hace que sea más sencillo el uso de las herramientas de monitorización y notificaciones.
• Las aplicaciones cuando están en contenedores son más estables y resilientes, lo que les otorga confiabilidad al sistema, y por ende, tiene menor tasa de caídas o interrupciones.

Hoy en día la gran mayoría de las empresas utilizan contenedores para la administración de sus servicios y aplicaciones, por lo que se considera una tecnología mínima que todas las empresas deberían utilizar. En EEUU la adopción y migración a contenedores Docker ha crecido sustancialmente:

Orquestación de contenedores 👉 Kubernetes o K8s

Sin entrar en mucho detalle, Kubernetes es una herramienta gratuita desarrollada por Google para la orquestación de contenedores. ¿Y esto que significa? Básicamente que Kubernetes se encarga de mantener, soportar y gestionar los distintos contenedores. Luego Kubernetes será responsable de las tareas típicas que requiere la administración de contenedores, como por ejemplo:

• Reiniciar un contenedor cuando éste no responda.
• Apagar un contenedor cuando una nueva versión esté disponible.
• Escalar un grupo de contenedores cuando exista un peak de consultas.
• Asignar y administrar las IPs de los contenedores. Balanceo de carga.
• Monitorear el consumo de recursos de cada contenedor.
• Mover contenedores entre nodos cuando un nodo falla.
• Montar los volúmenes asignados a cada contenedor.
• Gestionar las variables de entorno que les corresponden al contenedor.

Y cientos de otras características que permiten otorgar confiabilidad y escalabilidad a los servicios. En pocas palabras Kubernetes es una solución moderna para la operación y administración de los contenedores. También hay otras herramientas para la gestión de contenedores como OpenShift o Docker Swarm, pero Kubernetes es las más utilizada.

Kubernetes es hoy en día un estándar y es altamente recomendable que todas las empresas lo adopten e implementen. Claramente habrá que buscar y desarrollar las capacidades para que los equipos puedan administrar esta herramienta, costos que sin duda se pagarán con sistemas más confiables y duraderos.

Migración a Kubernetes🚀

En Patagon, apoyamos a nuestros clientes en la migración de sus sistemas a contenedores y Kubernetes. Típicamente el servicio se desarrolla en 4 fases:

1. Discovery. Análisis de solución actual y levantamiento de información.
2. Diseño de propuesta de solución según los objetivos definidos.
3. Desarrollo y testing. Migración de aplicaciones a contenedores.
4. Implementación, puesta en marcha y capacitación. Monitoreo y soporte inicial.

Discovery 🔎

La primera etapa es esencial para evaluar la factibilidad y complejidad del proceso. El siguiente custionario lo utilizamos en el proceso de levantamiento de información:

Cuestionario migración a Contenedores

Cuestionario Cloud / Servicios ¿Cual es su proveedor de servicios Cloud? ¿Cuál es el costo mensual de facturación por los servicios Cloud? (Aprox.) Equipo Capacidades Roles Máquinas ¿Cuántas máquinas posee? (físicas y virtuales?) Separar el detalle por ambien...

Google Docs

Existen muchas variables y condiciones que deben ser evaluadas. Si las capacidades están presentes en el equipo, como están construidas las aplicaciones, si existen triggers en alguno horario, cuál es el número de usuarios concurrentes máximos, etc. Toda esta información es relevante para dimensariar y planificar correctamente la migración.

Por supuesto que también es clave definir objetivos claros y precisos. Se trata de alinear las expectativas y no creer que por migrar a Kubernetes se solucionarán otros problemas. Por ejemplo, muchas veces se piensa que el performance y velocidad de las aplicaciones y servicios aumentará con la nueva tecnología, lo que es totalmente falso. O que desaparecerán ciertos errores, o que se acabará la saturación a la base de datos. No, Kubernetes no arregla problemas de las aplicaciones.

Las siguientes fases del proceso de migración dependerán del contexto de la empresa y de la arquitectura de los sistemas. Si bien los plazos dependen de múltiples factores, en el 80% de los casos todo el proyecto de migración se realiza en 9 meses o menos.

Diseño de propuesta

Según los objetivos definidos en la fase previa, y de acuerdo al análisis de la situación actual de los sistemas y el contexto de la empresa, se realiza una propuesta de diseño con la nueva arquitectura y la planificación correspondiente.

Hay que considerar muchos aspectos: seguridad, storage, networking, pipeline de desarrollo, gestión de permisos a usuarios y sistemas, bóveda para almacenamiento de credenciales, DNS y dominios, puertos y accesos, etc.

Además de lo anterior, y lo más complejo de estimar, es el trabajo que se necesitará para migrar cada aplicación y servicio a su ambiente dockerizado. Esta tarea es más dificil porque se debe evaluar en detalle cada solución (software), y se debe dimensionar los esfuerzos de desarrollo para transformarlo en contenedor.

Desarrollo y testing

Esta es la fase más entretenida, y que más tiempo toma. Corresponde al trabajo duro en que se moverán los servicios y aplicaciones a contenedores en un ambiente de pruebas controlado.

Y por supuesto, está la fase de pruebas que corresponderá a una evaluación intensa del comportamiento de las funcionalidades de nuestros sistemas. Estas pruebas también consideran pruebas de carga o estrés, para validar que nuestra nueva plataforma soporte el flujo de carga definido.

Implementación

La última fase contempla la implementación de la nueva arquitectura en los ambientes de producción. Esto típicamente requerirá una "ventana" de mantención que permita migrar los datos desde las bases de datos antiguas a las nuevas.

Se realizarán los cambios de redirección en el DNS y con ello se desvía a los usuarios a la nueva solución.

Las primeras 48 horas hábiles son escenciales para adaptar y corregir pequeños cosas en la configuración de los ambientes, cambios que son necesarios para el óptimo funcionamiento de todo el conjunto de servicios. Al mismo tiempo se definen SLAs y todo el flujo de soporte que sustentará la nueva infraestructura. En algunos casos se sugiere implementar un plan de recuperación de desástres (DRP).

Finalmente queda lo mejor, apagar la infraestructura antigua... y mirar en la siguiente factura la reducción sustancial de costos.

Caso de Negocio 💣

Felizmente nos tocó apoyar el 2021 a una empresa en la reducción de sus costos fijos operacionales relacionados con el pago de los servicios de AWS. Esta empresa, tenía un costo mensual promedio de ~5.000 USD por el uso de los servicios, es decir, 60 mil dólares anuales.

Hicimos nuestra tarea, y estimamos que podríamos habilitar una solución utilizando infraestructura propia en modalidad housing en un cloud privado, que a diferencia de un servicio cloud público como AWS, requerirá la mantención y soporte de los equipos.

Luego compramos los servidores, la memoria RAM y el almacenamiento. Implementarmos un cluster de Kubernetes y sobre él desplegaríamos las aplicaciones y servicios del cliente. El proyecto tuvo una duración de 6 meses.

• 3 x Servidores DELL PowerEdge R6515 48 vCPU: 8915 USD.
• 12 x Memorias RAM Kingston de 64GB c/u: 3.800 USD.
• Disco NVMe PCIe de 4TB como storage: 1600 USD.
• Profesional DevOps con certificacion en Kubernetes  – Habilitación de cluster de Kubernetes: 1600 USD.

Luego, la infraestructura y la implementación del cluster tuvo con único costo de implementación de 15.915 USD. No existió ningún costo de licencia. El valor mensual del housing en un data center en EEUU para los 3 servidores es de 200 USD/mes. La habilitación de los servidores fue relativamente rápida y menos de 4 semanas ya estaban operativos.

Ahora bien, el resto del proyecto fue la migración de las aplicaciones del cliente a ambientes dockerizados (en contenedores). La mayoría de las aplicaciones del cliente corrían directamente en en máquinas EC2, por lo que se debió refactorizar varias de ellas para llevarlas a Docker. Si bien este desarrollo fue parte del proyecto, no tiene sentido incluir dicho costo en la comparación ya que es parte de una modernización del diseño de las aplicaciones.

Queda un punto muy relevante, el soporte o mantención de los equipos. Alguien debe hacer los upgrades y aplicar los parches de seguridad a los servidores. Este servicio fácilmente se encuentra con profesionales freelance a costos relativamente bajos (~30 USD p/h), y no se requieren más de 10 horas mensuales. Es decir, el costo de mantención no debería ser mayor a los 3600 USD anuales.

En definitiva, la inversión de 15.915 USD en infraestructura se pagó con los ahorros en menos de 4 meses. A partir del segundo año, la reducción fue de un 90% (de 60k bajó a 6k). ¿Que tal?

Para mayor información respecto del servicio de migración, puede consultar el siguiente link:

Conclusión

Quizás faltó hablar un poco de los casos y excepciones en que no es conveniente migrar a contenedores. Si bien son pocos, hay escenarios en que la gestión con contenedores podría sería más dificil que con máquinas virtuales, o bien el performance podría verse degradado. Esto puede ser cuando los sistemas operativos de las máquinas virtuales tienen condiciones y características muy específicas y están adaptadas para corregir ciertas faltas en las aplicaciones.

Al margen de lo anterior, si bien la migración a contenedores puede ser dura y compleja en un principio para los equipos de desarrollo, los beneficios y ventajas no tienen comparación. Y la adquisición de las capacidades para adminsitrar contenedores deben traerse o enseñarse, pero son capacidades que deben estar presenten en las empresas de hoy.

Si están en proceso de migración, mucha suerte y éxito ! Esperamos que este tema se vuelva cada vez más recurrente en nuestro país.