Serveless vs Contenedores

¿cual escoger y por qué? traducido y adaptado del original en serverless.com

Contrario a lo que muchos piensan, Serverless (FaaS) y Containers ( Orquestación de contenedores) tienen cosas muy importantes en común.

¿Necesita un arquitectura moderna, adaptable al futuro ? Ambos la tienen. ¿Quiere construir esa arquitectura solida combinando las últimas innovaciones en sistemas distribuidos y desarrollo de aplicaciones grandes que escalen? Si, ambos también lo tienen.

Si, es difícil decidir cual es mejor para ustedes y necesitan tomar una decisión, así que amigo, necesitas saber.

¿Cuales son los puntos en común y distinciones? ¿cuales son las ventajas y desventajas de cada uno ? Es computo serverless vs contenedores, ahora.

¿pero, cómo llegamos aqui ?

Antes de saltar directo a los detalles, recordemos algunos puntos importantes:

1. Servidores físicos

Solíamos usar nuestra propia infraestructura en forma de servidores físicos. Configuramos esa máquinas, entregamos nuestro código, las escalamos y mantenemos. Todo el proceso era manual y bastante lento para arrancar.

2. Clusters de servidores y VMS

Usar un solo servidor para una aplicación era un desperdicio de recursos. Así que, evolucionamos nuestra infraestructura pensando y combinando muchos servidores físicos en un cluster.

Solíamos usar esas llamadas “maquinas virtuales” para correr multiples aplicaciones aisladas encima de nuestra infraestructura. La entrega (deployment) y el manejo es más rápido y fácil. Sin embargo, la administración de los servidores es aún necesaria y en gran medida muy manual.

3. Entrando a la nube (IaaS)

Montar y operar tu propio datacenter viene con nuevos retos operacionales, el computo en la nube comenzó a hacer frente a esos temas. ¿por qué no rentar servidores y servicios operativos individualmente por una cuota mensual? Esta aproximación hace fácil crecer o decrecer la infraestructura y permite a los equipos a moverse más rápido.

4. PaaS

Mientras que los ambientes en la nube hacen más conveniente la construcción de aplicaciones grandes y escalables, aun tienen la problemática y lo engorroso de una administración manual.

¿se instalaron los últimos parches de seguridad?

¿tenemos que actualizar ya el sistema?

¿cuantas servidores más necesitamos?

¿ No seria genial que todos eso problemas administrativos los quiten de nuestro escritorio y así podamos simplemente concentrarnos en las aplicaciones y valor en el negocio ?

Yep! Si es lo mismo que otros amigos que pensaron también.

En esta esquina: Contenedores

¿no sera agradable si uno pudiese empacar la aplicación con todaaaaas esas dependencias, en una caja dedicada y correrla donde sea ? ¿no importando que dependencias de software el sistema anfitrión ha instalado o donde y que sistema es ?

Esta es la idea de los contenedores.

Crear un contenedor el cual tenga todas las dependencias requeridas pre instaladas, poner el código de la aplicación dentro de este y correr donde sea que el runtime del contenedor este instalado. No más desarrolladores diciendo: “mmm, bueno , ¡en mi maquina si jalaba!”.

Los contenedores llamaron la atención cuando nos enteramos de que Google los usaba para soportar sus servicios (como Gmail o Maps). Usar contenedores fue inicialmente bastante incomodo, ya que , este requería conocimiento avanzados técnicos acerca de las tripas del kernel de Linux y como hacer scripts a la medida para poner la aplicación en un contenedor y correrlos en una maquina host .

Después Dotcloud ( una startup PaaS de San Francisco ) anunció una nueva herramienta llamada Docker en el Pycon US 2013. Docker era una herramienta CLI fácil de usar que hacia posible manejar los contenedores de software más fácilmente.

Dotcloud después se convirtió en Docker y Google trabajabaja ya en la implementación OpenSource del servicio conteneder de orquestación “Borg” , el cual es llamado Kubernetes.

Más y más empresas adoptaron contenedores y estándares alrededor esta nueva tecnología que se estaba definiendo. Más recientemente, cada proveedor de servicios en la nube ofrece una manera de hospedar aplicaciones en contenedores en su infraestructura.

Ventajas de los contenedores

  • Control y Flexibilidad
  • Ajenos al vendedor ( Vendor-agnostic)
  • Ruta fácil de migración
  • Portabilidad

Desventajas de los contenedores

  • Trabajo administrativo (e.j. aplicar los parches de seguridad para contenedores)
  • Escalar toma más tiempo
  • Costos de operación
  • Es difícil iniciar
  • Más intervención manual

En la otra esquina: el computo Serverless (FaaS)

Aproximadamente un año después, AWS introdujo el primer servicio de computo serverless llamado AWS Lambda.

Con la premisa más básica de que una configuración serverless es que toda la aplicación — toda la lógica de negocios , es implementada como funciones y eventos.

Vámonos por partes dijo Jack el Destripador. Las aplicaciones se dividen en diferentes funcionalidades (o servicios), los cuales son detonados por eventos. Uno¡ sube el código de la función y añade un evento a este.

Así funciona básicamente. El proveedor de la nube se ocupa del resto y asegura que tus funciones estén siempre disponibles y utilizables, no importando que.

Cuando el computo y/o arquitecturas serverless fueron presentadas en 2014, las cargas de trabajo eran bastante limitadas y se concentraban alrededor de trabajos más pequeños como imágenes / manipulación de datos, fue entonces cuando AWS lanzo su API Gateway como una fuente de eventos para sus funciones Lambda.

