Club de lectura en Codurance - Strategic monoliths and microservices

Los microservicios han acaparado la atención de la industria desde sus inicios. La idea de contar con un despliegue independiente, servicios escalables y una rápida interacción se extendió rápidamente entre los desarrolladores y entre los responsables de la comunidad del software.

Por lo tanto, estas ventajas recibieron más atención que sus contrapartes, lo que condujo al hype de los microservicios y, posteriormente, a la reflexión sobre el aprendizaje que obtuvo la comunidad. Por ejemplo, ocurrieron cosas interesantes cuando un gran proyecto de open source intentó adoptar los microservicios y tuvo que volver al monolito.

La comunidad aportó algunos aprendizajes, y pensadores reflexivos trataron de advertir las dificultades de mantener ese patrón arquitectónico en la producción. Production ready microservices de Susan J. Fowler fue uno de los libros que compartió algunos descubrimientos sobre la estandarización de microservicios, en el libro se compartió la experiencia recogida de Uber para que los lectores entendieran lo que se necesita para construir un ecosistema de este tipo. Asimismo, en el libro Architectural Patterns de Mark Richards, se enumeran diferentes estilos arquitectónicos incluyendo los microservicios.

Aquí estamos de nuevo repasando un libro más, esta vez el elegido es Strategic monoliths and microservices: Driving Innovation Using Purposeful Architecture de Vaughn Vernon y Tomasz Jaskula, la idea es repasar las reflexiones más relevantes que tuvimos en el club de lectura mientras leíamos el libro y compaginarlas con algunas experiencias propias sobre el tema.

Nota: Aquí hemos seguido la estructura del libro del autor, empezando por la parte I hasta la parte IV, cada sección se centra en aspectos específicos del proceso de toma de decisiones de los monolitos o de los microsiervos.

Aspectos destacados

• Los microservicios por alguna razón son hype y los monolitos se convirtieron en algo "malo"
• La adopción de microservicios viene con contrapartidas que normalmente se ignoran (comunicación asíncrona, trazado distribuido, etc., sam newman compartió más información al respecto)
• La decisión de optar por microservicios, o no, debe estar respaldada por los propósitos del negocio (de ahí el nombre del libro "purposeful architecture")
• El Domain Driven Design y el Event Sourcing se utilizan en gran medida para describir el enfoque de descubrimiento de las "reales" necesidades empresariales 
• A lo largo del libro, el monolito y posteriormente o el modulito son los enfoques recomendados la mayoría de las veces
• Los sistemas legacy que son monolitos conllevan el riesgo de no ser retirados nunca por las necesidades del negocio. Tal vez este podría beneficiarse de Patrones de Desplazamiento Legacy como alternativa
• La estrategia de cambiar a microservicios implica que la aplicación es un modulito con límites definidos (de nuevo se utiliza DDD)

Part I

Capítulos 1 al 3

La primera parte del libro ofrece una introducción de lo que significa la estrategia y de cómo los autores abordarán las situaciones a lo largo del libro. En esta sección los autores se dedican a construir el terreno sobre el cual desarrollarán sus argumentos sobre los beneficios o desventajas de la utilización de monolitos o microservicios (con el objetivo de negocio siempre en mente). Al final, estamos construyendo cosas por una razón.

 Lamentablemente, los autores han descubierto que la mayoría de las empresas y equipos que crean software afirman utilizar Agile, pero no entienden cómo ser ágiles.

También se comparte una introducción al sourcing de eventos y se utiliza como técnica de descubrimiento y experimentación. Éstas pueden ser una poderosa herramienta para sumergirse en la maleza del negocio y obtener la parte más importante que proporcionará valor, esto es lo que los autores llamaron herramientas esenciales de aprendizaje estratégico. Aprender rápido, experimentar a menudo y fracasar a menudo.

La mayor parte del conocimiento lo llevan los individuos en su mente. El conocimiento que no se ha exteriorizado se conoce como conocimiento tácito.

