Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo elegir una plataforma sin servidor en la nube

[08/03/2021] Ejecutar una granja de servidores en la nube a plena capacidad las 24 horas del día puede ser terriblemente caro. ¿Qué pasaría si se pudiera desconectar la mayor parte de la capacidad cuando no se necesita? Llevando esta idea a su conclusión lógica, ¿qué pasaría si pudieras activar sus servidores bajo demanda cuando se necesiten, y solo proporcionar la capacidad suficiente para manejar la carga?

Ingrese a la computación sin servidores o serverless. La computación sin servidor es un modelo de ejecución en la nube en el que un proveedor de la nube asigna dinámicamente -y luego cobra al usuario- solo los recursos informáticos y el almacenamiento necesarios para ejecutar un código concreto.

En otras palabras, la computación sin servidor es una computación back-end a la carta y de pago. Cuando una solicitud llega a un punto final sin servidor, el back-end reutiliza un punto final "caliente" existente que ya contiene el código correcto, o asigna y personaliza un recurso de un pool, o instala y personaliza un nuevo punto final. La infraestructura suele ejecutar tantas instancias como sean necesarias para atender las solicitudes entrantes, y libera las instancias ociosas tras un periodo de enfriamiento.

"Sin servidor" es, por supuesto, un término equivocado. El modelo utiliza servidores, aunque el usuario no tiene que gestionarlos. El contenedor u otro recurso que ejecuta el código sin servidor suele ejecutarse en una nube, pero también puede ejecutarse en un punto de presencia.

La función como servicio (FaaS) describe muchas arquitecturas sin servidor. En FaaS, el usuario escribe el código para una función, y la infraestructura se encarga de proporcionar el entorno de ejecución, cargar y ejecutar el código, y controlar el ciclo de vida de la ejecución. Un módulo FaaS puede integrarse con webhooks, peticiones HTTP, flujos, cubos de almacenamiento, bases de datos y otros bloques de construcción para crear una aplicación sin servidor.

Escollos de la computación sin servidor

A pesar de lo atractiva que puede ser la computación sin servidor -y la gente ha reducido su gasto en la nube en más de un 60% al cambiar a la computación sin servidor- hay varios problemas potenciales que puede tener que abordar. El problema más común es el arranque en frío.

Si no hay puntos finales "calientes" disponibles cuando llega una solicitud, entonces la infraestructura necesita instanciar un nuevo contenedor e inicializarlo con su código. La instanciación puede tardar varios segundos, lo que es un tiempo muy largo para un servicio que se supone que debe responder en milisegundos de un solo dígito. Eso es un arranque en frío, y debería evitarlo. El tiempo de retardo puede ser incluso peor si tiene una arquitectura en la que muchos servicios sin servidor están encadenados, y todos han arrancado en frío.

Hay varias maneras de evitar los arranques en frío. Una es utilizar pings keep-alive, aunque eso aumentará el tiempo de ejecución utilizado, y por tanto el costo. Otra es utilizar una arquitectura más ligera que los contenedores en la infraestructura sin servidor. Una tercera táctica es iniciar el proceso de tiempo de ejecución tan pronto como una solicitud de cliente comience su handshake de seguridad con el punto final, en lugar de esperar a que la conexión se establezca completamente. Otra táctica es mantener siempre un contenedor "caliente" y listo para pasar por la configuración de escalado de la nube.

Un segundo problema que puede afectar a los servicios sin servidor es el estrangulamiento. Por motivos de contención de costos, muchos servicios tienen límites en el número de instancias sin servidor que pueden utilizar. En un periodo de mucho tráfico, el número de instancias puede llegar a su límite, y las respuestas a las peticiones entrantes adicionales pueden retrasarse o incluso fallar. El estrangulamiento puede solucionarse ajustando cuidadosamente los límites para cubrir los picos legítimos de uso sin permitir un uso desbocado por un ataque de denegación de servicio o una falla en otra parte del sistema.

Un tercer problema con la arquitectura sin servidor es que la capa de almacenamiento podría no ser capaz de manejar los picos de tráfico, y podría respaldar los procesos sin servidor en ejecución, aunque haya muchas instancias disponibles. Una solución a este problema es utilizar cachés o colas residentes en memoria que puedan absorber los datos de un pico y luego driblarlos a la base de datos tan rápido como la base de datos pueda consignar los datos en el disco.