Eso cambio todo. Se hizo posible crear APIs completas que eran soportadas por el computo serverless. Más y más servicios integrados a la oferta de AWS Lambda haciendo posible construir aplicaciones mas grandes, completas y complejas, aplicaciones totalmente serverless.

Pero ¿ qué es exactamente una aplicación serverless ? En resumen, una arquitectura es serverless si tiene al menos tres de estas características:

  • Un flujo de trabajo orientado a eventos (event-driven workflow) (“Si X entonces Y”)
  • Pago por ejecución
  • Cero administración
  • Auto-scaling
  • Efímero, (short-lived), funciones sin estado

Ventajas del serverless

  • Cero administración
  • Pago por ejecución
  • Costo cero por tiempos muertos o de inactividad
  • Auto escalamiento
  • Tiempos de llegada al mercado mucho más rápido
  • Naturaleza de microservicios — una clara separación del código base
  • Se reduce significativamente la administración y la carga de mantenimiento.

Desventajas del serverless

  • No hay estandarización (aunque la Cloud Native Computing Foundation esta trabajando en ello ( CNCF por sus siglas en inglés ).
  • Ambientes de cajas negras — “Black box”
  • Te atas a un proveedor (vendor lock-in)
  • Arranques fríos (una latencia cuando detonamos una función).
  • Aplicaciones complejas pueden ser muy difíciles de construir.

¿cuando escoger cual ?

Gran pregunta :

“¿qué tecnología debo utilizar en mi próximo proyecto? ”

Honestamente, depende.

Cuando escoger contenedores

Los contenedores son grandiosos si necesitas la flexibilidad de instalar y usar software con requerimientos de versiones especificas. Con los contenedores, puedes escoger el sistema operativo subyacente y tener control completo del lenguaje de programación instalado y la versión del runtime.

Incluso es posible operar contenedores con diferentes pilas de software a través de una flota de contenedores más grandes, es de particular interes si por ejemplo necesitas migrar un sistema viejo, propietario a un ambiente de contenedores. Como un bono adicional, muchas herramientas para manejar contenedores que pueden escalar mucho, como Kubernetes vienen ya con todas las mejores practicas pre cocidas.

La flexibilidad vienes con un precio adicional de operación , sin embargo, los contenedores aún requieren mucho mantenimiento y configuración.

Para un máximo beneficio, van a necesitar dividir la aplicación monolítica en micro servicios separados, los cuales necesitan ser entregados como grupos individuales de contenedores. Esto significa que necesitarán herramientas que permiten que todos estos contenedores se hablen entre ellos. También necesitarán realizar el trabajo duro de mantener los sistemas operativos actualizados con los parches de seguridad y otras actualizaciones.

Mientras puedan configurar la plataforma de orquestación de contenedores para manejar automáticamente las fluctuaciones de trafico por ti, (es decir , self-healing y auto-scaling), el proceso de detectar esos cambios en los patrones de tráfico y ajuste de los contenedores para arriba o hacia abajo no será instantáneo. Un completo apagado donde no haya infraestructura utilizando contenedores (por ejemplo cuando no haya trafico) no será posible, siempre habrá costos de tiempo de ejecución.

Cuando escoger serverless

En ese sentido, serverless funciona bien si necesitas que los cambios en los patrones de trafico se detecten y manejen automáticamente. La aplicación se cierra completamente si no hay trafico. Con las aplicaciones serverless, solo pagas por los recursos que usas, no usas no pagas.

El desarrollador serverless no se tiene que preocupar de la administración de la infraestructura subyacente, solo necesita preocuparse del código y del valor del negocio hacia los usuarios finales. Las iteraciones pueden ser más rápidas, ya que el código puede ser entregado más rápido, sin set-up o provisionamiento. De hecho, debido a que la infraestructura por debajo es abstracta, el desarrollador puede no saber que pasa abajo o como luce, realmente no lo necesita.

Pero de hecho actualmente existen algunas limitaciones con el soporte de los proveedores y/o ataduras o bloqueos en los ecosistemas. Los lenguajes de programación y los entornos de ejecución son limitados a lo que el proveedor soporte ( existen algunas formas de darle la vuelta a esto o “shims” disponibles para saltar estas restricciones), y debemos decir que lenguajes más populares están ampliamente soportados (Java, Python , JS por mencionar algunos).

Las fuentes de los eventos , los que detonan todas tus funciones, son usualmente servicios específicos a la oferta del proveedor de la nube, es decir no esperes que tu código se ejecute de manera transparente en Azure y luego en AWS.

Organizar todas esta piezas de manera individual en el stack de tu aplicación puede llegar a ser complejo cuando la infraestructura y el código están tan separados.

Serverless es un poco más reciente y aún sus herramientas tienen mucho espacio para evolucionar. Como por ejemplo las herramientas de serverless.com ( de las cuales hablaremos en otro artículo).

¿el veredicto final ?

Por supuesto. estos es muy. muy, muy a grandes rasgos y simplificado. El mundo real siempre es mucho más complejo.

¿pero habrá una regla de oro ?

Escoger contenedores y orquestadores de contenedores cuando necesiten flexibilidad, o cuando necesitan migrar servicios o sistemas legacy, propietarios pues.

Escoger serverless cuando necesiten velocidad de desarrollo, una pronta salida a mercado, que escale la aplicación automáticamente y costos de ejecución mas bajos (bueno, al menos al inicio).

¿Interesado en aprender más y/o certificarte en DevOps? Da click aquí.

Cheerleader in chief for KMMX, RPA Enthusiast, DevOps, Technical Writer & International Speaker, Dad & 2 cats.

Cheerleader in chief for KMMX, RPA Enthusiast, DevOps, Technical Writer & International Speaker, Dad & 2 cats.