Se preparó una traducción del artículo para los estudiantes del curso de Prácticas y herramientas de DevOps en el proyecto educativo OTUS .

Cuando los primeros tutoriales comenzaron a usar AWS Lambda y la API de Gateway en 2015, no fue sorprendente que se centraran principalmente en copiar la arquitectura de microservicios. Pero para aquellos que usaron AWS Lambda a gran escala, con el tiempo quedó claro que había limitaciones significativas para aplicar el enfoque de microservicio a AWS Lambda ... Al menos había restricciones sobre lo que la mayoría de la gente quería decir con la construcción adecuada de microservicios.

Hablemos del por qué de los microservicios.

Los microservicios aparecieron principalmente debido a la frustración con las aplicaciones monolíticas. Monolith es una aplicación en la que toda la lógica está en una base de código lógico.

Hubo momentos en que, debido al alto costo de los servidores, era común implementar toda la aplicación en un solo servidor. La implementación de un monolito significaba que en el servidor estaba implementando parte o la totalidad de la aplicación.

Además, desplegar un monolito significaba que tenía que asegurarse de no romper nada. Muy a menudo, pequeños cambios conducen a la falla de todo el servidor y la aplicación completa.

Por lo tanto, cuando aparecieron nubes con la capacidad de proporcionar instancias con un clic en cuestión de minutos (en lugar de días o semanas), la posibilidad de separación de tareas se hizo evidente.
La destrucción del monolito se convirtió en una idea obvia, y nació la idea de los microservicios.

En lugar de crear un monolito con toda la lógica en un servidor / instancia, puede colocar partes de la aplicación en diferentes servidores y conectarlas entre sí utilizando algún tipo de protocolo ligero, generalmente una API HTTP.

Por lo tanto, la arquitectura de la aplicación ha pasado de monolitos a microservicios.

Aunque, me pregunto por qué? El valor de este enfoque es que, al editar el código, cambia la base del código no de toda la aplicación, sino del microservicio, solo la parte componente de la aplicación. Esto significa que no puede romper la aplicación completa.

Aunque esto es solo teóricamente, pero esta teoría es mejor que un monolito, aunque no es ideal.

Un elemento clave para cada servicio es ...

Interfaz de servicio

Esta es a menudo una forma de interfaz HTTP (al menos este es el enfoque más común). Como regla, esto no es un problema, excepto cuando tiene una gran cantidad de servicios y puede haber un problema de coordinación.

Avanzando hacia la arquitectura sin servidor

Entonces, el enfoque inicial para crear aplicaciones sin servidor en AWS fue "creemos microservicios" ...

Esto significaba crear una API de puerta de enlace con la función Lambda detrás y una declaración de interruptor que actúa como un enrutador.

Cada API de Gateway se convirtió en una interfaz de servicio, y eso parecía lógico.

Puede realizar varios servicios que se escalen por separado, lo que en algunos casos puede ser muy importante.

Excepto que no tiene sentido cuando se da cuenta de que las funciones de AWS Lambda y FaaS en general no deben considerarse como una instancia / servidor.

Porque aunque tienen servidores bajo el capó (bueno, hay servidores bajo la mayoría de las cosas que funcionan en Internet, pero nadie dice "S3 todavía tiene servidores" o "BigTable todavía tiene servidores" o "Azure Active Directory all todavía tiene servidores "...), existe la opinión de que debe tratar la función FaaS de la misma manera que el servicio ..." minilith ", como algunos lo llaman.

El problema es que aquí falta lo que, en mi opinión, es la clave para la arquitectura sin servidor:

La arquitectura sin servidor se trata de eventos

Arquitectura sin servidor, eventos y disparadores

Los sistemas sin servidor son inherentemente sistemas basados ​​en eventos y, por lo tanto, son representantes de la arquitectura controlada por eventos. Cambia su enfoque de diseño, gestión y arquitectura.

En el caso de los microservicios, la conclusión es responder a una interfaz; este es el mecanismo principal para interactuar con la lógica.

La solución sin servidor se trata de responder a eventos, y la API en realidad es solo un mecanismo para generar eventos.

Como parte del ecosistema de AWS, que es la más madura de las soluciones sin servidor, la API no se ve como la interfaz principal. Los eventos son mucho más importantes.

Y es por eso que hay alrededor de 50 eventos que pueden activar la función Lambda desde otros servicios de AWS.

