¿Cómo el cambio a microservicios crea un problema de tiempo de ejecución?

104

El siguiente comentarista escribe :

Los microservicios cambian su disfunción organizacional de un problema de tiempo de compilación a un problema de tiempo de ejecución.

Este comentarista se expande sobre el tema diciendo:

Característica no error. Problema de tiempo de ejecución => problemas de producción => comentarios más fuertes y rápidos sobre la disfunción a los responsables

Ahora lo entiendo con microservicios :

  • potencialmente aumenta la latencia de su rendimiento, lo cual es una preocupación de producción y tiempo de ejecución.
  • aumente el número de "interfaces de red" en su código donde podría haber posibles errores de análisis en tiempo de ejecución.
  • potencialmente puede hacer implementaciones azul-verde. Esos podrían ser retenidos por desajustes de interfaz (ver interfaces de red). Pero si los despliegues azul-verdes funcionan, entonces es más una preocupación de tiempo de ejecución.

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

ojo de halcón
fuente
13
Si A habla con B en un monolito, al menos la interfaz real puede probarse que es compatible (a través del tipeo estático), lo que hace que sea más probable que también sea correcta. Por lo general, los microservicios se comunican a través de algo sin esas comprobaciones de tiempo de compilación
Richard Tingle el
Si está estudiando los problemas relacionados con el uso de microservicios, debe leer el artículo de Fowler. martinfowler.com/articles/microservices.html Creo que no es solo un caso de tiempo de compilación vs tiempo de ejecución como dijo @Richard Tingle. Y realmente no estoy de acuerdo en que tener un problema de producción es mejor que uno en desarrollo. Pero los microservicios pueden ayudar a escalar grandes proyectos de otras maneras. (Y son una exageración para la mayoría de los proyectos pequeños)
Borjab
2
Ese comentarista es miope. Problema de tiempo de ejecución => problemas de producción => usuarios descontentos => dinero perdido.
Philipp
@Philipp: Ese es el punto. Problemas de tiempo de compilación causados ​​por disfunción organizacional => a nadie le importa. La pérdida de dinero causada por disfunción organizacional => perjudica exactamente a los responsables de dicha disfunción organizacional. La esperanza: la disfunción organizacional se repara más rápido.
Jörg W Mittag

Respuestas:

194

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

Dividir su sistema en componentes encapsulados, cohesivos y desacoplados es una buena idea. Le 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 obtiene ninguna ventaja arquitectónica. Obtiene cierta flexibilidad con respecto a la elección de tecnología y posiblemente (¡pero no necesariamente!) Algo de escalabilidad. Pero tiene garantizado algún dolor de cabeza derivado de (a) la naturaleza distribuida del sistema y (b) la comunicación entre los componentes. Elegir microservicios significa que tiene otros problemas que son tan apremiantes que está dispuesto a usar microservicios a pesar de estos problemas.

Si no puede diseñar un monolito que esté dividido limpiamente en componentes, tampoco podrá 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 está horriblemente roto. 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 será evidente hasta que los integre, y en ese punto ya es demasiado tarde para arreglar la arquitectura general.

La fuente número 1 de errores es la falta de coincidencia de la 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 de que se ejecute el código. 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 cambie a un lenguaje de descripción de servicio formal, no puede verificar ningún tipo de corrección del uso de su interfaz. tienes que probar, probar, probar! Pero las pruebas son caras y generalmente no exhaustivas, lo que deja la posibilidad de que todavía existan 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 eshilarantemente peligrosamente incorrecto, a menos que le divierta la posibilidad de pérdida de datos.

