En qué es y debería convertirse la informática sin servidor: la siguiente fase de la informática en la nube | Mayo de 2021

Por Johann Schleier-Smith, Vikram Sreekanti, Anurag Khandelwal, Joao Carreira, Neeraja J. Yadwadkar, Raluca Ada Popa, Joseph E. Gonzalez, Ion Stoica, David A. Patterson

Comunicaciones de la ACM,
Mayo de 2021,
Vol. 64 No. 5, Páginas 76-84
10.1145 / 3406011
Comentarios

En 2010, algunos de nosotros fuimos coautores de un Comunicaciones artículo que ayudó a explicar el fenómeno relativamente nuevo de la computación en nube.⁴ Dijimos que la computación en la nube brindaba la ilusión de servidores remotos infinitamente escalables sin cobrar una prima por la escala, ya que alquilar 1,000 servidores por una hora cuesta lo mismo que alquilar un servidor por 1,000 horas, y que las economías de escala para el proveedor de la nube le permitieron hacerlo. ser sorprendentemente económico. Enumeramos los desafíos de la computación en la nube y luego pronosticamos que la mayoría se superaría para que la industria cambiara cada vez más de la computación dentro de los centros de datos locales a «la nube», lo que de hecho ha sucedido. En la actualidad, dos tercios del gasto empresarial en tecnología de la información para infraestructura y software se basa en la nube.⁸

Volver arriba

Ideas clave

Estamos revisando la computación en la nube una década después para explicar su segunda fase emergente, que creemos acelerará aún más el cambio a la nube. La primera fase simplificó principalmente la administración del sistema al facilitar la configuración y administración de la infraestructura informática, principalmente mediante el uso de servidores virtuales y redes creadas a partir de centros de datos masivos de múltiples inquilinos. Esta segunda fase oculta los servidores al proporcionar abstracciones de programación para los creadores de aplicaciones que simplifican el desarrollo en la nube, lo que hace que el software en la nube sea más fácil de escribir. Dicho brevemente, el objetivo de la primera fase eran los administradores de sistemas y la segunda, los programadores. Este cambio requiere que los proveedores de la nube asuman muchas de las responsabilidades operativas necesarias para ejecutar bien las aplicaciones.

Para enfatizar el cambio de enfoque de los servidores a las aplicaciones, esta nueva fase se ha conocido como computación sin servidor, aunque los servidores remotos siguen siendo el cimiento invisible que lo impulsa. En este artículo, llamamos a la primera fase tradicional Computación con servidor.

La figura 1 muestra una analogía. Para asistir a una conferencia remota, puede alquilar un automóvil o tomar un taxi para ir del aeropuerto a su hotel. El alquiler de automóviles es como la informática con servidor, donde debe esperar en la fila, firmar un contrato, reservar el automóvil para toda su estadía sin importar cuánto lo use, conducir el automóvil usted mismo, navegar hasta el hotel, pagar el estacionamiento y llenarlo con combustible antes de devolverlo. El taxi es como una informática sin servidor, en la que simplemente necesita dar el nombre del hotel y pagar el viaje; el servicio de taxi proporciona un conductor capacitado que navega, cobra por el viaje y llena el tanque de gasolina. Los taxis simplifican el transporte, ya que no es necesario saber manejar un automóvil para llegar al hotel. Además, los taxis obtienen una mayor utilización que los coches de alquiler, lo que reduce los costes para la empresa de taxis. Dependiendo de la duración de la conferencia, el costo del alquiler del automóvil, el costo del estacionamiento, el costo de la gasolina, etc., los taxis no solo son más fáciles, sino que incluso pueden ser más baratos.

Figura 1. Enfoques de la computación en la nube en comparación con los viajes desde un aeropuerto: Serverful como alquilar un automóvil y sin servidor como tomar un taxi.

En la informática sin servidor, los programadores crean aplicaciones utilizando abstracciones de alto nivel ofrecidas por el proveedor de la nube. Por ejemplo, pueden definir funciones en la nube^a utilizando programación «sin estado» de estilo funcional en el lenguaje de su elección, a menudo JavaScript o Python, luego especifique cómo deben ejecutarse las funciones, ya sea en respuesta a solicitudes web o eventos desencadenantes. También pueden utilizar almacenamiento de objetos sin servidor, colas de mensajes, bases de datos de almacenamiento de valores clave, sincronización de datos de clientes móviles, etc., un grupo de ofertas de servicios conocidos colectivamente como Backend como servicio (BaaS). Los servicios de función de nube administrada también se denominan Función como servicio (FaaS) y, en conjunto, la computación en la nube sin servidor hoy en día = FaaS + BaaS (consulte la Figura 2).

