Mudanza a la nube, que necesitas meter y que no en tu contenedor

Mudanza a la nube, que necesitas meter y que no en tu contenedor

Hace ya un a√Īo que escrib√≠a sobre contenedores en este mismo blog, ese post los titul√© como Containers: ¬ęReady or not here we go¬Ľ. En este post, analizaba como me hab√≠a sorprendido no encontrar una alta adopci√≥n de proyectos basados en contenedores, en los clientes con los que trataba en ese momento.

Sin embargo, la foto actual un a√Īo despu√©s es muy distinta, podr√≠a decir que la mayor√≠a por no decir todos mis clientes, se est√°n pensando o tienen previsto trabajar en el corto plazo con esta tecnolog√≠a.

Es sorprendente ver como la forma en la que esperabas que sucediesen las cosas no ocurren, cuando escuché hablar de los contenedores, cuando el fenómeno de la virtualización empezó a crecer allá por los comienzos de este milenio. Era sorprendente ver cómo los fabricantes a favor de la Full Virtualization, menospreciaban por completo las capacidades y el vuelco que podía dar a la industria una virtualización basada en la paravirtualización.

Pros and cons de ambas tecnologías

La virtualizaci√≥n completa, o virtualizaci√≥n mediante hipervisor, permite que una delgada capa de software sea la encargada de emular y enmascarar los recursos presentados al sistema operativo. Permitiendo fraccionar y orquestar el acceso de m√ļltiples sistemas operativos al hardware que subyace por debajo. Este tipo de hipervisores pensados para el entorno de data center son conocidos como hipervisores de tipo 1.

Mientras que los contendores, u originalmente conocido como paravirtualizaci√≥n, b√°sicamente lo que permite es, que compartiendo el kernel del sistema operativo subyacente, por encima del mismo se creen dominios donde se despliegue una aplicaci√≥n especifica. En el caso de los contenedores, hay una peque√Īa capa de software conocida como motor que permite la gesti√≥n en el acceso a los recursos de la capa superior, donde b√°sicamente los recursos encapsulados en este dominio son:

  • La aplicaci√≥n
  • Dependencias
  • Librer√≠as
  • Binarios
  • Ficheros de configuraci√≥n

Docker como sinónimo de contenedor

A día de hoy, el uso extendido de Docker como herramienta para la creación de los contenedores, hace que la mayoría de nosotros asimilemos el termino contendores a Docker, pero no es así hay otra serie de herramientas comerciales como son LXC, LXD, Solaris Zones, RKT o BSD Jails, que nos permiten crear contenedores desde cero al igual que Docker. Igualmente, para los entornos Windows, Microsoft dispone de herramientas como Windows Server Containers and Hiper-V Containers.

En resumen, a las máquinas virtuales se les entrega a través del hipervisor un recurso hardware virtualizado, mientras a los contenedores se les entrega un sistema operativo virtualizado.

El detalle de cómo y cuáles son las capas involucradas en cada aproximación, se pueden ver con mayor detalle en la siguiente figura.

Hipervisor vs motor de contenedores

Ventajas y desventajas de los hipervidores:

  • Ventajas
    • Gestiona mejor las aplicaciones legacy, crea una foto de los recursos desplegados en el hardware original y los enmacara para la m√°quina virtual
    • Permite convivencia de diferentes sistemas operativos en el mismo hardware
    • Mayor aislamiento de la VM (virtual machine) a nivel del kernel del SO
  • Desventajas
    • Gran consumidor de recursos
    • El tama√Īo de la m√°quina virtual suele ser u fichero de configuraci√≥n de tama√Īos de GB

Ventajas y desventajas de los contenedores:

  • Ventajas
    • Optimiza los recursos hardware de manera muy eficiente
    • Fichero de configuraciones muy ligeros entorno a MB, permite crear, copiar y matar de forma muy eficiente
    • Mejor velocidad de respuesta ante picos de carga de trabajo en la clonaci√≥n de recursos
    • Mejora el ciclo de vida de los despliegues de aplicaciones
    • Las pruebas y depuraci√≥n de errores es mucho m√°s sencilla, ya que el contenedor es el mismo en desarrollo que en producci√≥n, haciendo realidad la frase m√°s popular entre los desarrolladores, ‚Äúen m√≠ m√°quina funciona‚ÄĚ.
  • Desventajas
    • Todos los contenedores hacen uso del mismo SO, tipo y versi√≥n
    • Mayor riesgo de disponibilidad por ataques de kernel, todos los contenedores comparten el mismo
    • Mayor complejidad en la gesti√≥n y uso de la red

Cuándo y cómo comenzar a trabajar con contenedores

Como comentaba anteriormente, parecía que la siguiente ola en cuanto a la evolución de la eficiencia de los data centers serían los contenedores, mejor uso de los recursos y mayor eficiencia en relación a los ratios de consolidación.

Pero no fue así, como hemos visto la gestión en cuanto a la complejidad de la red y la imposibilidad de corres más de un sistema operativo por host, hizo que su adopción se estancase en el data center.

Aplicaciones born in the cloud

No así en los proyectos born in the cloud, aquí su adopción ha sido mucho mayor, relacionada con la creación de aplicaciones cien por cien cloud native. Este tipo de aplicaciones, concebidas desde el minuto uno como microservicios que ejecutan localmente una lógica de negocio muy reducida y la aplicación global, se encarga de orquestar las llamadas a cada uno de los mismos, ha hecho que la nube sea el lugar predilecto para correr ese tipo de cargas de trabajo.

La siguiente ola esta siendo la de aquellos que disponen de aplicaciones propias y est√°n en la b√ļsqueda de eficiencias y mejoras en las mismas, por el hecho de avanzar en un enfoque a microservicios y la b√ļsqueda del stateless infinito.

Qué tener en cuenta antes de empezar a trabajar con contenedores

Para ellos, y si te encuentras en este punto, te traigo de nuevo un recetario de como empezar a trabajar con este tipo de tecnología y arquitecuras:

  1. Gestión del cambio y análisis de habilidades, revisa las competencias del equipo y el resto de las áreas involucradas en el proyecto, para que todo el mundo sea consciente que se puede hacer y qué no, así como alguna de las funcionalidades y riesgos, que se perderán u encontrareis por el camino.
  2. Despliegue como c√≥digo de la infraestructura: Las implementaciones de contenedores requieren automatizaci√≥n y administraci√≥n a trav√©s de interfaces de l√≠nea com√ļn (CLI) o interfaz de programaci√≥n de aplicaciones (API).
  3. Fijación de objetivos multinivel: Para medir con éxito el valor comercial de los contenedores, que solamente es una pieza tecnología adicional, las organizaciones deben establecer objetivos realistas.
  4. Seleccionar aplicaciones candidatas: Este paso final consiste en seleccionar cuidadosamente qué aplicaciones son candidatas para el proceso de refactorización o decidir si frente a un nuevo proyecto se debe implementar una nueva aplicación en contenedores o en otro tipo de infraestructura.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *