Informática sin servidores: Un paso adelante, dos pasos atrás

RESUMEN

La computación sin servidor ofrece la posibilidad de programar la nube de forma automática y con un
sistema de pago por uso. En este trabajo se abordan los vacíos críticos en la computación sin servidores
de primera generación, que ponen su potencial de escalado automático en contradicción con las
tendencias dominantes en la computación moderna: en particular la computación centrada en datos y
distribuida, pero también la computación de código abierto y el hardware a medida. En conjunto, estos
vacíos hacen que las ofertas actuales sin servidor no encajen bien con la innovación de la nube y son
especialmente perjudiciales para la innovación de los sistemas de datos. Además de identificar algunas
de las principales carencias de las actuales arquitecturas sin servidores, planteamos una serie de retos
que creemos que deben afrontarse para desbloquear el potencial radical que la nube -con sus exabytes
de almacenamiento y sus millones de núcleos- debería ofrecer a los desarrolladores innovadores.

1 INTRODUCCIÓN

Amazon Web Services celebró recientemente su 12º aniversario, marcando más de una década de
disponibilidad pública de la nube. Si bien la nube comenzó como un lugar para las máquinas de tiempo
compartido, estaba claro desde el principio que presentaba una plataforma informática radicalmente
nueva: el mayor conjunto de capacidad de datos y potencia informática distribuida jamás disponible para
el público en general, gestionada como un servicio. A pesar de ese potencial, todavía tenemos que
aprovechar los recursos de la nube de manera radical. La nube se utiliza hoy en día en gran medida como
plataforma de externalización para servicios de datos empresariales estándar. Para que esto cambie, los
desarrolladores creativos necesitan marcos de programación que les permitan aprovechar el poder de la
nube. Las nuevas plataformas informáticas han fomentado normalmente la innovación en los lenguajes y
entornos de programación. Sin embargo, una década después, es difícil identificar los nuevos entornos de
programación para la nube. Y ya sea por causa o efecto, los resultados son claramente visibles en la
práctica: la mayoría de los servicios en la nube son simplemente clones multi-tenancy, más fáciles de
administrar de servicios de datos empresariales heredados como almacenamiento de objetos, bases de
datos, sistemas de colas y servidores web/app. La multitenencia y la simplicidad administrativa son
objetivos admirables y deseables, y algunos de los nuevos servicios tienen características internas
interesantes por derecho propio. Pero esto es, en el mejor de los casos, sólo un indicio del potencial que
ofrecen millones de núcleos y exabytes de datos. Recientemente, los proveedores públicos de cloud
computing han comenzado a ofrecer nuevas interfaces de programación bajo la bandera de la
computación sin servidores, y el interés está creciendo. Las tendencias de búsqueda de Google muestran
que las consultas para el término "serverless" coinciden recientemente con el pico histórico de
popularidad de la frase "Map Reduce" o "MapReduce" (Figura 1). También ha habido un aumento
significativo en la atención al tema más recientemente por parte de la comunidad investigadora[13, 6, 27,
14]. La computación sin servidor ofrece la atractiva noción de una plataforma en la nube donde los
desarrolladores simplemente cargan su código, y la plataforma lo ejecuta en su nombre según sea
necesario a cualquier escala. Los desarrolladores no necesitan preocuparse por el aprovisionamiento o la
operación de servidores, y sólo pagan por los recursos informáticos utilizados cuando se invoca su código.
La noción de computación sin servidor es lo suficientemente vaga como para permitir a los optimistas
proyectar cualquier número de posibles interpretaciones amplias sobre lo que podría significar. Nuestro
objetivo aquí no es discutir sobre la terminología. Concretamente, cada uno de los proveedores de cloud
computing ya ha lanzado una infraestructura de computación sin servidores y está gastando un
importante presupuesto de marketing para promocionarla. En este artículo, evaluamos el campo basado
en los servicios de computación sin servidores que los proveedores están ofreciendo hoy en día y vemos
por qué son una decepción a la luz del potencial de la nube.

1
1.1 "Sin servidor" se convierte en FaaS

Para empezar, ofrecemos una rápida introducción a Functions-as-a-Service (FaaS), el nombre más
utilizado y descriptivo para el núcleo de las ofertas sin servidor de los proveedores públicos de cloud
computing. Debido a que AWS fue la primera nube pública -y sigue siendo la más grande- centramos
nuestra discusión en el marco de trabajo de AWS FaaS, Lambda; las ofertas de Azure y GCP difieren en
detalle pero no en espíritu. La idea detrás de FaaS es simple y directamente de un libro de texto de
programación. La programación tradicional se basa en funciones de escritura, que son mapeos de
entradas a salidas. Los programas consisten en composiciones de estas funciones. Por lo tanto, una forma
sencilla de programar la nube es permitir a los desarrolladores registrar funciones en la nube y componer
esas funciones en programas. Las ofertas típicas de FaaS hoy en día soportan una variedad de lenguajes
(por ejemplo, Python, Java, Javascript, Go), permiten a los programadores registrar funciones con el
proveedor de la nube, y permiten a los usuarios declarar eventos que activan cada función. La
infraestructura FaaS supervisa los eventos desencadenantes, asigna un tiempo de ejecución a la función,
la ejecuta y mantiene los resultados. El usuario sólo recibe una factura por los recursos informáticos
utilizados durante la invocación de funciones. Una oferta de FaaS por sí misma es de poco valor, ya que la
ejecución de cada función es aislada y efímera. La construcción de aplicaciones sobre FaaS requiere la
gestión de datos tanto en almacenamiento persistente como temporal, además de mecanismos para
activar y escalar la ejecución de funciones. Como resultado, los proveedores de nube enfatizan
rápidamente que la ausencia de servidores no es sólo FaaS. Es FaaS apoyado por una "biblioteca
estándar": los diversos servicios de escalado automático y multitenantados proporcionados por el
proveedor1. En el caso de AWS, esto incluye S3 (almacenamiento de objetos grandes), DynamoDB
(almacenamiento de valores clave), SQS (servicios de cola), SNS (servicios de notificación), y más. Toda
esta infraestructura es administrada y operada por AWS; los desarrolladores simplemente registran el
código FaaS que utiliza estos servicios y reciben facturas de "pago por uso" que aumentan y disminuyen
de acuerdo con su uso de almacenamiento y computación.

1.2 Hacia adelante, pero también hacia atrás

Enfatizamos que la computación sin servidor proporciona un modelo de programación que no es

simplemente elástico, en el sentido de que los humanos o los scripts pueden añadir y eliminar recursos
según sea necesario; es autoescalado. La carga de trabajo dirige automáticamente la asignación y la
desasignación de recursos. A medida que las aplicaciones modernas aumentan en dinámica y
complejidad, la tarea de asignar las máquinas virtuales de forma dinámica, supervisar los servicios y
responder a los cambios en la carga de trabajo se vuelve cada vez más onerosa y requiere una observación
humana constante o guiones a medida desarrollados para aplicaciones individuales. Al proporcionar
escalabilidad automática, las ofertas actuales de FaaS dan un gran paso adelante en la programación en
nube, ofreciendo una plataforma informática prácticamente gestionable y aparentemente ilimitada2.
Desafortunadamente, como veremos, las ofertas de la FaaS de hoy también retroceden dos pasos
importantes. En primer lugar, ignoran dolorosamente la importancia de un procesamiento eficiente de
los datos. En segundo lugar, obstaculizan el desarrollo de sistemas distribuidos. Esto es curioso, ya que la
computación distribuida basada en datos está en el centro de la mayor parte de la innovación en la
computación moderna. En el resto del artículo, destacamos los casos sencillos en los que FaaS ofrece
actualmente algunos beneficios. A continuación detallamos las deficiencias de las plataformas FaaS
existentes a las que se ha aludido anteriormente, y presentamos casos de uso sencillo para los que FaaS
es incapaz de proporcionar una forma eficiente de hacer las cosas. Por último, esbozamos los retos para
avanzar hacia una infraestructura de programación en la nube totalmente realizada.

2
2 SIN SERVIDOR ES MÁS? LOS CASOS FÁCILES AWS

Lambda ha sido adoptado por varias aplicaciones que buscan simplificar sus despliegues en nube. Muchos
de estos casos de uso han sido documentados por Amazon[16]. Esta sección proporciona una visión
general de los patrones de diseño empleados por estas aplicaciones documentadas. Los casos de uso
enumerados pueden dividirse en tres categorías basadas en la naturaleza de la interacción entre las
invocaciones de funciones. Funciones vergonzosamente paralelas. En algunas aplicaciones, cada
invocación de funciones es una tarea independiente y nunca necesita comunicarse con otras funciones.
Estos usos de las funciones lambda están intrínsecamente limitados en su alcance y complejidad. Ejemplos
concretos incluyen funciones que redimensionan las versiones canónicas de las imágenes para su uso en
una variedad de dispositivos de usuario final (Seattle Times), realizan reconocimiento de objetos en
imágenes (V!Studios), y ejecutan optimizaciones basadas en programación entera (Financial Engines)[16].
Los proyectos de investigación PyWren[13] y ExCamera[6] han demostrado que AWS Lambda se puede
hacer (con cierto esfuerzo) para realizar una variedad más amplia de estas funciones de "mapa",
incluyendo algunas cargas de trabajo de caracterización simple y álgebra lineal. Tales aplicaciones pueden
explotar directamente las características de auto-escalado de Lambda para escalar hacia arriba o hacia
abajo bajo demanda porque las solicitudes independientes nunca necesitan comunicarse entre sí y sólo
requieren pequeños gránulos de computación. Funciones de orquestación. Una segunda clase de casos
de uso aprovecha las funciones sin servidor simplemente para orquestar llamadas a servicios de
autoescala patentados, como los análisis a gran escala. Por ejemplo, Amazon proporciona una
arquitectura de aplicación de referencia que utiliza funciones Lambda para orquestar consultas analíticas
que son ejecutadas por AWS Athena, un servicio de consultas a escala automática que funciona con datos
en S3[24]. Otro ejemplo utiliza funciones Lambda para preprocesar los flujos de eventos antes de
canalizarlos a Athena a través de S3[21]. En ambas aplicaciones el "levantamiento pesado" del cálculo
sobre los datos es realizado por Athena, no por las funciones Lambda. Esto permite una manipulación
eficiente de los datos a escala, al introducir el cálculo en un servicio de autoescala existente. Nuestra
experiencia en el desarrollo de Google Cloud Dataprep de Trifacta es también un ejemplo de este patrón
de diseño[10]. La arquitectura básica de Dataprep incluye (1) software de cliente web que sintetiza
programas en el lenguaje específico del dominio (DSL) de Google Cloud Dataflow, (2) servicios de
autoescalado sin estado en Google Cloud que gestionan las solicitudes de los clientes y transmiten los
extractos DSL a Dataflow, y (3) el servicio de autoescalado Dataflow que ejecuta el DSL a escala. Aunque
el nivel medio aquí no está implementado sobre la oferta FaaS de Google, arquitecturas similares podrían
usar FaaS. Función Composición. La tercera categoría consiste en un conjunto de funciones que se
componen para crear aplicaciones y, por lo tanto, necesitan transmitir productos e insumos. Algunos
ejemplos de estas aplicaciones son los flujos de trabajo de funciones encadenadas mediante
dependencias de datos. Estas funciones generalmente manipulan el estado de alguna manera, y están
diseñadas como flujos de trabajo guiados por eventos de las funciones de Lambda, cosidas entre sí
mediante sistemas de colas (como SQS) o almacenes de objetos (como S3). Por ejemplo, la plataforma de
creación de cuentas de Autodesk realiza varias invocaciones de funciones en el camino crítico de crear
una sola cuenta de usuario[16]. Cada invocación maneja una pequeña porción de la lógica de creación de
la cuenta, como la notificación y validación de correo electrónico. Los autores de ese estudio de caso
reportaron tiempos promedio de registro de extremo a extremo de diez minutos; como veremos en la
siguiente sección, los gastos generales del manejo de tareas de Lambda y la administración del estado
explican algo de esta latencia. En resumen, las soluciones FaaS actuales son atractivas para cargas de
trabajo simples de tareas independientes, ya sean tareas vergonzosamente paralelas integradas en las
funciones de Lambda o tareas que deben ser ejecutadas por los servicios cloud propietarios. Los casos de
uso que implican tareas de estado tienen una latencia sorprendentemente alta: 10 minutos es un largo
tiempo de respuesta para que un proveedor de cloud computing haga publicidad, incluso para un flujo de

3
trabajo de registro. Estas realidades limitan los atractivos casos de uso de FaaS hoy en día, desalentando
nuevos programas de terceros que van más allá de las ofertas de servicios propietarios de los
proveedores.

3 POR QUÉ SERVERLESS HOY EN DÍA ES DEMASIADO POCO

La nube ofrece tres características clave: almacenamiento de datos ilimitado, potencia de computación
distribuida ilimitada y la capacidad de aprovecharlas sólo cuando sea necesario, pagando sólo por los
recursos que consuma, en lugar de comprar los recursos que pueda necesitar en el momento de mayor
consumo. La computación sin servidores da un paso adelante y dos pasos atrás en esta visión. Se da cuenta
del potencial de la ejecución de código de usuario final de pago por uso, totalmente gestionada a través
de la autoescala. Desafortunadamente, como veremos en esta sección, las ofertas actuales de FaaS
restringen fatalmente la capacidad de trabajar eficientemente con datos o recursos informáticos
distribuidos. Como resultado, la computación sin servidores hoy en día es, en el mejor de los casos, una
forma simple y poderosa de ejecutar computaciones paralelas vergonzosamente o de aprovechar
servicios propietarios. En el peor de los casos, puede verse como un esfuerzo cínico para bloquear a los
usuarios en esos servicios y para bloquear la innovación. La lista de las limitaciones de la oferta actual de
FaaS es notable. Nuestro ejemplo en ejecución, AWS Lambda, tiene las siguientes limitaciones que son
típicas de los demás proveedores3:

(1) Vida útil limitada. Después de 15 minutos, las invocaciones de funciones son desactivadas por la
infraestructura Lambda. Lambda puede mantener el estado de la función almacenado en la VM de
alojamiento para soportar el "arranque en caliente", pero no hay forma de garantizar que las invocaciones
posteriores se ejecuten en la misma VM. Por lo tanto, las funciones deben ser escritas asumiendo que el
estado no será recuperable a través de las invocaciones.

(2) Cuellos de botella de E/S. Las Lambdas se conectan a los servicios en la nube, en especial al
almacenamiento compartido, a través de una interfaz de red. En la práctica, esto significa típicamente
mover datos a través de nodos o racks. Con FaaS, las cosas parecen incluso peores de lo que sugiere la
topología de la red. Estudios recientes muestran que una sola función Lambda puede alcanzar un
promedio de 538Mbps de ancho de banda de red; los números de Google y Azure estaban en el mismo
estadio[27]. Peor aún, AWS parece intentar agrupar las funciones Lambda del mismo usuario en una sola
VM, de modo que el limitado ancho de banda es compartido por múltiples funciones. El resultado es que
a medida que la potencia de cálculo aumenta, el ancho de banda por función se reduce
proporcionalmente. Con 20 funciones Lambda, el ancho de banda medio de la red era 28,7 Mbps-2,5
órdenes de magnitud más lento que una única SSD[27]4.

(3) Comunicación a través de almacenamiento lento. Aunque las funciones Lambda pueden iniciar
conexiones de red de salida, no son directamente direccionables a la red mientras se ejecutan. Como
resultado, dos funciones Lambda sólo pueden comunicarse a través de un servicio intermediario de
autoescala; hoy en día, esto significa un sistema de almacenamiento como S3 que es radicalmente más
lento y más costoso que las redes punto a punto. Como corolario, un cliente de Lambda no puede abordar
la instancia de función particular que manejó la solicitud previa del cliente: no hay "pegajosidad" para las
conexiones con el cliente. Por lo tanto, mantener el estado en todas las llamadas de los clientes requiere
escribir el estado para ralentizar el almacenamiento y volver a leerlo en cada llamada posterior.

(4) No hay hardware especializado. Las ofertas de FaaS hoy en día sólo permiten a los usuarios
aprovisionar una porción de tiempo de un hiperhilo de CPU y una cierta cantidad de RAM; en el caso de
AWS Lambda, uno determina al otro. No existe una API o mecanismo para acceder a hardware
especializado. Sin embargo, como explicaron Patterson y Hennessy en su reciente conferencia de
Turing[20], la especialización en hardware sólo se acelerará en los próximos años.

Estas restricciones, combinadas con algunas deficiencias significativas en la biblioteca estándar de las
ofertas de FaaS, limitan sustancialmente el alcance de las aplicaciones factibles sin servidor. Una serie de

4
corolarios siguen directamente. FaaS es una arquitectura de envío de datos. Esta es quizás la mayor
deficiencia arquitectónica de las plataformas FaaS y sus APIs. Las funciones sin servidor se ejecutan en
VMs aisladas, separadas de los datos. Además, las funciones sin servidor son de corta duración y no
direccionables, por lo que su capacidad de almacenar en caché el estado internamente para atender
solicitudes repetidas es limitada. Por lo tanto, FaaS rutinariamente "envía datos a codificar" en lugar de
"código de envío a datos". Se trata de un antipatrón arquitectónico recurrente entre los diseñadores de
sistemas, que los aficionados a las bases de datos parecen necesitar señalar en cada generación. Las
realidades de la jerarquía de la memoria - a través de varias capas de almacenamiento y retardos de red
- hacen que ésta sea una mala decisión de diseño por razones de latencia, ancho de banda y costo. FaaS
Stymies Distributed Computing. Debido a que no hay direccionabilidad de red de las funciones sin
servidor, dos funciones pueden trabajar juntas sin servidor sólo al pasar datos a través de un
almacenamiento lento y costoso. Esto bloquea la informática distribuida básica. Ese campo se basa en
protocolos que realizan una comunicación de gran precisión entre los agentes, incluyendo aspectos
básicos como la elección del líder, la membresía, la consistencia de los datos y el compromiso de la
transacción. Muchas aplicaciones distribuidas y paralelas -especialmente en computación científica-
también dependen de una comunicación de grano fino. Se podría argumentar que FaaS fomenta un nuevo
modelo de programación distribuida basado en el estado global. Pero es bien sabido que existe una
dualidad entre los procesos de transmisión de mensajes y las funciones impulsadas por eventos en datos
compartidos[17]. Para FaaS, la gestión de eventos sigue requiriendo el paso de piezas del estado global
desde el almacenamiento lento hacia y desde las funciones sin estado, lo que conlleva tiempo y costes.
Mientras tanto, las ofertas actuales de almacenamiento sin servidor ofrecen una débil consistencia entre
réplicas. Por lo tanto, en el patrón impulsado por eventos, el acuerdo entre las funciones efímeras todavía
tendría que "atornillarse" como un protocolo de E/S adicionales similar al consenso clásico. En resumen,
con todas las comunicaciones en tránsito a través del almacenamiento, no hay una forma real de que
miles (y mucho menos millones) de núcleos en la nube trabajen juntos de forma eficiente utilizando las
plataformas actuales de FaaS, salvo a través de un paralelismo en gran medida descoordinado
(vergonzoso). FaaS bloquea la innovación de software acelerado por hardware. Muchos de los principales
casos de uso de Big Data hoy en día aprovechan el hardware personalizado. El ejemplo más destacado es
el uso generalizado de las GPU en el aprendizaje profundo, pero también existe una innovación constante
en el uso de aceleradores para el procesamiento de bases de datos. Todas las ofertas actuales de FaaS se
ejecutan en una plataforma de máquina virtual uniforme y bastante mundana. Estas máquinas virtuales
no sólo no ofrecen procesadores personalizados, sino que las ofertas actuales de FaaS ni siquiera admiten
bases de datos de memoria principal que mantienen grandes estructuras de datos basadas en RAM: la
mayor instancia de Lambda sólo permite 3 GB de RAM. La falta de acceso a dicho hardware -junto con
modelos de precios adecuados- limita significativamente la utilidad de las ofertas de FaaS como
plataforma para la innovación de software. FaaS desalienta la innovación en los servicios de código
abierto. El software de código abierto más popular no puede ejecutarse a escala en las ofertas actuales
sin servidor. Podría decirse que esto es inherente: que el software no fue diseñado para la ejecución sin
servidor, y espera una operación humana. Pero dadas las limitaciones de la FaaS en el procesamiento de
datos y la computación distribuida, no se debe esperar que surja un nuevo software de código abierto
escalable. En particular, los sistemas de datos de código abierto -un área de rápido crecimiento y madurez
en los últimos años- serían imposibles de construir sobre la base de las ofertas actuales de FaaS. La actual
infraestructura sin servidores, intencionadamente o no, bloquea a los usuarios para que utilicen servicios
de proveedores propietarios o para que mantengan sus propios servidores.