Figura 2. Computación en la nube sin servidor o con servidor completo: sin servidor proporciona una abstracción entre las aplicaciones y los servidores subyacentes.

La principal innovación de la tecnología sin servidor es la ocultación de servidores, que tienen un modelo operativo y de programación intrínsecamente complejo. Los usuarios del servidor deben crear redundancia para la confiabilidad, ajustar la capacidad en respuesta a los cambios en la carga, actualizar los sistemas para la seguridad, etc.¹⁷ Esto a menudo requiere un razonamiento difícil sobre los modos de falla y el rendimiento en sistemas distribuidos. Las herramientas pueden ayudar, por ejemplo, ajustando la capacidad heurísticamente, una forma de autoescalado, pero también requieren una configuración detallada y un seguimiento continuo. Por el contrario, la tecnología sin servidor entrega estas y otras responsabilidades al proveedor de la nube.

Tres cualidades esenciales de la computación sin servidor son:

1. Proporcionar una abstracción que oculta los servidores y la complejidad de programarlos y operarlos.
2. Ofreciendo un modelo de costos de pago por uso en lugar de un modelo basado en reservas, por lo que no hay cargo por recursos inactivos (consulte la Figura 3).
3. Recursos de escalado automático, rápido e ilimitado hacia arriba y hacia abajo para adaptarse a la demanda de cerca, de cero a prácticamente infinito.

Figura 3. Computación en la nube sin servidor o con servidor completo: los usuarios sin servidor pagan solo por los recursos consumidos, no por la capacidad reservada inactiva.

La síntesis basada en la nube de todas de estas propiedades es sustancialmente más transformador que los entornos anteriores que estuvieron cerca de proporcionarlas.^8,17 Volviendo a nuestra analogía, un servicio de taxi (computación sin servidor) debe proporcionar un taxi con un conductor con licencia (operación oculta), cobrar solo cuando se realiza un viaje (pago por uso) y programar suficientes taxis para minimizar el tiempo de espera del cliente (escala automática) . Si los taxis no proporcionan los tres de manera confiable, entonces los clientes pueden alquilar y operar automóviles (computación con servidor).

Un reciente Comunicaciones El artículo brindó una excelente introducción al estado actual de la computación sin servidor, en qué se diferencia de la infraestructura como servicio (IaaS) y la plataforma como servicio (PaaS), su participación de mercado, ejemplos de casos de uso y sus limitaciones. .⁸ En este artículo, compartimos nuestras opiniones sobre la evolución que representa la computación sin servidor, las fuerzas económicas que la moldean, por qué podría fallar y cómo podría evolucionar para alcanzar su potencial.

Proyectamos que la mayoría de la informática del centro de datos estará dominada por la informática sin servidor, pero también creemos que la informática sin servidor se apartará sustancialmente de las ofertas actuales sin servidor. En particular, creemos que surgirán nuevas abstracciones sin servidor de propósito general, que agregarán administración de estado sofisticada y optimización automática para permitir muchos más casos de uso. La tecnología sin servidor ahora depende de CPU homogéneas, pero en el futuro la tecnología sin servidor simplificará el uso de aceleradores de hardware como las unidades de procesamiento gráfico (GPU) o las unidades de procesamiento tensorial (TPU).¹⁹ que admiten cargas de trabajo específicas: ofrecen el camino más probable hacia un mayor rendimiento a medida que la Ley de Moore se ralentiza.¹⁴ Si bien hoy en día existen preocupaciones sobre la seguridad sin servidor, creemos que un diseño cuidadoso podría, de hecho, convertirlo en más fácil para que los desarrolladores de aplicaciones protejan su software contra atacantes externos.

Al igual que en 2010, una vez más pronosticamos que estos desafíos serán superados y esta segunda fase se convertirá en la forma dominante de computación en la nube, acelerando su popularidad al poner el poder de la nube en manos de todas desarrolladores de aplicaciones.

Volver arriba

Comprensión de lo que es sin servidor hoy en día

Funciones en la nube⁸ capturan gran parte de la mente compartida en la computación sin servidor, pero son uno de los muchos servicios en la nube sin servidor. El entusiasmo en torno a FaaS está bien justificado porque ofrece una idea de cómo se vería la computación sin servidor de propósito general, sin embargo, los servicios BaaS comprenden un conjunto mucho más grande y antiguo de servicios sin servidor.

Por ejemplo, AWS ofreció inicialmente su almacenamiento de objetos S3 como un servicio de archivo y respaldo remoto, años antes de anunciar el alquiler de la máquina virtual EC2. Puede pensar en S3 como un precursor de la informática sin servidor que ofrecía «almacenamiento sin disco», es decir, proporciona almacenamiento pero oculta los discos. Con el tiempo, los proveedores de la nube ofrecieron servicios BaaS adicionales para ayudar a la informática con capacidad de servidor. Las colas de mensajes (por ejemplo, AWS SQS, Google Cloud Pub / Sub) fueron otro de los primeros servicios. Más tarde aparecieron las bases de datos de valor clave (por ejemplo, Google Cloud Datastore, AWS DynamoDB, Azure CosmosDB) y motores de consulta de big data basados ​​en SQL (por ejemplo, AWS Athena, Google BigQuery).

Cuando AWS Lambda se lanzó en 2015, fue el primer producto de funciones en la nube y ofreció algo único y convincente: la capacidad de ejecutar casi cualquier código que se ejecute en un servidor. Incluía soporte para varios lenguajes de programación y para bibliotecas arbitrarias, todo sobre la base de pago por uso, operando de forma segura y a cualquier escala. Sin embargo, impuso ciertas limitaciones al modelo de programación que aún hoy lo restringen a determinadas aplicaciones. Estos incluyen un tiempo de ejecución máximo, la falta de estado persistente y redes restringidas.¹³

Hoy en día, varios entornos sin servidor pueden ejecutar código arbitrario, cada uno de los cuales se adapta a un caso de uso particular. Por ejemplo, Google Cloud Dataflow y AWS Glue permiten a los programadores ejecutar código arbitrario como una etapa en una canalización de procesamiento de datos, mientras que Google App Engine puede considerarse como un entorno sin servidor para crear aplicaciones web.

Estas muchas ofertas sin servidor tienen en común las tres cualidades esenciales de la computación sin servidor: una abstracción que oculta los servidores, un modelo de costos de pago por uso y un excelente ajuste de escala automático. En conjunto, ofrecen un conjunto de alternativas que pueden combinarse para satisfacer una gama cada vez mayor de aplicaciones.

Volver arriba

Economía de la nube sin servidor

La nube actual ha sido moldeada tanto por consideraciones comerciales como por el progreso técnico, y su futuro también lo será. Los clientes de la nube eligen la computación sin servidor porque les permite mantenerse enfocados en resolver problemas que son exclusivos de su dominio o negocio, en lugar de problemas en la administración de servidores o sistemas distribuidos.⁶ La solidez de esta propuesta de valor para el cliente es una de las principales causas de optimismo sobre la futura adopción de la informática sin servidor.

Si bien la computación sin servidor puede parecer más costosa debido a que los precios unitarios de los recursos son más altos (consulte la barra lateral «El costo de la tecnología sin servidor»), los clientes solo pagan por los recursos que están usando, mientras que el proveedor de la nube asume el costo de los recursos inactivos. En la práctica, los clientes obtienen ahorros sustanciales en los costos al migrar aplicaciones a servidores sin servidor.³⁰ Si bien esta reducción de costos podría amenazar los ingresos de los proveedores de nube, la paradoja de Jevons² sugiere que los precios bajos pueden provocar un crecimiento del consumo que compensa con creces la reducción en los costos unitarios, lo que lleva a un crecimiento de los ingresos. Los proveedores de la nube también obtienen una oportunidad de ganancias al ayudar a los clientes a satisfacer necesidades de recursos variables e impredecibles, algo que pueden hacer de manera más eficiente desde un grupo de recursos compartidos que los clientes pueden hacer con sus propios recursos dedicados.^dieciséis Esta oportunidad también existe en la computación con servidor, pero crece a medida que los recursos se comparten de manera más detallada. La computación sin servidor también ofrece a los proveedores de la nube oportunidades para mejorar sus márgenes porque los productos BaaS a menudo representan categorías de productos que tradicionalmente ofrecen productos de software de alto margen, como bases de datos.

El modelo de pago por uso sin servidor tiene una importante implicación positiva para el incentivo de los proveedores de nube para innovar. Antes de los servicios sin servidor, los servicios en la nube de escalado automático aprovisionarían automáticamente las máquinas virtuales, es decir, reservarían recursos, pero el cliente pagaría por esta capacidad incluso si permanecía inactiva. Sin servidor, el proveedor de la nube paga por los recursos inactivos, lo que crea un «aspecto en el juego» en el ajuste de escala automático y proporciona incentivos para garantizar una asignación de recursos eficiente. De manera similar, a medida que el proveedor de la nube asume el control directo sobre una mayor parte de la pila de aplicaciones, incluido el sistema operativo y el tiempo de ejecución del lenguaje, el modelo sin servidor fomenta las inversiones en eficiencia en todos los niveles.

Programadores más productivos, menores costos para los clientes, mayores ganancias para los proveedores y una mejor innovación crean condiciones favorables para la adopción sin servidor. Sin embargo, algunos clientes de la nube han expresado su preocupación por la dependencia de los proveedores, por temor a que se reduzca el poder de negociación al negociar precios con los proveedores de la nube.^dieciséis La abstracción de VM con servidor está estandarizada, principalmente debido al sistema operativo Linux y el conjunto de instrucciones x86, pero las funciones de nube sin servidor de cada proveedor y las API BaaS difieren tanto en formas evidentes como sutiles. Los costos de cambio resultantes benefician a los proveedores de nube más grandes y establecidos, y les brindan un incentivo para promover API propietarias complejas que son resistentes a la estandarización de facto. Las abstracciones simples y estandarizadas, quizás introducidas por proveedores de nube más pequeños, comunidades de código abierto o académicos, eliminarían el obstáculo económico más importante que queda para la adopción sin servidor.

Volver arriba

La siguiente fase de la computación en la nube

Quizás la mejor manera de entender el cambio que representa la computación sin servidor es enfocarse en la primera de las cualidades esenciales (como se señaló anteriormente): proporcionar una abstracción que oculta los servidores y, por lo tanto, simplifica la programación y el modelo operativo. Desde el principio, la computación en la nube proporcionó un modelo operativo simplificado, pero la programación simplificada proviene de la ocultación de servidores. La evolución futura de la computación sin servidor, y desde nuestro punto de vista de la computación en la nube, se guiará por los esfuerzos para proporcionar abstracciones que simplifiquen la programación en la nube.

Es sorprendente lo poco que la computación en la nube ha cambiado la forma en que trabajan los programadores hasta la fecha, especialmente en comparación con el impacto que ha tenido en los operadores. Gran parte del software que se ejecuta en la nube es exactamente el mismo software que se ejecuta en un centro de datos tradicional. Compare las habilidades de programación más demandadas en la actualidad con las que se necesitaban hace 10 años y notará que el conjunto de habilidades básicas ha cambiado muy poco, incluso cuando las tecnologías específicas van y vienen. Por el contrario, el trabajo del operador ha cambiado enormemente. La instalación y el mantenimiento de servidores, almacenamiento y redes son en gran parte cosas del pasado, reemplazados por un enfoque en la gestión de la infraestructura virtualizada a través de las API de proveedores de nube y por el movimiento DevOps, que enfatiza los aspectos técnicos y organizativos de la gestión del cambio.

¿Qué dificulta la programación de la nube? Si bien es posible usar la nube con un solo servidor, esto no ofrece tolerancia a fallas ni escalabilidad ni pago por uso, por lo que la mayoría de la programación en la nube se convierte rápidamente en programación de sistemas distribuidos. Al escribir sistemas distribuidos, los programadores deben razonar sobre la extensión espacial del centro de datos, sus diversos modos de falla parcial y todas sus amenazas de seguridad. En el lenguaje de Fred P. Brooks, estas preocupaciones representan «complejidad accidental», que surge del entorno de implementación y contrasta con la «complejidad esencial», que es inherente a la funcionalidad que proporciona la aplicación.⁷ En el momento de la redacción de Brooks, los lenguajes de alto nivel estaban desplazando al lenguaje ensamblador, liberando a los programadores de razonar sobre detalles complejos de la máquina, como la asignación de registros o el diseño de datos en la memoria. Así como los lenguajes de alto nivel ocultan muchos detalles de cómo funciona una CPU, la computación sin servidor oculta muchos detalles de lo que se necesita para construir un sistema distribuido confiable, escalable y seguro.

A continuación, consideramos enfoques alternativos a la abstracción sin servidor, incluidos los que existen en la actualidad y los que imaginamos. Estos compiten por responder a la pregunta, «si no son servidores, ¿entonces qué?» Agrupamos estos enfoques alternativos de abstracción en específico de la aplicación y propósito general categorías (ver Tabla 1). Las abstracciones específicas de la aplicación resuelven un caso de uso particular, y varias de ellas existen en los productos de hoy. Las abstracciones de propósito general deben funcionar bien en una amplia variedad de usos y seguir siendo un desafío de investigación.

Tabla 1. Enfoques de abstracción alternativos.

Examinemos un ejemplo ilustrativo del procesamiento de macrodatos. Considere una consulta simple que podría surgir en un entorno de comercio electrónico: calcular un promedio de más de 10 mil millones de registros utilizando pesos derivados de un millón de categorías. Esta carga de trabajo tiene el potencial de un gran paralelismo, por lo que se beneficia de la ilusión de recursos infinitos sin servidor.

