¿Cómo los cambios a microservicios crean un problema de tiempo de ejecución?

Tengo un problema. ¡Usemos microservicios! Ahora tengo 13 problemas distribuidos.

Es una buena idea dividir su sistema en componentes encapsulados, cohesivos y desacoplados. Te permite abordar diferentes problemas por separado. Pero puede hacerlo perfectamente bien en una implementación monolítica (consulte Fowler: Microservice Premium ). Después de todo, ¡esto es lo que OOP ha estado enseñando durante muchas décadas! Si decide convertir sus componentes en microservicios, no obtendrá ninguna ventaja arquitectónica. Obtiene cierta flexibilidad con respecto a la elección de tecnología y posiblemente (pero no necesariamente) escalabilidad. Pero tiene garantizado algunos dolores de cabeza derivados de (a) la naturaleza distribuida del sistema y (b) la comunicación entre los componentes. Elegir microservicios significa que tiene otros problemas tan urgentes que está dispuesto a usar microservicios a pesar de estos problemas.

Si no puedes diseñar un monolito que esté bien dividido en componentes, tampoco podrás diseñar un sistema de microservicio. En una base de código monolítico, el dolor será bastante obvio. Idealmente, el código simplemente no se compilará si se rompe horriblemente. Pero con los microservicios, cada servicio puede desarrollarse por separado, posiblemente incluso en diferentes idiomas. Cualquier problema en la interacción de los componentes no se hará evidente hasta que los integre, y en ese momento ya es demasiado tarde para arreglar la arquitectura general.

La fuente de errores No 1 es la falta de coincidencia de interfaz. Puede haber errores evidentes como un parámetro faltante, o ejemplos más sutiles, como olvidar verificar un código de error u olvidar verificar una condición previa antes de llamar a un método. La escritura estática detecta estos problemas lo antes posible: en su IDE y en el compilador, antes , el código siempre se ejecuta. Los sistemas dinámicos no tienen este lujo. No explotará hasta que se ejecute ese código defectuoso.

Las implicaciones para los microservicios son aterradoras. Los microservicios son inherentemente dinámicos. A menos que pase a un lenguaje de descripción de servicio formal, no puede verificar ningún tipo de corrección en el uso de su interfaz. Tienes que probar, probar, probar! Pero las pruebas son caras y, por lo general, no son exhaustivas, lo que deja la posibilidad de que aún puedan existir problemas en la producción. ¿Cuándo se hará evidente ese problema? Solo cuando se toma ese camino defectuoso, en tiempo de ejecución, en producción. La noción de que los problemas de producción conducirían a una retroalimentación más rápida es hilarantemente peligrosamente equivocada, a menos que la posibilidad de pérdida de datos le divierta.

El primer tweet fue mío, así que lo ampliaré:

Supongamos que tiene 100 desarrolladores que trabajan en una aplicación monolítica. Eso es demasiada gente para comunicarse efectivamente entre sí, por lo que la empresa tiene que trabajar duro para dividirlos en equipos más pequeños y crear buenos patrones de comunicación entre ellos. Cuando la organización es "disfuncional", los equipos probablemente no se hablan entre sí, no están alineados con una meta mayor, no están de acuerdo en las prioridades, etc. - como resultado, les lleva una eternidad enviar algo. Es un "problema de tiempo de compilación" en el sentido de que la disfunción es obvia antes de que se produzca el software. El proyecto probablemente sea una marcha de la muerte o nunca se enviará ("compilar").

Creo que muchas personas se sienten atraídas por los microservicios y se están moviendo hacia ellos, no por los beneficios técnicos / arquitectónicos inherentes, sino porque les permite ignorar la disfunción organizativa. En lugar de intentar alinear a 100 desarrolladores, esperan que puedan tener pequeños equipos trabajando en silos, cada uno centrado en su pequeño y pequeño servicio. Si estás en una organización tan disfuncional, esto es tan atractivo: te da mucho más permiso para evitar a las personas que no te gustan, para no comunicarse.

