Si alguna vez le despertaron a las 3 de la madrugada porque un servidor se descompuso, comprenderá el atractivo de la palabra de moda “serverless”, o sin “sin servidor”. Las máquinas pueden demorar horas, días o incluso semanas para configurarse, y luego necesitan ser actualizadas constantemente para corregir errores y agujeros de seguridad. Estas actualizaciones suelen traer problemas propios porque las nuevas actualizaciones provocan incompatibilidades que obligan a otras actualizaciones, o al menos eso parece, al infinito.

La cadena interminable de dolores de cabeza por la ejecución de un servidor es una de las razones por las que las principales empresas en la nube han adoptado la arquitectura “serverless” o sin servidor. Saben que el jefe escuchó las excusas -el servidor esto, el servidor aquello, durante demasiado tiempo. Si pudiéramos deshacernos de esos servidores, debe pensar.

Es un término de ventas maravilloso con el único problema de que no es estrictamente cierto. Estas aplicaciones son ‘sin servidor’ de la misma manera que los restaurantes son sin cocina. Si lo que desea está en el menú y le gusta cómo lo prepara el cocinero, sentarse en un restaurante es excelente. Pero si quiere un plato diferente, si quiere diferentes especias, será mejor que tenga su propia cocina.

Amazon, Google y Microsoft son tres de las compañías más grandes que luchan por alojar aplicaciones del futuro, que esperan escribir en su API sin servidor y se administren a través de su capa de automatización. Si las plataformas hacen lo que usted desea, y los nuevos modelos son bastante generales, pueden ser la forma más simple y rápida de crear su propia aplicación web multimillonaria. Solo escribe los aspectos cruciales de la lógica y la plataforma maneja todos los detalles.

Las funciones sin servidor se están convirtiendo en el lenguaje de pegamento o scripting que vincula todas las características de la nube. Las herramientas de mapeo o de inteligencia artificial (IA) -que una vez fueron bastante independientes, ahora están vinculadas a través de las funciones sin servidor basadas en eventos. Ahora, su trabajo se puede resolver con solicitudes que fluctúan y rebotan en las distintas esquinas de cada nube, desencadenando y desencadenando un flujo de eventos. Si desea explorar el aprendizaje automático y utilizarlo para analizar sus datos, una de las formas más rápidas de hacerlo es crear una aplicación sin servidor, y comenzar a enviar eventos al rincón de aprendizaje automático de la nube.

La promesa implícita es que al hacer todo más delgado, es más fácil compartir recursos en la nube. En el pasado, todos crearían frenéticamente nuevas instancias con, por ejemplo, Ubuntu Server ejecutándose en su propia máquina virtual. Todos usaban el mismo sistema operativo y se duplicaba un billón de veces en el mismo cuadro real que pretendía ser una docena o más de cajas virtuales de Ubuntu. Las operaciones sin servidor evitan toda esa duplicación, haciendo que la computación en la nube sea mucho más barata, especialmente para trabajos que se ejecutan de forma esporádica, y nunca realmente se atascan en la vieja caja que se encuentra en su sala de servidores con aire acondicionado.

Por supuesto, toda esta conveniencia tiene un costo oculto. Si alguna vez quiere salir o mover su código a otro sitio, probablemente estará reescribiendo la mayoría de la pila. Las APIs son diferentes, y si bien hay cierta estandarización en torno a los lenguajes populares como JavaScript, están bastante cerca de ser propietarias. Hay muchas oportunidades para lock-in.

Para comprender el atractivo de las opciones sin servidor, pasé un tiempo construyendo algunas funciones y hurgando en las pilas. No escribí mucho código, pero ese era el punto. Pasé más tiempo haciendo clic en los botones y escribiendo en formularios web para configurar todo. ¿Recuerda cuando configurábamos todo con XML y luego con JSON? Ahora completamos un formulario web y la nube lo hace por nosotros. Sin embargo, todavía tiene que pensar como un programador para entender lo que ocurre detrás de las escenas y más allá de su control.

AWS Lambda
AWS Lambda está creciendo en la capa de script de shell para toda la nube de Amazon. Es un sistema básico que le permite incorporar funciones que responden a eventos que podrían ser generados por casi cualquier parte de la gran infraestructura de la nube de Amazon. Si se carga un archivo nuevo a S3, puede hacer que active una función que haga algo interesante con él. Si un video es codificado con Amazon Elástic Transcoder, podría tener una función Lambda esperando a ser activada cuando termine. Estas funciones, a su vez, pueden desencadenar otras operaciones de Lambda, o tal vez simplemente enviar una actualización a alguien.