Presentamos dos ofertas sin servidor específicas de la aplicación que se adaptan a este ejemplo e ilustran cómo la categoría ofrece múltiples enfoques. Se podría usar el motor de consultas de big data de AWS Athena, una herramienta programada con SQL (lenguaje de consulta estructurado), para ejecutar consultas en datos en el almacenamiento de objetos. SQL se adapta particularmente bien a la analítica y puede expresar este cálculo con una sola declaración. Alternativamente, se podría usar un marco como el que proporciona Google Cloud Dataflow. Hacerlo requiere escribir un estilo MapReduce simple¹¹ programa, por ejemplo, que utiliza Java o Python, con dos funciones: una que calcula un promedio ponderado para algún fragmento de datos y otra que combina promedios ponderados para fragmentos separados en uno para su unión. El marco se encarga de canalizar los datos dentro y fuera de estas funciones, así como del autoescalado, la confiabilidad y otras preocupaciones de los sistemas distribuidos. A diferencia de la herramienta basada en SQL, esta abstracción puede ejecutar código arbitrario, lo que puede hacerla adecuada para una gama más amplia de problemas de análisis.

Las abstracciones sin servidor de propósito general que ofrecen una solución eficaz para nuestro ejemplo de big data aún no existen. Puede parecer que las funciones en la nube brindan una solución, ya que permiten a los usuarios escribir código arbitrario y, para algunas cargas de trabajo, lo hacen,²⁸ pero debido a las limitaciones, a veces funcionan mucho peor que las alternativas.^13,17La Figura 4 ilustra cómo el tráfico de red podría ser mucho mayor si implementamos nuestro ejemplo usando funciones en la nube, en lugar de usar un marco específico de aplicación como Cloud Dataflow. Con las funciones de la nube, el proveedor distribuye el trabajo entre varias instancias de VM sin tener en cuenta los patrones de comunicación de la aplicación, lo que simplifica el escalado automático pero aumenta el tráfico de red.

Figura 4. Mayor comunicación para patrones de agregación y difusión.

Sugerimos dos caminos para mejorar las funciones de la nube para que funcionen bien en una gama más amplia de aplicaciones, convirtiéndolas potencialmente en abstracciones sin servidor de propósito general. Primero, imaginamos que las sugerencias proporcionadas por el programador podrían indicar cómo lograr un mejor rendimiento. Las sugerencias pueden describir patrones de comunicación de la aplicación (por ejemplo, transmisión o reducción total) o sugerir afinidad de ubicación de tareas.²⁵ Este enfoque tiene precedentes en los compiladores (por ejemplo, predicción de rama, alineación y sugerencias de captación previa).

En segundo lugar, y de manera más convincente, imaginamos que las ineficiencias se eliminarán mediante la optimización automática. En nuestro ejemplo, el proveedor de la nube podría prometer inferir optimizaciones de localidad a partir de patrones de comunicación observados. En algunos casos, estas inferencias también pueden hacerse estáticamente, basándose en un análisis del programa. En el contexto de una sola máquina, esto tiene un amplio precedente en lo que hacen los compiladores modernos y los tiempos de ejecución del lenguaje, y uno podría pensar en esta forma de computación sin servidor como una extensión del soporte del lenguaje a los sistemas distribuidos.

La Figura 5 ilustra la diferencia entre abstracciones sin servidor específicas de la aplicación y de propósito general. En el caso de uso general, el proveedor de la nube expone algunos bloques de construcción básicos, por ejemplo, una versión mejorada de las funciones de la nube y algún tipo de almacenamiento sin servidor. Se puede construir una variedad de casos de uso específicos de la aplicación sobre estos fundamentos. Sin servidor para aplicaciones específicas, los proveedores de nube ofrecen una proliferación de BaaS para satisfacer las necesidades de un número cada vez mayor de aplicaciones.

Figura 5. Posibles direcciones futuras para la tecnología sin servidor.

Hoy en día, la computación sin servidor sigue siendo completamente de la variedad específica de la aplicación. Incluso las funciones en la nube, que pueden ejecutar código arbitrario, son populares principalmente para el servicio de API sin estado y el procesamiento de datos impulsado por eventos.²⁷ Esperamos que crezca la computación sin servidor para aplicaciones específicas, pero estamos muy entusiasmados con la posible aparición de abstracciones sin servidor de propósito general, que podrían albergar ecosistemas de software que satisfagan todas las necesidades. En nuestra opinión, solo el enfoque de propósito general puede, en última instancia, desplazar a los servidores para convertirse en la forma predeterminada de programación en la nube. Sin embargo, la tecnología sin servidor de propósito general no existe en la actualidad y su desarrollo presenta desafíos de investigación.

