Mi red solía tener este aspecto: repaso a un viejo diagrama de homelab

Todo homelab tiene un momento en su historia que sobre el papel parece perfecto.

Varios servidores zumbando sobre una red de alta velocidad, una infraestructura bien planificada y todo conectado exactamente como debe. Es el tipo de montaje que conviertes con orgullo en un diagrama y compartes con otros aficionados.

Eso es justo lo que pasó cuando un usuario compartió un viejo diagrama de red que había hecho con ExcaliDraw. Lo creó hace un par de años para un trabajo de clase, cuando su infraestructura era mucho más elaborada que hoy.

Desde entonces, la vida siguió su curso. Vendió hardware, algunos equipos fallaron y la red evolucionó, así que lo que era un homelab cuidadosamente diseñado se fue convirtiendo poco a poco en algo más pequeño y práctico. Pero el diagrama sigue existiendo, y cuenta una historia que muchos aficionados al homelab reconocen al instante.

Cuando un diagrama se convierte en la foto de un momento

Los diagramas de red tienen una cualidad curiosa: congelan la infraestructura en el tiempo.

El diagrama que se compartió en esta conversación se hizo en una época en la que el usuario tenía acceso a hardware mucho más potente. Su entorno incluía equipos empresariales como servidores HP DL380 Gen9 y material de red Mellanox de 10 gigabits, hardware serio para un homelab.

Pero mantener montajes así puede salir caro. El consumo eléctrico se acumula, las piezas de repuesto cuestan dinero y a veces los equipos simplemente fallan.

En este caso, el usuario explicó que tuvo que vender uno de los servidores, junto con las tarjetas de red Mellanox de 10 gigas y los receptores. El switch de distribución acabó muriendo también; ya era un equipo heredado de otra persona y estaba cerca del final de su vida. De repente la red, antes compleja, tenía un aspecto muy distinto, y el diagrama se quedó como recuerdo de lo que había sido el montaje.

Por qué a la gente le sigue gustando dibujar su infraestructura

Aun con herramientas de infraestructura automatizadas por todas partes, la gente sigue dibujando diagramas, y con razón. Los diagramas convierten sistemas abstractos en algo visible. En lugar de tener docenas de conexiones en la cabeza, ves toda la arquitectura desplegada delante de ti.

Eso ayuda especialmente en un homelab, donde se experimenta sin parar. Los contenedores pasan de un nodo a otro, los firewalls cambian y los pools de almacenamiento crecen. Un buen diagrama te ayuda a recordar qué se conecta con qué, y a veces te sirve para explicar tu montaje a otras personas que sienten curiosidad por cómo funciona todo.

Esa curiosidad apareció enseguida en la conversación. Varias personas preguntaron cómo se había hecho el diagrama, suponiendo que hacían falta conocimientos de programación o herramientas especializadas. La respuesta fue sorprendentemente sencilla.

La herramienta detrás del diagrama: ExcaliDraw

Los diagramas se hicieron con ExcaliDraw, una herramienta de dibujo colaborativo conocida por su estilo a mano alzada.

Comparada con herramientas de diagramas tradicionales como Visio o Draw.io, ExcaliDraw resulta deliberadamente suelta. Las líneas parecen bocetos y las formas no son perfectamente rígidas, así que el resultado se parece más a algo dibujado en una pizarra que a una diapositiva de presentación corporativa.

Ese estilo informal la hace popular entre desarrolladores y administradores de sistemas. Puedes esbozar ideas rápido sin preocuparte por una alineación perfecta ni por un formato estricto, y para mucha gente esa libertad facilita pensar en sistemas complejos.

El autor contó que usaba ExcaliDraw mucho antes del reciente auge de las herramientas de IA y los asistentes de programación; era simplemente su forma preferida de plasmar ideas de infraestructura. Curiosamente, los diagramas se construyeron en origen con componentes al estilo JSX, mezclando conceptos de programación con diseño visual. No es un enfoque habitual, pero refleja cómo piensan hoy muchos desarrolladores en los sistemas: como combinaciones de componentes conectados por flujos.