3.1 Estudios de caso

Para evaluar la gravedad de estos problemas, documentamos tres estudios de caso a partir de Big Data y
la configuración de la computación distribuida. Entrenamiento con modelos. Nuestro primer caso de
estudio explora el rendimiento de AWS Lambda para una aplicación común de datos intensivos: la
formación en modelos de aprendizaje de máquinas. Como veremos, sufre dramáticamente de la
arquitectura de envío de datos de Lambda. Utilizando datos de revisión de productos públicos de

5
Amazon[2], configuramos TensorFlow para entrenar una red neuronal que predice las valoraciones
medias de los clientes. Cada reseña de producto se presenta con un modelo de bolsa de palabras, lo que
da como resultado 6.787 características y un total de 90 GB de datos de formación. El modelo es un
perceptrón multicapa con dos capas ocultas, cada una con 10 neuronas y una función de activación de
Relu. A cada lambda se le asigna la vida útil máxima (15 minutos) y 640 MB de RAM y se ejecutan tantas
iteraciones de entrenamiento como sea posible. Nuestro programa de formación utiliza el AdamOptimizer
con una velocidad de aprendizaje de 0,001 y un tamaño de lote de 100 MB. Cada iteración en Lambda
tomó 3.08 segundos: 2.49 para obtener un lote de 100MB desde S3 y 0.59 segundos para ejecutar el
AdamOptimizer. Una función Lambda sobrepasa su límite de 15 minutos después de 294 iteraciones de
este algoritmo. Entrenamos el modelo en más de 10 pases completos de los datos de entrenamiento, lo
que se traduce en 31 ejecuciones lambda secuenciales, cada una de las cuales dura 15 minutos, o 465
minutos de latencia total. Esto cuesta $0.29. Para comparar, entrenamos el mismo modelo en una
instancia m4.large EC2, que tiene 8GB de RAM y 2vCPUs. En esta configuración, cada iteración es
significativamente más rápida (0,14 segundos): 0,04 segundos para obtener datos de un volumen de EBS
y 0,1 segundos para ejecutar el optimizador. El mismo proceso de entrenamiento toma alrededor de 1300
segundos (poco menos de 22 minutos), lo que se traduce en un costo de $0.04. Los recursos limitados y
la arquitectura de envío de datos de Lambda hacen que la ejecución de este algoritmo en Lambda sea 21
veces más lenta y 7,3 veces más cara que en EC2. Servicio de predicción de baja latencia por lotes. Nuestro
siguiente estudio de caso se enfoca en el uso de un modelo entrenado: hacer predicciones en vivo. Hemos
estado trabajando durante algún tiempo en el servicio de predicción de baja latencia en Clipper[5]. A
primera vista, el servicio de predicción parece ser muy adecuado para la FaaS. Cada función es
independiente, y se pueden desplegar múltiples copias para escalar el número de predicciones realizadas
con un determinado modelo. En la práctica, el servicio de predicción se basa en el acceso a hardware
especializado, como las GPU, que no están disponibles a través de AWS Lambda. Dejando este tema a un
lado, queríamos entender si las optimizaciones de rendimiento clave de un sistema como Clipper podrían
lograrse en un entorno FaaS. Una de las optimizaciones en Clipper es procesar las entradas en lotes; en el
caso tradicional, esto proporciona un paralelismo de tuberías a través de la gestión de las solicitudes de
entrada (realizadas por una CPU) con el procesamiento vectorial de predicción de múltiples entradas
(realizado por una GPU). Teníamos curiosidad por ver si el Lambda podría proporcionar beneficios
similares para la acumulación de lotes de tubería con predicción. Con ese fin, ejercitamos el servicio
preferido de Lambda para la dosificación de insumos: Servicio Simple de Cola de AWS (SQS). Escribimos
una sencilla aplicación en Lambda que canaliza el trabajo de dosificación realizado por SQS con un
clasificador trivial que funciona en las funciones de Lambda. Concretamente, nuestra aplicación acepta
lotes de documentos de texto, utiliza un modelo para clasificar cada palabra del documento como "sucia"
o no, y escribe el documento en un servicio de almacenamiento con las palabras sucias sustituidas por
signos de puntuación. Nuestro modelo en este experimento es una simple lista negra de palabras sucias.
SQS sólo permite lotes de 10 mensajes a la vez, por lo que limitamos todos los experimentos aquí a lotes
de 10 mensajes. La latencia media de más de 1.000 invocaciones de lotes para la aplicación Lambda era
de 559 ms por lote si el modelo se recuperaba en cada invocación y los resultados se escribían en S3.
Como optimización, permitimos que el modelo fuera compilado en la función misma y los resultados
fueron colocados de nuevo en una cola SQS; en esta implementación la latencia promedio de los lotes fue
de 447ms. Para comparar, realizamos dos experimentos usando m5.large EC2. El primero reemplazó el
papel de Lambda en la aplicación con una máquina EC2 para recibir lotes de mensajes SQS, lo que mostró
una latencia de 13 ms por lote con un promedio de más de 1.000 lotes-27 veces más rápido que nuestra
implementación de Lambda "optimizada".