Volver arriba

Desafíos de la investigación

La informática sin servidor está evolucionando rápidamente y ofrece varios desafíos de investigación, muchos de ellos comunes a aplicaciones específicas y sin servidor de propósito general.

Administración del Estado. Las aplicaciones en la nube distribuidas a menudo necesitan intercambiar estados efímeros o de corta duración entre las tareas de sus componentes. Los ejemplos incluyen cachés de toda la aplicación, índices y otras tablas de búsqueda, o resultados intermedios de análisis de big data. Las funciones en la nube hoy permiten que las aplicaciones almacenen estados efímeros localmente en cada función, lo cual es útil para el almacenamiento en caché y como memoria de trabajo para el programa. El estado compartido sin servidor se puede guardar en almacenamiento de objetos o almacenes de valores clave, pero estos no proporcionan simultáneamente baja latencia, bajo costo, alto rendimiento y acceso detallado, como es posible con los servidores.¹⁷ Los enfoques para abordar estos desafíos incluyen el almacenamiento temporal de datos para análisis²¹ así como funciones en la nube con estado que integran el almacenamiento en caché y brindan garantías de coherencia.²⁹

Redes. Las funciones en la nube transfieren la responsabilidad de programar el trabajo del usuario al proveedor de la nube, lo que tiene varias consecuencias interesantes. Dado que los usuarios ceden el control sobre cuándo se ejecutan las funciones, el paso del estado entre las funciones de la nube requiere un viaje a través del almacenamiento compartido; la comunicación de red directa tiene poco sentido y los proveedores de la nube la bloquean. El acceso al almacenamiento compartido agrega una latencia significativa, a veces cientos de milisegundos. Los usuarios también ceden el control sobre dónde se ejecutan las funciones, lo que excluye las optimizaciones comunes con los servidores, incluido el intercambio de entradas comunes entre tareas y la combinación de salidas antes de enviarlas a la red (consulte la Figura 4 y la discusión anterior). Los intentos de superar estos desafíos resaltarán la tensión entre dar a los programadores más control y permitir que el proveedor de la nube realice optimizaciones automáticamente.

Rendimiento predecible. Tanto FaaS como BaaS pueden exhibir un rendimiento variable que impide su uso en aplicaciones que deben cumplir con estrictas garantías. Parte de la razón de esto es fundamental: los proveedores sin servidor confían en la multiplexación estadística para crear la ilusión de recursos infinitos, al tiempo que niegan a los usuarios el control sobre la suscripción excesiva de recursos. Siempre existe la posibilidad de que un momento desafortunado cree retrasos en las colas. También existe un costo de latencia para reasignar recursos de un cliente a otro, lo que en el contexto de la función de nube se conoce como «inicio en frío». La latencia de arranque en frío tiene varios componentes,¹⁷ y uno de los más importantes es el tiempo que lleva inicializar el entorno de software de la función. Ya ha habido avances en esta área. Entornos de funciones en la nube como Google gVisor y AWS Firecracker¹ ahora puede comenzar en unos 100 ms, mientras que las máquinas virtuales tradicionales tardan decenas de segundos en arrancar. También es posible acelerar la inicialización a nivel de aplicación, como la carga de bibliotecas.²⁶ Probablemente todavía haya mucho margen de mejora en estas áreas, aunque también hay evidencia de que la optimización del rendimiento y el aislamiento para la seguridad están fundamentalmente en desacuerdo.²⁴ Los clientes de AWS Lambda también pueden evitar las latencias de arranque en frío comprando «simultaneidad aprovisionada», que reintroduce de manera controvertida una forma de reserva de recursos en el modelo sin servidor. Esperamos también ver precios basados ​​en garantías estadísticas u objetivos de nivel de servicio (SLO), que están ausentes en la tecnología sin servidor en la actualidad.

Seguridad. La informática sin servidor conduce a un uso compartido de recursos detallado y, por lo tanto, aumenta la exposición a ataques de canal lateral, mediante el cual los atacantes explotan comportamientos sutiles del hardware real que difieren de las especificaciones o las suposiciones del programador (consulte el recuadro «Sin servidor y seguridad»). Las amenazas van desde ataques de Rowhammer a DRAM²⁰ a quienes explotan las vulnerabilidades de la microarquitectura.²² Además de adoptar mitigaciones desarrolladas para la computación con servidor, los servidores sin servidor pueden emplear una programación aleatoria para que sea más difícil para un atacante apuntar a una víctima específica. La computación sin servidor también puede incurrir en una mayor fuga de información a través de la comunicación de red debido a la descomposición fina de una aplicación y la distribución física de sus partes. Un atacante que observe el tamaño y el tiempo del tráfico de la red, incluso si está encriptado, podría hacer inferencias sobre datos privados. Abordar estos riesgos puede ser posible a través de la informática inconsciente.¹²

