Containers vs Serverless : ¿A quién elegir y cuándo?

Tanto los contenedores como los modelos de despliegue y desarrollo serverless forman parte de la cultura de tener una arquitectura escalable y disponible según el uso de la aplicación. Esto hace que sea difícil elegir entre los dos y eso es exactamente lo que vamos a discutir en este post.

¿Qué son los contenedores?

Los contenedores no sólo ofrecen la posibilidad de superar algunas limitaciones de la virtualización tradicional, sino que sientan las bases para un cambio radical en la forma de entender el desarrollo y el ciclo de vida de los servicios.

La idea detrás de los contenedores no nació en el mundo Linux, sino que tiene sus raíces en una tecnología conocida como FreeBSD jail, aparecida en el año 2000, que permite particionar un sistema FreeBSD en subsistemas (jail) aislados entre sí y del sistema subyacente extendiendo el concepto de chroot.

Esto se introdujo en el mundo Linux con el proyecto Linux Vserver y se integró en los años siguientes con nuevas tecnologías, como cgroup, systemd y Linux Kernel Namespace, perfilando así el proyecto Linux Container (LXC).

En 2008, con la llegada de DockerEn los últimos años, se han añadido nuevas herramientas y nuevas ideas, como la posibilidad de crear imágenes en capas (es decir, resultantes de la fusión de varias imágenes) y la introducción del registro de imágenes. Así pues, los proyectos de contenedores en el mundo Linux han recibido un nuevo impulso que ha dado lugar al nacimiento de la Open Container Initiative, cuyos miembros, entre ellos Docker y Red Hat, colaboran para definir estándares abiertos y compartidos para las tecnologías de contenedores.

Con estas premisas y estas herramientas disponibles, es natural que nos preguntemos si existen alternativas a la virtualización tradicional.

Más allá de los aspectos más estrictamente técnicos, un contenedor Linux es el conjunto de uno o varios procesos aislados del resto del sistema, que:

• Disponer de una interfaz de gestión estándar (para arrancar, parar, variables de entorno).
• Optimizar el uso de recursos con respecto a las máquinas virtuales
• Simplificar la gestión de aplicaciones de gran tamaño (repartidas en varios contenedores).

La presencia de las normas propuestas por los organismos de normalización también garantiza la interoperabilidad y la posibilidad de orquestar contenedores incluso entre nubes diferentes.

El concepto de imagen y la forma de construirla y agregarla constituye el aspecto más significativo e innovador, no tanto desde el punto de vista tecnológico como por el impacto que tiene en el desarrollo y la gestión operativa, con consecuencias que afectan también a la forma de entender los negocios.

Las imágenes son inmutables, esto significa que cada contenedor ejecutado desde la misma imagen es idéntico a los demás, no contiene ninguna información de estado ni datos persistentes. La persistencia se confía a otras herramientas como bases de datos externas y sistemas de ficheros. Esto determina, en primer lugar, una clara distinción entre el entorno de ejecución de la aplicación y los datos sobre los que opera, introduciendo lógicas de separación funcional que aportan beneficios en términos de limpieza, gestión de procesos y seguridad.

La verdadera innovación en el proceso de desarrollo y en el ciclo de vida de la aplicación reside en que, una vez creado un entorno operativo completo y coherente en una o varias imágenes, independiente de los datos sobre los que opera, podrá pasar por todas las fases, desde el desarrollo hasta la producción, sin sufrir cambios.

¿Qué es Serverless?

Los contenedores, aunque permiten una mejor asignación de recursos en comparación con las máquinas virtuales, no permiten realmente escalar a cero y crecer linealmente: cuando un contenedor no presta servicios, sigue activo como proceso. Una respuesta a esta necesidad puede venir de enfoques sin servidor.

Una asignación de recursos realmente eficiente requiere que toda la potencia de cálculo se instancie realmente sólo bajo demanda y se libere inmediatamente después de su uso.

Los primeros pasos en esta dirección los dio Google con la introducción de Google App Engine en 2008, pero el verdadero impulso llegó con la introducción por parte de Amazon en 2014 de AWS Lambdael primer verdadero modelo FaaS. Posteriormente, se sumaron soluciones alternativas propuestas por otros proveedores: Microsoft con Azure Functions, IBM y Google con sus propias Cloud Functions. El mundo del código abierto también se ha movido en esta dirección con el lanzamiento de productos como Apache OpenWhisk, OpenLambda y IronFunctions.

Computación sin servidor es una de las formas de distribuir servicios en un contexto de nube que implica la ejecución de aplicaciones o, más correctamente, funciones, sin requerir ninguna visibilidad de la infraestructura subyacente: el aprovisionamiento, el escalado y la gestión tienen lugar de forma automática y lineal sólo ante solicitudes y necesidades reales. Por tanto, el término serverless no debe entenderse como "ausencia" de servidores, sino como transparencia de los sistemas implicados desde el punto de vista de desarrolladores y usuarios.

Esta característica significa que el Paradigma DevOps, típico en el uso de tecnologías contenedorizadas, se abandona para volver a una nueva distinción más clara entre el componente de infraestructura y el de aplicación, introduciendo dos nuevos conceptos en el mundo de la nube:

• FaaS (Function as a Service) permite a los desarrolladores disponer de un entorno de ejecución para sus aplicaciones (ya sean C #, Java, Node.js, Python, etc.) que se instancie únicamente en respuesta a determinados eventos.
• BaaS (Backend as a Service) permite delegar en terceros las funciones típicas de las aplicaciones sin tener que implementarlas en persona (por ejemplo, el caso de servicios como Auth0, que ofrece funciones de gestión de identidades y autenticación).

Hay muchos Marcos sin servidor disponibles en el mercado.

La principal diferencia entre serverless y contenedores

Los contenedores son muy importantes para el impulso que ha ido tomando la arquitectura Serverless, principalmente por incorporar conceptos y la cultura de dejar de usar las viejas máquinas virtuales y servidores clásicos. Todo se puede alojar en local o en la nube, sin complicaciones ni complejidades.

La gran diferencia entre una arquitectura Serverless utilizando FaaS y Containers es la falta de preocupación por los procesos que se ejecutan a nivel de sistema operativo. Incluso con servicios como Docker que ofrecen capacidades de abstracción similares a la tecnología Containers, especialmente cuando se utiliza junto con Kubernetes, la arquitectura Serverless y FaaS permiten un grado aún mayor de este tipo de abstracción en el desarrollo de aplicaciones.

En una arquitectura Serverless que utiliza FaaS, la escalabilidad de la aplicación se gestiona de forma automática y transparente, y además tiene la capacidad de una alta granularidad del servicio para su mejor rendimiento. Las plataformas que utilizan contenedores necesitan que este aprovisionamiento se gestione manualmente, incluso con herramientas automatizadas.
Al final, el estilo de la aplicación y la infraestructura disponible determinarán cuál de las dos formas de despliegue será la mejor utilizada. La arquitectura sin servidor tiene un alto nivel de abstracción de procesamiento del sistema operativo, mientras que los contenedores están evolucionando y desarrollando formas de automatizar la escalabilidad y la disponibilidad.

Cómo elegir entre serverless y contenedores?

En esta panorámica hemos tratado de destacar la radicalidad de la transformación que ha sacudido el mundo de los servicios informáticos en los últimos años, redefiniendo infraestructuras, modelos de desarrollo e incluso modelos de negocio.

Sin embargo, lo que puede parecer un proceso evolutivo en el que las nuevas tecnologías están destinadas a sustituir a las anteriores, es en realidad un camino mucho menos lineal: existen y probablemente seguirán existiendo durante mucho tiempo escenarios en los que cada una de las tres tecnologías será la única aplicable, otros en los que deberán integrarse y cada una encontrará su propio espacio.

No todas las cargas de trabajo son portables en contenedores: en algunos casos, sería necesario rediseñar y reescribir la aplicación. No es seguro que esto sea siempre posible, por lo que sigue habiendo situaciones en las que las máquinas virtuales permiten un control del sistema o una flexibilidad que las hace indispensables.

Contenedores y casos de uso sin servidor

Contenedores encuentran su uso ideal en aplicaciones complejas, que requieren un alto nivel de control del entorno operativo, posiblemente con largos tiempos de procesamiento y que al mismo tiempo se prestan a la implementación en un entorno de contenedores.

Aunque el uso de recursos es menos eficiente que con un enfoque sin servidor, los resultados son mejores en promedio, ya que al menos el primer contenedor está siempre activo y no tiene que instanciarse desde cero.

El diseño, el desarrollo y la gestión pueden ser más sencillos, ya que la presencia de marcos y estándares compartidos permite la orquestación entre nubes de distintos proveedores con un escalado mucho más sencillo que el de los servidores virtuales.

Por el contrario, en los contenedores las modificaciones de funciones individuales requieren la creación y despliegue de una nueva imagen, con la ampliación de los tiempos de lanzamiento y la posibilidad de error. El crecimiento del número de instancias en respuesta al aumento de la carga conlleva dificultades de supervisión y posibles problemas de rendimiento, ya que la capacidad de crecimiento siempre está limitada por la velocidad de los componentes que garantizan la persistencia de los datos.

Un ejemplo típico de uso puede ser un gran sitio de comercio electrónico compuesto por numerosas partes, como la lista de precios, gestión de almacenesy pagos, cada uno de los cuales puede empaquetarse en un contenedor para el que el tiempo de ejecución y los límites de memoria no constituyan un problema.

El enfoque sin servidor puede ser ideal en un contexto de microservicios y en escenarios, como la IoTdonde determinadas funciones sólo deben invocarse cuando se producen eventos específicos y no formar parte de un servicio siempre activo.

Al ser un modelo estrictamente de pago por uso, permite optimizar los costes, sobre todo en los casos en los que es difícil proceder a un dimensionamiento a priori o predecir la carga a la que habrá que hacer frente.

La dificultad de diseño y la ausencia de normas, que en muchos casos determina el problema de la dependencia del proveedor, siguen constituyendo una fuerte limitación del campo de utilización.

Palabras finales

En resumen, ninguna tecnología es mejor que la otra en sentido absoluto: cada una responde a necesidades específicas. Pueden coexistir e integrarse, según las necesidades, en un mismo proyecto. Por tanto, lo mejor no es decidir un camino previo para el desarrollo de sus aplicaciones, sino partir de un análisis minucioso de las características y requisitos para elegir la arquitectura más adecuada.