La falta de herramientas de monitorización y depuración puede contribuir a todos estos problemas y hacerlos más difíciles de diagnosticar.

Verá que no he mencionado el "bloqueo del proveedor" como un escollo. Como verá, eso es más una compensación que un problema real.

AWS Lambda y servicios relacionados

AWS Lambda es una oferta FaaS. Podría pensar que AWS Lambda es el único producto sin servidor de Amazon, pero se equivocaría. AWS Lambda es actualmente uno de los más de una docena de productos sin servidor de AWS. También podría pensar que AWS Lambda (2014) fue el primer servicio FaaS, pero fue precedido por Zimki (2006), Google App Engine (2008) y PiCloud (2010).

AWS Lambda admite código de función sin estado escrito en Python, Node.js, Ruby, Java, C#, PowerShell y Go. Las funciones Lambda se ejecutan en respuesta a eventos, como cargas de objetos a Amazon S3, notificaciones de Amazon SNS o acciones de la API. Las funciones Lambda reciben automáticamente un directorio temporal de 500MB y pueden utilizar Amazon S3, Amazon DynamoDB u otro servicio de almacenamiento disponible en Internet para el estado persistente. Una función Lambda puede lanzar procesos utilizando cualquier lenguaje soportado por Amazon Linux, y puede llamar a bibliotecas. Una función Lambda puede ejecutarse en cualquier región de AWS.

Merece la pena destacar varios de los otros productos sin servidor de AWS. Lambda@Edge le permite ejecutar funciones de Lambda en más de 200 ubicaciones de AWS Edge en respuesta a los eventos de la red de entrega de contenido de Amazon CloudFront. Amazon DynamoDB es un servicio de base de datos de valor clave y de documentos rápido y flexible con una latencia consistente de un milisegundo a escala. Y Amazon Kinesis es una plataforma de streaming de datos en AWS. También puede ejecutar funciones Lambda en dispositivos locales y conectados (como controladores para IoT) con AWS Greengrass.

El AWS Serverless Application Model (AWS SAM) puede modelar e implementar sus aplicaciones y servicios sin servidor. Además de SAM, AWS Lambda admite ocho marcos de código abierto y de terceros.

El repositorio de aplicaciones sin servidor de AWS le permite encontrar y reutilizar aplicaciones sin servidor y componentes de aplicaciones para una variedad de casos de uso. Puede utilizar Amazon CloudWatch para monitorizar sus aplicaciones sin servidor, y AWS X-Ray para analizarlas y depurarlas. Por último, AWS Lambda anunció recientemente una vista previa de Lambda Extensions, una nueva forma de integrar fácilmente Lambda con herramientas de monitorización, observabilidad, seguridad y gobernanza.

Microsoft Azure Functions

Microsoft Azure Functions es una plataforma de computación sin eventos que también puede resolver problemas complejos de orquestación. Puede crear y depurar Azure Functions localmente sin necesidad de una configuración adicional, desplegar y operar a escala en la nube, e integrar servicios utilizando triggers y bindings.

Puede codificar Azure Functions en C#, F#, Java, JavaScript (Node.js), PowerShell o Python. Cualquier aplicación de Azure Functions puede utilizar solo una de las anteriores. Puede desarrollar Azure Functions localmente en Visual Studio, Visual Studio Code (véase la captura de pantalla siguiente), IntelliJ, Eclipse y las Azure Functions Core Tools. O puede editar pequeñas funciones de Azure directamente en el portal de Azure.

Durable Functions es una extensión de Azure Functions que permite escribir funciones con estado en un entorno informático sin servidor. La extensión le permite definir flujos de trabajo con estado escribiendo funciones de orquestador, y entidades con estado escribiendo funciones de entidad utilizando el modelo de programación de Azure Functions.

Los desencadenantes son los que hacen que una función se ejecute. Un activador define cómo se invoca una función, y una función debe tener exactamente un activador. Los disparadores tienen datos asociados, que a menudo se proporcionan como la carga útil de la función.