amon
fuente
13
@JacquesB Estoy seguro de que la "disfunción organizacional" se refiere a la incapacidad para desarrollar un sistema. La mayor parte de mi respuesta es el contexto para ilustrar cómo se puede llegar a tal conclusión, pero es mi opinión profesional y no tomada del tweet.
amon
10
"monolito que está dividido limpiamente en componentes", ¿qué demonios significa eso?
10
Y no hablar de versiones de interfaces (interfaces que cambian con el tiempo).
Peter Mortensen el
12
@mobileink Monolith no es un término ideal aquí ya que sugiere "sin arquitectura". Pero lo que estoy tratando de transmitir es un sistema que se desarrolla e implementa como un solo sistema, en contraste con una arquitectura orientada a servicios donde partes del sistema pueden implementarse de manera independiente. Por favor, editar el mensaje si usted sabe un término mejor ...
amon
77
@amon Escuchar la palabra Monolith no evoca de inmediato la idea de "no arquitectura". La mayoría de los edificios son monolitos, al igual que las grandes pirámides de Egipto, y muchos otros artículos. Claramente fueron diseñados y entregados en su conjunto. Muchos sistemas de software carecen de buena arquitectura; pero la falta de buena arquitectura parece ser independiente de cómo se implementan. Puede tomar prestado parte del andamiaje de otro proyecto y llamarlo arquitectura (3 niveles, 2 niveles, n niveles, microservicios, etc.), pero hacerlo no garantiza que lo haya hecho bien.
Edwin Buck
215

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

Supongamos que tiene 100 desarrolladores que trabajan en una aplicación monolítica. Esa es demasiada gente para comunicarse de manera efectiva entre sí, por lo que la compañía 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 están hablando entre sí, no están alineados con un objetivo más amplio, no están de acuerdo con 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 es probablemente 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 mudando a ellos, no por los beneficios técnicos / arquitectónicos inherentes, sino porque les permite ignorar la disfunción organizacional. En lugar de tratar de alinear a 100 desarrolladores, esperan poder tener pequeños equipos trabajando en silos, cada uno enfocado en su propio pequeño micro servicio. Si está en una organización tan disfuncional, esto es muy atractivo: le da un permiso mucho mayor para evitar a las personas que no le 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 comunican) se manifiestan en el "tiempo de ejecución".

El punto de mi tweet fue: si lo que tienes es un problema de personas , una nueva arquitectura no va a ayudar. Solo retrasará los efectos del problema. Creo que el atractivo de los microservicios para muchas personas es la esperanza de que resuelva mágicamente estos problemas.

Paul Stovell
fuente
67
+1. Esto es mucho mejor como una respuesta de Stack Exchange que como un tweet. :-)
ruakh
3
Lo mismo es cierto para cualquier sistema dinámico, realmente. La escritura dinámica es muy útil, pero solo si tiene las personas adecuadas. Las "bases de datos de forma libre" son muy útiles, pero solo si tiene las personas adecuadas. Si no tiene las personas adecuadas, solo está delegando los problemas, no resolviéndolos.
Luaan
2
Creo que esto es una tautología. Cuando las personas son el problema, los problemas pueden manifestarse en todas partes. No puedo imaginar enviar una solución que se ejecute como un conjunto de microservicios sin pruebas de integración adecuadas. No hay forma de enviar una solución con un flujo de trabajo compatible en tal caso. Si alguien se muda a microservicios sin pruebas de flujo, especialmente para ocultar problemas, ese es el problema. También podría enviar binarios no probados / rotos. Eleva el problema de los programadores de nivel de tropa más arriba, donde pertenece.
luk32
10
@ luk32 En parte, sí, pero la esencia de los microservicios que lo hacen atractivo para los malos equipos es que haces que tu déficit de habilidades y comunicación pase desapercibido durante un período de tiempo más largo. No se trata de tener los problemas o no, se trata de cuándo aparecerán
T. Sar - Reincorporar a Mónica el
18
Muy buena respuesta. Gracias por confirmar mi opinión de Twitter como completamente inútil para cualquier cosa que no sea agitar a la gente.
Robert Harvey
43

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

¡Eso no es lo que dicen esos tweets! No dicen nada sobre el cambio a microservicios , ni dicen nada sobre la creación de problemas. Solo dicen algo sobre problemas cambiantes .

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

