La computación sin servidor es un modelo de ejecución de computación en la nube en el que el proveedor de la nube asigna recursos de la máquina a pedido, ocupándose de los servidores en nombre de sus clientes. Sin servidor es un nombre inapropiado en el sentido de que los proveedores de servicios en la nube aún utilizan servidores para ejecutar código para los desarrolladores . Sin embargo, los desarrolladores de aplicaciones sin servidor no se preocupan por la planificación de la capacidad , la configuración, la administración, el mantenimiento, la tolerancia a fallas o el escalado de contenedores, máquinas virtuales o servidores físicos. Cuando una aplicación no está en uso, no hay recursos informáticos asignados a la aplicación. El precio se basa en la cantidad real de recursos consumidos por una aplicación. [1] Puede ser una forma de computación de utilidad .
Una definición propuesta para la computación sin servidor que abarca estas ideas es que la computación sin servidor es un "paradigma de computación en la nube que abarca una clase de plataformas de computación en la nube que permiten desarrollar, implementar y ejecutar aplicaciones (o componentes de las mismas) en la nube sin asignar ni administrar servidores y recursos virtualizados ni preocuparse por otros aspectos operativos. La responsabilidad de los aspectos operativos, como la tolerancia a fallas o el escalamiento elástico de los recursos de computación, almacenamiento y comunicación para adaptarse a las diferentes demandas de las aplicaciones, se descarga al proveedor de la nube. Los proveedores aplican una facturación basada en la utilización: cobran a los usuarios de la nube con granularidad fina, en proporción a los recursos que las aplicaciones realmente consumen de la infraestructura de la nube, como tiempo de computación, memoria y espacio de almacenamiento ". [2] Tenga en cuenta que la definición de sin servidor se ha ampliado con el tiempo. Según Ben Kehoe, sin servidor es un espectro; uno no debe obsesionarse con una definición estricta de sin servidor ni con ninguna tecnología sin servidor específica. En cambio, uno debe centrarse en la mentalidad sin servidor: cómo usar sin servidor para resolver los problemas comerciales de uno. [3]
La computación sin servidor puede simplificar el proceso de implementación de código en producción . No elimina por completo la complejidad, sino que principalmente la traslada del equipo de operaciones al equipo de desarrollo. Y cuanto más detallada sea la aplicación, más difícil será administrarla. [ Aclaración necesaria ] [4]
El código sin servidor se puede utilizar junto con el código implementado en estilos tradicionales, como microservicios o monolitos . Alternativamente, las aplicaciones se pueden escribir para que sean puramente sin servidor y no utilicen servidores aprovisionados en absoluto. [5] Esto no debe confundirse con los modelos informáticos o de redes que no requieren un servidor real para funcionar, como peer-to-peer (P2P).
Según Yan Cui, la tecnología sin servidor solo debería adoptarse cuando ayude a ofrecer valor al cliente más rápidamente. Y, al mismo tiempo, las organizaciones deberían dar pequeños pasos y reducir los riesgos a lo largo del camino. [6]
Los proveedores sin servidor ofrecen entornos de ejecución de cómputo que ejecutan la lógica de la aplicación, pero no almacenan datos. Los modelos de entornos de ejecución comunes son la función como servicio (FaaS) y el contenedor como servicio . Los lenguajes comunes compatibles con los entornos de ejecución sin servidor son Java , Python y PHP . Por lo general, las funciones se ejecutan dentro de límites de aislamiento, como los contenedores de Linux .
La primera plataforma de ejecución de código de pago por uso fue Zimki , lanzada en 2006, pero no tuvo éxito comercial. [7] En 2008, Google lanzó Google App Engine , que incluía facturación medida para aplicaciones que usaban un marco Python personalizado, pero no podían ejecutar código arbitrario. [8] PiCloud, lanzado en 2010, ofrecía soporte FaaS para Python.
Google App Engine, presentado en 2008, fue la primera oferta de computación abstracta sin servidor. [9] App Engine incluía funciones HTTP con un tiempo de espera de 60 segundos y un almacén de blobs y un almacén de datos con sus propios tiempos de espera. No se permitía la persistencia en memoria. Todas las operaciones debían ejecutarse dentro de estos límites, pero esto permitió que las aplicaciones creadas en App Engine escalaran casi infinitamente y se utilizó para brindar soporte a los primeros clientes, incluido Snapchat , así como muchas aplicaciones internas y externas de Google. El soporte de lenguaje se limitó a Python utilizando módulos nativos de Python, así como una selección limitada de módulos de Python en C que fueron elegidos por Google. Al igual que las plataformas sin servidor posteriores, App Engine también utilizó la facturación de pago por uso. [10]
AWS Lambda , presentado por Amazon en 2014, [11] popularizó el modelo abstracto de computación sin servidor. Cuenta con el respaldo de varias herramientas sin servidor de AWS adicionales, como AWS Serverless Application Model (AWS SAM) , Amazon CloudWatch y otras.
Google Cloud Platform creó una segunda oferta sin servidor, Google Cloud Functions , en 2016. [12]
Oracle Cloud Functions es una plataforma sin servidor que se ofrece en Oracle Cloud Infrastructure y se basa en el proyecto Fn de código abierto, de modo que los desarrolladores pueden crear aplicaciones que se puedan trasladar a otros entornos locales y en la nube. Admite código en Python , Go , Java , Ruby y Node . [13]
Han surgido varias bases de datos sin servidor para extender el modelo de ejecución sin servidor al RDBMS , eliminando la necesidad de aprovisionar o escalar hardware de base de datos física o virtualizada .
Nutanix ofrece una solución llamada Era que convierte un RDBMS existente como Oracle , MariaDB , PostgreSQL o Microsoft SQL Server en un servicio sin servidor. [14]
Amazon Aurora ofrece una versión sin servidor de sus bases de datos, basada en MySQL y PostgreSQL, que proporciona configuraciones de escalamiento automático a pedido. [15]
Azure Data Lake es un servicio de análisis y almacenamiento de datos altamente escalable. El servicio está alojado en Azure , la nube pública de Microsoft. Azure Data Lake Analytics proporciona una infraestructura distribuida que puede asignar o desasignar recursos de forma dinámica para que los clientes paguen solo por los servicios que utilizan.
Oracle Cloud ofrece una versión sin servidor de su Oracle Autonomous Database, que es el servicio de procesamiento de transacciones autónomo. El servicio sin servidor también incluye una edición JSON. [16]
Firebase , también propiedad de Google, [17] incluye una base de datos jerárquica y está disponible a través de planes fijos y de pago por uso. [18]
La tecnología sin servidor puede resultar más rentable que alquilar o comprar una cantidad fija de servidores, [19] lo que generalmente implica períodos significativos de subutilización o tiempo de inactividad. [1] Incluso puede resultar más rentable que aprovisionar un grupo de escalamiento automático , debido a un empaquetamiento más eficiente de los recursos subyacentes de la máquina.
Esto se puede describir como computación de pago por uso [19] o código desnudo [19] , ya que se cobra únicamente en función del tiempo y la memoria asignados para ejecutar el código, sin tarifas asociadas por tiempo de inactividad. [19] Una analogía útil aquí es entre el alquiler de automóviles (máquinas virtuales en la nube tradicionales) versus aplicaciones de viajes compartidos como Uber o Lyft (computación sin servidor). Los beneficios de costos inmediatos están relacionados con la falta de costos operativos, incluidos: licencias, instalación, dependencias y costos de personal para mantenimiento, soporte o parches. [19] Debido a la escalabilidad infinita, los desarrolladores pueden sufrir un shock en la factura como resultado de un código defectuoso o un ataque de denegación de servicio . Sin embargo, esto a menudo se reembolsa, a expensas del proveedor de servicios. [20]
Además, una arquitectura sin servidor significa que los desarrolladores y operadores no necesitan dedicar tiempo a configurar y ajustar políticas o sistemas de escalado automático; el proveedor de la nube es responsable de escalar la capacidad según la demanda. [1] [21] [19] Como dice Google: "del prototipo a la producción a escala planetaria". [19]
Como los sistemas nativos de la nube inherentemente escalan hacia abajo y hacia arriba, estos sistemas se conocen como elásticos en lugar de escalables.
Pequeños equipos de desarrolladores pueden ejecutar código por sí mismos sin depender de equipos de ingenieros de infraestructura y soporte; más desarrolladores se están volviendo expertos en DevOps y las distinciones entre ser un desarrollador de software o un ingeniero de hardware se están difuminando. [19]
Con la función como servicio , las unidades de código expuestas al mundo exterior son funciones simples controladas por eventos . Esto significa que, por lo general, el programador no tiene que preocuparse por el multihilo ni por manejar directamente las solicitudes HTTP en su código, lo que simplifica la tarea de desarrollo de software back-end.
Las aplicaciones sin servidor son propensas a las falacias de la computación distribuida . Además, son propensas a las siguientes falacias: [22] [23]
El código sin servidor que se utiliza con poca frecuencia puede sufrir una mayor latencia de 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 escalado automático, el proveedor de la nube normalmente desconecta por completo el código sin servidor cuando no se utiliza. Esto significa que si el entorno de ejecución (por ejemplo, el entorno de ejecución de Java ) requiere una cantidad significativa de tiempo para iniciarse, creará latencia adicional. [24] Esto se conoce como inicio en frío en la informática sin servidor.
La computación sin servidor no es adecuada para algunas cargas de trabajo informáticas, como la computación de alto rendimiento , debido a los límites de recursos impuestos por los proveedores de la nube, y también porque probablemente sería más barato aprovisionar en masa la cantidad de servidores que se cree que se requieren en un momento dado. [25] Esto dificulta la implementación de aplicaciones complejas (como aquellas con un gráfico acíclico dirigido de funciones); la computación sin servidor lista para usar es más adecuada para la ejecución de funciones individuales sin estado. Algunas ofertas comerciales como AWS Step Functions de Amazon y Azure Durable Functions de Microsoft están destinadas a facilitar este desafío.
Diagnosticar problemas de rendimiento o uso excesivo de recursos con código sin servidor puede ser más difícil que con código de servidor tradicional, porque si bien se pueden cronometrar funciones enteras, [5] normalmente no hay posibilidad de profundizar en más detalles adjuntando perfiladores , depuradores o herramientas APM . [26] Además, el entorno en el que se ejecuta el código normalmente no es de código abierto, por lo que sus características de rendimiento no se pueden replicar con precisión en un entorno local .
Según OWASP , las aplicaciones sin servidor son vulnerables a variaciones de ataques tradicionales, código inseguro y algunos ataques específicos de las aplicaciones sin servidor (como la denegación de acceso a la billetera [27] ). Por lo tanto, los riesgos han cambiado y la prevención de ataques requiere un cambio de mentalidad. [28] [29]
A veces se considera erróneamente que las arquitecturas sin servidor son más seguras que las tradicionales. Si bien esto es cierto hasta cierto punto porque el proveedor de la nube se encarga de las vulnerabilidades del sistema operativo, la superficie de ataque total es significativamente mayor, ya que hay muchos más componentes en la aplicación en comparación con las arquitecturas tradicionales, y cada componente es un punto de entrada a la aplicación sin servidor. Además, las soluciones de seguridad que los clientes solían tener para proteger sus cargas de trabajo en la nube se vuelven irrelevantes, ya que los clientes no pueden controlar ni instalar nada en el punto final y a nivel de red , como un sistema de detección/prevención de intrusiones (IDS/IPS). [30]
Esto se ve intensificado por las propiedades de monocultura de toda la red de servidores. (Una única falla puede aplicarse globalmente). Según Protego, la "solución para proteger las aplicaciones sin servidor es una estrecha colaboración entre los desarrolladores, DevOps y AppSec, también conocido como DevSecOps. Encuentre el equilibrio en el que los desarrolladores no sean dueños de la seguridad, pero tampoco estén exentos de responsabilidad. Tome medidas para que sea un problema de todos. Cree equipos multifuncionales y trabaje hacia una estrecha integración entre los especialistas en seguridad y los equipos de desarrollo. Colabore para que su organización pueda resolver los riesgos de seguridad a la velocidad de la seguridad sin servidor". [31]
Muchos entornos de funciones sin servidor se basan en entornos de nube pública propietarios . En este caso, se deben tener en cuenta algunas implicaciones de privacidad , como los recursos compartidos y el acceso por parte de empleados externos. Sin embargo, la computación sin servidor también se puede realizar en un entorno de nube privada o incluso en las instalaciones, utilizando, por ejemplo, la plataforma Kubernetes . Esto ofrece a las empresas un control total sobre los mecanismos de privacidad, al igual que ocurre con el alojamiento en configuraciones de servidor tradicionales.
La computación sin servidor está contemplada por la International Data Center Authority (IDCA) en su Framework AE360. [32] Sin embargo, la parte relacionada con la portabilidad puede ser un problema al trasladar la lógica empresarial de una nube pública a otra, para lo cual 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 . [33]
La computación sin servidor se ofrece como un servicio de terceros. Las aplicaciones y el software que se ejecutan en el entorno sin servidor están bloqueados de forma predeterminada para un proveedor de nube específico. Este problema se agrava en la computación sin servidor, ya que con su mayor nivel de abstracción, los proveedores públicos solo permiten a los clientes cargar código en una plataforma FaaS sin la autoridad para configurar los entornos subyacentes. Más importante aún, al considerar un flujo de trabajo más complejo que incluye Backend-as-a-Service (BaaS), una oferta de BaaS normalmente solo puede activar de forma nativa una oferta FaaS del mismo proveedor. Esto hace que la migración de la carga de trabajo en la computación sin servidor sea prácticamente imposible. Por lo tanto, considerar cómo diseñar e implementar flujos de trabajo sin servidor desde una perspectiva de múltiples nubes parece prometedor y está comenzando a prevalecer [ ¿cuándo? ] . [34] [35] [36]
Seguir las prácticas de DevSecOps puede ayudar a utilizar y proteger las tecnologías sin servidor de forma más eficaz. [37] En las aplicaciones sin servidor, la línea entre la infraestructura y la lógica empresarial es borrosa y las aplicaciones suelen estar repartidas entre varios servicios. Según Yan Cui, para obtener el máximo valor de los esfuerzos de prueba, las aplicaciones sin servidor deben probarse principalmente por sus integraciones y, posiblemente, las pruebas unitarias solo deben usarse si existe una lógica empresarial compleja. Además, para facilitar la depuración y la implementación de aplicaciones sin servidor, los desarrolladores deben utilizar la orquestación dentro del contexto delimitado de un microservicio y deben utilizar la coreografía entre los contextos delimitados. [6]
Según Yan Cui, los recursos efímeros deben mantenerse juntos para lograr una alta cohesión . Sin embargo, los recursos compartidos que tienen un tiempo de puesta en marcha largo (por ejemplo, el clúster AWS RDS ) y una zona de aterrizaje deben tener su propio repositorio , canal de implementación y pila separados . [6]
Las funciones sin servidor se pueden utilizar para: [38]
{{cite web}}: CS1 maint: estado de la URL ( enlace ){{cite journal}}: Requiere citar revista |journal=( ayuda )