Puede escribir funciones de Lambda en JavaScript (Node.js), Python, Java, C # y Go. Dado que estos lenguajes pueden incrustar muchos otros idiomas, es bastante posible ejecutar otros códigos como Haskell, Lisp o incluso C ++.

Escribir funciones de Lambda a menudo se siente mucho más complejo de lo esperado, porque Amazon ofrece muchas opciones de configuración y optimización. Si bien es técnicamente cierto que puede escribir unas pocas líneas de código y lograr grandes cosas, sentí que tenía que dedicar más tiempo a la configuración del funcionamiento del código. Gran parte de esto se logra rellenando formularios en el navegador, en lugar de escribir en archivos de texto. A veces parece que acabamos de cambiar un editor de texto por un formulario de navegador, pero ese es el precio de mantener toda la flexibilidad que Amazon extiende al usuario Lambda.

Algunos de los pasos adicionales se deben a que Amazon expone más opciones para el usuario, y espera más del escritor de la función por primera vez. Una vez que terminé de escribir una función en Google o Microsoft, podría apuntar mi navegador a la URL correcta y probarla de inmediato. Amazon me hizo clic para configurar la puerta de enlace API y abrir el agujero correcto en el firewall.

Al final, todo este clic agrega una capa de agarre que hace que el trabajo sea un poco más fácil que comenzar con un archivo de texto. Cuando estaba creando una función, el navegador tenía una advertencia: “Esta función contiene bibliotecas externas”. En los días del Nodo puro, eso era algo que simplemente se esperaba que yo supiera, o lo aprendía buscando en Google el mensaje de error mientras cruzaba los dedos y esperaba que la respuesta estuviera ahí afuera. Ahora la nube se apresura a ayudar.

Amazon tiene una serie de otras opciones que son tan “sin servidor” como AWS Lambda; si sin servidor significa relevarlo de las tareas de administración del servidor. Tiene herramientas elásticas como Amazon EC2 Auto Scaling y AWS Fargate que activan y cierran servidores, y AWS Elastic Beanstalk, que toma su código cargado, lo implementa en servidores web y maneja el equilibrio de carga y la escala. Por supuesto, con muchas de estas herramientas de automatización, usted sigue siendo responsable de crear la imagen del servidor.

Una de las ofertas más útiles es AWS Step Functions, una especie de herramienta de diagrama de flujo sin código para crear máquinas de estado para modelar lo que los arquitectos de software llaman flujo de trabajo. Parte del problema es que todas las funciones sin servidor están pensadas para ser completamente libres de estado, algo que funciona cuando se aplica una lógica empresarial bastante básica, pero puede ser una pesadilla cuando lleva a un cliente a través de una lista de control o un diagrama de flujo. Está constantemente saliendo a la base de datos para volver a cargar la información sobre el cliente. Las funciones paso a paso combinan las funciones Lambda con el estado.

Google Cloud Functions y Firebase
Si su objetivo es deshacerse de la molestia de configurar servidores, Google Cloud tiene una serie de servicios que ofrecen varias libertades de cosas como la necesidad de una contraseña de root, o incluso el uso de una línea de comando.

En el 2008, a partir de Google App Engine, Google ha estado agregando lentamente diferentes opciones “sin servidor” con varias combinaciones de mensajería y transparencia de datos. Una llamada Google Cloud Pub/Sub oculta su cola de mensajes, por lo que todo lo que necesita hacer es escribir el código para el productor y consumidor de datos. Google Cloud Functions ofrece cálculos basados en eventos para muchos de los principales productos, incluidas algunas de las herramientas de marquesina y las APIs. Y luego está Google Firebase, una base de datos sobre esteroides que le permite mezclar código JavaScript en una capa de almacenamiento de datos que entrega los datos a su cliente.

De estos, Firebase es lo más intrigante para mí. Algunos sugieren que las bases de datos fueron la aplicación sin servidor original, abstrayendo las estructuras de datos y las tareas de almacenamiento en disco para entregar toda la información a través de un puerto TCP/IP. Firebase lleva esta abstracción al extremo, al agregar código JavaScript y mensajes para hacer casi todo lo que quiera hacer con la infraestructura del servidor, incluida la autenticación. Técnicamente es solo una base de datos, pero es una que puede manejar gran parte de la lógica de negocios y la mensajería para su stack. Realmente puede salirse con la suya con un poco de cliente HTML, CSS, JavaScript y Firebase.

