Sin servidor en la nube: AWS frente a Google Cloud frente a Microsoft Azure

Si alguna vez te han despertado a las 3 am porque un servidor se volvió loco, comprenderás el atractivo de una palabra de moda como "sin servidor". Las máquinas pueden tardar horas, días o, a veces, incluso semanas en configurarse y luego deben actualizarse constantemente para corregir errores y agujeros de seguridad. Estas actualizaciones suelen traer sus propias molestias porque las nuevas actualizaciones provocan incompatibilidades que obligan a otras actualizaciones o eso parece ad infinitum.

La interminable cadena de dolores de cabeza por ejecutar un servidor es una de las razones por las que las principales empresas de la nube han adoptado la arquitectura "sin servidor". Saben que el jefe ha escuchado las excusas, el servidor esto, el servidor aquello, durante demasiado tiempo. Si tan solo pudiéramos deshacernos de esos servidores, el jefe debe pensar.

Es un término de ventas maravilloso con el único problema de que no es estrictamente cierto. Estas aplicaciones no tienen servidor de la misma manera que los restaurantes no tienen cocina. Si lo que quieres está en el menú y te gusta cómo lo prepara el cocinero, sentarte en un restaurante es genial. Pero si quieres un plato diferente, si quieres diferentes especias, bueno, será mejor que tengas tu propia cocina.

Amazon, Google y Microsoft son tres de las empresas más grandes que luchan por alojar aplicaciones del futuro, las que esperan que se escriban en su API sin servidor y se gestionen a través de su capa de automatización. Si las plataformas hacen lo que usted quiere, y los nuevos modelos son bastante generales, pueden ser la forma más sencilla y rápida de crear su propia aplicación web unicornio multimillonaria. Escribe solo los bits cruciales de la lógica y la plataforma maneja todos los detalles.

Las funciones sin servidor se están convirtiendo en el lenguaje adhesivo o de secuencias de comandos que vincula todas las funciones de la nube. Las herramientas de mapeo o IA que alguna vez fueron bastante independientes ahora están vinculadas a través de funciones sin servidor controladas por eventos. Ahora, una mayor parte de su trabajo puede resolverse mediante solicitudes que se propagan y rebotan en los distintos rincones de cada nube, desencadenando y desencadenando un flujo de eventos. Si desea explorar el aprendizaje automático y usarlo 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 cortar todo lo que sea más delgado facilita compartir recursos en la nube. En el pasado, todo el mundo creaba frenéticamente nuevas instancias con, digamos, Ubuntu Server ejecutándose en su propia máquina virtual. Todos usaban el mismo sistema operativo y se duplicaba un trillón de veces en la misma caja real que pretendía ser una docena o más de cajas virtuales de Ubuntu. Las operaciones sin servidor evitan toda esa duplicación, lo que hace que la computación en la nube sea dramáticamente más barata, especialmente para trabajos que se ejecutan esporádicamente y nunca atascan la vieja caja en su sala de servidores con aire acondicionado.

Por supuesto, toda esta conveniencia tiene un costo oculto. Si alguna vez desea dejar o mover su código a otro sitio, probablemente se quedará atascado reescribiendo la mayor parte de la pila. Las API son diferentes y, si bien existe cierta estandarización en torno a lenguajes populares como JavaScript, están bastante cerca de ser propietarias. Hay muchas oportunidades para encerrarse.

Para comprender el atractivo de las opciones sin servidor, dediqué un tiempo a desarrollar algunas funciones y revisar 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. ¿Recuerdas cuando configuramos todo con XML y luego JSON? Ahora llenamos un formulario web y la nube lo hace por nosotros. Sin embargo, todavía tiene que pensar como un programador para comprender lo que sucede detrás de escena y más allá de su control.

AWS Lambda

AWS Lambda se está convirtiendo en la capa de scripts de shell para toda la nube de Amazon. Es un sistema básico que le permite integrar funciones que responden a eventos que pueden ser generados por casi cualquier parte de la vasta infraestructura de nube de Amazon. Si se carga un archivo nuevo en S3, puede hacer que active una función que haga algo interesante con él. Si Amazon Elastic Transcoder transcodifica algún video, es posible que tenga una función Lambda esperando a que se active cuando finalice. Estas funciones, a su vez, pueden desencadenar otras operaciones de Lambda o tal vez simplemente enviarle a alguien una actualización.

Puede escribir funciones Lambda en JavaScript (Node.js), Python, Java, C # y Go. Dado que estos lenguajes pueden incorporar muchos otros lenguajes, es muy posible ejecutar otro código como Haskell, Lisp o incluso C ++. (Consulte esta historia sobre la compilación de C ++ heredado en una biblioteca para usar con AWS Lambda).

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 solo unas pocas líneas de código y lograr grandes cosas, sentí que luego tenía que dedicar más tiempo a configurar cómo se ejecuta el código. Mucho de esto se logra completando 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 conservar toda la flexibilidad que Amazon ofrece al usuario de Lambda.