El segundo experimento utilizó ZeroMQ para reemplazar el rol de SQS en la aplicación, y recibir mensajes
directamente en la máquina EC2. Esta versión "serverful" tenía una latencia por lote de 2,8ms-127× más
rápida que la implementación optimizada de Lambda. La fijación de precios añade un insulto a la lesión
de rendimiento en estos servicios. Si quisiéramos escalar esta aplicación a 1 millón de mensajes por
segundo, la tasa de solicitud SQS por sí sola costaría $1,584 por hora. Tenga en cuenta que esto no tiene
en cuenta los costes de ejecución de Lambda. Por otra parte, la instancia EC2 tiene un rendimiento de
aproximadamente 3.500 solicitudes por segundo, por lo que 1 millón de mensajes por segundo requeriría

6
290 instancias EC2, con un coste total de 27,84 dólares por hora, lo que supone un ahorro de costes de
57x. Informática distribuida. Lambda prohíbe la conectividad directa de red entre funciones, por lo que
nos vemos obligados a probar soluciones alternativas para lograr la computación distribuida. Como
veremos, las soluciones disponibles son insosteniblemente lentas. Como se discutió en la sección anterior,
existen dos patrones duales clásicos para implementar sistemas de comunicación concurrentes: ejecución
por eventos sobre estado compartido (el enfoque FaaS natural), o transmisión de mensajes a través de
agentes de larga duración con estado distribuido[17]. En el entorno Lambda, ambos patrones de diseño
comparten la propiedad de que las funciones sólo pueden pasar datos entre sí a través del
almacenamiento compartido: S3 o DynamoDB. En el patrón controlado por eventos, los datos se leen y
se escriben en el almacenamiento al principio y al final de la función. En el patrón de paso de mensajes,
los mensajes se envían por escrito al almacenamiento y se leen desde el almacenamiento a través de
sondeos periódicos. Comenzamos con una simple pregunta: ¿Es el almacenamiento en la nube un medio
de comunicación razonable? Para evaluar esto, medimos la latencia de "enviar/recibir" (escribir+leer)
para comunicar 1KB entre las funciones de Python. Los resultados de Lambda fueron excesivamente
lentos, como se muestra en la Tabla 1. Vienen en dos formas. En primer lugar, medimos el coste de
programación puramente funcional y orientado a eventos de un objeto de 1KB que se gestiona mediante
la invocación de una función Lambda, lo que implica tanto E/S como gastos generales de la función y es
exorbitantemente caro5. A continuación medimos el coste de la E/S explícita de Lambda, es decir, una
lectura y escritura media de una función de larga duración, lo que sigue siendo en un orden de magnitud
más lento de lo que a uno le gustaría. Vemos que las latencias del EC2 son casi idénticas, por lo que los
gastos generales están en los costes de servicio de almacenamiento, no en Lambda. Finalmente
mostramos la latencia de la mensajería usando las funciones de Python direccionándose directamente
entre sí a través de ZeroMQ. Este último coste se aproxima a las típicas mediciones de redes de centros
de datos en bastidores; los estudios de hace incluso unos pocos años informan de que las mediciones
medias entre bastidores se sitúan en torno a 1,26 ms[8] En resumen, la comunicación a través del
almacenamiento en nube no es un sustituto razonable para las redes con dirección directa, incluso con
E/S directa, ya que es al menos un orden de magnitud demasiado lento. El estilo de programación de FaaS
"puro" y funcional exacerba ese gasto en un grado desmesurado, y debe evitarse a toda costa. Para poner
esto en perspectiva, construimos un estudio de caso de sistemas distribuidos en el estilo de agentes
comunicantes. Como se indicó en la sección anterior, independientemente del patrón de diseño que elija,
el acuerdo de estado distribuido (incluso el estado "global" en el almacenamiento ligeramente consistente
de AWS) requiere algún tipo de protocolo. Existe una amplia literatura de protocolos distribuidos, pero la
mayoría requiere al menos ponerse de acuerdo sobre un líder o la membresía del sistema en cualquier
momento. Para modelar esto, implementamos uno de los protocolos más simples en Python: Elección del
líder matón de García Molina[7]. Usando Lambda, toda la comunicación entre nuestras funciones fue
hecha en forma de pizarra vía DynamoDB. Con cada votación de Lambda cuatro veces por segundo,
encontramos que cada ronda de elección de líderes tomaba 16,7 segundos. Recordemos que las funciones
de Lambda mueren después de 15 minutos. Por lo tanto, en el escenario (inalcanzable) del mejor de los
casos -cuando cada líder es elegido inmediatamente después de unirse al sistema- el sistema gastará el
1,9% de su tiempo total simplemente en el protocolo de elección del líder. Incluso si usted piensa que
esto es tolerable, tenga en cuenta que el uso de DynamoDB como un medio de comunicación de grano
fino es increíblemente caro: El soporte de un clúster de 1.000 nodos cuesta como mínimo 450 dólares por
hora6.

3.2 ¿Pueden las limitaciones liberarnos?

Las limitaciones documentadas anteriormente hacen que los actuales marcos de trabajo FaaS sean
insostenibles para la creación de nuevas y sofisticadas funcionalidades de backend. Sin embargo, las
limitaciones de los desarrolladores no son necesariamente algo malo. A veces es importante que una
nueva plataforma refleje su "física" de manera que anime a los desarrolladores a escribir programas bien
adaptados a la plataforma. En particular, las limitaciones de FaaS favorecen la flexibilidad operativa sobre
el control del desarrollador, un tema que generalmente coincidimos en que es crítico para la escala y