Aprender infraestructura por las malas

Otra parte interesante de la conversación fue cómo nació el diagrama. Empezó como un trabajo de una asignatura de seguridad, no como un homelab de producción ni como un proyecto laboral.

Los diagramas ilustraban flujos de comunicación entre sistemas, como emisores, receptores, cifrado y firmas digitales. Esos flujos podían representar la entrega de correo, la mensajería cifrada u otros procesos de comunicación segura. Así que los diagramas trataban menos del hardware y más de entender cómo viajan los datos de forma segura entre sistemas.

Ese proyecto académico se convirtió en algo mayor. El estudiante sacó una A en el trabajo, y los diagramas pasaron a ser la base para aprender más sobre redes y diseño de infraestructura.

Para mucha gente de la comunidad homelab, ese camino resulta familiar: un proyecto de clase se convierte en afición, y con el tiempo la afición se convierte en infraestructura real.

El lado caótico de hacer diagramas

Aunque los diagramas quedaban impresionantes, su creador admitió que el proceso no fue precisamente fluido. Espaciar los elementos en diagramas complejos puede ser sorprendentemente difícil, y en cuanto un diagrama de red pasa de unos pocos nodos, todo cuesta más de organizar. Los componentes se solapan, las líneas se cruzan de mala manera y las secciones de la arquitectura empiezan a apelotonarse.

El usuario bromeó con que las "zonas de React" del diagrama se habían desordenado mientras intentaba reorganizarlo todo. Cualquiera que haya hecho diagramas grandes conoce bien esa frustración. Empiezas con una distribución limpia, luego añades otro servidor y otro segmento de red, y al poco el diagrama parece un plato de espaguetis. Aun así, esas imperfecciones forman parte del proceso.

De los diagramas a la infraestructura real

La conversación acabó derivando hacia lo que el usuario tiene funcionando hoy. Un comentarista sospechaba que un montaje así seguramente incluía contenedores o cargas de trabajo basadas en Docker, y acertó.

El autor contó que ahora mantiene un clúster de Portainer de cuatro nodos que gestiona servicios en contenedores repartidos por varias máquinas. Está muy lejos de un homelab sencillo de un solo servidor.

Aunque el hardware original ha cambiado, el espíritu de experimentación sigue igual. Los contenedores, los clústeres y los flujos de red, todos los elementos que aparecían en los diagramas, siguen existiendo en la infraestructura real. El diagrama simplemente captó una etapa anterior de ese camino.

Por qué los diagramas viejos siguen importando

Es fácil descartar los diagramas de infraestructura antiguos cuando el hardware cambia, pero a menudo muestran cómo aprendió alguien a pensar en los sistemas.

Todo homelab evoluciona. Los servidores se sustituyen, las redes encogen o crecen y la tecnología cambia rápido. Pero lo aprendido al diseñar esos diagramas se queda contigo. Entender cómo fluyen los datos por un sistema, cómo interactúan los firewalls con los contenedores y cómo funciona el cifrado entre emisor y receptor construye un modelo mental que te acompaña en los proyectos siguientes.

Por eso muchos ingenieros guardan sus diagramas viejos. Además de documentación, son un registro de cómo evolucionó su forma de entender los sistemas.

El orgullo detrás de un homelab

Si hay una emoción que recorre conversaciones como esta, es un orgullo discreto, muy lejos de los pulidos vídeos de marketing tecnológico: el orgullo de alguien que ha construido por su cuenta algo imperfecto, experimental y en constante evolución.

El usuario que compartió el diagrama incluso admitió que seguía aprendiendo, sobre todo en herramientas de frontend como React. Las redes y los contenedores eran su punto fuerte, pero visualizarlo todo en código era un reto, y aun así siguió peleándose con ello.

Esa es la historia detrás de la mayoría de los homelabs: experimentos en marcha que nunca terminan de estarse quietos.