Lenguajes de programación. La programación simplificada de sistemas distribuidos es un beneficio fundamental de la computación sin servidor,¹⁸ y si bien gran parte del trabajo previo en esta área es relevante, la configuración sin servidor requiere una nueva perspectiva y agrega urgencia. Los desafíos tradicionales incluyen la tolerancia a fallas, la coherencia, la simultaneidad y el rendimiento y la eficiencia que provienen de la localidad. Los nuevos desafíos incluyen soporte de primera clase para autoescalado, pago por uso y multiplexación fina.

Las preocupaciones sobre la tolerancia a fallas aumentan debido a los intentos de extender la computación sin servidor más allá de las funciones de nube sin estado. Azure Durable Functions usa características del lenguaje C # para proporcionar puntos de control transparentes, lo que facilita la escritura de tareas sin servidor con estado y reanudables. Microsoft Orleans,⁵ que implementa un modelo de actor,¹⁵ De forma similar, oculta a los programadores las preocupaciones sobre la tolerancia a fallos. Los actores también proporcionan una noción de localidad y podrían ser una contraparte de las funciones en la nube para la computación sin servidor con estado. Rayo²⁵ encarna elementos de ambos. Los enfoques de coherencia incluyen transacciones integradas en el lenguaje, promovidas por Argus.²³ Sin embargo, las transacciones están plagadas de desafíos de rendimiento y escalabilidad, que un entorno sin servidor de autoescalado puede exacerbar. Un enfoque alternativo radica en lenguajes como Bloom,³ que permite el análisis automatizado para determinar qué partes de un programa pueden ejecutarse de forma independiente, sin coordinación y, por lo tanto, de forma escalable. El pago por uso debería alentar a los desarrolladores de idiomas a repensar la administración de recursos, por ejemplo, la recolección de basura automatizada podría adaptarse a los precios de la memoria medida. Enfoques de lenguaje para la programación en la nube,⁹ que abordan la complejidad de la programación de sistemas distribuidos de frente, pueden representar el enfoque más directo y ambicioso para simplificar la programación en la nube.

Aprendizaje automático. Creemos que la optimización automática con aprendizaje automático jugará un papel importante en todas las áreas discutidas anteriormente. Puede ayudar a decidir dónde ejecutar el código, dónde mantener el estado, cuándo iniciar un nuevo entorno de ejecución y cómo mantener la utilización alta y los costos bajos mientras se cumplen los objetivos de rendimiento. También puede ayudar a identificar actividades maliciosas que amenazan la seguridad, o a cortar automáticamente grandes programas en pedazos que se pueden ejecutar en funciones de nube separadas. El aprendizaje automático también puede ayudar a optimizar la computación con servidor.¹⁰ pero las abstracciones sin servidor brindan a los proveedores de la nube más control sobre las perillas relevantes, así como la visibilidad de muchos clientes requerida para entrenar modelos sólidos y efectivos.

Hardware. Las tendencias actuales en hardware pueden ser complementarias a la informática sin servidor. Los microprocesadores x86 que dominan la nube apenas mejoran en rendimiento; en 2017, la latencia del programa mejoró solo un 3%,¹⁴ una tendencia que, de continuar, implica que el rendimiento no se duplicará en 20 años. De manera similar, el fin de la Ley de Moore está desacelerando el crecimiento de la capacidad DRAM por chip. La respuesta de la industria ha sido la introducción de Arquitecturas Específicas de Dominio (DSA), que se adaptan a un tipo específico de problema y ofrecen un rendimiento y una eficiencia significativos, pero un rendimiento deficiente para otras aplicaciones.¹⁴ Las GPU se han utilizado durante mucho tiempo para acelerar los gráficos y estamos empezando a ver DSA para ML como las TPU. Las GPU y TPU pueden superar a las CPU para tareas limitadas por factores de 30 veces.¹⁹ Estos ejemplos son los primeros de muchos, ya que los procesadores de propósito general mejorados con DSA probablemente se convertirán en la norma.

Es sorprendente lo poco que la computación en la nube ha cambiado la forma en que trabajan los programadores hasta la fecha, especialmente en comparación con el impacto que ha tenido en los operadores.

