Muy buenas, les saluda Luis y en esta ocasión les traigo otro nuevo artículo.
Índice
Alguna historia de fondo
A principios de esta semana, me encontré con una biblioteca de Python con una propuesta de valor bastante convincente. Esta biblioteca se llama Diagramas, y como dice su homónimo, crea diagramas.
Estos diagramas que se producen son generalmente los que crearía al pegar imágenes torpemente en draw.io o Google Diagrams, después de lo cual perdería horas alineando todo correctamente.
Además de ese proceso agotador cuando más tarde necesité actualizar estos diagramas, necesitaba levantar y cambiar más de la mitad de los componentes solo para algunos cambios en la arquitectura.
Después de investigar más a fondo la biblioteca, pude ver que podía aliviar esta espina en mi costado.
Introducción a sus propios diagramas
El primer requisito para comenzar a construir algunos de estos diagramas es tener instalado Python 3.6 o superior. Una vez que este sea el caso, deberá instalar GraphViz, ya que esto es lo que representa los diagramas.
El repositorio de Github también tiene una sección de «Introducción» bastante decente, por lo que si necesita ayuda para instalar algo, no dude en consultarla. aquí.
Una vez que haya instalado los “diagramas” de la biblioteca con su administrador de paquetes Python favorito, estará listo para comenzar a crear.
Para mí, comenzar fue tan fácil como el siguiente comando, ya que cumplí con los requisitos iniciales.
Tipos de componentes
La biblioteca de diagramas proporciona componentes para varios proveedores diferentes. Lo siguiente probablemente será más relevante para la mayoría de los casos de uso de los 14 disponibles.
- AWS / GCP / Azure – Estos proveedores exponen los activos oficiales del servicio en la nube que usaría para cualquier diagrama que aproveche uno de los principales proveedores de la nube. Mi equipo trabaja principalmente en GCP, y pasaba horas construyendo estos diagramas manualmente antes de tropezar con esta biblioteca, así que me emocioné un poco cuando descubrí que tenía estos activos de nodo al alcance de la mano.
- Genérico y local – Es probable que estos nodos se usen juntos en el caso de que desee ilustrar las tecnologías subyacentes de una manera independiente de la nube. Por ejemplo, proporcionar una arquitectura con un componente Beam sobre la pantalla Google DataFlow.
- Frameworks – Estos componentes te serán de utilidad si quieres ilustrar un nodo con un lenguaje de programación.
- SaaS – Incluso hay una colección de nodos SaaS que se pueden usar y que resultan útiles cuando se desea mostrar que su arquitectura tiene notificaciones que llegan a algo como Slack.
Conceptos de diagrama
- Diagramas – Un diagrama es un objeto principal que representa un diagrama.
- Nodos – Un concepto abstracto que representa un solo componente del sistema.
- Clusters – Le permite organizar los nodos en grupos (o clusters) en lugar de componentes aislados.
- Bordes – Representa un vínculo entre nodos.
Tu primer diagrama
Ahora que conoce los conceptos básicos, creemos un diagrama extremadamente simple con código siguiendo el orden en el que aprendimos estos conceptos.
El diagrama de ejemplo que crearemos será un sitio web simple con equilibrio de carga en AWS que usa una base de datos PostgreSQL y una caché de Redis para que podamos usar más de un proveedor de componentes.
Paso 1: creación del espacio de trabajo del diagrama
Esto simplemente generará un diagrama en blanco con la etiqueta designada como se muestra a continuación.
Paso 2: agregar los nodos
Ahora que tenemos nuestro espacio de trabajo, es hora de agregar los nodos que necesitamos para nuestro sitio web. Los nodos que queremos agregar provienen de dos proveedores diferentes.
Los proveedores de AWS y OnPrem. Probablemente, si estuviera haciendo esto de verdad, se quedaría con AWS, ya que tienen ofertas como RDS y ElastiCache que probablemente usaría con ese proveedor de nube.
Como puede ver, ya no tenemos un diagrama en blanco. Cada uno de nuestros nodos está representado y estos son los «ingredientes» de la arquitectura que queremos construir.
Los siguientes pasos serán organizar algunos de nuestros nodos en agrupaciones lógicas y luego vincular cada uno de los nodos con bordes.
Paso 3: Agrupar los nodos (opcional)
Para este ejemplo, solo agruparemos los servidores web con equilibrio de carga. En una buena cantidad de los diagramas que he creado en el pasado, esto no siempre fue necesario, pero a medida que su arquitectura crece, agrupar estos nodos dentro de clústeres generalmente mejora la legibilidad.
A continuación, puede ver que para hacer esto solo necesitamos mover la instanciación de los nodos al alcance del clúster que estamos creando.
Como puede ver, el diagrama sigue siendo solo una lista de nodos, pero ahora hemos agrupado los nodos apropiados en agrupaciones lógicas.
Paso 4: vincularlo todo junto
En este paso final no enlazaremos los nodos que acabamos de organizar para que se aprovechen en nuestra arquitectura. Esta tarea solía llevarme más tiempo cuando necesitaba actualizar o modificar una arquitectura.
Si echas un vistazo a continuación, solo es cuestión de definir el flujo de cada nodo con flechas dobles, ¡y listo! Con este ejemplo, simplemente enlazaremos los nodos sin etiquetas, pero si echas un vistazo a la documentación, aplicar etiquetas a tus enlaces es una tarea bastante fácil.
La imagen que se produce se puede ver a continuación y ahora puede ver un flujo lógico entre cada nodo en el diagrama. Este flujo se puede revertir cambiando el orden en el que define los nodos.
Además de ajustar el flujo, puede cambiar varias cosas, ya que un objeto de borde contiene tres atributos: etiqueta, color y estilo. No cubriremos cómo colocarlos aquí.
Si está interesado en obtener más información, la documentación está vinculada al final de este artículo, y estos atributos reflejan los atributos de borde de graphviz correspondientes, lo que facilita las cosas si ha aprovechado esa herramienta en el pasado.
Conclusión
Ahora que se ha esforzado por construir un hermoso diagrama con código, hay mucho potencial al aprovechar este flujo de trabajo cuando se trata de posibilidades de automatización, y el tiempo ahorrado con el mantenimiento general de un diagrama de arquitectura.
El tiempo ahorrado solo al usar esta herramienta me permitirá usar este enfoque en el futuro. Seguramente no echaré de menos el esfuerzo que implica realizar ajustes manuales en el diagrama, alineando cuidadosamente los componentes y las flechas con cada iteración de mi arquitectura.
Espero que mi experiencia de profundizar en la construcción de diagramas con código haya sido interesante y potencialmente útil para sus futuros esfuerzos de diagramación.
Gracias por leer este artículo.
Añadir comentario