Construí mi propio alternativo a Kubernetes: ¿estoy loco?

# Construí mi propio alternativo a Kubernetes: ¿estoy loco?

Si trabajas en desarrollo, seguro sabes de lo que hablo: Kubernetes es una de esas herramientas que amas y odias a la vez. Amas porque antes de ella, desplegar en producción era como hacer malabares en la oscuridad. Odias porque, seamos sinceros, su complejidad puede volverte loco.

Hoy te quiero contar una historia que me pasó hace poco. Una historia que empieza con una ducha y termina conmigo creando mi propia alternativa a Kubernetes. Sí, como lo lees. Y no, no estoy completamente loco (o quizás sí un poco).

El amor-odio con Kubernetes

Antes de Kubernetes, herramientas como Mesos, Fleet o Nomad intentaban resolver el problema de la orquestación de contenedores. Pero ninguna lo hizo tan bien como Kubernetes. Según el informe de la CNCF de 2023, más del 96% de las organizaciones que usan contenedores hoy en día utilizan Kubernetes. Es un dato impresionante, ¿verdad?

Pero, como nada es perfecto, Kubernetes tiene un talón de Aquiles: su diseño. No hablo del diseño visual, sino de cómo funcionan las cosas por dentro. Los ingenieros de Google lo construyeron pensando como ingenieros: funciona, sí, pero entenderlo requiere un curso dedicado. Literalmente, existe una certificación llamada CKA que se ha convertido en un commodity en el mercado laboral.

El problema concreto es este: para tener un clúster mínimo de Kubernetes necesitas entender al menos 15 abstracciones diferentes. Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, RBAC, PVCs, StorageClasses, NetworkPolicies... y la lista sigue. Con cada nueva versión, el número crece. La versión 1.29 introdujo más de 60 cambios en la API, y en 2024 se deprecaron más de 10 APIs que muchos proyectos usaban.

El dilema de las pequeñas empresas

Aquí está el meollo del asunto. Las grandes empresas pueden permitirse tener un ingeniero DevOps certificado. Pero las pequeñas empresas, esas que no pueden pagar un sueldo de 60.000 euros al año para un especialista, se encuentran en una encrucijada. Saben que necesitan Kubernetes, pero no pueden gestionarlo.

Y es aquí donde entran alternativas como Dokploy, que usa Docker Swarm. Pero Docker Swarm, aunque técnicamente sigue mantenido por Docker Inc., ha visto su desarrollo ralentizado drásticamente. El ecosistema dejó de invertir en él, y su adopción se ha reducido. Es un proyecto funcionalmente estancado, lo que para infraestructura crítica es un riesgo real.

Otra alternativa es Nomad de HashiCorp. Es más simple que Kubernetes, un solo binario, sin tanta ceremonia. Pero, en mi opinión, cometió el error de acoplarse demasiado al ecosistema de HashiCorp: necesitas Consul para el descubrimiento de servicios, Vault para los secretos, Terraform para la infraestructura. Funciona genial si adoptas todo, pero si no, es limitante. Y ahora, tras la adquisición de HashiCorp por IBM en 2024 y el cambio de licencia de MPL a BSL, esa dependencia se ha vuelto aún más arriesgada.

La chispa: una ducha y una decisión

Algo que debes saber sobre mí: me encanta estudiar todo lo relacionado con TI. Más que mi profesión, es mi hobby. Y me gusta dar sentido a lo que estudio.

Hace poco empecé un proyecto personal. Tengo tres instancias VPS, empecé a analizar qué necesitaba y me di cuenta de que no necesitaba toda la complejidad de Kubernetes. Me fui con Dokploy, que funciona bien para un MVP. Pero la pregunta seguía ahí: ¿qué pasa cuando crezca?

Así que un día, en la ducha, reflexionando sobre todo esto, pensé: puedo usar Dokploy mientras sea un MVP, puedo hacer un curso de Kubernetes y esperar que la IA configure todo correctamente, o puedo construir una alternativa real. Elegí la opción obvia: construir la alternativa.

Puedes pensar que estoy loco. Pero recuerda: Kubernetes nació porque los ingenieros de Google pensaron que podían hacer algo mejor que Borg. Docker nació porque alguien pensó que LXC podía ser más simple. Los proyectos reales surgen cuando la gente decide pensar diferente sobre problemas conocidos.

Mi proyecto: simple, abierto y sin ánimo de lucro

Mi objetivo no es la fama ni el dinero. El proyecto será 100% open source, licencia Apache 2, sin niveles de pago. Lo que quiero es resolver un problema real: la complejidad innecesaria en la orquestación de contenedores. No prometo que lo lograré, pero vale la pena intentarlo.

Llevo trabajando en esto unas semanas. El repositorio sigue siendo privado, pero pronto, cuando tenga una versión más estable, lo haré público. En los próximos posts detallaré las decisiones de arquitectura y el razonamiento detrás de ellas, incluyendo por qué construí mi propio orquestador en lugar de basarme en Kubernetes.

Si tú también sientes que la complejidad de Kubernetes está desproporcionada con el problema que resuelve, quédate. Seguro que cometeré muchos errores, pero documentaré todo.

Conclusión

Al final, todo esto me ha enseñado que a veces la mejor solución no es la más compleja, sino la que mejor se adapta a tus necesidades. Si estás en una situación similar, te animo a que reflexiones: ¿realmente necesitas toda la potencia de Kubernetes para tu proyecto? Quizás una alternativa más simple te funcione mejor.

Y si estás interesado en cómo gestionar tu infraestructura de forma más eficiente, no dudes en contactarme. En [Guillermo Mateo](https://guillermomateo.es) ofrecemos servicios de [desarrollo web](https://guillermomateo.es/aplicaciones-web) y [automatización de procesos](https://guillermomateo.es/automatizacion-procesos) que pueden ayudarte a simplificar tu stack tecnológico. También puedes consultar la documentación oficial de Kubernetes en [kubernetes.io](https://kubernetes.io) para entender mejor sus capacidades.

¡Nos vemos en el próximo post!