Los patrones de microservicios hicieron que la arquitectura de Uber funcionara mejor

Los microservicios no viven aislados

Los microservicios son partes de sistemas distribuidos grandes y complejos que, a menudo, están alojados en contenedores. Cuanto más distribuido el sistema, son más las maneras en que puede y fallará, aumentando la necesidad de usar patrones de microservicios probados y verdaderos. Cada nueva dependencia o tecnología introducida añade un nuevo punto de falla. Con 100 microservicios, esto puede llegar a ser desordenado. Hay un mito de que los microservicios son como el salvaje oeste, donde los desarrolladores tienen dominio libre sobre decisiones arquitectónicas, lenguajes de programación o bases de datos. Fowler dijo: "Los desarrolladores piensan que los microservicios les permiten codificar para simplemente hacer el trabajo. Los desarrolladores a menudo oyen que el objetivo es construir un servicio que haga una cosa bien y pueden hacer lo que quieran. Esto no es práctico o factible desde una perspectiva organizativa".

Esto puede crear retos alrededor de la expansión y la deuda técnica. Los desarrolladores pueden adoptar sus herramientas y lenguajes favoritos, implementar con scripts personalizados y adoptar una cadena de compilación personalizada. Puesto que hay 1.000 maneras de hacer cada cosa, la organización termina con más de 1.000 maneras de hacer una cosa. Fowler dijo: "Cada vez que cambias a algo como un contenedor de construcción, debes asegurarte de que esto se haga de una manera que sea productiva y no comprometa los servicios y la disponibilidad del sistema en general".

Cuando las organizaciones son impulsadas por el miedo y adoptan rápidamente un enfoque ad hoc para el desarrollo de microservicios, los desarrolladores no saben sobre los otros microservicios. No saben si las dependencias son confiables. A veces ni siquiera hay acuerdos en el mismo equipo. Cuando Uber dice que la producción de microservicios está lista, todas las dependencias y clientes pueden confiar en ello porque saben que se han aplicado patrones de microservicios adecuados. Fowler dijo: "Este es un objetivo muy alto. Nunca tendremos todo listo para la producción, pero se puede llegar allí".

Los peligros de los estándares individuales

Un acercamiento a los estándares es comenzar con la estandarización local. Los desarrolladores averiguan qué requisitos son apropiados para cada servicio individual y luego construyen desde allí. Este fue el enfoque adoptado en Uber en el principio.

"Hubo muchos problemas", dijo Fowler. Los servicios funcionaban muy bien, pero no podían confiar en otros servicios. Cuando un servicio cambiaba, tenía que cambiar para todos. Este enfoque tampoco era escalable, ya que los ingenieros de confiabilidad del sitio no podían ir a cada equipo y determinar los estándares para cada microservicio.

Conecte los estándares globales con las métricas empresariales

Un enfoque mucho mejor es desarrollar estándares globales que apliquen a todos los microservicios, dijo Fowler. Estos deben ser lo suficientemente generales para aplicarse a cada microservicio y, sin embargo, lo suficientemente específicos como para ser cuantificables y producir resultados mensurables. Estos requisitos estándar también necesitan volver a las métricas clave del negocio. Un enfoque podría ser estipular acuerdos de nivel de servicio para la disponibilidad entre microservicios como una forma de medir la confianza. Esto es fácil de medir, pero difícil de codificar.

Un enfoque mucho mejor es mirar qué principios conducen a la disponibilidad, que incluye estabilidad, fiabilidad, escalabilidad, rendimiento, tolerancia a fallos y documentación. Estos no son útiles por sí mismos, por lo que a Uber se le ocurrió requisitos cuantificables que se relacionan con estos. Estos también necesitan estar vinculados a métricas empresariales de alto nivel, como las vistas de páginas de clientes. Estas métricas necesitan traducirse en solicitudes por segundo en un microservicio.

La documentación debe hacerse desde el principio o conducirá a una deuda técnica. Fowler encontró que, cuando hablaba con los miembros del equipo, nadie podía dibujar la misma arquitectura. Colectivamente, sabrían cómo lucen las cosas, pero era raro que una mayoría pudiera saber cómo encaja un microservicio particular en la arquitectura general. Sin este tipo de comprensión es difícil construir buenos microservicios.

Los tres pasos clave para implementar estándares de microservicio en Uber incluyeron el convencimiento del grupo, la determinación de requisitos organizacionales de producción y hacer de la producción parte de la cultura de ingeniería. Es necesario contar con requisitos cuantificables que puedan ser probados.

"Es un proceso largo, pero hace una gran diferencia", dijo Fowler. "Los desarrolladores quieren hacer lo mejor que pueden. La estandarización no es una puerta, no es un obstáculo. Es algo que usted puede entregar a los desarrolladores, diciendo: ‘Sé que puedes construir servicios increíbles, aquí hay un sistema para ayudarte a construir el mejor servicio posible’. Y los desarrolladores ven esto y les gusta".