En primer lugar quiero exponer aquí los problemas asociados a las máquinas virtuales (MVs) que quedan resueltos con los contenedores (Dockers). Las desventajas de las MVs con respecto a los contenedores (Dockers) se pueden resumir en 6 principalmente (existen muchas más):

  • «Inicialmente» la inseguridad de un servicio compromete la máquina entera y su sistema operativo (máquina física o virtual).
  • Existe un gran malgasto de recursos ya que se tienen tantos S.Os como máquinas virtuales.
  • La gestión de servicios depende de aplicaciones específicas para ello y no suelen ser triviales.
  • Las recuperaciones, backups e imágenes son muy pesados (decenas de Gb).
  • Su arranque, parada y auto escalado es muy lento y limitado (dependen en gran medida del S.O).
  • No son los modelos óptimos para servicios de altas capacidades o/y on-cloud.

Parece que la solución a todo esto es la compatibilidad de las máquinas virtuales (MVs)/maquinas físicas o en local, híbridas u on-cloud con los contenedores (dockers).

Anteriormente hemos hablado de «Inicialmente» la inseguridad de un servicio (en una MV) compromete la máquina entera y su sistema operativo. Sin embargo, existe una característica que le confiere una mayor seguridad a las MVs que a los contenedores (Dockers). En el caso de las MVs, cada una de ellas tiene una estructura completa y lo que afecta a esta se queda en ella sin afectar al resto. Esto NO ocurre con Dockers ya que existe una capa común sobre la que se ejecutan todos los contenedores y si la seguridad no se establece adecuadamente un contenedor podría afectar a la capa «Docker Engine» y, por lo tanto, afectar al resto de contenedores.

Una de las grandes apuestas por los servicios on-cloud o las estructuras hibridas es la capacidad de balanceo de carga (Load Balancer). La arquitectura de balanceo de carga permite distribuir las peticiones de servicio o procesamiento entre distintas arquitecturas, ya sean contenedores, máquinas virtuales, servicios on-cloud o servidores dedicados.

Esta característica también se manifiesta en la arquitectura de los microservicios (como se vio anteriormente) y se basa en la estrategia de distribuir la carga de trabajo en varias entidades para que la latencia de respuesta sea menor y que la caída de uno solo de estos servicios no comprometa al resto.

En la siguiente imagen podemos ver como podemos balancear la carga de demanda de los servicios de varios clientes (los cuales dirigen sus peticiones a un solo punto) entre varios sistemas.

Diagrama de un balanceador de carga (LB)

Esto es posible realizarlo con varias soluciones de servicios on-cloud o las soluciones que proporciona Docker (Swarm) o Kubernetes (entre otras).

Además de los anterior, el poder contar con servicios de LB (Load Balancer) on-cloud que nos asegura la utilización de esta característica en cualquier lugar del planeta.