@media screen and (min-width: 580px) { .flotantewhatsapp{ display:none; } }

Compartir por WhatsApp

ventajas-e-inconvenientes-de-los-containers-en-programacion-1

Ventajas e Inconvenientes de los Containers en Programación

Ventajas e Inconvenientes de los Containers en Programación

Durante estos días, algo que no me había pasado estos años, estoy viendo que varios compañeros están interesándose especialmente en documentarse en tecnologías relacionadas con contenedores (Docker, Kubernetes, OpenShift…)

Pero, la realidad, es que prácticamente todo el mundo, aún sabiendo que puede ser el futuro (prácticamente presente) de los sistemas virtualizados y del desarrollo de aplicaciones, no ven cómo pueden aplicarlo a sus sistemas y qué ventajas o inconvenientes les puede aportar. A parte, que creo que es complicado saber el esfuerzo extra que puede suponer tanto para administradores de sistemas como para desarrolladores…

La mayoría de informáticos con los que tengo más relación, y hablamos de estos temas, tienen la visión de sistemas (máquina virtual, networking, seguridad, aplicaciones en 3 capas…) y no de desarrollo, donde creo que puede ser más fácil extraer las ventajas e inconvenientes, que por supuesto también los hay.

Por eso, voy a daros mi visión de las ventajas e inconvenientes de trabajar con contenedores en un entorno de desarrollo o de programación.

El primer problema que encuentro, es que si un administrador de sistemas quiere comenzar a usar contenedores pensando en que funcionalmente es lo mismo que una máquina virtual, creo que no entiende el contexto en el que se encuentra.

ventajas-e-inconvenientes-de-los-containers-en-programacion-2

Cuando quieres migrar desde máquinas virtuales a contenedores, la arquitectura de implementación de nuestras aplicaciones debe cambiar por completo. Normalmente, los que hacemos diseños de infraestructuras, basamos nuestro diseño en que la infraestructura “no falle”.

Si tú quieres implementar contenedores, y mantener la alta disponibilidad, flexibilidad y rendimiento, tienes que pensar todo lo contrario, debes diseñar tu infraestructura para que todo componente pueda “fallar”.

Pongo un ejemplo, con aplicaciones tradicionales de 3 niveles, frontend (dashboard), backend (webservice) y base de datos. Si tú quieres llevar estas aplicaciones a contenedores tendrás que tener en cuenta que:

  • Tu servidor de base de datos, tendrá mínimo dos contenedores en un clúster activo / activo y que estos datos son a su vez persistentes.
  • Los webservices también tendrán su propio equilibrio de carga, contenedores sin estado y con datos también persistentes al menos en el almacenamiento.
  • Los dashboards se compondrán de contenedores sin estado (HTML / PHP puro), y también con equilibrio de carga.

Lo explico de otra forma, normalmente, un host que compone un clúster de contenedores (Docker Swarm o Kubernetes, por ejemplo), te va a dar una HA (alta disponibilidad) bastante básica, el comportamiento es el del reinicio de contenedores ante fallos. Para dar un HA real, deberemos implementar una infraestructura con aplicaciones distribuidas por el clúster en un modo activo / activo o mediante un balanceador de carga. Y esto lo podemos aplicar a servicios web, aplicaciones o bases de datos por igual.

Esto influye mucho, porque no todas las aplicaciones o servicios serán “contenerizables”. Pongo un ejemplo, no te serviría un MySQL en un solo contenedor o con un solo maestro, deberás pensar en un diseño de varios maestros. Esto en aplicaciones o servicios con licencias, podría tener un incremento del gasto, por ejemplo.

Pensarlo mejor, ¿la aplicación o servicio que queréis migrar de un contenedor es capaz de aguantar una caída de un host entero o de uno de los componentes de su diseño sin ser un caos? Si es capaz de esto, podéis evaluar llevar un servicio a un contenedor.

ventajas-e-inconvenientes-de-los-containers-en-programacion-1