Creemos que la computación sin servidor puede proporcionar un modelo de programación útil para integrar diversas arquitecturas, por ejemplo, con funciones de nube separadas que se ejecutan en aceleradores separados. También ayuda a crear espacio para la innovación al elevar el nivel de abstracción, por ejemplo, al permitir que un proveedor de nube sustituya un DSA por una CPU al reconocer una carga de trabajo que podría beneficiarse.

Volver arriba

Por qué la informática sin servidor aún puede fallar

Si bien creemos que la computación sin servidor puede crecer hasta convertirse en la programación en la nube predeterminada, también podemos imaginar varios escenarios en los que la computación con servidor conserva su dominio. Primero, la computación con servidor es un objetivo en movimiento, uno que mejora sin descanso, aunque lentamente. Las VM en la nube que antes se facturaban por horas ahora tienen un incremento de facturación mínimo de un minuto y se cobran por el segundo a partir de entonces. Las herramientas de organización de contenedores y máquinas virtuales (por ejemplo, Kubernetes, Terraform) ayudan a agilizar las implementaciones complejas y automatizan cada vez más las tareas administrativas, como la realización de copias de seguridad. Los programadores pueden confiar en ecosistemas de software maduros y una sólida compatibilidad heredada al crear aplicaciones, mientras que las empresas ya cuentan con equipos capacitados en implementaciones en la nube para servidores. El hardware del servidor también se hace cada vez más grande y más potente, lo que une la CPU, la memoria y la potencia del acelerador en un entorno estrechamente acoplado, un beneficio para algunas aplicaciones.

Second, today’s successful serverless products fall into the application-specific category and are narrowly targeted, whereas general-purpose serverless abstractions have a better chance of displacing serverful computing (which is also general-purpose). However general-purpose serverless computing faces hurdles: the technology that we envision does not exist yet, and it may be a less lucrative business for cloud providers.

Finally, even if our vision plays out, the brand of «serverless computing» might not survive. The temptation to label older products as the next new thing is strong and can create confusion in the marketplace. We have been happy to see products such as Google App Engine pick up the serverless moniker, and along with it features such as scaling to zero. However, if the term becomes diluted by half-hearted efforts, then perhaps general-purpose serverless computing will emerge under another name.

Back to Top

Conclusion and Predictions

Cloud computing is both flourishing and evolving. It has overcome the challenges that faced it in 2010, as we projected.⁴ Offering lower costs and simplified system administration, the business is growing up to 50% annually and proving highly profitable for cloud providers. Cloud computing is now entering a second phase in which its continued growth will be driven by a new value proposition: simplified cloud programming.

Analogous to how hailing a taxi simplifies transportation over renting a car (see Figure 1), serverless computing relieves programmers from thinking about servers and everything complicated that goes along with them. Following the same naming convention, you could classify a taxi service as carless transportation in that the passenger need not know how to operate a car to get a ride. Serverless raises the level of abstraction of the cloud, adopts pay-as-you-go pricing, and rapidly auto-scales down to zero and up to practically infinite resources.

Serverless computing is still evolving, and many open questions remain, both in defining its abstractions and in implementing them. We (boldly) conclude this paper with five predictions for serverless computing in the next decade:

1. Today’s FaaS and BaaS categories will give way to a broader range of abstractions, which we categorize as either general-purpose serverless computing o application-specific serverless computing. While serverful cloud computing won’t disappear, its relative use in the cloud will decline as serverless computing overcomes its current limitations.
2. We expect new general-purpose serverless abstractions to support just about any use case. They will support state management, as well as optimizations—either user-suggested or automatically inferred—to achieve efficiencies comparable or maybe better than those of serverful computing.
3. We see no fundamental reason for the cost of serverless computing to exceed that of serverful computing. We predict that as severless evolves and increases in popularity almost any application, be it tiny or massive-scale, costs no more—and perhaps a lot less—with serverless computing
4. Machine learning will play a critical role in serverless implementations, allowing cloud providers to optimize execution of large-scale distributed systems while providing a simple programming interface.
5. Computer hardware for serverless computing will be much more heterogeneous than the conventional x86 servers that powers it today.

If these predictions hold, serverless computing will become the default computing paradigm of the Cloud Era, largely replacing serverful computing and thereby closing the Client-Server Era, just as the smartphone brought the end of the PC Era.

Acknowledgments. We thank the reviewers for their thoughtful comments, as well as the many friends who gave feedback on early drafts. This work was conducted at UC Berkeley RISELab and it was supported by a National Science Foundation Expedition Project, Alibaba Group, Amazon Web Services, Ant Financial, Ericsson, Facebook, Future-wei, Google, Intel, Microsoft, Scotia-bank, Splunk, and VMware.

Back to Top

Back to Top

Back to Top

Back to Top

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2021 ACM, Inc.

No entries found