Breaking

Post Top Ad

Your Ad Spot

martes, 24 de septiembre de 2019

Aprendiendo de la manera difícil: microservicios

Un plano de una arquitectura de microservicio, anotado con "¿qué podría salir mal?"

A finales de 2016, mi equipo y yo comenzamos a construir una nueva plataforma. Tener una pizarra en blanco como esta es el sueño de un desarrollador: sin código heredado, sin compatibilidad con versiones anteriores de las que preocuparse y, lo mejor de todo, podríamos elegir The Right Technology ™ para el trabajo.
Tres años después, después de mucho dolor y sufrimiento, estoy aquí para hacer una pequeña retrospectiva. Sin embargo, antes de sumergirme, voy a reconocer dos cosas.
  • La retrospectiva es 20/20
  • No hay bala de plata
No hay manera de saber si hacer las cosas de manera diferente habrían resultado en menos frustración, pero sin duda alguna había algunas piezas clave de gran importancia el asesoramiento de todo dominio / arquitectura que hemos elegido ignorar. En ese momento, pensamos que sabíamos mejor.
Entonces, para aquellos que se embarcan en viajes similares, estos son algunos de los consejos más importantes que lamento no haber tomado.

Consejo ignorado # 1: Ley de Conway

Esta ley establece que, inevitablemente, la arquitectura de su sistema se parecerá de alguna manera a la estructura organizativa de su empresa.
Un diagrama de un mapeo de organigrama en una arquitectura de sistema
A medida que nuestra plataforma ha evolucionado, hemos escrito y operado entre 30 y 40 microservicios, dependiendo de cómo cuente. No todos todavía existen, algunos han sido reescritos en un idioma diferente, etc.
El problema es que desde que comenzamos a construir, nunca fuimos más que un puñado de desarrolladores de backend. Como siempre fuimos un equipo pequeño y muy unido, cada desarrollador trabajaría en todos los servicios. Las decisiones de arquitectura se tomaron como un grupo, y estar de guardia significaba tratar problemas potenciales en cualquier área.
Como probablemente pueda adivinar por la alta relación servicio-desarrollador, terminamos con muchos servicios "separados" pero estrechamente acoplados. Esto nos dolió mucho.
Debido al acoplamiento, hubo una tentación incesante de reducir nuestra carga de trabajo mediante el despliegue "solo" de cambios entre servicios al mismo tiempo, lo que va en contra del principio de implementación independiente .

Consejo ignorado # 2: no eres Google

Un pequeño punto que lo representa, junto a una gran figura de palo que representa a Google
Uno de los beneficios menores de los microservicios es que pueden escalar de forma independiente. En nuestro diseño inicial, ya habíamos separado los componentes que se esperaba que fueran cuellos de botella a escala. Verificación de la realidad: Resulta que la escala donde esto importaría está mucho más allá de cualquier cosa que podamos encontrar.
De hecho, no solo estábamos adivinando sobre los límites del dominio, sino que cada servicio también incluía una cierta cantidad de sobrecarga. Ejecutamos una colección de contenedores de sidecar y Kubernetes Daemonsets para funciones de operaciones (como monitoreo y registro). Llegó a un punto en el que estábamos gastando más recursos en la infraestructura de soporte que nuestra aplicación real. Por una gran cantidad.
Ahora, no estoy diciendo que estaríamos mejor con un monolito, pero si hubiéramos comenzado con una arquitectura más simple, podríamos haber:
  • Piezas rotas cuando nos volvimos más seguros en el dominio y encontramos las abstracciones correctas
  • Recopilamos datos sobre dónde estaban los cuellos de botella del rendimiento real, si eso incluso se convirtió en un problema
  • Ahorró un montón de dinero superponiendo la infraestructura de soporte

Consejo ignorado # 3: todavía no eres Google

Un pequeño punto que lo representa (nuevamente), junto a una gran figura de palo que representa a Google
Otro beneficio de los microservicios es la libertad de elegir la mejor herramienta para el trabajo. Estábamos experimentando con idiomas ejecutamos servicios escritos en Python , NodeJS y Golang . Esto fue genial en general, pero se convirtió en una pesadilla al escribir bibliotecas compartidas, ya que el mismo código tenía que implementarse en tres idiomas diferentes.
Creo en experimentar con diferentes herramientas, pero terminamos tratando todo como listo para la producción y de larga duración. Si está escribiendo bibliotecas compartidas internas, los servicios que las utilizan ya no son un experimento.
He tenido que aceptar establecerme con un solo idioma. Resulta que está totalmente bien. Experimente tanto como sea posible, pero también es valioso tener una pila primaria que sea repetible y consistente. Esto es aún más cierto si todos sus servicios operan bajo el mismo paraguas (por ejemplo, un servidor web con conexión de base de datos).

Consejo ignorado # 4: todo es una compensación

Resulta que una arquitectura de microservicio tiene muchas desventajas. No voy a entrar en ellos aquí (otros ya lo han hecho ), pero creo que es importante entender para qué se está registrando.
Si nos hubiéramos sentado y analizado los pros y los contras, probablemente habríamos descubierto que solo comenzaría a valer la pena a medida que creciéramos en múltiples equipos de back-end, utilizando diferentes softwares para resolver diferentes problemas.
Un gráfico que representa los pros y los contras de los microservicios.
El viaje al valor neto positivo

El castigo

Hemos dedicado tiempo y esfuerzo a regresar por donde vinimos. En enero de 2019, retrocedimos un paso y buscamos el nudo más grande de nuestra arquitectura. Identificamos diez servicios que estaban tan unidos que chocar uno solo los colapsaría a todos como un castillo de naipes. Desde entonces hemos fusionado los diez para que sean un solo servicio, y no hemos mirado atrás.
También hemos eliminado gradualmente nuestros servicios de Python, y todos menos uno de nuestros servicios de Golang. En algunos casos, esto ha significado reescrituras literales en NodeJS. Nos queda un conjunto único de bibliotecas JavaScript compartidas para mantener.

Aprendizajes

Si pudiera retroceder en el tiempo y darme algunas advertencias, diría lo siguiente:
  • Diseñe para los problemas que sabe que tiene y sea muy meticuloso cuando adivine el futuro.
  • Es más seguro comenzar con algunos servicios más grandes y dividirlos a medida que se revelan los límites. Una buena regla general es que un microservicio es mejor que dos, a menos que pueda articular la razón para dividirlos. Por supuesto, hayson muchas razones válidas, pero asegúrese de saber cómo se aplican antes de seguir adelante.
  • Cuando experimente y cree servicios MVP, sea muy claro acerca de lo que no hará y cúmplalo. Es fácil quedar atrapado en el mantenimiento de algo que no es la solución correcta.

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

Post Top Ad

Your Ad Spot

Páginas