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.[1]​ 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. [2]​

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.[3]​

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.[4]​ 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 [5]​.

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.[6]​ 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.[7]​ PiCloud, publicado en 2010, ofrecía soporte FaaS para Python.[8]​


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.[9]​ 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.[10]​

AWS Lambda, introducido por Amazon en 2014,[11]​ 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.[12]​

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

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

Cloudflare ofrece Cloudflare Workers, desde 2017.[16]​

Fastly ofrece Compute@edge, desde 2019.[17]​

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.[18]​

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,[19]​ incluye una base de datos jerárquica y está disponible en planes fijos y con crédito de prepago.[20]​

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,[21]​ que generalmente incluye periodos significativos de bajo uso o tiempo de inactividad.[1]​ 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[21]​ o de código simple[21]​ 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.[21]​


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.[21]​ 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.[1]​[15]​[21]​ Como Google dice: "del prototipo a la producción y a escala planeta."[21]​

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.[21]​

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.[22]​

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.[23]​

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,[4]​ normalmente no se puede profundizar en los detalles conectando analistas de rendimiento (profilers), depuradores o herramientas APM.[24]​ 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).[25]​


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."[26]​

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.[27]​ 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.[28]​

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.[29]​ Por tanto, serverless puede causar múltiples problemas durante su migración.[30]​

Véase también

Referencias

  1. ↑ a b c Miller, Ron (24 de noviembre de 2015). «AWS Lambda Makes Serverless Applications A Reality». TechCrunch. Consultado el 10 de julio de 2016. 
  2. ↑ «¿Qué es la computación sin servidor? | IBM». www.ibm.com. 13 de octubre de 2021. Consultado el 20 de noviembre de 2024. 
  3. ↑ «What is serverless computing». Google Cloud (en inglés). Consultado el 20 de noviembre de 2024. 
  4. ↑ a b MSV, Janakiram (16 de julio de 2015). «PaaS Vendors, Watch Out! Amazon Is All Set To Disrupt the Market». Consultado el 10 de julio de 2016. 
  5. ↑ Moura, Paulo (6 de diciembre de 2022). «¿Qué es serverless? | Azion». Azion Technologies. Consultado el 20 de noviembre de 2024. 
  6. ↑ Williams, Christopher. «Fotango to smother Zimki on Christmas Eve». Consultado el 11 de junio de 2017. 
  7. ↑ «Python Runtime Environment | App Engine standard environment for Python | Google Cloud Platform». Google Cloud Platform (en inglés). Consultado el 11 de junio de 2017. 
  8. ↑ «PiCloud Launches Serverless Computing Platform To The Public». TechCrunch (en inglés estadounidense). Consultado el 17 de diciembre de 2018. 
  9. ↑ Evans, Jon. TechCrunch https://techcrunch.com/2015/04/11/whatever-happened-to-paas/. Consultado el 17 de diciembre de 2020.  Falta el |título= (ayuda)
  10. ↑ «Google App Engine Offers Pricing Plan Beyond Quotas; Grab A Free I/O Ticket To Celebrate». TechCrunch. Consultado el 17 de diciembre de 2020. 
  11. ↑ Miller, Ron (13 de noviembre de 2014). «Amazon Launches Lambda, An Event-Driven Compute Service». TechCrunch. Consultado el 10 de julio de 2016. 
  12. ↑ Novet, Jordan (9 de febrero de 2016). «Google has quietly launched its answer to AWS Lambda». VentureBeat. Consultado el 10 de julio de 2016. 
  13. ↑ Zimmerman, Mike (23 de febrero de 2016). «IBM Unveils Fast, Open Alternative to Event-Driven Programming». 
  14. ↑ «IBM Cloud Code Engine Is Now Generally Available». www.ibm.com (en inglés estadounidense). Consultado el 4 de mayo de 2021. 
  15. ↑ a b Miller, Ron (31 de marzo de 2016). «Microsoft answers AWS Lambda's event-triggered serverless apps with Azure Functions». TechCrunch. Consultado el 10 de julio de 2016. 
  16. ↑ Varda, Kenton (29 de septiembre de 2017). «Introducing Cloudflare Workers: Run JavaScript Service Workers at the Edge». Cloudflare. 
  17. ↑ «Fastly Expands Serverless Capabilities With the Launch of Compute@Edge». Fastly. 6 de noviembre de 2019. 
  18. ↑ https://www.nutanix.com/products/era/
  19. ↑ Lardinois, Frederic. «Google Acquires Firebase To Help Developers Build Better Real-Time Apps | TechCrunch». Consultado el 11 de junio de 2017. 
  20. ↑ Darrow, Barb (20 de junio de 2013). «Firebase gets $5.6M to launch its paid product and fire up its base». gigaom.com (en inglés estadounidense). Archivado desde el original el 3 de octubre de 2021. Consultado el 11 de junio de 2017. 
  21. ↑ a b c d e f g h Jamieson, Frazer (4 de septiembre de 2017). «Losing the server? Everybody is talking about serverless architecture». 
  22. ↑ van Eyk, Erwin; Iosup, Alexandru; Abad, Cristina L.; Grohmann, Johannes; Eismann, Simon (2018). A SPEC RG Cloud Group's Vision on the Performance Challenges of FaaS Cloud Architectures. pp. 21-24. doi:10.1145/3185768.3186308. 
  23. ↑ Hellerstein, Joseph; Faleiro, Jose; Gonzalez, Joseph; Schleier-Smith, Johann; Screekanti, Vikram; Tumanov, Alexey; Wu, Chenggang (2019). Serverless Computing: One Step Forward, Two Steps Back. 
  24. ↑ Leitner, Philipp; Wittern, Erik; Spillner, Josef; Hummer, Waldemar (2019). «A mixed-method empirical study of Function-as-a-Service software development in industrial practice». Journal of Systems and Software 149: 340-359. ISSN 0164-1212. doi:10.1016/j.jss.2018.12.013. 
  25. ↑ https://www.puresec.io/serverless-security-top-12-csa-puresec
  26. ↑ Solow, Hillel (5 de febrero de 2019). «Serverless Computing Security Risks & Challenges». protego.io (en inglés estadounidense). Archivado desde el original el 4 de enero de 2020. Consultado el 20 de marzo de 2019. 
  27. ↑ https://www.idc-a.org/ae360
  28. ↑ «CNCF, Oracle Boost Serverless Standardization Efforts» (en inglés estadounidense). Consultado el 24 de noviembre de 2018. 
  29. ↑ Bashir, Faizan (28 de mayo de 2018). «What is Serverless Architecture? What are its Pros and Cons?». Hacker Noon. Consultado el 3 de abril de 2019. 
  30. ↑ «What Is Serverless? Here's a Plain Answer!». Squadex (en inglés estadounidense). 17 de enero de 2019. Consultado el 3 de abril de 2019. 

Enlaces externos