Entonces, lo que el primer tweet dice básicamente 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 aparecen durante el tiempo de compilación, es decir, durante el desarrollo, aparecerán durante el tiempo de ejecución, es decir, en la producción" (técnicamente, también podrían aparecer durante las pruebas, pero recuerden, la cita se limita a organizaciones disfuncionales, que probablemente tengan un régimen de prueba por debajo del estándar)

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

Entonces, el primer tweet dice que los microservicios mueven los problemas causados ​​por una mala administració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 es algo bueno, porque entonces, los problemas perjudican a los responsables de ellos.

Jörg W Mittag
fuente
66
@Michael Si no puede ver cómo impactan la calidad del código, quizás considere qué impacto, si es que tiene alguno, tiene la administración en cualquier parte de la calidad de los productos que crea su negocio.
wjl
30
@ Michael: En última instancia, todo es causado por la administración de nivel superior. ¿La baja calidad del código se debe a plazos imposibles? ¿Quién establece esos plazos? ¿Quién les dice a aquellos que establecen esos plazos para establecer esos plazos? ¿La baja calidad del código es causada por desarrolladores incompetentes? ¿Quién contrató a esos desarrolladores incompetentes? ¿Quién contrató a quienes contrataron a esos desarrolladores incompetentes? ¿Es causado por herramientas inadecuadas? ¿Quién compra esas herramientas? ¿Quién aprueba el presupuesto para comprar esas herramientas? ¿Es causado por una arquitectura estúpida? ¿Quién contrató al arquitecto? ¿Quién lo puso a cargo? Esos tweets fueron específicamente en el contexto ...
Jörg W Mittag
13
... disfunción organizacional. Bueno, hacer que la organización funcione es prácticamente EL trabajo de la gerencia de nivel superior. Eso es lo que es la administración .
Jörg W Mittag el
44
Aunque probablemente funcionará a largo plazo, la idea de resolver los problemas de su empresa haciendo que afecten a los clientes no parece correcta.
Stijn de Witt
1
@ JörgWMittag No creo que sea razonable afirmar que un código incorrecto escrito por malos desarrolladores es culpa de las personas que contrataron a esos malos desarrolladores y no a los malos desarrolladores. En última instancia, podría ser responsabilidad de la administración, pero es causada por los desarrolladores.
Miles Rout
9

Crea un problema de tiempo de ejecución en lugar de un problema de tiempo 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 microservicios podría no aparecer hasta que dos componentes específicos realmente interactúen de una manera específica.

Kilian Foth
fuente
99
Esto parece suponer que las aplicaciones "monolíticas" siempre tienen un tipo estático. ¿Qué pasa con los idiomas escritos dinámicamente? ¿Y qué hay de las interfaces de servicio con tipos estáticos?
JacquesB
1
@JacquesB OTOH, puedo pensar en exactamente cero lenguajes compilados escritos dinámicamente.
user253751
2
@JacquesB JavaScript y Python no se compilan. A menos que cuente las estructuras internas del intérprete como un objetivo de compilación, en cuyo caso se compila cada idioma .
user253751
3
@immibis: cada implementación ECMAScript existente actualmente tiene al menos un compilador. V8, por ejemplo, tiene dos compiladores y exactamente cero intérpretes, nunca interpreta, siempre compila en código máquina nativo binario. SpiderMonkey tiene cuatro compiladores, creo, y un intérprete, pero ese intérprete no interpreta ECMAScript. SpiderMonkey nunca interpreta ECMAScript, siempre lo compila primero en el código de bytes de SpiderMonkey, que luego puede compilar en código máquina nativo binario. Todas las implementaciones actuales de Python, Ruby y PHP tienen compiladores.
Jörg W Mittag
12
@LieRyan Estás muy confundido si crees que la inferencia de tipos es la misma que la escrita dinámicamente y / o que Haskell está escrita dinámicamente.
Derek Elkins
2

Tanto en sistemas monolíticos como en microservicios, debe definir interfaces entre los subsistemas. Las interfaces deben estar bien diseñadas, bien 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. Por lo tanto, incluso tiene 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 usa 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 de organización a los responsables.

bernie
fuente