Puede que tenga la tentación de llamar a las capas de JavaScript de Firebase “procedimientos almacenados”, tal como lo hizo Oracle, pero eso no daría la imagen completa. El código de Firebase está escrito en JavaScript, por lo que se ejecutará en una versión local de Node.js. Puede incorporar gran parte de la lógica empresarial en esta capa, porque el mundo de Node ya está lleno de bibliotecas para manejar este flujo de trabajo. Además, disfrutará de los placeres del código isomórfico que se ejecuta en el cliente, el servidor y ahora la base de datos.

La parte que me llamó la atención fue la capa de sincronización integrada en Firebase. Se sincronizará copias de objetos de la base de datos en toda la red. El truco es que puede configurar su aplicación cliente como simplemente otro nodo de base de datos, que se suscribe a todos los cambios para los datos relevantes (y solo a los datos relevantes). Si los datos cambian en un lugar, cambian en todas partes. Puede evitar todas las molestias de mensajes y concentrarse solo en escribir la información en Firebase porque Firebase la replicará donde debe estar.

No necesita centrarse solo en Firebase. Las funciones más básicas de Google Cloud son un enfoque más simple para incorporar código personalizado a través de la nube de Google. En este momento, Cloud Functions es, en gran medida, solo una opción para escribir el código Node.js que se ejecutará en un entorno de Nodo preconfigurado. Mientras que el resto de Google Cloud Platform admite una amplia variedad de idiomas, desde Java y C # hasta Go, Python y PHP-Cloud Functions se limitan estrictamente a JavaScript y Node. Ha habido indicios de que vendrán otras opciones de idiomas y no me sorprendería que aparezcan pronto.

Google Cloud Functions no llega tan profundamente a Google Cloud como AWS Lambda llega a AWS, al menos en este punto. Cuando busqué construir una función para interactuar con Google Docs, descubrí que probablemente tendría que usar la API REST y escribir el código en algo llamado Apps Script. En otras palabras, el mundo de Google Docs tiene su propia API REST que no tiene servidor mucho antes de que se acuñara la palabra de moda.

Vale la pena señalar que Google App Engine sigue fuerte. Al principio, simplemente se ofreció para hacer girar las aplicaciones de Python para satisfacer la demanda de cualquier persona que ingrese al sitio web, pero se ha extendido a lo largo de los años para manejar muchos entornos de ejecución de idiomas diferentes. Una vez que haya agrupado su código en un ejecutable, App Engine maneja el proceso de inicio de nodos suficientes para manejar su tráfico, escalando hacia arriba o hacia abajo a medida que los usuarios envían sus solicitudes.

Sigue habiendo algunos obstáculos a tener en cuenta. Al igual que con Cloud Functions, su código debe escribirse de una manera relativamente sin estado, y debe finalizar cada solicitud en un período de tiempo limitado. Pero App Engine no tira todos los andamios ni se olvida de todo entre las solicitudes. App Engine fue una gran parte de la revolución sin servidores, y sigue siendo la más accesible para aquellos que mantienen un pie en el método de la vieja escuela de construir su propia pila en Python, PHP, Java, C # o Go.

Funciones de Microsoft Azure
Microsoft, por supuesto, está trabajando tan duro como los demás para asegurarse de que las personas también puedan hacer todas estas cosas inteligentes sin servidores con la nube de Azure. La compañía ha creado sus propias funciones básicas para los eventos de malabares: las funciones de Azure, y construyó algunas herramientas sofisticadas que son incluso más accesibles para los semiprogramadores.

La mayor ventaja que Microsoft puede tener es quizá su colección de aplicaciones de Office, los antiguos ejecutables de escritorio que poco a poco migran a la nube. De hecho, una contabilidad de los ingresos en la nube pone a Microsoft por delante de Amazon, en parte al agrupar algunos de los ingresos de Office en la rúbrica efímera de “nube”.

Uno de los mejores ejemplos de la documentación de Azure Functions muestra cómo se puede activar una función en la nube cuando alguien guarda una hoja de cálculo en OneDrive. De repente, los pequeños duendes en la nube cobran vida y hacen cosas en la hoja de cálculo. Esto seguramente será una bendición para las tiendas de TI que respaldan a los equipos que aman sus hojas de cálculo de Excel (u otros documentos de Office). Pueden escribir Funciones Azure para hacer prácticamente cualquier cosa. A menudo pensamos que HTML y la web son la única interfaz para la nube, pero no hay ninguna razón por la cual no pueda ser a través de formatos de documentos como Microsoft Word o Excel.