7
elasticidad de la nube, y un cambio importante en el diseño con respecto a la ética de los sistemas de
datos tradicionales. ¿Son realmente saludables algunas de las limitaciones de la FaaS para el futuro de la
programación distribuida? A veces, comenzar con un modelo limitado asegura que las tareas simples sigan
siendo simples. Como patrón general de diseño, el código sin estado tiene muchas virtudes: generalmente
es fácil de escribir y depurar, y por naturaleza puede ser trivial y dinámicamente replicado y reiniciado
con el propósito de escalar y tolerar fallas. Si vemos a serverless como un DSL y tiempo de ejecución para
las tareas simples en las que sobresale, sus limitaciones pueden ayudar a asegurar una buena higiene del
software. Otra ventaja de las restricciones es que pueden conducir a una innovación más profunda. Como
ejemplo destacado, la incapacidad de las funciones de FaaS para comunicarse puede obligarnos a pensar
más profundamente sobre por qué y cuándo debemos utilizar los protocolos de coordinación de los
sistemas distribuidos, y cuándo podemos funcionar sin coordinación. Los frameworks FaaS actuales
ofrecen pocas garantías en cuanto a la ejecución secuencial a través de las funciones. Los desarrolladores
se ven obligados a componer programas más grandes a partir de tareas asíncronas, sin garantías como la
consistencia secuencial o la serialización para razonar sobre la semántica de la mutación del estado global
a través de las tareas. Estas limitaciones pueden ser un reto para los desarrolladores acostumbrados a
escribir programas o transacciones secuenciales. Pero el resultado puede ser saludable y manejable: este
tipo de modelo "desordenado" y poco consistente ha estado en el centro de varias propuestas de
propósito más general para el diseño de programas escalables y disponibles en los últimos años, incluso
de nuestro grupo[9, 1, 23, 15]. Un rasgo distintivo del trabajo reciente en esta área es que ofrece
construcciones de programación que son más ricas que la composición de funciones de caja negra; en
principio, sin embargo, las ideas podrían ser superpuestas a las de FaaS. Como otro ejemplo, los
frameworks FaaS de hoy en día no ofrecen garantías de localización física del hardware: los
desarrolladores no pueden controlar dónde se ejecutará una función, o si su dirección física permanecerá
constante. Una vez más, esto puede ser una limitación manejable: el direccionamiento virtual de agentes
que cambian dinámicamente fue un sello distintivo del trabajo previo en la investigación peer-to-peer que
presagiaba los servicios en la nube[22, 25]. Otro beneficio de la simplicidad es que puede fomentar el
desarrollo de la plataforma y la comunidad. Hay una analogía constructiva con MapReduce. Aunque no
fue un éxito por derecho propio, MapReduce fue sencillo para los desarrolladores al principio; como
resultado, ayudó a cambiar la mentalidad de la comunidad de desarrolladores y, finalmente, condujo a la
revitalización de SQL y el álgebra relacional (en forma de librerías "dataframe") como interfaces populares
y escalables para la programación de análisis sofisticados. Tal vez las ofertas actuales de FaaS conduzcan
de manera similar a la revitalización de ideas previas para la programación distribuida a escala. Una
diferencia notable es que el SQL y el álgebra relacional estaban bien establecidos, mientras que el estado
final natural de la programación distribuida asíncrona sobre datos en la nube sigue siendo una cuestión
de investigación y debate. Creemos que muchas de las limitaciones de las ofertas actuales de FaaS
también se pueden superar, manteniendo el autoescalado y desbloqueando el potencial de rendimiento
de los datos y la informática distribuida. En la siguiente sección esbozamos lo que consideramos los
principales desafíos y oportunidades para avanzar en los tres frentes.

3.3 Objeciones anticipadas

En este documento nos centramos intencionadamente en las limitaciones de las API de FaaS públicas, y
argumentamos que están decepcionantemente lejos de estar listas para una programación de propósito
general y rica en datos. Aunque muchos de nuestros primeros lectores estuvieron de acuerdo con los
desafíos que hemos planteado, también hemos escuchado objeciones. Tratamos de abordar los más
comunes aquí.

"Sigue usando esa palabra. No creo que signifique lo que tú crees que significa".

Algunos de nuestros colegas que trabajan en las plataformas en nube han argumentado que nuestra visión
del término "sin servidor" es demasiado estrecha: detrás de la cortina de un proveedor de nube, están

8
construyendo soluciones "sin servidor" para los clientes que son de escalado automático y libre de
gestión.entendemos que el uso del término - hablamos de Google Cloud Dataprep de forma similar. Tal
vez esta confusión sea la razón por la que "sin servidor" no es un adjetivo útil para reunir a la comunidad
técnica en torno a la innovación en la nube. En pocas palabras, la entrega de un servicio backend especial
de escalado automático no resuelve el problema de permitir la programación en nube de propósito
general. Además, el trabajo requerido para entregar estas ofertas de backend "sin servidor" se realiza en
gran medida con una programación "nodo a nodo" anticuada y es una tarea tradicional y costosa. De
hecho, cualquiera puede hacer este tipo de trabajo en la nube pública sin ofertas "sin servidor", utilizando
plataformas de orquestación como Kubernetes7. Nuestro objetivo aquí es suscitar un debate más
profundo sobre el gran reto de la programación a escala de nube, un reto que creemos que las ofertas de
FaaS de cara al público están intentando (y en la actualidad están fallando) proporcionar.

"¡Sólo espera el próximo anuncio de la cadena!"

Algunos lectores de los primeros borradores comentaron que las redes de centros de datos son cada vez
más rápidas y que los proveedores de cloud computing transmiten estas innovaciones a los clientes.
Además, hoy en día se sabe que el escalamiento debe lograrse separando los niveles de cálculo y de datos.
No tenemos nada que objetar a estos puntos, pero no abordan los problemas clave que planteamos aquí,
más allá de las cuestiones de afinación. Las redes de centros de datos seguramente mejorarán, pero
inevitablemente continuarán jugando un papel limitante en una jerarquía de memoria más amplia.
Cualquier diseño de sistema razonable necesitará la capacidad de coubicar selectivamente el código y los
datos en el mismo lado de un límite de la red, ya sea mediante el almacenamiento en caché/prefabricación
de datos cerca del cálculo o empujando el cálculo más cerca de los datos. Ninguna de las dos
características es proporcionada de manera significativa por las ofertas actuales de FaaS. Las mejoras en
la velocidad de la red son improbables, ya que pueden cambiar los parámetros de uso de ciertas
optimizaciones, pero rara vez justifican la ausencia de esas oportunidades de optimización. Mientras
tanto, la separación de los niveles de computación y almacenamiento en un diseño lógico no debe impedir
la coubicación en una implementación física; se puede escalar el cálculo y el almacenamiento de forma
independiente para obtener flexibilidad y ubicarlos según sea necesario para el rendimiento. Este es el
corazón de las indirecciones arquitectónicas como la "independencia de datos": aumentan la flexibilidad
en lugar de limitarla. A un nivel técnico más reducido, los avances actuales en materia de redes no parecen
radicales. Las redes de latencia ultra baja como Inifiniband tienen un alcance limitado; requieren una
interconexión que soporte la conmutación, la cual naturalmente incurre en latencia. El límite de alcance
se traduce entonces típicamente en una necesidad de enrutamiento jerárquico para escalar
horizontalmente, lo que da heterogeneidad de latencia. Mientras tanto, otras tecnologías mejorarán
junto con las redes, incluido el almacenamiento conectado directamente, como HBM y NVRAM.