Desafortunadamente, se convierte en un "problema de tiempo de ejecución" porque una vez que el software se está ejecutando en producción, la buena comunicación se vuelve igual de importante. Los problemas con la organización (los equipos y cómo se alinean y se comunican) se manifiestan en el "tiempo de ejecución".

El punto de mi tweet era: si lo que tienes es un problema de personas , una nueva arquitectura no te ayudará. Sólo retrasará los efectos del problema. Creo que el atractivo de los microservicios para muchas personas es la esperanza de que resolverá mágicamente los problemas de estas personas.

  

Mi pregunta es: ¿Qué significa que cambiar a microservicios crea un problema de tiempo de ejecución?

¡Eso es no lo que dicen esos tweets! No dicen nada sobre cambiar a microservicios , ni dicen nada sobre crear problemas. Solo dicen algo sobre cambiar problemas .

Y ponen una restricción contextual en sus afirmaciones, a saber, que su organización es disfuncional.

Entonces, lo que el tweet first básicamente dice es dos cosas:

• "Si su organización es incapaz de diseñar sistemas complejos ahora sin microservicios, mágicamente no podrá diseñar sistemas complejos con microservicios" y
• "los problemas causados por esa incapacidad que ahora aparece durante el tiempo de compilación, es decir, durante el desarrollo, se mostrará durante el tiempo de ejecución, es decir, en la producción" (técnicamente, también podrían aparecer durante las pruebas, pero recuerde, el la cotización se limita a organizaciones disfuncionales, que probablemente tienen un régimen de prueba sub-estándar)

El segundo tweet dice que el hecho de que los problemas solo se manifiesten en la producción, es decir, cuando los clientes los ven, es una característica, no un error, porque cuando los clientes se quejan, eso suele escucharse. en lugares diferentes que cuando se rompe una compilación, es decir, en lugares que pueden hacer algo con respecto a la disfunción organizativa (p. ej., gestión de alto nivel). Dado que la disfunción organizativa generalmente es una falla de la administración de alto nivel, esto significa que los clientes insatisfechos se reflejan mal en aquellos que son en última instancia responsables de esa insatisfacción, mientras que la baja calidad del código causada por fallas de la administración de alto nivel generalmente solo refleja mal a los desarrolladores, que son , sin embargo, no tiene la culpa y no puede hacer nada al respecto.

Entonces, el primer tweet dice que los microservicios mueven los problemas causados por una mala gestión desde el momento de la compilación, donde solo los desarrolladores los ven, hasta el tiempo de ejecución, donde los clientes los ven. El segundo tweet dice que eso es bueno, porque los problemas afectan a quienes son responsables de ellos.

Crea un problema de tiempo de ejecución en lugar de un problema de compilación .

Una aplicación monolítica es difícil y costosa de compilar. Pero una vez que se compila, puede estar razonablemente seguro de que no existen incompatibilidades extremadamente estúpidas entre los componentes, porque el sistema de tipos puede atraparlos. El mismo error en un sistema de microservives podría no aparecer hasta dos componentes específicos en realidad interactúa de una manera específica.

Tanto en los sistemas monolíticos como en los microservicios, debe definir interfaces entre los subsistemas. Las interfaces deben estar bien diseñadas, documentadas y lo más estables posible. Esto es lo mismo que en OOP.

Si su organización no puede hacer esto, los microservicios tampoco resolverán el problema. En microservicios tienes interfaces web públicas. Así que incluso tienes que dedicar más esfuerzo al diseño de la interfaz.

Si la interfaz no está diseñada correctamente, obtendrá dos tipos de problemas de tiempo de ejecución:

1. Si la interfaz no se utiliza correctamente, obtendrá un error en tiempo de ejecución, no en tiempo de compilación.
2. Llamar a una interfaz web es bastante lento, por lo que puede tener problemas de rendimiento.

Creo que producir problemas de tiempo de ejecución no es la forma correcta de comunicar los problemas organizativos a los responsables.