La vinculación a una función es una forma de conectar declarativamente otro recurso a la función; las vinculaciones pueden estar conectadas como vinculaciones de entrada, vinculaciones de salida, o ambas. Los datos de los enlaces se proporcionan a la función como parámetros.

Serverless, sin servidor, Microsoft Azure Functios

Google Cloud Functions

Google Cloud Functions es una plataforma FaaS escalable de pago por uso. Tiene capacidad integrada de supervisión, registro y depuración, seguridad incorporada a nivel de función y por función, y capacidades de red clave para escenarios de nube híbrida y multicloud. Le permite conectarse a Google Cloud o a servicios en la nube de terceros a través de activadores para agilizar los problemas de orquestación más difíciles.

Google Cloud Functions admite código en Go, Java, Node.js (véase la captura de pantalla siguiente) y Python. Cloud Functions admite solicitudes HTTP utilizando métodos de solicitud HTTP comunes como GET, PUT, POST, DELETE y OPTIONS, así como funciones en segundo plano para gestionar eventos de su infraestructura en la nube. Puede utilizar Cloud Build u otra plataforma CI/CD para probar y desplegar automáticamente las funciones de la nube, junto con un repositorio de código fuente como GitHub, Bitbucket o Cloud Source Repositories. También puede desarrollar y desplegar Cloud Functions desde su máquina local.

Serverless, sin servidor, Google Cloud Functions

IBM Cloud Functions

Basada en Apache OpenWhisk, IBM Cloud Functions es una plataforma de programación políglota de funciones como servicio para desarrollar código ligero que se ejecuta y escala bajo demanda. Puede desarrollar IBM Cloud Functions en Node.js (ver captura de pantalla más abajo), Python, Swift y PHP. IBM destaca la integración entre Cloud Functions y las APIs de Watson dentro del flujo de trabajo evento-desencadenante-acción, para que el análisis cognitivo de los datos de la aplicación forme parte de sus flujos de trabajo sin servidor.

serverless, sin servidor, IBM Cloud Functions

Oracle Cloud Functions y el proyecto Fn

Oracle Cloud Functions es una plataforma sin servidor que permite a los desarrolladores crear, ejecutar y escalar aplicaciones sin gestionar ninguna infraestructura. Las funciones se integran con la infraestructura de Oracle Cloud, los servicios de plataforma y las aplicaciones SaaS. Dado que Oracle Cloud Functions se basa en el proyecto Fn de código abierto, los desarrolladores pueden crear aplicaciones que pueden ser portadas a otros entornos en la nube y en las instalaciones. Oracle Cloud Functions admite código en Python (véase la captura de pantalla siguiente), Go, Java, Ruby y Node.js.

serverless, sin servidor, Oracle Cloud Functions, Fn Proyect

Cloudflare Workers

Cloudflare es una red de borde más conocida por proteger los sitios web de los ataques de denegación de servicio distribuidos (DDoS). Los Cloudflare Workers le permiten desplegar código sin servidor en la red de borde global de Cloudflare, donde se ejecutan en V8 Isolates, que tienen una sobrecarga mucho menor que los contenedores o las máquinas virtuales. Puede escribir Cloudflare Workers en JavaScript (ver captura de pantalla más abajo), Rust, C, C++, Python o Kotlin.

Los Cloudflare Workers no sufren problemas de arranque en frío como la mayoría de los otros frameworks sin servidor. Los aislados V8 pueden calentarse en menos de cinco milisegundos. Además, Cloudflare comienza a cargar un trabajador en respuesta al apretón de manos TLS inicial, lo que normalmente significa que la sobrecarga efectiva de arranque en frío desaparece por completo, ya que el tiempo de carga es menor que la latencia del sitio en la mayoría de los casos.

serverless, sin servidor, Cloudflare Workers

Serverless Framework

Serverless Framework es una forma de evitar la dependencia del proveedor con las funciones como servicio, al menos parcialmente, generando el código de la función localmente. Bajo el capó, la CLI de Serverless Framework despliega su código a una plataforma FaaS como AWS Lambda, Microsoft Azure Functions, Google Cloud Functions, Apache OpenWhisk o Cloudflare Workers, o a una solución basada en Kubernetes como Kubeless o Knative. También se puede probar localmente. Por otro lado, muchas de las plantillas de servicio de Serverless Framework son específicas para un proveedor de nube y un lenguaje en particular, como AWS Lambda y Node.js (ver captura de pantalla más abajo).

