Microservicios: En marcha

Capítulo 1. Hacia una arquitectura de microservicios

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

El objetivo de este libro es ayudarte a construir una arquitectura de microservicios que funcione. En sus páginas encontrarás consejos prescriptivos y de opinión para construir software. Esos consejos proceden de experiencias reales de profesionales que hemos recopilado, tanto de implementaciones con éxito como de las que podrían haber ido mejor. Hemos refinado estas lecciones en un modelo que esperamos te permita poner en marcha más rápidamente tu propio sistema.

Recientemente, el estilo de construcción de software de microservicios ha explotado en popularidad. A principios de la década de 2010, el término microservicios surgió como una forma de describir un nuevo estilo de arquitectura de software. Las aplicaciones construidas con este nuevo estilo se construyen con componentes pequeños e independientes que funcionan juntos. Desde entonces, los índices de adopción del estilo de microservicios se han disparado. Startups, empresas y todos los demás han estado aprendiendo e implantando arquitecturas de microservicios. El creciente ecosistema de herramientas, servicios y soluciones en este espacio es testimonio de su amplia popularidad. En el momento de escribir esto, Allied Market Research ha pronosticado que el mercado mundial de arquitecturas de microservicios crecerá hasta los 8.070 millones de USD en 2026, desde los 2.070 millones de USD actuales. Este tipo de cifras indican mucho interés, mucha adopción y mucho, mucho trabajo en microservicios.

Para muchos, construir software al estilo de los microservicios ha resultado ser todo un reto. La verdad es que implementar un sistema de microservicios no es fácil. Hacer que muchas piezas independientes funcionen juntas es más difícil de lo que parece. Los costes de gestión, mantenimiento, soporte y pruebas se acumulan en el sistema. A escala, esos costes pueden llegar a ser prohibitivos. Si no tienes cuidado, el dolor de gestionar el sistema puede hacer que los microservicios parezcan una mala idea.

Pero las ventajas de crear microservicios hacen que los riesgos merezcan la pena. Los microservicios bien hechos te permiten hacer cambios en el software de forma más rápida y segura a escala. Cambios más rápidos y seguros significan más agilidad para tu negocio. Esa agilidad se traduce en mejores resultados para tu negocio y tu organización.

El truco para liberar todo ese valor es disponer de la arquitectura adecuada para apoyar los servicios. Tiene que reducir los costes del sistema, sin disminuir el valor de los servicios independientes. Para construir esa arquitectura, tendrás que tomar decisiones importantes desde el principio. Esas decisiones abarcarán métodos, procesos, equipos, tecnologías y herramientas. También tendrán que trabajar juntas para formar un todo emergente y optimizado.

Una buena forma de construir un sistema como éste es mediante la evolución. Puedes empezar con algunas pequeñas decisiones y aprender y crecer sobre la marcha. De hecho, la mayoría de los pioneros acabaron con microservicios mediante la experimentación iterativa. No partieron con el objetivo de construir una aplicación basada en microservicios. En lugar de eso, acabaron con ellos a través de un proceso continuo de optimización y mejora.

Empezar de cero e iterar lleva tiempo. Pero la buena noticia es que puedes utilizar las experiencias de estos profesionales para ayudarte a construir tu sistema más rápidamente. Empieza tu construcción con una base de patrones, métodos y herramientas que se hayan utilizado juntos con éxito. A continuación, optimiza el sistema para que cumpla los objetivos y limitaciones exclusivos de tu organización.

En este libro, hemos documentado las decisiones que forman una sólida base de microservicios. Antes de sumergirnos en los detalles del modelo, abordemos una cuestión importante. ¿Qué entendemos exactamente por "microservicios"?

¿Qué son los microservicios?

No existe una definición oficial y canónica de microservicios en . Un buen punto de partida es el artículo seminal de James Lewis y Martin Fowler sobre microservicios de 2014. En ese artículo, describen los microservicios como:

un enfoque para desarrollar una única aplicación como un conjunto de pequeños servicios, cada uno ejecutándose en su propio proceso y comunicándose con mecanismos ligeros. [...] construidos en torno a las capacidades empresariales y desplegables de forma independiente mediante una maquinaria de implementación totalmente automatizada.