Las aplicaciones de Azure’s Logic me llamaron la atención como una de las herramientas que le permite completar formularios, en lugar de preocuparse por la semántica y la sintaxis. Todavía necesita pensar como un programador y tomar decisiones inteligentes sobre abstracciones y datos, pero puede convencerse a sí mismo de que no está escribiendo tanto “código” como llenando formularios.

Al igual que las Funciones de Paso de Amazon, Logic Apps codifica “flujos de trabajo”, una palabra de moda que es un poco más compleja que la “función” promedio que se lanza, gracias a la disponibilidad de algún estado. Todavía puede escribir lógica que vincule varias funciones y conectores en forma de diagrama de flujo, pero no la deletrea tanto en un lenguaje de computadora oficial.

La gran ventaja de las aplicaciones lógicas son los “conectores” pre construidos que profundizan en algunas de las aplicaciones más grandes de Microsoft y de terceros que existen. Puede empujar o extraer datos de manera efectiva hacia y desde sus aplicaciones lógicas y los gustos de Salesforce, Twitter y Office 365. Estas conexiones serán muy valiosas para la gente de TI de la empresa, que ahora puede vincular herramientas externas escribiendo aplicaciones lógicas tal como crearon scripts de shell en el pasado.

Otra esquina intrigante de Azure es Azure Cosmos DB, una base de datos que no es SQL y SQL al mismo tiempo. Microsoft ha duplicado las API para Cassandra y MongoDB para que pueda ingresar y sacar información sin reescribir su código Cassandra o MongoDB. O si desea escribir SQL, puede hacerlo también. Cosmos DB mantiene las cosas en orden y construye índices de todo para mantenerlo funcionando rápidamente. Esto lo convierte en un intrigante nexo central si tiene muchos códigos SQL y NoSQL que desea que funcionen juntos. O tal vez solo quiera dejar la puerta abierta a diferentes enfoques en el futuro.

Comparación de nubes sin servidor
¿Qué plataforma sin servidor es la adecuada para usted? Escribir funciones básicas es prácticamente lo mismo en los tres silos, pero hay diferencias. Los más obvios pueden ser los idiomas disponibles, ya que cada uno reproduce los favoritos después de que terminan de admitir Node.js y JavaScript. No es sorprendente que pueda escribir C # para Microsoft Azure, pero su compatibilidad con F # y TypeScript es única. Amazon acepta Java, C # y Python. Google está estrictamente limitado a JavaScript para sus funciones básicas por ahora, aunque admite muchos más idiomas en App Engine.

La parte más difícil de comparar las nubes sin servidor es controlar el precio y la velocidad, porque hay mucho más oculto bajo el capó. A menudo me sentía como un loco cuando gastaba instancias de máquina virtual que tenían un precio de centavos por hora. Ahora los proveedores están rebanando el salami tan finamente que puede obtener cientos de miles de invocaciones de funciones por menos de un dólar. Estará dando vueltas a la palabra “millón” como el Dr. Evil en las películas de “Austin Powers”.

Por supuesto, esta baratura aparente engaña rápidamente a la parte racional de nuestro cerebro, consciente de su presupuesto, al igual que cuando estamos de vacaciones en un país extraño con denominaciones de moneda muy diferentes. Pronto ordenará otro millón de llamadas a la base de datos, al igual que la vez que compró una ronda de bebidas en el bar en Cancún porque no pudo dividir lo suficientemente rápido como para descubrir lo que realmente cuesta.

Cuando la nube le vendía una máquina virtual en bruto, podía estimar lo que obtiene al mirar la cantidad de RAM y la potencia de la CPU, pero en el mundo de los servidores no tiene una pista real de lo que está sucediendo.

Vale la pena señalar que el modelo sin servidor prácticamente le obliga a esconder datos en la base de datos de la nube local, porque no puede guardar ningún estado con su código. Tiene que confiar en estos backends. Su función debe ejecutarse sin cachés locales o configuración, porque otras versiones siempre se están creando y destruyendo. Por lo tanto, el código de pegamento de la base de datos llena su código como esas venas del Upside Down en “Stranger Things”.

La única forma real de comparar costos es construir su aplicación en todas las plataformas, un desafío desalentador. Es posible mover parte del código entre los tres porque todos ejecutan Node.js, pero incluso entonces encontrará diferencias con las que solo necesitas vivir. (Por ejemplo, maneja las solicitudes HTTP directamente en Microsoft y Google, pero a través de la API Gateway en AWS).