Al comenzar a leer el libro, gran parte de las inquietudes giran en torno a la implementación real y a la forma en que el pensamiento propuesto podría aplicarse en proyectos del mundo real, afortunadamente los autores profundizan sobre esto más adelante en las partes III y IV. En esta primera sección se explican los problemas y razones más comunes que impulsan al cambio a cualquier organización. Por lo general, las startups son las que más se inclinan por el cambio, al contrario de las grandes corporaciones, que suelen preferir el statu quo. Pero, como afirman los autores, la innovación es clave para la continuidad del negocio.

Nota: el "statu quo" no es necesariamente "malo", las empresas deben ofrecer sus servicios a largo plazo.

Algunas palabras clave para profundizar en estas secciones:

• Ley de Conway inversa
• Bruce Tuckman sobre el comportamiento organizativo
• Marco Cynefin
• ADR's

Parte II

Capítulos 4 al 7

En la segunda parte, los autores empiezan a utilizar los conceptos del Domain Driven Design para representar una estrategia guiada por las necesidades del negocio y también para empezar a enlazar lo presentado en la primera parte.

Además, la crítica sobre lo que se convirtió en agile es algo que me hizo dar cuenta de que después de 20 años de agile, la mayoría de la industria piensa que agile es SCRUM, esta es también la interpretación del autor en la sección Don't blame agile. Y lo que es peor, tal y como describen los autores, SCRUM también incluye la adquisición de conocimientos como el último requisito del marco.

¿Cómo puede un equipo colocar una nueva función en el backlog antes de entenderla?

Para los autores, el conocimiento debería ser el centro, en el software estamos aprendiendo todo el tiempo para hacer algo por el negocio - agile cultiva eso. Hay algunas cosas de las que, como industria, nos olvidamos, incluso creamos algunas palabras de moda para alejarnos del negocio y crear una barrera en el lenguaje mientras nos comunicamos.

Te preguntarás por qué el conocimiento es tan clave para el éxito de un negocio, y los autores lo tienen claro:

Como dice el refrán, "no se puede cronometrar el mercado".

El aprendizaje debe ser el objetivo final para poder navegar por el monolito y también para empezar a entender los contextos en los que vive la aplicación. Los sistemas etiquetados como "Big ball of mud" existen y con ellos se acumulan años de deuda técnica, pero ahí dentro hay mucha información de la que sacar partido y entender cómo funciona un negocio.

Vale la pena decir que dividir un sistema grande, o al menos modular algunas de sus partes, ayuda a los equipos a entender mejor lo que hace cada pieza. Esto es importante, ya que los autores afirman que eliminar por completo el sistema gigante podría no ocurrir nunca. Cuando lo hace, el camino para liquidar el sistema es largo.

Cualquier esfuerzo en una gran empresa nunca eliminará todos los legacy bits desordenados e indecorosos.

Para ayudar a comprender y organizar mejor los contextos dentro de la empresa y los sistemas legacy, pueden ser útiles algunas estrategias del Domain Driven Design.

Por ejemplo, crear un lenguaje uniforme para que el equipo hable y comparta sus conocimientos (esto puede ayudar a normalizar las diferentes lagunas de conocimiento que tienen los miembros del equipo), contextos delimitados para que el equipo entienda dónde empiezan y terminan las cosas.

La idea de mapear y tener todo en su sitio es permitir que los equipos entiendan, se comuniquen y fallen rápidamente y aprendan. Los autores también describen el uso de estas herramientas en el capítulo 6, titulado "Mapping, Failing, and Succeeding-Choose Two".

• Asociación
  En la discusión de este tipo de mapeo de contexto, vamos a limitar el mapeo de asociación a uno que se produce entre dos equipos. A menudo es cierto que dos equipos tienen objetivos alineados y ninguno puede tener éxito sin el otro

• Núcleo compartido
  Un núcleo compartido es un mapeo en el que es posible compartir un pequeño modelo entre dos o más contextos limitados. Más de 100 países utilizan los códigos de la CIE-10 para informar de las estadísticas sobre las causas de muerte. Este tipo de normas forman modelos naturales de núcleo compartido.
  
  
