Lamento reventar algunas burbujas aquí, pero la arquitectura sin servidor es efectivamente solo una palabra de moda. Hace poco asistí a la cumbre de aws en Sydney, y aunque sin duda presentaron algunos conceptos sensuales, el uso de la palabra “sin servidor” me pareció distintivamente “comercializador”.
Debo agregar aquí que no tengo absolutamente ninguna afiliación con Amazon (ni ninguna competencia) ni idea de cómo logran lambda. También agregaré que compro completamente con su modelo.
La arquitectura sin servidor es, para mí, una palabra de moda porque no es necesario configurar o mantener explícitamente un punto final accesible desde el exterior para alcanzar cierta funcionalidad. Es un mercado de humo y espejos para promocionar AWS Lambda.
- ¿Qué es una buena herramienta de conferencia web basada en la nube?
- ¿Por qué Google se unió a la comunidad OpenStack?
- ¿Cuál es la mejor nube para administrar archivos para una empresa en varios idiomas?
- ¿Cuáles son los mejores argumentos que tiene AWS, en el mejor de los casos, un foso estrecho o reducido?
- ¿Qué herramientas y tecnologías específicas (con nombre) se utilizan para garantizar y asegurar un aislamiento absoluto en una solución en la nube multiinquilino?
Al mismo tiempo, sin embargo, la idea de tener un sistema de backend capaz de activar múltiples invocaciones, que es efectivamente lo que ofrece Amazon, es muy atractiva. “Sin servidor” en ese contexto es análogo a girar subprocesos paralelos de un script bash, o múltiples instancias de una aplicación Java con el mismo propósito y un alcance de acción mínimo.
Nada de esto tiene la intención de disminuir el propósito final detrás de la palabra de moda de Amazon. Lo que han logrado es alucinante desde un punto de vista de implementación y demostración de cómo hacer microservicios. Pero tratar de aplicar la palabra de moda como un patrón de arquitectura real es entender mal lo que, precisamente, hace un servidor.
[Editar en respuesta a comentarios sobre diferentes proveedores:]
Una rosa con cualquier otro nombre, Miguel. Google y ms azure seguramente usan técnicas similares. En última instancia, * hay * un oyente de algún tipo, que responde con funcionalidad enlatada … esencialmente un servidor, independientemente de la ofuscación y la facturación a su alrededor. Una forma en que puedo ver que se está haciendo es proporcionando un punto de acceso ligero a los comandos exec predefinidos.
Si intentara implementar un patrón similar usted mismo, aún necesitaría un servidor accesible externamente para enrutar a sus instancias localizadas de clases funcionales estrechamente definidas.
Nuevamente, no estoy tratando de disminuir los logros de los equipos lambda o de funciones g, pero sin toda la arquitectura prefabricada detrás de esto, “computación sin servidor” es una palabra de moda.
Me encantan las ideas y los propósitos detrás de todo esto, pero tratar de implementarlo para escalar sería, francamente, una locura. Tendría que comprar cualquiera de las arquitecturas preexistentes para que valga la pena, lo que honestamente limita la discusión sobre patrones de enfoque para plataformas específicas.
Puede lograr fácilmente un patrón similar con ejecutivos autoadministrados detrás de un servidor API y llamarlo sin servidor, pero aún así sería un servicio “servido”. Rebotando aplicaciones internas como microservicios para lograr lo mismo, termina usando casi exactamente los mismos principios que un microservicio “servido” estándar.