Los componentes sin servidor se construyen en torno a casos de uso de orden superior (por ejemplo, un sitio web, un blog, un sistema de pago, un servicio de imágenes). Un complemento es un código JavaScript personalizado que crea nuevos comandos o extiende los comandos existentes dentro del Serverless Framework.

Serverless Framework Open Source soporta código en Node.js, Python, Java, Go, C#, Ruby, Swift, Kotlin, PHP, Scala, y más. Serverless Framework Pro proporciona las herramientas que necesitas para gestionar el ciclo de vida completo de las aplicaciones sin servidor, incluyendo CI/CD, monitorización y resolución de problemas.

serverless, sin servidor, Serverless Framework

Apache OpenWhisk

OpenWhisk es una plataforma de funciones sin servidor de código abierto para construir aplicaciones en la nube. OpenWhisk ofrece un rico modelo de programación para crear APIs sin servidor a partir de funciones, componiendo funciones en flujos de trabajo sin servidor, y conectando eventos a funciones usando reglas y disparadores.

Puede ejecutar una pila de OpenWhisk localmente, o desplegarla en un clúster de Kubernetes, ya sea uno propio o un clúster de Kubernetes gestionado de un proveedor de nube pública, o utilizar un proveedor de nube que soporte completamente OpenWhisk, como IBM Cloud. Actualmente, OpenWhisk es compatible con código escrito en Ballerina, Go, Java, JavaScript (véase la captura de pantalla siguiente), PHP, Python, Ruby, Rust, Swift y .NET Core; también puede suministrar su propio contenedor Docker.

El proyecto OpenWhisk incluye una serie de herramientas para desarrolladores. Éstas incluyen la interfaz de línea de comandos wsk para crear, ejecutar y gestionar fácilmente las entidades de OpenWhisk; wskdeploy para ayudar a desplegar y gestionar todos sus paquetes, acciones, activadores, reglas y APIs de OpenWhisk desde un único comando utilizando un manifiesto de aplicación; la API REST de OpenWhisk; y los clientes de la API de OpenWhisk en JavaScript y Go.

serverless, sin servidor, Apache OpenWhisk

Fission

Fission es un marco sin servidor de código abierto para Kubernetes con un enfoque en la productividad del desarrollador y el alto rendimiento. Fission opera solo con el código: Docker y Kubernetes se abstraen en el funcionamiento normal, aunque puede utilizar ambos para extender Fission si lo desea.

Fission es extensible a cualquier lenguaje. El núcleo está escrito en Go, y las partes específicas del lenguaje están aisladas en algo llamado entornos. Actualmente Fission soporta funciones en Node.js, Python, Ruby, Go, PHP y Bash, así como cualquier ejecutable de Linux.

Fission mantiene un conjunto de contenedores "calientes" que contienen cada uno un pequeño cargador dinámico. Cuando se llama a una función por primera vez, es decir, cuando se "inicia en frío", se elige un contenedor en funcionamiento y se carga la función. Esta reserva es lo que hace que Fission sea rápido. Las latencias de arranque en frío suelen ser de unos 100 milisegundos.

Knative

Knative, creado por Google con contribuciones de más de 50 empresas diferentes, ofrece un conjunto esencial de componentes para construir y ejecutar aplicaciones sin servidor en Kubernetes. Los componentes de Knative se centran en resolver tareas mundanas pero difíciles, como el despliegue de un contenedor, el enrutamiento y la gestión del tráfico con el despliegue azul/verde, el escalado automático y el dimensionamiento de las cargas de trabajo en función de la demanda, y la vinculación de los servicios en ejecución a los ecosistemas de eventos. El servicio Google Cloud Run está construido a partir de Knative.

Kubeless

Kubeless es un marco de trabajo sin servidor nativo de Kubernetes, de código abierto, diseñado para el despliegue sobre un clúster de Kubernetes, y para aprovechar las primitivas de Kubernetes. Kubeless reproduce gran parte de la funcionalidad de AWS Lambda, Microsoft Azure Functions y Google Cloud Functions. Puede escribir funciones Kubeless en Python, Node.js, Ruby, PHP, Golang, .NET y Ballerina. Los activadores de eventos de Kubeless utilizan el sistema de mensajería Kafka y los eventos HTTP.