"El punto principal es la economía simple: Sin servidor es inevitable."

Algunos han visto este documento como una visión negativa de la computación sin servidores, y desde
esa perspectiva ven el documento en el lado equivocado de la historia. Después de todo, varios
observadores de la industria han descrito la inevitabilidad económica de la computación sin servidores.
Por citar a uno de ellos: No tuve que preocuparme por construir una plataforma y el concepto de un
servidor, la planificación de la capacidad y todo eso del "yak shaving" estaba lejos de mi mente.... Sin
embargo, estos cambios no son realmente las partes emocionantes. El asesino, el gotcha es la facturación
por la función.... Esto es como el maná del cielo para alguien que intenta construir un negocio.
Ciertamente tengo la inversión en el desarrollo del código pero con la aplicación siendo un costo
operacional variable entonces puedo hacer una máquina de impresión de dinero que crece con los
usuarios.... Es de esperar que el mundo entero se vea superado por la falta de servidores para el año
2025[28]. No es nuestra intención echar agua fría sobre esta visión. Para reiterar, vemos el escalamiento
automático (y por lo tanto el pago por uso) como un gran paso adelante, pero decepcionantemente

9
limitado a las aplicaciones que pueden funcionar sobre la infraestructura de proveedores de hoy en día.
Reconocemos que existe un enorme mercado de aplicaciones tan "estrechas", muchas de las cuales
consisten en poco más que lógica de negocio sobre una base de datos. La interrupción de estas
aplicaciones mediante el cambio de su economía desplazará un gasto significativo de los proveedores
empresariales tradicionales a proveedores nuevos y más eficientes basados en la nube. Sin embargo, este
movimiento empresarial no acelerará el cambio radical en la computación que ofrece la nube.
Específicamente, no fomentará -y puede incluso disuadir- el desarrollo por parte de terceros y de código
abierto de nuevos servicios de estado, que son el núcleo de la informática moderna. Mientras tanto, con
la innovación disuadida, los proveedores de cloud computing incrementan el dominio del mercado para
sus soluciones propietarias. Esta línea de razonamiento puede sugerir que la computación sin servidor
podría producir un mínimo local: otro escenario en el que el potencial de computación y almacenamiento
de la nube se pierde en el ruido de la refactorización de casos de uso de baja tecnología y a menudo
legacy. El objetivo de nuestra discusión aquí -y esperamos que sea el objetivo de nuestro público objetivo-
es empujar la tecnología central hacia abajo en el campo de juego, en lugar de apostar por ella desde
fuera. Con este fin, esperamos que este artículo cambie la discusión de "What is serverless" o "Will
serverless win" a un replanteamiento de cómo diseñamos la infraestructura y los modelos de
programación para impulsar la innovación real en sistemas ricos en datos y a escala de nube. Para llegar
a ese futuro es necesario volver a examinar los diseños y las limitaciones de lo que hoy se denomina
"computación sin servidor".

4 UN PASO ADELANTE HACIA EL FUTURO

Creemos firmemente que los programadores de la nube -ya sea que estén escribiendo aplicaciones
simples o sistemas complejos- necesitan ser capaces de aprovechar la potencia de cálculo y la capacidad
de almacenamiento de la nube de una manera auto escalable y rentable. El logro de estos objetivos
requiere un marco programable que vaya más allá de FaaS, para gestionar dinámicamente la asignación
de recursos con el fin de cumplir con los objetivos de rendimiento especificados por el usuario, tanto para
el cálculo como para los datos. Aquí identificamos algunos de los retos clave que quedan para lograr un
entorno verdaderamente programable para la nube. Código de Fluido y Colocación de Datos. Para lograr
un buen rendimiento, la infraestructura debe ser capaz y estar dispuesta a colocar físicamente ciertos
códigos y datos. Esto a menudo se logra mejor enviando el código a los datos, en lugar del enfoque FaaS
actual, que consiste en llevar los datos al código. Al mismo tiempo, la elasticidad requiere que el código y
los datos estén separados lógicamente, para permitir que la infraestructura adapte la colocación: a veces
los datos necesitan ser replicados o repartidos para que coincidan con las necesidades del código. En
esencia, éste es el reto tradicional de la independencia de los datos, pero a una escala extrema y variable,
con un uso multiarrendado y una gran adaptabilidad en el tiempo. Los DSL de alto nivel centrados en los
datos (por ejemplo, SQL+UDFs, MapReduce, TensorFlow) pueden hacer que esto sea más fácil de tratar,
al exponer a un alto nivel cómo fluyen los datos a través de la computación. Cuanto más declarativo sea
el lenguaje, más lógica será la separación (y optimización del espacio de búsqueda) que se ofrece a la
infraestructura. Soporte de Hardware heterogéneo. Los proveedores de cloud computing pueden atraer
una masa crítica de cargas de trabajo que hacen que el hardware especializado sea rentable. Los
programadores de la nube deberían poder aprovechar estos recursos. Idealmente, los desarrolladores de
aplicaciones podrían especificar aplicaciones utilizando DSLs de alto nivel, y los proveedores de cloud
computing compilarían esas aplicaciones en el hardware más rentable que cumpla con los SLOs
especificados por el usuario. Alternativamente, para ciertos diseños puede ser útil permitir a los
desarrolladores dirigir el código a características de hardware específicas por especificación, para
fomentar el co-diseño innovador de hardware/software. Uno puede tener debates filosóficos sobre si tal
co-diseño es apropiado, o si la "independencia del hardware" es una preocupación primordial en la nube.
En cualquier caso, reconocer la afinidad del hardware no significa que aboguemos por una vinculación
estrecha del hardware a los servicios; la plataforma debe tomar decisiones físicas dinámicas sobre la
asignación de código a recursos distinguidos, basadas en especificaciones de requisitos de rendimiento
lógico proporcionadas por los programadores o extraídas del código. Estas especificaciones se pueden