La buena noticia es que no necesita ser tan paranoico. En mis experimentos, muchas aplicaciones básicas usan casi ningún recurso y se puede recorrer un largo camino en las capas libres que ofrecen los tres para atraer a los desarrolladores pobres. El modelo sin servidor realmente nos está ahorrando un paquete en la parte superior. A menos que sea del tipo que ejecutó sus servidores casi a plena carga todo el tiempo y obtuvo aire acondicionado gratis, es probable que termine ahorrando mucho dinero al adoptar un enfoque sin servidores. Ahorrará tanto dinero que no querrá discutir si se trata de un dólar por cada millón de invocaciones o 1,50 dólares.

Hay un problema más profundo. Si alguna vez se cansa de estas nubes, está atascado. No es fácil extraer el código y ejecutarlo en un servidor de otro fabricante, algo que podría hacer con un contenedor Docker lleno de su propio código. Si tiene suerte, puede duplicar la misma arquitectura en bruto y las funciones básicas de JavaScript, pero después de eso estará reescribiendo el código de pegamento de la base de datos en cualquier lugar. Las tres compañías tienen sus propias capas de almacenamiento de datos.

Tampoco está claro qué sucede cuando las cosas van mal. Ejecutar su propio servidor significa que, bueno, su jefe puede ahorcarlo si algo no funciona. No está tan claro qué sucede en este espacio. Una página en Google contiene esta benigna advertencia: “Esta es una versión beta de Google Cloud Functions. Esta API puede ser modificada de manera incompatible con versiones anteriores, y no está sujeta a ninguna política de SLA o desaprobación”.

Los términos de servicio de Amazon han mejorado mucho más desde que ingresaron por primera vez al espacio, pero aún incluyen advertencias para tener en cuenta, como: “Podemos eliminar, con 30 días de aviso y sin responsabilidad de ningún tipo, cualquiera de sus contenidos cargado en AWS Lambda, si no se ha ejecutado durante más de tres (3) meses. Asegúrese de que su código se ejecute si desea mantenerlo”. Advertencias como esta son ciertamente justas (sé que mis antiguas funciones de Lambda nunca volverán a usarse), pero muestran cómo está cediendo algo de control.

Microsoft ofrece un acuerdo de nivel de servicio para los servicios de Azure que promete compensación financiera por tiempo de inactividad a través de créditos de servicio. ¿Esto se aplicará cuando sus funciones disminuyan? Tal vez, siempre y cuando no vaya a alguna zona beta del servicio. Vale la pena pasar un poco de tiempo prestando atención a estos detalles, si va a construir algo más crítico que una sala de chat para niños.

En la mayoría de los casos, la comparación real que querrá hacer es entre las otras características y servicios de las nubes de Amazon, Google y Microsoft, no con la capa de función. La capacidad de activar funciones de Azure con archivos de Office en OneDrive será una gran atracción, si apoya a las personas que aman sus aplicaciones de Office. Google Firebase facilita el uso de funciones para proporcionar servicios de soporte como mensajería y autenticación a aplicaciones web. AWS Lambda recurre a tantos servicios de Amazon, que parece que el cielo realmente es el límite.

Técnicamente es posible mezclar y combinar todas estas nubes y funciones, porque todas hablan el mismo lenguaje PUT y GET de las llamadas HTTP API. No hay ninguna razón por la que no pueda combinar una aplicación llena de microservicios que mezclan lo mejor de las tres nubes. Pero terminará con una mayor latencia a medida que los paquetes abandonan las nubes locales y viajan por la naturaleza de la Internet abierta. Y luego habrá ligeras diferencias en el análisis sintáctico y la estructura que hacen que sea más sencillo simplemente sentarse en el cálido abrazo de una empresa.

Por lo tanto, probablemente tenga sentido permanecer en la sección segura de una sola nube, al menos cuando se trata de aplicaciones que están bastante interconectadas. ¿Realmente le gusta Google Maps y quiere usarlo para su proyecto? Entonces también podría usar Google Cloud Functions incluso si en su corazón prefiere usar F # con las Funciones Azure de Microsoft. Lo mismo ocurre con el reconocimiento de voz de Amazon o la API de análisis de imágenes de Google, o cualquiera de las docenas de diferentes servicios y API de aprendizaje automático. Las funciones no son tan importantes, lo que realmente importa es lo que unen.

Peter Wayner, InfoWorld.com – CIOPeru.pe