Kubeless utiliza una definición de recursos personalizados de Kubernetes para poder crear funciones como recursos personalizados de Kubernetes. A continuación, ejecuta un controlador en el clúster que vigila estos recursos personalizados y lanza tiempos de ejecución bajo demanda. El controlador inyecta dinámicamente el código de sus funciones en los tiempos de ejecución y los pone a disposición a través de HTTP o mediante un mecanismo de publicación/suscripción.

OpenFaaS

OpenFaaS es un marco sin servidor de código abierto para Kubernetes con el lema "Funciones sin servidor simplificadas". OpenFaaS forma parte de la pila "PLONK" de tecnologías nativas de la nube: Prometheus (sistema de monitorización y base de datos de series temporales), Linkerd (malla de servicios), OpenFaaS, NATS (mensajería segura y streaming) y Kubernetes. Puedes utilizar OpenFaaS para desplegar funciones y microservicios basados en eventos en Kubernetes utilizando su Template Store o un Dockerfile.

Cómo elegir una plataforma sin servidor en la nube

Con todas esas opciones, ¿cómo puede elegir solo una? Como en casi todas las cuestiones de arquitectura de software, depende.

Para empezar, debe evaluar el estado de software existente y sus objetivos. Una organización que comienza con aplicaciones heredadas escritas en Cobol y que se ejecutan en mainframes internos tiene un camino muy diferente que una organización que tiene un amplio patrimonio de software en la nube.

Para las organizaciones con un estado en la nube, vale la pena hacer una lista de sus implementaciones, las nubes que utilizan y las zonas de disponibilidad. También vale la pena conocer la ubicación de sus clientes y usuarios, y los patrones de uso de sus servicios.

Por ejemplo, una aplicación que se utiliza 24 horas al día, 7 días a la semana, con un nivel de carga constante, no es probablemente un buen candidato para la implementación sin servidor: Un servidor de tamaño adecuado, una máquina virtual o un clúster de contenedores podría ser más barato y más fácil de gestionar. Por otro lado, una aplicación que se utiliza a intervalos irregulares y a escalas muy variables, y que se activa por una acción importante (como una revisión del código fuente) podría ser un candidato perfecto para una arquitectura sin servidor.

Un servicio con requisitos de baja latencia que se utiliza en todo el mundo podría ser un buen candidato para el despliegue en muchas zonas de disponibilidad o puntos de presencia de borde. Un servicio utilizado únicamente en Washington, DC, podría desplegarse en una única zona de disponibilidad en Virginia.

Una empresa que tenga experiencia con Kubernetes podría considerar una de las plataformas sin servidor de código abierto que se despliegan en Kubernetes. Una organización que carezca de experiencia con Kubernetes podría estar mejor desplegada en una infraestructura FaaS nativa de la nube, tanto si el marco es de código abierto, como el Serverless Framework, como si es propietario, como AWS Lambda, Google Cloud Functions o Azure Functions.

Si la aplicación sin servidor que está construyendo depende de una base de datos en la nube o de un servicio de streaming, entonces debería considerar desplegarlos en la misma nube para minimizar las latencias intra-aplicación. Esto no limita demasiado su elección de framework. Por ejemplo, una aplicación que tiene un almacén de datos de Google Cloud Bigtable puede tener su componente sin servidor en Google Cloud Functions, Google Cloud Run, Serverless Framework, OpenWhisk, Kubeless, OpenFaaS, Fission o Knative, y aun así es probable que muestre una latencia mínima.

En muchos casos su aplicación será igual o similar a los casos de uso comunes. Vale la pena comprobar los ejemplos y las bibliotecas de las plataformas sin servidor que estás considerando para ver si hay una arquitectura de referencia que haga el trabajo por usted. No es que la mayoría de las funciones como servicio requieran escribir mucho código: Más bien, la reutilización de código para FaaS aprovecha arquitecturas bien probadas y comprobadas y evita la necesidad de hacer mucha depuración.

Puede ver también