Serverless computing es un modelo de ejecución de computación en la nube en el que el proveedor de los servicios en la nube destina por demanda recursos de las máquinas virtuales, cuidando de los servidores por sus clientes. "Serverless" (sin servidor) es un término poco adecuado ya que los servidores todavía se utilizan por parte de los proveedores de servicio en la nube para ejecutar código para los desarrolladores. Aun así, los desarrolladores de aplicaciones serverless no se preocupan con la planificación de capacidad, la configuración, la administración, el mantenimiento, la tolerancia a fallos, o con la escalada de contenedores, VMs, o servidores físicos. Serverless computing no mantiene recursos en la memoria volátil; la computación se realiza en ráfagas cortas con resultados persistentes para almacenamiento. Cuando una aplicación no está en uso, no hay recursos de computación destinados a ella. El precio se basa en la cantidad real de recursos consumidos por aplicación. Puede ser una forma de computación bajo demanda.

Para entender el concepto de Serverless computing, en la creación de aplicaciones, los desarrolladores se enfrentan a una serie de tareas adicionales de administración del servidor que deben realizarse para implementar su código, Todos estos factores generan tiempos de ejecución prolongados y ocasiona gastos de operación que pueden ocasionar la ralentización de los equipos de desarrollo.

Las redes sin servidores buscan a que los desarrolladores experimenten una experiencia invisible "sin el uso de servidores", por lo que los desarrolladores no se verían en la necesidad de pensar en servidores o cualquier razón en la que una aplicación necesite para ejecutarse. Por tal motivo, el proveedor de servicios realiza todo el trabajo en segundo plano para asegurarse de que se tengan los recursos para ejecutar el código y cumplir con los requisitos sin que se le cobre por la capacidad inactiva.

Las redes sin servidores pueden simplificar el proceso de desplegar código para producción. El código serverless se puede utilizar conjuntamente con el código desplegado en estilos tradicionales, como microservicios o aplicaciones monolíticas. Alternativamente, las aplicaciones se pueden escribir para ser puramente serverless (sin servidor) y no utilizar ningún servidor provisto. Esto no se debe confundir con modelos de red o computación que no requieran de un servidor real para funcionar, como peer-to-peer (P2P).

Componentes clave del Serverless Computing Las redes sin servidores comprenden una variedad de servicios que facilitan el desarrollo y la implementación de aplicaciones en la nube. Entre estos servicios se incluyen:

Función como Servicio (FaaS): Este servicio puede ejecutar código con base a una respuesta a eventos o solicitudes, sin necesidad de gestionar el hardware que viene incluido. Esto permite que los desarrolladores solo paguen por los recursos que realmente utilizan. Almacenamiento de Objetos y Bases de Datos: Las bases de datos sin servidor pueden combinar las ventajas de las arquitecturas tradicionales con características modernas, como el pago por uso, la gestión por parte del proveedor y el escalado automático. El almacenamiento de objetos está diseñado para que se puedan manejar grandes volúmenes de datos no estructurados, lo cual los métodos tradicionales no pueden hacer eficazmente. Transmisión y Mensajería de Eventos: Este componente maneja la recepción y transmisión de eventos, dirigiéndolos tanto a la al servicio FaaS como a la base de datos, donde se activan las funciones correspondientes. Si llega a ocurrir un error durante este proceso, los eventos se guardan en una cola para su procesamiento. Puerta de Enlace API: Sirve como un proxy inverso que recibe todas las solicitudes dirigidas para la API. Sus funciones se basan en el enrutamiento, la limitación de velocidad, la autenticación de usuarios y otras tareas administrativas que facilitan la integración y conectividad mediante APIs.

En conjunto, estos servicios ayudan a los desarrolladores a que puedan construir aplicaciones sin la necesidad de preocuparse por la infraestructura que manejen, por lo que se optimizan costos y esfuerzos con solo pagar únicamente por lo que se utiliza.

Tiempo de ejecución Serverless Los vendedores de servicios Serverless ofrecen tiempos de computación, también conocidos como plataformas de Función como Servicio (FaaS), las cuales ejecutan lógica aplicada pero no almacenan datos. Los lenguajes comunes aceptados por los tiempos de ejecución serverless son Java, Python y PHP. Generalmente, las funciones se ejecutan en entornos aislados, como por ejemplo, contenedores de Linux.

Ofertas comerciales La primera plataforma de ejecución de código "con crédito de prepago" fue Zimki, publicado en 2006, pero no fue comercialmente exitoso. En 2008, Google publicó Google App Engine, el cual tenía un sistema de facturación por niveles para aplicaciones que utilizaba un framework de Python hecho para ello, pero no podía ejecutar código arbitrario. PiCloud, publicado en 2010, ofrecía soporte FaaS para Python. Kubeless y Fission son dos plataformas FaaS de Código abierto que se ejecutan con Kubernetes.

Google App Engine, introducido en 2008, fue el primer serverless computing abstracto en el mercado. El motor de aplicación (App Engine) incluía funciones HTTP con un timeout de 60 segundos, y un almacenamiento BLOB y de datos con sus propios timeouts. No se permitía la persistencia en memoria. Todas las operaciones tenían que ejecutarse dentro de estos límites, pero esto permitía que las aplicaciones construidas en el Motor de Aplicación escalaran casi infinitamente y fue utilizado como soporte para los primeros clientes, incluyendo a Snapchat, así como muchas aplicaciones internas y externas de Google. El lenguaje admitido se limitaba a Python al usar módulos nativos de ese lenguaje, al igual que una selección limitada de módulos de Python en C que fueron elegidos por Google. Como en plataformas serverless posteriores, su motor de aplicación también utilizaba la tarificación pague-por-lo-que-use.