Otro punto importante a evaluar es la capa de red. En una máquina virtual o servidor físico, es relativamente sencillo gestionarla, pero a nivel de contenedor, tenéis que pensar que existen unos NATs desde los Host de vuestros contenedores a los propios contenedores. Ese NAT genera una red aislada en el host, deberéis colocar un sistema y sacrificar esfuerzos en un diseño correcto, que permita la conexión asíncrona entre contenedores que tengan el mismo espacio o la replicación correcta entre contenedores en diferentes hosts.

Personalmente, creo que los contenedores no son apropiados para aplicaciones que necesitan potencia bruta (al menos de momento), pero en cambio son excepcionales cuando los requisitos de la aplicación fluctúan en picos (ejemplo, una campaña de rebajas en una gran tienda online).

Si veis su diseño por rendimiento, podéis pensar que al ser más pequeños, tener menos código para funcionar, pueden mejorar el rendimiento de tus sistemas, y optimizar tus recursos. Esto puede ser correcto, salvo que tu desarrollo no tenga establecidos límites de CPU, Memoria o IO usado por contenedor. Ahí los contenedores se convierten en un gran problema, ya que como hemos explicado otras veces, el kernel detecta que los recursos de la máquina host se están agotando para hacer funciones críticas del sistema, y optará por matar procesos. Si tu aplicación es crítica, le va a importar poco si no pones el remedio.

A nivel de seguridad también tienen sus ventajas e inconvenientes. Por una parte, vamos a dividir nuestro desarrollo en pequeñas “porciones” independientes, así que en la teoría, si un contenedor es atacado, el resto de componentes no se debería ver comprometido. Pero también tienen una desventaja, comparten el acceso al kernel del host, y volvemos a lo comentado antes, si el desarrollo no ha colocado sus límites os podéis encontrar con una bonita denegación de servicio.

Otra ventaja que veo, es que cuando un desarrollador implemente una app es su portátil o entorno de laboratorio, es menos complejo pasarla a un entorno productivo. Al final sus dependencias irán en ese contenedor, y sería más cómodo al nivel de administración de servidores o tener que generar máquinas virtuales, problemas de compatibilidades con diferente software, actualizaciones de componentes…los requerimientos de la implementación se deberían reducir de alguna forma.

En resumen, ya existen múltiples herramientas que facilitan la gestión de contenedores, de sus clústeres o redes, cada organización debe encontrar la suya. Personalmente, creo que sigue verde en el mundo IT porque los que nos dedicamos a esto lo ven lejano aunque ya estén aquí para quedarse. Aunque existen empresas a las que les pueden encajar (probablemente ya los estén usando). Por ejemplo, para las empresas que desarrollen, que hayan apostado por la nube o les guste estar a la última, se abre un mundo de posibilidades. Han venido para quedarse, y todas las empresas grandes están apostando por ellos, simplemente hay que aterrizar cómo los queremos implementar nosotros, ya seas una pyme, mediana empresa o multinacional.

¿Y vosotros qué opináis?

Si estáis empezando en este mundo, acordaros de nuestras publicaciones totalmente gratuitas:

¿Te ha gustado la entrada SÍGUENOS EN TWITTER O INVITANOS A UN CAFE?

El Blog de Negu

Acerca de Raul Unzue Pulido

Administrador de sistemas virtuales e infraestructuras IT, linuxero y entusiasta de la tecnología.

Compruebe también

devsecops-seguridad-en-el-cloud-computing-1

DevSecOps: Seguridad en el Cloud Computing

DevSecOps: Seguridad en el Cloud Computing Durante este tiempo, hemos hablado de DevOps, se trata …

2 comentarios

  1. Alfredo Lozano

    Muy interesante Raul. Podríamos decir que tú puedes tener la visión de los dos lados y tu experiencia con contenedores.

Deja una respuesta

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

2 × cuatro =

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies
Blog Maquinas Virtuales - El Blog de Negu