El verdadero núcleo del artículo de Lewis y Fowler es el conjunto de nueve características que poseen los microservicios. Su lista comienza con la característica central de los microservicios de componentización mediante servicios, lo que significa dividir una aplicación en servicios más pequeños. A partir de ahí, pasan a cubrir una amplia gama de capacidades. Documentan la necesidad de un diseño organizativo y de gestión con las características de organización en torno a las capacidades empresariales y gobernanza descentralizada. Insinúan las prácticas DevOps y de entrega ágil cuando introducen la automatización de la infraestructura y los productos, no los proyectos. También identifican algunos principios clave de arquitectura, como como puntos finales inteligentes y tuberías tontas, diseño para fallos y diseño evolutivo.

Merece la pena comprender cada una de estas características, y te animamos a que leas su artículo si aún no lo has hecho. Juntas, estas características forman una solución holística con un conjunto muy amplio de preocupaciones. Incluye la tecnología, la infraestructura, la ingeniería, la operacionalización, la gobernanza, la estructura del equipo y la cultura.

Para contrastar, he aquí otra definición para microservicios del libro Microservice Architecture de Irakli Nadareishvili, Ronnie Mitra, Matt McLarty y Mike Amundsen (O'Reilly):

Un microservicio es un componente de alcance limitado que se puede implementar de forma independiente y que admite la interoperabilidad mediante la comunicación basada en mensajes. La arquitectura de microservicios es un estilo de ingeniería de sistemas de software altamente automatizados y evolutivos, formados por microservicios alineados con las capacidades.

Esta definición es similar a la de Lewis y Fowler, pero presta especial atención a los ámbitos delimitados, la interoperabilidad y la comunicación basada en mensajes. También distingue entre microservicios y la arquitectura que los hace posibles.

Estos son sólo dos ejemplos de un mar de definiciones de microservicios. Al igual que estos ejemplos, la mayoría de las definiciones son similares en líneas generales, pero cada una de ellas difiere ligeramente en su enfoque. Pero suelen ser lo suficientemente diferentes como para que resulte difícil determinar si has construido un sistema de microservicios de manual.

En el mundo de la tecnología, los nombres son importantes porque nos proporcionan una forma sencilla de comunicar conceptos complejos. En este caso, la etiqueta "microservicios" nos permite describir un estilo de arquitectura de software que tiene tres rasgos generales de diseño:

1. La arquitectura de la aplicación se compone principalmente de "servicios" invocables por la máquina que se ponen a disposición en una red.

2. Los tamaños (o límites) de los servicios son un factor de diseño importante. Estos límites incluyen factores de tiempo de ejecución, tiempo de diseño y personas.

3. El sistema de software, la organización y la forma de trabajar se optimizan holísticamente para alcanzar un objetivo.

Se trata de un conjunto bastante general de rasgos de diseño. Por ejemplo, no documenta estilos organizativos, herramientas específicas o principios arquitectónicos que deban utilizarse. Tampoco se definen patrones o prácticas formales. En cambio, esto nos da sólo las características suficientes para poder identificar un sistema de microservicios cuando veamos uno.

La verdad es que puedes conseguir llamar arquitectura de microservicios a casi cualquier sistema basado en API si te esfuerzas lo suficiente. Pero el verdadero foco de atención debe estar en el objetivo de tu sistema. Creemos que la pregunta de por qué construirías microservicios es mucho más esclarecedora que la pregunta de qué son. Aunque los microservicios tienen muchas ventajas potenciales, creemos que la mejor razón para construir software de esta forma es reducir tus costes de coordinación .

Reducir los costes de coordinación

Empresas de todo el mundo han tenido éxito implementando arquitecturas de microservicios. Casi universalmente, los profesionales con los que hemos hablado han informado de un aumento de la velocidad de entrega del software. Creemos que esa mejora proviene del beneficio fundamental del estilo de microservicios: una reducción de los costes de coordinación.

Hay que señalar que existen muchas formas de aumentar la velocidad en la ingeniería de software. Construir software a la manera de los microservicios es sólo una opción. Por ejemplo, podrías construir un sistema rápidamente tomando atajos e incurriendo en una "deuda técnica " de la que te ocuparás más tarde. O podrías centrarte menos en la estabilidad y la seguridad y simplemente lanzar tu producto. En algunas situaciones y para algunas empresas, estos enfoques son razonables.

Pero los sistemas desarrollados para los sectores financiero, sanitario y gubernamental, entre otros, no pueden comprometer la seguridad en aras de la velocidad. Y sin embargo, las fuerzas competitivas y del mercado exigen mayor velocidad a estas industrias como a cualquier otra. Aquí es donde puede brillar un sistema de microservicios. Proporciona un enfoque arquitectónico que te permite aumentar la velocidad sin comprometer la seguridad. Y te permite hacerlo a escala.

El problema del coste de coordinación

Crear software complejo es un trabajo duro . En las películas y en la televisión, un programador brillante puede diseñar heroicamente un producto que cambie el mundo en el transcurso de un fin de semana sin dormir. En la vida real se necesita mucha gente y mucho tiempo para obtener un resultado de calidad. Múltiples equipos que trabajan en un proyecto complejo suelen implementar diferentes partes de dicho sistema, siguiendo hojas de ruta independientes, a ritmos independientes. Periódicamente, estas partes deben integrarse para resolver las dependencias de , momento en el que los equipos, en su mayoría autónomos, deben coordinar su trabajo (véase la Figura 1-1).

Imagina que Jane es la jefa del equipo encargado del flujo de trabajo de Contabilidad. Su equipo acaba de terminar un sprint y depende de un componente que está desarrollando el equipo encargado del módulo de Envíos, dirigido por Tyrone. Como las hojas de ruta son independientes, podría ser que el equipo de Tyrone no haya terminado de implementar el componente necesario en el flujo de trabajo de Envíos. En este punto, Jane tiene una de dos opciones: puede esperar a que le entreguen el componente (priorizando la seguridad pero sacrificando la velocidad al poner a su equipo en pausa) y hacer una prueba de integración adecuada, o puede confiar en un contrato de interfaz acordado entre su equipo y el de Tyrone, suponiendo que su equipo entregará el componente exactamente como estaba previsto. En este último caso, Jane procedería sin interrupción, aumentando la velocidad de su equipo, pero comprometiendo potencialmente la seguridad general del sistema, ya que las pruebas de integración no se realizaron en la fase más temprana posible y se asumió un "camino feliz".

Figura 1-1. Ejemplo de cronograma de un proyecto complejo con puntos de contacto de coordinación

Cualquier jefe de equipo en un entorno complejo y multiequipo se enfrenta regularmente a esta elección entre ignorar los costes de coordinación y mantener el impulso o reconocer la necesidad de coordinación y reducir la velocidad. Normalmente elegimos una u otra utilizando nuestra intuición sobre el riesgo frente a los beneficios, pero en general, en un sistema suficientemente complejo, cuando estas elecciones se producen con suficiente frecuencia, existe una tensión muy pronunciada entre velocidad y seguridad.

La tensión es real; sin embargo, no está relacionada con nuestros instintos primarios y hay una forma de solucionarla. Puesto que los costes de coordinación causan la tensión, ¿qué pasaría si tuviéramos un sistema diseñado específicamente de forma que minimizara esos costes de coordinación? ¿Y si en lugar de elegir entre una cosa u otra, los equipos ni siquiera se enfrentaran a la elección la mayor parte del tiempo? Puedes tener un diseño así, haciendo hincapié en la minimización de la coordinación, si tienes equipos autónomos trabajando en pequeños lotes de trabajo aislado. Y eso es exactamente de lo que trata la arquitectura de microservicios, en su esencia.

Comprender que la fuerza fundamental para construir arquitecturas de microservicios con éxito es aspirar a minimizar la coordinación es extremadamente útil. Nos proporciona una prueba de fuego universal. Construir sistemas distribuidos complejos como una arquitectura de microservicios no es fácil, y en caso de duda deberíamos preguntarnos siempre: "¿Esta decisión a la que me enfrento va a reducir o no los costes de coordinación de mis equipos?". La respuesta correcta será mucho más obvia cuando veamos las decisiones desde la perspectiva de los costes de coordinación.

En última instancia, los microservicios se han hecho populares porque ayudan a las empresas a tener éxito. Las organizaciones modernas están sometidas a una increíble presión para adaptarse, cambiar y mejorar con mayor frecuencia y rapidez. Invertir en una arquitectura tecnológica diseñada a propósito para cambiar de velocidad y cambiar de seguridad a la escala de una gran organización tiene mucho sentido. El estilo de microservicios permite a las empresas que operan en dominios complejos tener la agilidad de una empresa más sencilla y pequeña, sin dejar de aprovechar la potencia y el alcance de su tamaño real. Es increíblemente atractivo y el crecimiento de su adopción lo demuestra; sin embargo, las ventajas no son gratuitas. Se necesita mucho trabajo previo, concentración y toma de decisiones para construir una arquitectura de microservicios que pueda desbloquear ese valor.

Las partes difíciles

Uno de los mayores obstáculos a los que se enfrentan quienes adoptan por primera vez los microservicios es enfrentarse al enorme alcance y amplitud de un sistema de microservicios. Puede que empieces centrándote en crear servicios más pequeños y delimitados. Pero muy pronto te encontrarás con que tienes que idear la infraestructura, los modelos de datos, los marcos, los modelos de equipo y los procesos adecuados para soportarlos. Es mucho terreno que cubrir y lidiar con todo ese alcance puede dar lugar a algunos retos únicos. He aquí los tres grandes problemas de diseño a los que suelen enfrentarse los arquitectos e ingenieros de microservicios:

Largos bucles de retroalimentación

Un gran reto es que las decisiones impactantes en un sistema de microservicios no son fáciles de medir. De las decisiones que tomes hoy pueden surgir problemas, pero puede que no aparezcan hasta mucho más tarde. Por ejemplo, cuando empiezas puedes decidir utilizar una biblioteca de comunicación compartida para facilitar que tus servicios hablen entre sí. Con el tiempo puede quedar claro que mantener esa biblioteca actualizada en todos tus microservicios y equipos resulta ser un problema enorme. El quid del problema aquí es que resulta difícil comprender el impacto de la decisión que estás tomando hasta que surgen los problemas, lo que dificulta la evaluación de las opciones y la elección entre ellas.

Demasiadas piezas móviles

En el fondo, un sistema de microservicios es un sistema adaptativo complejo. Esto significa que cada parte del sistema influye de algún modo en las demás partes. Cuando todas esas partes se unen, se produce un comportamiento emergente del sistema. Si alguna vez has introducido una nueva herramienta o un nuevo proceso en una organización, probablemente hayas visto esto de primera mano. Algunos equipos asimilan los nuevos estímulos y cambian inmediatamente, otros necesitan ayuda y apoyo para adaptarse, pero pase lo que pase, casi siempre se acaban produciendo consecuencias en la forma de trabajar de las personas y en las decisiones que se toman. Por ejemplo, los equipos tecnológicos que introducen herramientas de contenedorización Docker acaban inevitablemente adaptando su ciclo de vida de desarrollo y lanzamiento como consecuencia de su adopción del modelo de implementación de contenedores. A veces estas consecuencias están planificadas, pero a menudo tenemos que lidiar con las consecuencias no intencionadas de los cambios que se introducen. Esta complejidad es lo que dificulta el diseño de sistemas de microservicios. Es difícil predecir los impactos específicos de los cambios que se introducen, lo que conlleva el riesgo de que hagamos más mal que bien con un nuevo modelo de arquitectura.

Parálisis por análisis

Si al complejo sistema que tenemos que diseñar añadimos el problema de los largos bucles de retroalimentación de nuestras decisiones de , es fácil ver por qué la arquitectura de microservicios es un reto. Las decisiones que tienes que tomar son a la vez muy impactantes y difíciles de medir. Esto puede llevar a una especulación, discusión y evaluación interminables de las decisiones arquitectónicas por miedo a hacer el tipo de sistema equivocado. En lugar de construir un sistema que pueda lograr resultados empresariales, acabamos en un estado de indecisión, intentando modelar las infinitas permutaciones de nuestras elecciones. Este estado se conoce comúnmente como parálisis por análisis. No ayuda el hecho de que la web esté llena de historias de terror, consejos y buenas prácticas contradictorias para construir una arquitectura de microservicios.

En última instancia, el verdadero reto de construir una arquitectura de microservicios es el de tratar con un sistema grande y complicado que abarca un ámbito enorme. La buena noticia es que éste no es un problema único a resolver. En este libro, reuniremos y utilizaremos un conjunto de prácticas y patrones que han evolucionado para este tipo de dominio. También presentaremos e implementaremos herramientas que incorporan estas formas de trabajar y hacen que el trabajo que se realiza en un sistema de microservicios sea más fácil, seguro, barato y rápido.

Aprender haciendo

Hasta ahora, hemos establecido que el estilo de microservicios puede ayudarte a entregar software más rápidamente sin comprometer la seguridad. Pero también hemos identificado que el camino hacia una buena arquitectura de microservicios es difícil y está plagado de decisiones desafiantes y complejas. Muchos de los implementadores de microservicios con éxito con los que hemos hablado han construido sus sistemas mediante la iteración y la mejora continuas. Con frecuencia, han tenido que construir arquitecturas que fracasaron antes de llegar a comprender cómo construir un sistema que funcione.

Si tuvieras tiempo ilimitado, podrías construir una gran arquitectura de microservicios únicamente mediante la experimentación. Podrías adoptar infinitos modelos organizativos, probar todas las metodologías y construir microservicios de diversos tamaños. Mientras pudieras medir tus resultados, seguirías mejorando el sistema. Con suficientes pruebas, acabarías teniendo un sistema que te funcionara, así como mucha experiencia construyendo sistemas de microservicios.

Lo más probable, sin embargo, es que no dispongas del lujo de un tiempo ilimitado. Entonces, ¿cómo puedes adquirir la experiencia que necesitas para crear mejores microservicios?

Para ayudar a afrontar este reto, hemos desarrollado un modelo prescriptivo de microservicios. Hemos tomado decisiones sobre el diseño del equipo, el proceso, la arquitectura, la infraestructura e incluso las herramientas y tecnologías. Cubriremos un amplio abanico de áreas temáticas mientras construimos una solución que aúne esas áreas. Nuestras decisiones se basan en opiniones basadas en experiencias de construcción de sistemas de microservicios para grandes organizaciones. Si sigues nuestras instrucciones, al final del libro habrás construido un sistema de microservicios sencillo y operativo en una arquitectura basada en la nube.

Nota

Para que nuestros ejemplos de microservicios cobren vida, utilizaremos como telón de fondo un sistema ficticio de reservas de una aerolínea. Será una versión muy simplificada de lo que sería un sistema de reservas real. Nuestro sistema de reservas de aerolíneas, muy básico, incluirá dos funciones: un servicio de información de vuelos de sólo lectura y un servicio de reserva de asientos.

Nuestro objetivo es guiarte en la construcción de tu primera implementación de microservicios lo más rápidamente posible. Según nuestra experiencia, el acto de construir un sistema real es la mejor manera de comprender realmente el trabajo que conlleva y las decisiones clave. No esperamos que estés de acuerdo con todas nuestras decisiones. De hecho, ¡cuestionar las decisiones que hemos tomado por ti es una gran parte del viaje de aprendizaje! Esperamos que el modelo que construyamos juntos sea sólo el primero de muchos sistemas de microservicios que construirás en .

El Modelo Dreyfus de Adquisición de Habilidades

Empezar un viaje de aprendizaje siguiendo instrucciones es un camino probado para adquirir pericia. En el modelo de cinco etapas de Stuart y Hubert Dreyfus para la adquisición de destrezas por parte de los adultos, la primera etapa implica seguir una guía prescriptiva antes de que se establezcan la competencia y la pericia.

El modelo de microservicios "en marcha"

El alcance de una arquitectura de microservicios es bastante amplio. Por desgracia, no podemos abarcar todo el ámbito en este único libro. Sin embargo, hemos hecho un esfuerzo por cubrir las áreas temáticas más relevantes para un sistema de microservicios y que tienen mayor impacto en el éxito. Echemos un vistazo rápido a lo que cubriremos en nuestro modelo de microservicios "en marcha".

Diseño del equipo

Comenzaremos nuestra construcción de en el Capítulo 2 abordando el lado humano de un sistema de microservicios. Descubriremos los retos del diseño eficaz de equipos y los factores fundamentales que influyen en la coordinación de microservicios. También presentaremos los equipos que utilizaremos en nuestro sistema de ejemplo, junto con una herramienta llamada Topologías de Equipo para ayudar a diseñarlos.

Diseño de microservicios

Después de diseñar los equipos, introduciremos el proceso SEED(S) en el Capítulo 3. Se trata de un proceso de diseño que nos ayudará a crear microservicios que satisfagan las necesidades de los usuarios y consumidores con interfaces y comportamientos procesables. Después, en el Capítulo 4, abordaremos el problema de diseñar los límites adecuados para nuestros microservicios de ejemplo. También introduciremos algunos conceptos importantes del Diseño Orientado al Dominio y utilizaremos un proceso llamado Tormenta de Eventos para "dimensionar" nuestros servicios.

Diseño de datos

Los datos son uno de los aspectos más difíciles de un diseño de microservicios. En el Capítulo 5, echaremos un vistazo a los factores relacionados con los datos que deberás tener en cuenta en un sistema de microservicios. Introduciremos el concepto de independencia de datos y sentaremos las bases de la arquitectura de datos en nuestro proyecto de ejemplo.

Plataforma en la nube

Nuestra implementación de microservicios se construirá sobre una infraestructura basada en la nube. En el Capítulo 6, introduciremos y aplicaremos los principios de infraestructura inmutable e infraestructura como código (IaC) como base de nuestra infraestructura de microservicios. También introduciremos AWS como nuestra plataforma en la nube y construiremos una canalización CI/CD basada en Acciones de GitHub. A continuación, en el Capítulo 7, utilizaremos esa canalización para diseñar y desarrollar una infraestructura de microservicios basada en AWS que incluirá redes, un clúster Kubernetes y una herramienta de implementación GitOps.

Desarrollo de microservicios

Con nuestra plataforma de infraestructura en , nos sumergiremos en el trabajo de ingeniería de los microservicios. Empezaremos por cubrir los principios y herramientas que necesitarás para tener éxito en el Capítulo 8. Después, en el Capítulo 9, implementaremos dos microservicios independientes y heterogéneos para nuestra aplicación de ejemplo.

Liberación y cambio

Reuniremos toda la solución en el Capítulo 10, donde desplegaremos uno de los microservicios de ejemplo que hemos diseñado en la plataforma basada en la nube que hemos desarrollado. Para ello, utilizaremos un conjunto de tecnologías, como DockerHub, Kubernetes, Helm y Argo CD. Por último, tras el lanzamiento, echaremos un vistazo retrospectivo al sistema en el Capítulo 11.

Nota

El modelo que hemos desarrollado se basa en un conjunto de cinco principios rectores, incluido el patrón de aplicación de doce factores. Si te interesa, puedes leer sobre los principios rectores de nuestro modelo en el repositorio GitHub de este libro.

Esperamos que este breve resumen te dé una idea del alcance de nuestro modelo y de nuestra aplicación de ejemplo. Al final del libro habremos implementado un sistema completo. Para llegar allí, tendremos que tomar muchas decisiones. Por tanto, la primera herramienta que necesitaremos es una forma de llevar la cuenta de las realmente importantes.

Decisiones, decisiones...

Cuando se trata de construir software , las decisiones son algo importante. Los ingenieros de software y arquitectos profesionales cobran mucho por las decisiones que toman y los problemas que resuelven. La calidad del software y los resultados empresariales que impulsan dependen de la calidad de esas decisiones.

Pero las decisiones no siempre son fáciles de tomar. Tampoco son siempre correctas. Tomamos las mejores decisiones que podemos dada la información, la experiencia y el talento de que disponemos. Cuando alguna de esas variables cambia, nuestras decisiones también deben cambiar. Algunas decisiones son correctas en su momento, pero quedan desfasadas cuando cambian la tecnología, las personas o las situaciones. Algunas decisiones nunca fueron buenas en primer lugar. En cualquier caso, necesitamos una forma de captar las decisiones que importan para poder reevaluarlas y mejorarlas con el tiempo.

Para abordar esa necesidad, vamos a utilizar una herramienta llamada registro de decisiones de arquitectura (o ADR). No estamos seguros de quién inventó el término ADR ni de cuándo se utilizó por primera vez, pero la idea de documentar las decisiones de diseño existe desde hace mucho tiempo. El verdadero problema es que la mayoría de la gente no se toma la molestia de hacerlo. Según nuestra experiencia, las ADR son una herramienta extremadamente útil y una buena forma de obtener claridad sobre las decisiones que hay que tomar.

Un buen registro de decisiones debe recoger cuatro elementos importantes:

Contexto

¿Cuál es el reto? ¿Cuál es el problema que intentamos resolver? ¿Cuáles son las limitaciones? Un registro de decisiones debe ofrecernos un resumen de estos elementos contextuales. De ese modo podemos comprender la justificación de una decisión y por qué puede ser necesario actualizarla.

Alternativas

Una decisión no es una decisión a menos que haya que elegir. Un buen registro de decisiones debe ayudarnos a comprender cuáles son las elecciones. Esto nos ayuda a comprender mejor el contexto y el "espacio de selección" en el momento en que se tomó la decisión.

Elección

En el centro de una decisión está la elección. Todo registro de decisiones debe documentar la elección realizada.

Impacto

Las decisiones tienen consecuencias y un registro de decisiones debe documentar las importantes. ¿Cuáles son las compensaciones? ¿Cómo afectará nuestra decisión a nuestra forma de trabajar o a otras decisiones que deban tomarse?

Puedes crear registros de decisiones como quieras. Puedes escribirlos como archivos de texto, utilizar una herramienta de gestión de proyectos, o incluso seguirlos en una hoja de cálculo. El formato y las herramientas son menos importantes que el contenido. Siempre que captures las áreas que hemos descrito, tendrás un buen registro de decisiones.

Para nuestro proyecto de ejemplo, utilizaremos un formato existente llamado registro de decisiones de arquitectura ligera (LADR). El formato LADR fue creado por Michael Nygard, y es una forma agradable y concisa de documentar un registro de decisiones. Vamos a conocer el LADR construyendo juntos un .

Consejo

Si quieres utilizar algo distinto de LADR, Joel Parker Henderson mantiene una gran lista de formatos y plantillas ADR.

Redactar un acta de decisión arquitectónica ligera

La primera decisión clave que registraremos es la decisión de llevar un registro de las decisiones. Dicho de forma más sencilla, crearemos un ADR que diga que pretendemos llevar un registro de nuestras decisiones. Como hemos mencionado, utilizaremos el formato LADR. Lo bueno de LADR es que está diseñado para ser ligero. Nos permite llevar un registro de las decisiones en sencillos archivos de texto que podemos escribir rápidamente. Como se trata de archivos de texto, podemos incluso gestionar nuestros registros de decisiones del mismo modo que gestionamos el código fuente.

Los LADR se escriben utilizando un formato de texto llamado Markdown, que proporciona una forma elegante y sencilla de escribir documentación. Lo bueno de Markdown es que es fácil de leer para los humanos en su forma bruta y la mayoría de las herramientas populares saben cómo renderizarlo. Por ejemplo, Confluence, GitLab, GitHub y SharePoint pueden procesar Markdown y presentarlo como undocumento formateado y legible por humanos.

Para crear nuestro primer LADR basado en Markdown, abre tu editor de texto favorito y empieza a trabajar en un nuevo documento. Lo primero que haremos será diseñar la estructura.

Añade el siguiente texto a tu archivo LADR:

# OPM1: Use ADRS for decision tracking

## Status
Accepted

## Context

## Decision

## Consequences

Estos son los elementos clave de nuestro registro de decisiones . Los caracteres # que preceden a las líneas son fichas Markdown que permitirán al analizador sintáctico saber que estas líneas deben ser títulos. Observa que hemos dado a esta decisión un título que corresponde a la decisión que estamos tomando. También hemos dado a la decisión el título ligeramente críptico "OPM1". Se trata de un código abreviado que nos ayudará a etiquetar y comprender a qué parte del sistema se refiere la decisión. En este caso, "OPM1" indica que es la primera decisión que registramos relacionada con el modelo operativo.

La cabecera Status de nuestro registro nos permite saber en qué fase del ciclo de vida se encuentra esta decisión. Por ejemplo, si estás redactando una nueva decisión sobre la que necesitas obtener un acuerdo, podrías empezar con un estado de Proposed. O, si estás considerando cambiar una decisión existente, podrías cambiar su estado a Under Review. En nuestro caso, ya hemos tomado la decisión por ti, así que hemos establecido el estado en Accepted.

La sección Context describe el problema, las limitaciones y los antecedentes de la decisión que se está tomando. En nuestro caso, queremos plasmar la necesidad de registrar decisiones importantes y por qué es importante. Añade el siguiente texto (o tu propia variación del mismo) a la sección Context de tu registro:

## Context
A microservices architecture is complex and we'll need to make many
decisions. We'll need a way to keep track of the important decision
we make, so that we can revisit and re-evalute them in the future.
We'd prefer to use a lightweight, text-based solution so that we
don't have to install any new software tools.

Una vez establecido el contexto, podemos pasar a registrar la decisión real que hemos tomado. Podemos enumerar algunas de las alternativas consideradas, así como nuestra elección de utilizar LADR. Añade lo siguiente a la sección Decision para documentar este hecho:

## Decision
We've decided to use Michael Nygard's lightweight architectural
decision record (LADR) format. LADR is text based and is
lightweight enough to meet our needs. We'll keep each LADR record
in its own text file and manage the files like code.

We also considered the following alternative solutions:
* Project management tooling (not selected, because we didn't want
  to install tools)
* Informal or "word of mouth" record keeping (not reliable)

Sólo queda documentar las consecuencias. En nuestro caso, una de las principales consecuencias es que tendremos que dedicar tiempo a documentar realmente nuestras decisiones y a gestionar los registros. Vamos a plasmarlo de la siguiente manera

## Consequences
* We'll need to write decision records for key decisions
* We'll need a source code management solution to manage decision record files

Eso es todo lo que se necesita para escribir una LADR. Es una forma increíblemente útil de capturar tu pensamiento y tiene la ventaja añadida de obligarte a tomar decisiones racionales y meditadas desde el principio. A medida que construyamos nuestra aplicación de vuelos de ejemplo, llevaremos un registro de las decisiones clave que tomemos. Para ahorrar tiempo, no escribiremos todo el registro de decisiones. En su lugar, resaltaremos que se ha tomado una decisión clave, como en la siguiente nota.

Decisión clave: Utilizar las ADR para el Seguimiento de las Decisiones

Utiliza los ADR para registrar las decisiones clave que hemos tomado en el diseño y la construcción de nuestro sistema.

Podrás encontrar una versión detallada de de cada registro de decisión en el repositorio GitHub de este libro.

Resumen

En este capítulo hemos introducido algunos conceptos fundamentales para este libro. Proporcionamos una definición laxa de un sistema de microservicios, incluyendo un conjunto de tres rasgos clave. Identificamos la reducción de los costes de coordinación como el beneficio clave de los microservicios. También exploramos cómo la complejidad y la parálisis del análisis plantean retos a quienes adoptan los microservicios.

Para ayudar a abordar estos retos, presentamos el modelo de microservicios "en marcha", una implementación prescriptiva y de opinión que acelerará el proceso de aprendizaje de los implementadores. Cubrimos los aspectos del modelo y los temas que trataremos. Por último, introdujimos el concepto de registro de decisiones arquitectónicas (ADR) que pensamos utilizar a lo largo del resto del libro.

Con la visión general fuera del camino, todo lo que queda es construir el sistema. Empezaremos en el Capítulo 2 abordando cómo se trabaja con microservicios, centrándonos especialmente en la coordinación de equipos.