• Customer–Supplier Development
  Un equipo se considera ascendente. El otro equipo se considera descendente. El equipo descendente necesita el apoyo de integración del equipo ascendente. El equipo ascendente tiene influencia sobre lo que recibe el equipo descendente. Establecer una relación formal entre los dos equipos que mantenga a cada parte honesta en su comunicación y compromiso hacia el apoyo, y en ser un cliente que entienda que no es la presión solitaria a la que se enfrenta su proveedor, y posiblemente un antiguo socio.
  
  
• Conformista
  Una relación conformista está en vigor cuando se dan al menos dos de unas pocas condiciones
  
  
• Capa de Anticorrupción
  Este patrón adopta una perspectiva de integración defensiva al hacer todo lo posible para evitar que el modelo ascendente corrompa el modelo descendente.
  Aunque este libro no pretende hacer recomendaciones tecnológicas, sí parece oportuno reconocer que la introducción de GraphQL representa un cambio de juego para estos trabajos.
  
  
• Servicio Open-Host
  Piensa en un servicio de alojamiento abierto como una API para el intercambio de información, donde algunos intercambios podrían requerir que el proveedor de la API apoye las mutaciones de datos desde el modelo descendente al ascendente.
  
  
• Lengua publicada
  
  
• Caminos separados
  
  
  

Algunas palabras clave para profundizar en estas secciones:

• Contexto limitado
• Lenguaje uniforme

Los autores también comparten que fracasar es una buena forma de aprender

El fracaso puede conducir a algo bueno debido a las oportunidades de aprendizaje que produce. Ese tipo de fracaso controlado se basa en un enfoque científico utilizando la experimentación y, en última instancia, conduce al éxito.

Teniendo en cuenta todo esto, en esta parte los autores también se toman el tiempo para repasar algunos conceptos de DDD y recapitularlos. Aquí se menciona por primera vez el segundo libro de esta serie, ya que los ejemplos representados aquí no tienen muchos detalles y los autores destacan que el siguiente se centra en la implementación.

• Entidades
• Objetos de valor
• Agregados
• Servicios de dominio
• Comportamiento funcional

Parte III

Capítulos 8 y 9

La última parte, al menos para mí, fue una de las más interesantes, ya que el enfoque cambió hacia un punto de vista arquitectónico e hizo algunas revisiones en torno a la arquitectura hexagonal y la arquitectura dirigida por eventos.

Si crees que la buena arquitectura es cara, prueba con la mala.
-Brian Foote [BBoM]

Como en otros libros, entra en juego la definición de arquitectura. La idea de aportar comunicación y comprensión a esta definición arroja algunas luces sobre los debates en torno a las áreas conflictivas.

Como también se menciona en el libro Arquitectura limpia, el pago de la arquitectura se puede hacer ahora o más tarde. Pero, cuanto más tarde, más caro será, tal vez todo esto viene al por qué del libro, desplazando a la izquierda la decisión de la arquitectura también es importante.

Los autores dejan claro que el objetivo de una arquitectura es conseguir unos atributos, denominados:

• flexibilidad
• seguridad
• rendimiento y
• escalabilidad

Por supuesto, teniendo en cuenta las necesidades del negocio, los autores están a favor de la arquitectura hexagonal, en el libro, se sumergen en lo que es, y por qué utilizar dicho estilo. Alistair Cockburn grabó un video de tres episodios (pero en una sola charla) sus reflexiones para poner en marcha este estilo de arquitectura. Y tener una arquitectura hexagonal no implica que sean necesarios los microservicios.

Sin embargo, el libro sigue como una revisión de diferentes estilos arquitectónicos, denominados:

- Solicitud-Respuesta REST
- Abastecimiento de eventos
- CQRS
- Sin servidor

Parte IV

Capítulos 10 al 12

La última parte del libro se centra en diferentes aspectos de la arquitectura de software centrados en cómo ofrecer una arquitectura (ya sea monolítica o de microservicios) basada en las necesidades del negocio.