Algunos de los pasos adicionales se deben a que Amazon expone más opciones al usuario y espera más del escritor de funciones 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 inmediatamente. Amazon me hizo hacer 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 de Node puro, eso era algo que se esperaba que supiera, o lo aprendería buscando en Google el mensaje de error mientras cruzaba los dedos y esperaba que la respuesta estuviera ahí. Ahora la nube se apresura a ayudar.

Amazon tiene otras opciones que son casi tan "sin servidor" como AWS Lambda, si sin servidor significa liberarlo de las tareas de administración del servidor. Tiene herramientas elásticas como Amazon EC2 Auto Scaling y AWS Fargate que encienden y apagan los servidores, y AWS Elastic Beanstalk, que toma el código cargado, lo implementa en los servidores web y maneja el equilibrio de carga y el escalado. Por supuesto, con muchas de estas herramientas de automatización, aún eres 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 destinadas a estar completamente libres de estado, algo que funciona cuando se aplica una lógica empresarial bastante básica, pero que puede ser un poco una pesadilla cuando se lleva a un cliente a través de un lista de verificación o diagrama de flujo. Vas constantemente a la base de datos para recargar la información sobre el cliente. Step Las funciones unen 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 cantidades de libertad de cosas como la necesidad de una contraseña de root o incluso el uso de una línea de comandos.

Comenzando con Google App Engine en 2008, Google ha ido agregando lentamente diferentes opciones "sin servidor" con varias combinaciones de mensajería y transparencia de datos. Uno llamado Google Cloud Pub / Sub le oculta la 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 computación basada en eventos para muchos de los principales productos, incluidas algunas de las herramientas y API de marquesina. Y luego está Google Firebase, una base de datos de 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 el más intrigante para mí. Algunos sugieren que las bases de datos eran la aplicación sin servidor original, que abstraían 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 también código JavaScript y mensajería para hacer casi todo lo que pueda querer hacer con la infraestructura del lado 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 empresarial y la mensajería para su pila. Realmente puede salirse con la suya con un poco de HTML, CSS, JavaScript y Firebase del cliente.

Es posible que tenga la tentación de llamar a las capas de JavaScript de Firebase "procedimientos almacenados", tal como lo hizo Oracle, pero eso sería perder el panorama general. El código de Firebase está escrito en JavaScript, por lo que se ejecutará en una versión local de Node.js. Puede incrustar 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. Sincronizará copias de objetos de la base de datos en toda la red. El truco es que puede configurar su aplicación cliente como solo otro nodo de base de datos que se suscribe a todos los cambios para los datos relevantes (y solo los datos relevantes). Si los datos cambian en un lugar, cambian en todas partes. Puede evitar todas las molestias de la mensajería y concentrarse en simplemente escribir la información en Firebase porque Firebase la replicará donde debe estar.

No es necesario que se centre solo en Firebase. Las funciones más básicas de Google Cloud son un enfoque más simple para incrustar código personalizado en la nube de Google. En este momento, Cloud Functions es en gran parte solo una opción para escribir código Node.js que se ejecutará en un entorno Node preconfigurado. Si bien el resto de Google Cloud Platform admite una amplia variedad de lenguajes, desde Java y C # hasta Go, Python y PHP, Cloud Functions está estrictamente limitado a JavaScript y Node. Ha habido indicios de que vendrán otras opciones de idioma y no me sorprendería que aparecieran pronto.

Google Cloud Functions no llega tan profundamente a Google Cloud como AWS Lambda llega a AWS, al menos en este punto. Cuando busqué en la construcción de 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 tenía servidor mucho antes de que se acuñara la palabra de moda.

Vale la pena señalar que Google App Engine sigue funcionando con fuerza. Al principio, solo ofrecía poner en marcha aplicaciones de Python para satisfacer la demanda de cualquiera que visitara el sitio web, pero se ha extendido a lo largo de los años para manejar muchos tiempos de ejecución de idiomas diferentes. Una vez que empaqueta su código en un ejecutable, App Engine maneja el proceso de iniciar suficientes nodos para manejar su tráfico, escalando hacia arriba o hacia abajo a medida que sus usuarios envían 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 descarta todo el andamiaje ni se olvida de todo entre solicitudes. App Engine fue una gran parte de la revolución sin servidor y sigue siendo la más accesible para aquellos que mantienen un pie atrás 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 servidor con la nube de Azure. La empresa ha creado sus propias funciones básicas para hacer malabares con los eventos (las funciones de Azure) y ha creado algunas herramientas sofisticadas que son aún más accesibles para los semiprogramadores.

La mayor ventaja que puede tener Microsoft puede ser su colección de aplicaciones de Office, los antiguos ejecutables de escritorio que están migrando lenta pero seguramente a la nube. De hecho, una contabilidad de los ingresos de la nube puso a Microsoft por delante de Amazon, en parte al agrupar parte de sus ingresos de Office en la efímera rúbrica 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 elfos en la nube cobran vida y hacen cosas en la hoja de cálculo. Esto seguramente será una bendición para los departamentos de TI que brindan soporte a los equipos que adoran sus hojas de cálculo de Excel (u otros documentos de Office). Pueden escribir Azure Functions 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 que no pueda ser a través de formatos de documentos como Microsoft Word o Excel.