Serverless computing
# Serverless computing

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.

Serverless computing puede 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).

## 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.

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

A veces, serverless es erróneamente considerado más seguro que las arquitecturas tradicionales. Si bien es cierto que es verdad hasta cierto punto ya que el proveedor de la nube se encarga de las vulnerabilidades en el Sistema Operativo, el conjunto total de los ataque es significativamente mayor ya que hay muchos más componentes en la aplicación en comparación con las arquitecturas tradicionales y cada uno de sus componentes es un punto de acceso a la aplicación serverless. Es más, las soluciones de seguridad que los clientes solían tener para proteger sus cargas de trabajo (workloads) pasaron a ser irrelevantes ya que los clientes no pueden controlar ni instalar nada en el endpoint ni en el nivel de red, como un sistema de detección/prevención de intrusiones (IDS/IPS).

Esto se ve intensificado por las propiedades monoculturales de toda la red de servidores. (Una sola falta puede aplicarse globalmente.) Según Protego, la "solución para asegurar las aplicaciones serverless es una estrecha colaboración entre desarrolladores, DevOps y AppSec, también conocida como DevSecOps. Encontrar el equilibrio en el que los desarrolladores no son dueños de la seguridad, pero tampoco están exentos de responsabilidad. Tomar medidas para que sea un problema de todos. Crear equipos interfuncionales y trabajar para lograr una estrecha integración entre los especialistas en seguridad y los equipos de desarrollo. Colaborar para que la organización pueda resolver los riesgos de seguridad a la velocidad de los servidores."

### Privacidad

Muchos entornos funcionales serverless se basan en propietarios de entornos públicos en la nube . Aquí, deben de considerarse algunas implicaciones de privacidad, como recursos compartidos y acceso de empleados externos. Aun así, también puede hacerse serverless computing en entornos de nube privada o incluso on-premises utilizando, por ejemplo, la plataforma de Kubernetes. Esto da a las compañías control total de los mecanismos de privacidad, justo como con los hosting en las configuraciones tradicionales de servidor.

### Estándares

Serverless computing está cubierta por la International Data Center Authority (IDCA) en su Marco AE360. Sin embargo, la parte relacionada con la portabilidad puede ser un problema a la hora de trasladar la lógica empresarial de una nube pública a otra para la que se creó la solución Docker. La Cloud Native Computing Foundation (CNCF) también está trabajando en el desarrollo de una especificación con Oracle.

### Bloqueo de vendedores

Serverless computing se proporciona como un servicio de terceros. Las aplicaciones y el software que se ejecutan en el entorno sin servidor están bloqueados por defecto a un proveedor de nube específico. Por tanto, serverless puede causar múltiples problemas durante su migración.