Los autores también ofrecieron ideas sobre la "honestidad intelectual", que para mí es algo que hay que tener en cuenta en las decisiones tomadas por personas que carecen de los conocimientos adecuados. Al final, también añadiría las personas que intentan ocultar alguna información.

Cuando un monolito no ha sido diseñado y puesto en práctica como un monolito deseable y bien modularizado, una corrección del rumbo es difícil pero no imposible.

Nos reservamos este último tiempo para centrarnos en la estrategia que los autores proponen en los últimos capítulos como una forma de facilitar la transición (si es necesario). La mayoría de las empresas que están probando o probaron los microservicios están sufriendo por el camino que tomaron, parece que los autores también se enfrentaron a eso:

Cuando se trata de una gran bola de barro heredada, dar el paso directamente a una arquitectura de microservicios será el viaje más difícil.

En esta parte los autores comparten lo que, como industria, deberíamos saber desde hace tiempo.

La importancia que se da a los desarrolladores y arquitectos se representa de forma clara para hacernos reflexionar: "No subestimes la importancia de contratar a los mejores arquitectos y desarrolladores de software. ¿Las grandes empresas buscan gangas en los ejecutivos de nivel C?".

Parece que a medida que la industria ha crecido, el listón necesario para los desarrolladores ha disminuido y, lo que es impresionante, los salarios han crecido como en cualquier otra industria. Además de eso, hay algunas ideas clave que también son conocidas pero que vale la pena repetir:

• Ningún servicio debe compartir su base de datos con ningún otro sistema o nivel de sistema
• La refactorización es una actividad continua
• Los monolitos no son una gran bola de barro

El número de Microservicios debe ser determinado por el propósito del negocio y la justificación técnica.

Hacia el final del libro llega la discusión en torno a la complejidad añadida que surge de los microservicios (aunque en algunos contextos sean deseados), la red debe ser tenida en cuenta y no es fiable. Además de eso, algunos patrones nacieron para lidiar con tal escenario:

• Supervisión de fallos
• Interruptores automáticos
• Reintentos con backoff exponencial limitado
• Receptores idempotentes
• Entrega de mensajes fuera de secuencia

Y por supuesto, recuerda que lo que está en producción todavía necesita ser mantenido, en ese sentido, los autores proporcionan una lista de pasos con lo que debería ser el enfoque a tomar:

Paso 1. Identificar todas las capacidades empresariales que existen en la Gran Bola de Barro.

Paso 2. Clasificar las capacidades empresariales según su importancia estratégica: ventaja competitiva principal > funcionalidad de apoyo > operaciones genéricas que podrían ser sustituidas por soluciones de terceros.

Paso 3. Recopilar un inventario de las reglas de negocio y de las funcionalidades que siguen siendo relevantes y que ahora son irrelevantes.

Paso 4. Decidir qué capacidades empresariales se extraerán en orden de prioridad

Paso 5. Planificar cómo se extraerá la primera de las capacidades empresariales.

Paso 6. Trabajar de forma iterativa y entregar de forma incremental los pasos 1-5.

Otro aspecto es la sincronización de datos que debe producirse cuando se establece la estrategia.

Puede parecer mejor referirse a "armonizar" como "sincronizar", porque lo que se describe aquí es una especie de sincronización. Sin embargo, los datos sin duda tomarán una forma diferente y posiblemente cambiarán su significado entre el sistema heredado y los nuevos microservicios.

Estos fueron los aspectos más destacados de nuestra última reunión del Club de lectura de Codurance en el que debatimos el libro Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture de Vaughn Vernon y Tomasz Jaskula. Esperamos que estas consideraciones los haya motivado a aprender más sobre monolitos y microservicios y los animamos a revisar este libro para repasar y profundizar conceptos. 

Si quieren revisar más contenido relevante sobre diferentes temas, aquí les dejamos un link a nuestra página de Insights.

¡Hasta la próxima!