🥇Microservicios: el tamaño importa, incluso si tiene Kubernetes

19 de septiembre en Moscú se llevó a cabo el primer mitap temático HUG (Highload++ User Group), que estuvo dedicado a los microservicios. En él se presentó la ponencia «Operación de microservicios: el tamaño importa, incluso si tienes Kubernetes», en la que compartimos la amplia experiencia de la empresa «Flant» en la operación de proyectos con arquitectura de microservicios. En primer lugar, será útil para todos los desarrolladores que estén considerando aplicar este enfoque en su proyecto actual o futuro.

Presentamos el video de la presentación (50 minutos, mucho más informativo que el artículo), así como un resumen principal en formato de texto.

NB: El video y la presentación también están disponibles al final de esta publicación.

Introducción

Normalmente, una buena historia tiene un principio, un desarrollo y un final. Esta presentación se asemeja más a un principio, y además trágico. También es importante señalar que presenta una perspectiva de los microservicios desde el lado de la operación.

Comenzaré con este gráfico, cuyo autor (en 2015) fue Martin Fowler:

En él se puede ver cómo, en el caso de una aplicación monolítica, al alcanzar cierto tamaño, comienza a disminuir la productividad. Los microservicios se caracterizan por tener una productividad inicial más baja, pero a medida que aumenta la complejidad, la degradación en la eficiencia no es tan evidente.

Complementaré este gráfico para el caso de uso de Kubernetes:

¿Por qué una aplicación con microservicios ha mejorado? Porque esta arquitectura plantea serias exigencias a la arquitectura, que a su vez se resuelven perfectamente con las capacidades de Kubernetes. Por otro lado, parte de esta funcionalidad también será útil para el monolito, especialmente porque el monolito típico de hoy en día no es del todo un monolito (los detalles se abordarán más adelante en la presentación).

Como se puede ver, el gráfico final (cuando tanto las aplicaciones monolíticas como las microservicios se utilizan en una infraestructura con Kubernetes) no difiere mucho del original. A continuación, hablaremos sobre las aplicaciones operadas utilizando Kubernetes.

Utilidad y maleficio de los microservicios

Y aquí está la idea principal:

¿Qué es una arquitectura de microservicios normal? Debe brindarte un beneficio real, aumentando la eficiencia del trabajo. Si regresamos al gráfico, aquí está:

Si la llamamos útil, entonces en el otro lado del gráfico habrá perjudicial microservicios (interfiriendo con el trabajo):

Volviendo a la "idea principal": ¿vale la pena confiar en mi experiencia? Desde principios de este año he visto 85 proyectos. No todos eran microservicios (aproximadamente un tercio a la mitad tenía esa arquitectura), pero de todas formas es un número considerable. A nosotros (la empresa 'Flant') como outsourcers nos resulta posible observar una amplia variedad de aplicaciones, desarrolladas tanto en pequeñas empresas (con 5 desarrolladores), como en grandes (~500 desarrolladores). Un beneficio adicional es que vemos cómo estas aplicaciones viven y evolucionan a lo largo de los años.

¿Por qué microservicios?

A la pregunta sobre la utilidad de los microservicios hay una respuesta bastante concreta de Martin Fowler ya mencionado:

límites claros de modularidad;
despliegue independiente;
libertad de elección de tecnologías.

He hablado mucho con arquitectos y desarrolladores de software y les he preguntado por qué necesitan microservicios. He elaborado mi lista de expectativas. Esto es lo que obtuve:

Si describiera "en sensaciones" algunos de los puntos, serían:

límites claros de los módulos: tenemos un temible monolito, y ahora todo estará ordenadamente distribuido en repositorios de Git, donde todo está "bien organizado", sin mezclar lo caliente con lo blando;
independencia del despliegue: podremos desplegar servicios de forma independiente, para que el desarrollo avance más rápido (publicar nuevas características en paralelo);
independencia del desarrollo: podemos ceder este microservicio a un equipo/desarrollador, y otro a otro, lo que nos permite desarrollar más rápidamente;
bmayor audiencia.mayor fiabilidad: si ocurre una degradación parcial (un microservicio de 20 falla), solo dejará de funcionar un botón, mientras que el sistema en general seguirá operando.

Arquitectura microservicios típica (dañina)

Para explicar por qué en realidad todo no es como esperamos, presentaré una imagen sintética de la arquitectura de microservicios, basada en la experiencia de muchos proyectos diferentes.

Como ejemplo tomaremos una tienda en línea abstracta, que busca competir con Amazon o al menos con OZON. Su arquitectura de microservicios se ve así:

Por una combinación de razones, estos microservicios están escritos en diferentes plataformas:

Dado que cada microservicio debe ser autónomo, muchos de ellos necesitan su propia base de datos y caché. La arquitectura final resulta así:

¿Cuáles son sus consecuencias?

Fowler también tiene un artículo al respecto sobre el 'precio' por usar microservicios: Y veremos si nuestras expectativas se cumplieron.

Límites claros de los módulos…

cuántos microservicios realmente necesitamos corregir

Pero , ¿para implementar un cambio? ¿Podemos entender cómo funciona todo sin un rastreador distribuido (ya que cualquier solicitud es procesada por la mitad de los microservicios)?Hay un patrón de '

gran bola de barro', y aquí se ha creado una bola de barro distribuida. En apoyo a esto, aquí hay una ilustración aproximada de cómo viajan las solicitudes:Independencia de despliegue…

