Kubernetes o VPS ¿Cuál es mejor? Mi experiencia.

Tras varios años trabajando con kubernetes, en ocasiones me planteo si es mejor trabajar con máquinas virtuales en lugar de usar k8s. En este post, te cuento mi experiencia y las ventajas e inconvenientes de cada opción.

Cuando empecé a trabajar como ingeniero de software me formé en diferentes áreas: front, back, servidores... lo que se conoce como un ingeniero de software full-stack. El mundo de los despliegues me interesaba mucho ya que requiere conocer cómo interactúan todas las piezas de un sistema en su conjunto, y sumado a mi interés por la optimización y rendimiento, me hizo conocer en profundidad cómo funcionan los servidores, por lo que especializándome como DevOps.

Aunque DevOps es más bien una filosofía de trabajo, durante varios años se ha convertido en un puesto específico el sector. Podríamos decir que he trabajado como Platform Engineer / SRE / DevOps / SysOps / SysAdmin.

En el pasado recuerdo haber trabajado con máquinas virtuales gestionadas manualmente, mediante procesos que utilizaban herramientas como Ansible, Docker o un simple script Bash: procesos muy simples que son prácticos y funcionan.

Al poco tiempo surgieron Docker y Kubernetes, y aquí he experimentado lo que es mantener un clúster de kubernetes on-premise y enfrentarte a miles de retos y bugs (sí kubernetes también tiene bugs), hasta migrarlo a un entorno cloud. Lo cierto es que conocer kubernetes en profundidad implica entender muy bien las diferentes capas de abstracción, cómo se deben configurar los despliegues, las partes que lo componen, etc. Esto requiere estudiar, practicar y tiempo para experimentar situaciones y problemas que únicamente puedes enfrentarte en el mundo real, cuando gestionas cargas de trabajo 24/7 que no pueden fallar.

Tras varios años utilizando kubernetes en mi día a día, hace un par de años me surgió la siguiente reflexión: kubernetes es genial pero ¿No es un VPS es mucho más simple y es mejor? ¿Pero quién dice que sea mejor o peor? Así que decidí aventurarme a volver a experimentar lo que es gestionar entornos con máquinas virtuales para aprender, sacar conclusiones y contártelo.

Explorando los VPS

Como desde pequeño he creado múltiples side-projects he tenido que desplegar diferentes productos (algunos os los traeré por aquí) y siempre me preguntaba cuál es la mejor opción para desplegarlos de forma simple y barata. A día de hoy hay múltiples herramientas que puedes utilizar para desplegar tu proyecto, pero en este artículo las voy a simplificar a dos: Kubernetes y un VPS.

También puedes utilizar plataformas serverless, son cómodas cuando no te sales del camino, aunque tienen bastante complejidad asociada y el problema de controlar los costes. No me suelen gustar las sorpresas por lo que prefiero utilizar otras opciones, aunque para procesos concretos sí las he utilizado.

Como quería volver a explorar el mundo de desplegar de forma simple (y barata) pero estable, decidí configurar una serie de máquinas virtuales (VPS) que tienen un coste económico muy asequible, que junto con una serie de script para desplegar estos proyectos, me han aportado mucha experiencia fuera del entorno Docker/K8S y he conseguido tener unos despliegues muy estables que prácticamente no requieren mantenimiento.

Tras varios años cambiando y experimentando con diferentes opciones, estoy muy contento habiendo explorado esta opción ya que me permite enfocarme en lo realmente importante, a la vez que tener un buen compromiso entre productividad/coste.

En resumen: puedes tener un producto muy bueno y estable funcionando en servidores VPS / on-premise / alquilados / tu propio rack alojado en un data-center. Al estar fuera del cloud, tendrás más margen de beneficios aunque necesitarás compensarlo con conocimientos o personas que lo dominen y sepan lo que hacen aquí.

Kubernetes (o k8s)

Kubernetes me encanta, aunque he tenido momentos complicados cuando te enfrentas a bugs o problemas que requieren mucho tiempo. Quitando esto, Kubernetes tiene muchas ventajas: al utilizar docker, o contenedores (virtualización), te permite tener diferentes entornos idénticos asegurando que funcionan. Te elimina la frase de "en mi local funciona" (aunque hay formas de que con docker también te ocurra).

Lo bueno de kubernetes es que conociendo "únicamente" un stack (un stack complejo que requiere de estudio, entendimiento y perfeccionamiento) puedes desplegar y gestionar todo tipo de cargas con un equipo pequeño sin despeinarte (siempre y cuando sepas lo que haces, claro).

El problema que le veo es la complejidad asociada y el coste, por lo que o lo montas en cloud o tienes un equipo que te permita gestionarlo. Además, lo ideal para configurarlo es utilizar terraform (una pasada, me encanta una vez lo dominas), tienes que conocer cómo funcionan muchas partes al final (almacenamiento, redes, cómputo), luego necesitas integrar esto con el proveedor cloud (o si lo tienes on-premise es aún más divertido).

Además Kubernetes requiere gestionar otras partes como despliegues, luego los despliegues se convierten en plantillas (helm o kustomize), integración continua (CI/CD), gestión de secretos, gestión de permisos, registros de imágenes de docker, etc.

Y la verdad es que sí, son muchas cosas que hay que saber pero si este es tu stack y lo dominas bien, puedes gestionar cualquier tipo de carga cómodamente y optimizar los costes al mínimo.

También es cierto que no es lo mismo desplegar un pequeño side-project que un producto que genera dinero y por tanto montar infraestructura como esta podría verse como un retorno de la inversión. Como siempre digo, depende.

Conclusión: ¿Qué utilizo para desplegar?

Todo depende de las necesidades que tengas. Si tienes pocos proyectos y un equipo de personas relativamente pequeño, gestionar tus propios servidores puede ser una buena opción. Por otro lado, si tienes varios proyectos y diferentes equipos que necesitas escalar, tener kubernetes te puede permitir homogeneizar el stack con el que se trabaja en el departamento y, con una única herramienta gestionar cómodamente todos los proyectos.

Claramente puede haber diferencia si las necesidades de tu producto requieren por ejemplo monitorización, donde puedes tener Grafana, Prometheus, Elastic/Kiabana (ELK), o si necesitas mantener un pipeline de datos con Kafka, o diferentes herramientas que tu empresa o departamento pueda necesitar. También dependerá de la necesidad que tengas de escalar tus cargas de trabajo de forma dinámica.

Si tienes un único proyecto y no te interesan estos aspectos ahora mismo, como siempre digo empieza por la opción que sea más simple para ti, por probabilidad Next.js y Vercel a día de hoy.

Como conclusión, el dónde desplegar tu proyecto es un tema importante al que debes dedicarle algo de tiempo, ya que esta decisión te acompañará durante unos años, pero no demasiado porque si tu proyecto o empresa crece, o cambian las necesidades, no te preocupes porque podrás y deberás migrarlo o adaptarlo a las nuevas necesidades. Únicamente te costará algo de tiempo, dinero (y coste de oportunidad), aunque si tienes poca deuda técnica, irás rápido.

En mi experiencia es una decisión de Tipo 2 (reversible) según el esquema de Jeff Bezos, así que dedica algo de tiempo pero no te preocupes si te equivocas ya que ambas opciones son buenas.

Si quieres empezar con un coste bajo, lo mejor es utilizar plataformas como vercel o un VPS. Kubernetes será más caro y requiere conocer muchas partes, por lo que necesitarás formarte o tener un equipo que lo haga por tí. Siempre podrás transicionar de uno a otro por lo que, como he dicho, no perdería demasiado tiempo en caer en parálisis por análisis.