Detrás de esto hay una sola persona.
Empezó con un par de portátiles que nunca apagaba y una factura de AWS que no podía justificar.
Casi todo lo que sé desde entonces lo aprendí rompiéndolo primero.
Esto empezó en un dormitorio, no en una sala de servidores. Un portátil estaba encendido día y noche, con el ventilador zumbando bajo una lámpara de escritorio. Algunas noches lo reiniciaba en Windows para otra cosa, y lo que estuviera corriendo en él simplemente se paraba; me daba cuenta al día siguiente. Sin presupuesto, sin plan, solo cabezonería y una larga racha de malas decisiones que poco a poco fueron mejorando.
¿Cómo empezó Albgott?
Con lo que tenía por casa: un par de portátiles y ningún plan. Lo que lo convirtió en algo serio fue una factura de AWS de unos 300 € por máquinas que había dejado encendidas, y estar harto de depender de Google Drive, de un Jenkins que alojaba otra persona y de cualquier SaaS que no controlaba. Así que empecé a montar lo mío. Mal al principio, un poco mejor con cada error. Lo he tirado abajo y lo he vuelto a montar más de una vez, cada vez sobre una base más sólida.
¿Por qué no usar AWS o cualquier otro proveedor cloud?
Lo usaba, hasta esa factura. Desplegar un contenedor en una plataforma gestionada es la parte fácil; cualquiera lo hace en una tarde. Diseñar los segmentos de red, escribir las reglas del firewall, ser quien recibe la alerta a las 3 de la madrugada: una plataforma gestionada hace todo eso por ti sin que lo notes, y eso es justo lo que yo quería aprender.
¿No es demasiado para una sola persona?
Probablemente sí. Ocho segmentos de red aislados, tres nodos, observabilidad completa y su propio pipeline de CI, todo para los proyectos personales y el trabajo con clientes de una sola persona. Podría tenerlo todo en un VPS. No lo hago porque la idea es operarlo como lo haría un equipo de verdad, y eso no se aprende en un VPS.
¿Qué es lo peor que se ha roto?
Sobre todo en los primeros años. Mi proveedor nunca me dio una IP fija, así que durante un tiempo la cambiaba a mano en media docena de sitios cada vez que variaba, hasta que por fin configuré DDNS. Peor aún: una vez se cayó mi servidor DNS y me enteré porque un cliente me llamó para preguntar por qué su web no cargaba. Ninguno de mis dashboards me avisó. De ahí salió un segundo servidor DNS, sincronizado con transferencias de zona autenticadas, y la lección de no fiarme de un sistema cuyo interior no puedo ver.
¿Cómo sabes ahora que algo va mal?
Durante mucho tiempo, mirando. Revisaba a mano unos cuantos dashboards y esperaba que nada hubiera muerto en silencio desde la última vez. Y cuando algo se rompía, a menudo no recordaba por dónde empezar, porque no había nada escrito. Los dos problemas se arreglaron igual, aunque más tarde de lo que debería: las alertas llegan directamente a Telegram y cada servicio tiene documentación interna que actualizo el mismo día que lo cambio.
¿Qué problema técnico te enseñó algo?
WireGuard en el MikroTik. Un peer completaba el handshake y parecía conectado, pero el tráfico no se enrutaba. RouterOS no le asigna a la interfaz del túnel una dirección de gateway solo porque el peer tenga una, así que hay que añadirla a mano con /ip address. Es una línea, y ahora es la primera advertencia de mi documentación de WireGuard. También me dejó una lección más general: que el handshake funcione solo demuestra que el túnel existe. Que el tráfico llegue a algún sitio es cosa del enrutamiento, y que esté permitido es cosa del firewall.
¿Por qué hacer público todo esto?
Porque un homelab privado no le demuestra nada a nadie más que a mí. Escribirlo para desconocidos también me obliga a ser preciso: un diagrama que publico tiene que coincidir con lo real, y un roadmap que publico tiene que avanzar.
¿Qué decisión de los inicios tomarías hoy de otra forma?
No segmentar la red desde el primer día. Al principio todo vivía en el mismo dominio de broadcast, porque dividirlo parecía excesivo para un proyecto sin usuarios. No lo era. Cada cambio posterior tuvo que empezar por deshacer una decisión que había tomado en una tarde sin pensarla mucho.
Entonces, ¿Albgott está terminado?
Ni de lejos. Lo siguiente es un NAS, para tener copias fuera de los nodos y almacenamiento compartido entre ellos, y buena parte de la configuración todavía tiene que pasar a código. Después, IA en local: la GTX 1070 de pve01 ya se comparte con contenedores LXC mediante bind-mounts de dispositivo en lugar de passthrough con VFIO, así que un servidor de inferencia puede usarla sin quitársela al host. La lista completa está en el roadmap →. Sospecho que lo más interesante todavía está por llegar.
¿TIENES ALGO QUE NO PUEDE CAERSE?
Si estás montando infraestructura o un servicio que tiene que seguir funcionando después del día del lanzamiento, cuéntamelo. Me encanta pensar en las partes difíciles.