Técnicamente se ha logrado: podemos desplegar cada microservicio por separado. Pero en la práctica hay que tener en cuenta que siempre se despliegan

muchos microservicios , y necesitamos considerarel orden de su despliegue . En realidad, necesitamos probar en un entorno separado si estamos desplegando la versión en el orden correcto.Libertad de elección tecnológica…

La hay. Solo hay que recordar que a menudo la libertad roza el descontrol. Es muy importante no elegir tecnologías solo para 'jugar' con ellas.

Independencia de desarrollo…

¿Cómo crear un entorno de prueba para toda la aplicación (con tantos componentes)? Y además, hay que mantenerlo actualizado. Todo esto lleva a que

el número real de entornos de prueba , que podemos mantener en principio,resulta ser mínimo. ¿Y desplegar todo esto localmente? Resulta que a menudo el desarrollador hace su trabajo de manera independiente, pero 'a ciegas', porque se ve obligado a esperar a que se libere un entorno para pruebas..

Escalado separado…

Sí, pero está limitado en el ámbito de las bases de datos utilizadas. En el ejemplo de arquitectura proporcionado no habrá problemas con Cassandra, pero los habrá con MySQL y PostgreSQL.

ayor confiabilidad…mayor audiencia.No solo que, en realidad, la falla de un microservicio a menudo rompe el funcionamiento correcto de todo el sistema, sino que también hay un nuevo problema:

hacer que cada microservicio sea tolerante a fallos es muy complicado. hacer que cada microservicio sea tolerante a fallos es muy complicadoPorque en los microservicios se utilizan diferentes tecnologías (memcache, Redis, etc.), se debe pensar y realizar todo para cada uno, lo cual es posible, pero requiere enormes recursos.

Medición de la carga…

Esto realmente está yendo muy bien.

La "ligereza" de los microservicios…

No solo hemos aumentado enormemente los costos de red (aumentan las solicitudes a DNS, etc.), sino que debido a la multitud de subconsultas empezamos a replicar datos (almacenar cachés), lo que ha llevado a un volumen significativo de almacenamiento.

Y así es como resulta la conformidad con nuestras expectativas:

¡Pero eso no es todo!

Porque:

Lo más probable es que necesitemos un bus de mensajes.
¿Cómo hacer una copia de seguridad consistente en un momento específico? La única opción real es detener el tráfico para eso. Pero, ¿cómo hacerlo en producción?
Si hablamos de soportar varias regiones, organizar la resiliencia en cada una de ellas es una tarea muy laboriosa.
Surge el problema de realizar cambios centralizados. Por ejemplo, si necesitamos actualizar la versión de PHP, tendremos que hacer un commit en cada repositorio (y hay decenas de ellos).
El crecimiento de la complejidad operativa resulta ser exponencial a primera vista.

¿Qué hacer con todo esto?

Empieza con una aplicación monolítica.La experiencia de Fowler indica sobre que prácticamente todas las aplicaciones de microservicios exitosas comenzaron como un monolito que se volvió demasiado grande, y luego se descompuso. Al mismo tiempo, prácticamente todos los sistemas construidos como microservicios desde el principio, tarde o temprano, enfrentaron serios problemas.

Otro pensamiento valioso es que para que un proyecto con arquitectura de microservicios sea exitoso, debes conocer muy bien tanto el dominio como cómo hacer microservicios.Y la mejor manera de conocer el dominio es hacer un monolito.

Pero, ¿qué hacer si ya nos encontramos en esa situación?

El primer paso para resolver cualquier problema es aceptar que existe y entender que es un problema, que ya no queremos sufrir.

Si en el caso de un monolito que se ha expandido (cuando ya no podemos adquirir más recursos), lo dividimos, en este caso se produce lo contrario: cuando una excesiva microservicios ya no ayuda, sino que obstaculiza — recorta lo innecesario y agranda!

Por ejemplo, para el modelo colectivo mencionado anteriormente…

Deshágase de los microservicios más cuestionables:

Agrupe todos los microservicios que se encargan de generar el frontend:

… en un solo microservicio, escrito en un (moderno y adecuado, como usted mismo considera) lenguaje/framework:

Tendrá un solo ORM (una base de datos) y al principio un par de aplicaciones:

… aunque en realidad se pueden trasladar muchas más, obteniendo el siguiente resultado:

Además, en Kubernetes lanzamos todo esto como instancias separadas, lo que significa que aún podemos medir la carga y escalarlas por separado.

Resumiendo

Mire el panorama más amplio. A menudo, todos estos problemas con los microservicios surgen porque alguien tomó su tarea, pero quería 'jugar a los microservicios'.

En la palabra 'microservicios', la parte 'micro' es innecesaria. Son 'micro' solo porque son más pequeños que un enorme monolito. Pero no debe pensar en ellos como algo pequeño.

Y para la reflexión final, volvamos al gráfico original:

La nota escrita para él (en la parte superior derecha) se reduce a que las habilidades del equipo que realiza su proyecto son siempre primordiales — son las que jugarán un papel clave en su elección entre microservicios y monolitos. Si al equipo le falta habilidad, pero comienza a hacer microservicios, la historia será fatal.

Videos y presentaciones

Video de la presentación (~50 minutos; desafortunadamente, no captura las numerosas emociones de los asistentes, que en gran medida definieron el ambiente de la charla, pero así es):