10
aprovechar para la multiplexación más general, consciente de la heterogeneidad de los recursos y de la
división espacio-temporal[26]. Agentes virtuales direccionables de larga duración.

Las afinidades entre el código, los datos y/o el hardware tienden a repetirse con el tiempo. Si la plataforma
paga un costo para crear una afinidad (por ejemplo, mover datos), debería recuperar ese costo a través
de múltiples solicitudes. Esto motiva la capacidad de los programadores para establecer agentes de
software -llamados funciones, actores, servicios, etc.- que persisten en el tiempo en la nube, con
identidades conocidas. Estos agentes deben ser abordables con un rendimiento comparable al de las
redes estándar. Sin embargo, los requisitos de elasticidad dictan que estos agentes se redistribuyan virtual
y dinámicamente a través de los recursos físicos. De ahí que necesitemos alternativas virtuales a las
construcciones de sistemas operativos tradicionales como "hilos" y "puertos": puntos finales con nombre
en la red. Varias ideas de la literatura han aportado aspectos de esta idea: actores[11], tuplespaces[4]
pub/sub[19] y DHTs[22] son todos ejemplos. Las soluciones elegidas necesitan incurrir en gastos generales
mínimos en el rendimiento de la red en bruto. Programación desordenada. Como se mencionó
anteriormente, los requisitos de la computación distribuida y el redimensionamiento elástico requieren
cambios en la programación. La metáfora secuencial de la programación procedimental no escalará a la
nube. Los desarrolladores necesitan lenguajes que fomenten el código que funcione correctamente en
unidades pequeñas y granulares -tanto de datos como de cálculo- que puedan moverse fácilmente a
través del tiempo y el espacio. Hay ejemplos de estos patrones en la literatura, particularmente en
metáforas basadas en flujos asíncronos como Functional Reactive Programming[12] y Declarative
Languages for Networking[18] y Distributed Computing[1]. Un desafío particular en la computación
distribuida es combinar estas metáforas de programación con el razonamiento sobre la semántica de la
consistencia de los datos distribuidos; el trabajo anterior ofrece algunas respuestas[9, 1, 23, 3, 15], pero
se necesita más trabajo para permitir aplicaciones de servicio completo. Programación flexible, IR común.
Idealmente, una variedad de nuevos lenguajes de programación y DSLs serán explorados en este dominio.
Aún así, es oneroso para cada pila de lenguajes implementar un conjunto completo de las optimizaciones
relevantes (por ejemplo, código y datos de fluidos, construcciones desordenadas). Como resultado, sería
muy beneficioso desarrollar una Representación Intermedia (IR) interna común para la ejecución en nube
que pueda servir como un objetivo de compilación desde muchos idiomas. Este IR debe soportar código
enchufable de una variedad de lenguajes, como es hecho por UDFs en lenguajes declarativos, o funciones
en FaaS.

Objetivos y garantías de nivel de servicio: Hoy en día, ninguna de las principales ofertas de FaaS tiene APIs
para objetivos de nivel de servicio. El precio es simplemente una función del "tamaño" (RAM, número de
núcleos) y del tiempo de funcionamiento utilizado. Para apoyar el uso práctico, las ofertas de FaaS
deberían permitir a los SLOs que tienen el precio correspondiente, con las penalizaciones apropiadas por
estimación errónea. Lograr OSGs predecibles requiere una "superficie de costes" suave en la optimización
- las no linealidades son la perdición de los OSGs. Esto refuerza nuestra discusión anterior con respecto a
los pequeños gránulos de código y datos con la colocación de fluidos y la ejecución desordenada.
Preocupaciones de seguridad: La programación en la nube trae consigo tanto oportunidades como retos
relacionados con la seguridad. La infraestructura de software gestionada por la nube transfiere la
responsabilidad de la seguridad a un pequeño número de personal de operaciones bien motivado en el
proveedor de cloud computing. Esto, junto con las especificaciones adecuadas de las políticas del cliente,
debería, en principio, mitigar muchos de los problemas de seguridad que se producen hoy en día debido
a la mala configuración o a la mala gestión. Además, si la programación en la nube se logra a través de
abstracciones de alto nivel, ofrecerá la oportunidad para el análisis de programas y la aplicación de
restricciones que podrían mejorar la seguridad. Sin embargo, algunas de las mejoras arquitectónicas
deseadas para el desempeño en este documento hacen más difícil lograr la seguridad para las partes
responsables. Por ejemplo, permitir que el código se mueva con fluidez hacia el almacenamiento de datos
compartidos es potencialmente complicado: exacerba los retos de gestión de la seguridad relacionados
con la multitenencia y la posibilidad de que el código malicioso reúna señales entre los clientes. Pero hay
nuevas oportunidades de investigación para la innovación en este espacio. Tecnologías como los enclaves

11
de hardware pueden ayudar a proteger el código en ejecución, y ha habido un trabajo inicial en el
procesamiento de datos en esas configuraciones (por ejemplo,[29]). Mientras tanto, es importante que
los investigadores y desarrolladores piensen no sólo en las tecnologías preventivas, sino también en las
formas de garantizar la auditoría y el análisis de seguridad post-hoc, así como en las tecnologías que
permitan un control más preciso y fácil de usar por parte del usuario final sobre las políticas. En conjunto,
estos desafíos parecen interesantes y superables. Las plataformas FaaS de los proveedores de cloud
computing no son completamente de código abierto, pero los problemas de sistemas descritos
anteriormente pueden ser explorados en nuevos sistemas por terceros utilizando funciones de cloud
computing como la orquestación de contenedores. Es probable que el análisis de los programas y las
cuestiones de programación abran oportunidades significativas para una investigación más formal,
especialmente para los programas centrados en los datos. Por último, los problemas de diseño del
lenguaje siguen siendo un reto fascinante, que une la capacidad de análisis de los programas con la
productividad de los programadores y los gustos de diseño. En resumen, somos optimistas en cuanto a
que la investigación puede abrir todo el potencial de la nube a los programadores. Ya sea que llamemos
a los nuevos resultados "computación sin servidor" o cualquier otra cosa, el futuro es fluido.

12