El consejo es que si puede ejecutar la función Lambda sin pasar por la API de Gateway, será mucho más rápido y más eficiente que usar la API de Gateway, especialmente si la ejecuta desde otra interfaz de AWS.

Eche un vistazo a las mejores prácticas sin servidor , verá una serie de puntos que difieren de cuántos microservicios de diseño.

En primer lugar, funciones unidireccionales. La mayoría de los microservicios suelen usar una arquitectura de solicitud-respuesta porque la mayoría de las aplicaciones web funcionan de esta manera. Las funciones en una aplicación sin servidor, como regla, son unidireccionales, y las colas se usan como un "disyuntor", por lo que la solicitud-respuesta se vuelve menos común.

La capa de datos también se gestiona y comprende de diferentes maneras. La mejor práctica es tener múltiples funciones, en lugar de una función proxy con una instrucción switch.

La idea de múltiples funciones también proporciona ventajas adicionales sobre los microservicios. Si una función arroja un error, esto solo afectará a esta función, y no al resto de la aplicación, porque la función no tiene estado (¡al menos debería serlo!). ¡Y esta es una muy buena razón para no hacer "minilith"!

Por lo tanto, aunque la experiencia en la creación de microservicios le brinda algunas ventajas al diseñar soluciones sin servidor, en realidad puede perder la mayor parte de lo que hace que las aplicaciones sin servidor sean valiosas.

Los microservicios generalmente difieren de una aplicación sin servidor bien diseñada en varias formas. Esto significa que, aunque es posible crear microservicios con un servidor sin servidor, en realidad no existe una ruta directa desde los microservicios a una arquitectura sin servidor.

La ruta de los microservicios a la arquitectura sin servidor

Entonces, ¿cuál es el camino desde los microservicios a las soluciones sin servidor? ¿Existe una forma rápida de aprender los conceptos básicos para simplificar la transición de uno a otro, ya que los microservicios están muy extendidos?

Creo que esto es lo que el mundo sin servidor está desconcertando. Recientemente, hubo una gran discusión en Twitter en la que hablamos sobre este tema. Vale la pena consultarlo, aunque solo sea para ver de qué está hablando la comunidad (mire las diversas respuestas y verá numerosas opiniones sobre este tema, aunque nadie menciona directamente los microservicios).

Hablan sobre algunas herramientas que se les indicarán para facilitar la creación de aplicaciones sin servidor, pero al final se convertirán en la plataforma en la que tendrás que construir todo. No creo que beneficie o ayude a alguien a comprender mejor el estilo arquitectónico.

Como comunidad, entendemos que la arquitectura sin servidor es el futuro. Pero la transición de los viejos estilos arquitectónicos no siempre será fácil, incluso cuando la arquitectura sin servidor es la opción correcta (y a veces no la correcta).

Hay una razón para esto. No es tan fácil cambiar el pensamiento de una persona. Es fácil construir una función Lambda. Pero crear una aplicación sin servidor bien diseñada no es fácil. Porque requiere un cambio de pensamiento, y es relativamente difícil.

Y como he dicho varias veces, debemos dejar de enseñar a las personas aplicaciones de "hola mundo" y detenernos en esto porque muchas personas piensan que esto será suficiente para ellos.

La razón por la que escribí Mejores prácticas sin servidor fue para ayudar a las personas a comprender que no deberían hacer suposiciones sobre cómo construir aplicaciones sin servidor basadas en el conocimiento actual.

Las herramientas que ahora utilizamos para crear soluciones sin servidor son las mismas herramientas que utilizamos para crear aplicaciones de "nube 1.0", pero no son completamente adecuadas para estos fines. Estas herramientas son imperfectas, pero estamos tratando de explicarlas y hacerlas lo mejor posible.

¿Qué necesitamos de ti?

Creo que la comunidad, de hecho, está muy abierta para ayudar a las personas en capacitación y desarrollo en la creación de soluciones sin servidor.

Entonces, como comunidad, necesitamos sus preguntas:
- ¿Cuáles son tus dificultades?
- ¿Dónde están las brechas?
- ¿Qué tutoriales faltan?

Y algo por el estilo.

Estoy listo para ayudar a las empresas a hacer esta transición. Trabajé con la alta gerencia, los CTO y los CEO para ayudar a determinar qué valor crea una empresa utilizando un enfoque sin servidor, y estoy feliz de ayudar a otras empresas.

Estoy muy feliz de ayudar Póngase en contacto con LinkedIn aquí .