AWS Lambda, introducido por Amazon en 2014, popularizó el modelo abstracto de serverless computing. Soporta herramientas serverless adicionales de AWS como AWS Serverless Application Model (AWS SAM) Amazon CloudWatch, y otros.

La plataforma en la Nube de Google (Google Cloud Platform) creó una segunda oferta de serverless, Google Cloud Functions en 2016.

IBM oferta IBM Cloud Functions en la nube pública de IBM desde 2016. IBM añadió un segundo producto serverless, IBM Cloud Code Engine en 2021.

Microsoft Azure ofrece Azure Functions, ofreció ambos en la nube pública de Azure o on-premises (en local) vía Azure Stack.

Cloudflare ofrece Cloudflare Workers, desde 2017.

Fastly ofrece Compute@edge, desde 2019.

Bases de datos serverless Varias bases de datos serverless han surgido en los últimos años. Estos sistemas extienden el modelo de ejecución serverless al RDBMS, eliminando la necesidad de provisión, escala virtualizada o hardware físico de bases de datos.

Nutanix ofrece una solución denominada Era que convierte un RDBMS existente como Oracle, MariaDB, PostgreSQL o Microsoft SQL Server en un servicio serverless.https://www.nutanix.com/products/era/

Amazon Aurora ofrece una versión serverless de sus bases de datos, basado en MySQL y PostgreSQL, proporciona configuraciones bajo demanda y auto escalables.

Azure Data Lake es un almacenamiento de datos altamente escalable y un servicio de análisis de datos. El servicio se encuentra en Azure, la nube pública de Microsoft. Azure Data Lake Analytics proporciona una infraestructura distribuida que dinámicamente destinan o retiran recursos de modo que los clientes pagan únicamente por los servicios que utilizan.

Firebase, también propiedad de Google, incluye una base de datos jerárquica y está disponible en planes fijos y con crédito de prepago.

Confluent, proporciona a través de tres grandes nubes una implementación serverless de Apache Kafka (un sistema de procesamiento de streaming de eventos y almacenamiento). Su infraestructura abstracta se paga por uso y auto escaladas.

Ventajas

Coste Serverless puede ser más eficaz en cuanto a costes que alquilar o comprar una cantidad fija de servidores, que generalmente incluye periodos significativos de bajo uso o tiempo de inactividad. Puede que sea incluso más eficaz que proveerse de un grupo auto escalable, debido a un bin-packing más eficiente de los recursos subyacentes de la máquina. Esto se puede describir como una computación de prepago o de código simple ya que los cargos aplicados se basan únicamente sobre el tiempo y memoria asociados al ejecutar el código, sin pagos asociados por tiempo de inactividad. Los beneficios inmediatos de coste están relacionados con la carencia de costes operativos, lo que incluye: licencias, instalación, dependencias, y el coste del personal de mantenimiento, soporte, o parches. La carencia de coste de personal es una ventaja que se aplica en términos generales a computación en nube.

Elasticidad versus escalabilidad Además, una arquitectura serverless significa que los desarrolladores y operadores no necesitan perder tiempo instalando y configurando las políticas de auto escalabilidad o sistemas; el proveedor de la nube es el responsable de asociar la capacidad de escalabilidad a la demanda. Como Google dice: "del prototipo a la producción y a escala planeta."

Como los sistemas nativos en la nube se pueden escalar inherentemente hacia arriba y hacia abajo, se los conoce como elásticos más que como escalables.

Los pequeños equipos de desarrolladores pueden ejecutar código ellos mismo sin depender de equipos de infraestructuras ni ingenieros de soporte; cada vez más desarrolladores se convierten en hábiles DevOps y las distinciones entre ser un desarrollador de software o de hardware son cada vez más difusas.

Productividad Con FaaS, las unidades de código expuesto al mundo exterior son funciones guiadas por eventos simples. Esto significa que el programador no tiene que preocuparse por el multihilo ni manejar directamente las peticiones HTTP en su código, simplificando la tarea de desarrollo de software backend.

Desventajas

Rendimiento El código que no se usa frecuentemente en serverless puede sufrir de mucha más latencia en su respuesta que el código que se ejecuta continuamente en un servidor dedicado, una máquina virtual o un contenedor. Esto se debe a que, a diferencia del auto escalado, el proveedor en la nube reduce la velocidad de lectura y escritura ("spins down") completamente el código serverless cuando no se usa. Esto significa que si el tiempo de ejecución (por ejemplo, el tiempo de ejecución de Java) requiere una cantidad significativa de tiempo para empezar, se creará una latencia adicional.

Límites de los recursos Serverless computing no es adecuado para algunas cargas de trabajo computacionales, como la computación de rendimiento alto, debido a los límites impuestos en los recursos por parte de los proveedores de la nube, y también porque probablemente sea más barato aprovisionar de forma masiva el número de servidores que se cree necesario en un momento dado.

Monitorización y depuración El diagnóstico del rendimiento o de los problemas del uso excesivo de los recursos puede ser más difícil con el código serverless que con el código tradicional de servidor, ya que aunque se pueden cronometrar funciones enteras, normalmente no se puede profundizar en los detalles conectando analistas de rendimiento (profilers), depuradores o herramientas APM. Además, el entorno en el que se ejecuta el código no es de código abierto, así que las características de su rendimiento no pueden ser replicadas de forma precisa en un entorno local.

Seguridad