Cuando se construye una empresa de hosting, hay un atajo evidente. Comprar una licencia de un panel existente, conectarlo a los servidores y empezar a vender. Muchos proveedores lo hacen. WHMCS, Blesta, o alguna solución white-label que te da un panel de control, facturación y gestión básica de servidores de serie. Se puede estar funcionando en una semana.

CubePath miró ese camino y decidió no tomarlo. En su lugar, destinó una parte enorme de sus recursos a construir su propio API y panel de control desde cero. Fue más lento, más caro y mucho más complejo que comprar algo ya hecho. También ha sido la mejor decisión que se ha tomado.

Este post explica por qué se tomó esa decisión, cómo se ha arquitecturado y por qué es la razón por la que CubePath puede lanzar nuevos productos más rápido que proveedores diez veces su tamaño.

Por Qué No Usar Lo Que Ya Existe

El problema con los paneles de terceros no es que sean malos. Funcionan bien para hosting básico. El problema es lo que pasa cuando quieres hacer algo que no tenían previsto.

CubePath quería lanzar Managed Kubernetes. Ningún panel del mercado lo soporta. Quería ofrecer Load Balancers Anycast. No está en el panel. ¿CDN con reglas de caché personalizadas? ¿Clusters GPU? ¿Redes privadas multi-región con MTU 9000? Nada de eso existe en ningún panel de hosting de terceros.

Así que un proveedor acaba en uno de dos sitios. O limita su producto a lo que el panel soporta, lo que significa verse exactamente igual que cualquier otro proveedor usando el mismo panel. O empieza a hackear funcionalidades encima, construyendo integraciones personalizadas alrededor de la arquitectura de otro, parcheando sus limitaciones, y peleándose con su ciclo de actualizaciones cada vez que lanzan una nueva versión que rompe las personalizaciones.

El roadmap de producto queda atado al roadmap de otro. La experiencia de usuario está limitada por las decisiones de UI de otro. Y la capacidad de innovar está restringida a lo que se pueda atornillar encima de un sistema que nunca fue diseñado para lo que se intenta construir.

CubePath no quería nada de eso. Quería control total sobre cada producto, cada funcionalidad y cada píxel de la experiencia que se entrega a los clientes.

API-First: Todo Empieza por la API

La base de toda la plataforma de CubePath es la API. No el panel. La API.

Cada producto existe como API primero. Cuando se construye una funcionalidad nueva, lo primero que se desarrolla es el endpoint de la API. El panel de control es simplemente un cliente que consume esa API, igual que lo haría un script de Terraform de un cliente o una automatización personalizada.

Esto suena a detalle técnico, pero cambia todo en cómo funciona la plataforma:

Si no está en la API, no existe. Esto fuerza una arquitectura limpia. Cada acción, desde desplegar un VPS hasta crear un cluster de Kubernetes o configurar un Load Balancer, tiene una llamada API bien definida detrás. No hay funcionalidad oculta que solo funcione por la UI. Todo lo que un cliente puede hacer en el panel, lo puede automatizar a través de la API.

El panel nunca puede ir por delante de la API. Como el panel está construido encima de la API, no al lado, siempre están sincronizados. No existe la situación de "se ha añadido un botón en el panel pero la API todavía no lo soporta." La API es la fuente de verdad.

Los clientes tienen automatización desde el día uno. Cuando se lanza un producto nuevo, tiene documentación de API el día del lanzamiento. No semanas después, no "próximamente." La API fue literalmente lo primero que se construyó para ese producto. Los clientes que quieren integrar CubePath en sus pipelines CI/CD, workflows de Terraform o automatización propia pueden hacerlo inmediatamente.

Las integraciones con terceros son directas. Como la API es limpia y consistente en todos los productos, construir integraciones con herramientas como Terraform, Ansible, Pulumi o scripts propios es predecible. Se aprende el patrón una vez y se aplica a cada producto que CubePath ofrece.

Microservicios: Cada Producto Es Su Propio Servicio

La plataforma de CubePath no es un monolito. Cada producto corre como un microservicio independiente: aprovisionamiento de VPS, Managed Kubernetes, DNS, Load Balancers, CDN, facturación, networking. Cada uno es su propio servicio con su propio código, su propio pipeline de despliegue y su propio escalado.

¿Por qué importa?

Despliegue independiente. Cuando se lanza una actualización en el servicio de Kubernetes, el servicio de aprovisionamiento de VPS ni se entera. No hay riesgo de que una actualización de DNS rompa el sistema de facturación. Cada servicio se despliega, actualiza y revierte de forma independiente. Esto es lo que permite lanzar actualizaciones a diario sin riesgo.

Escalado independiente. Durante un pico de tráfico en aprovisionamiento de VPS, se escala ese servicio sin tocar nada más. El servicio de gestión del plano de control de Kubernetes tiene características de escalado completamente diferentes al servicio de configuración de CDN. Los microservicios dejan que cada uno escale para su propia carga de trabajo.

Desarrollo en paralelo. El equipo de ingeniería puede trabajar en múltiples productos simultáneamente sin pisarse. El equipo trabajando en soporte de clusters GPU no está bloqueado por el equipo mejorando el servicio de Load Balancers. Repos diferentes, pipelines diferentes, ciclos de despliegue diferentes.

Aislamiento de fallos. Si un servicio tiene un problema, el radio de explosión está contenido. Un bug en el servicio de gestión de DNS no tumba el aprovisionamiento de VPS. El panel sigue funcionando, la API sigue respondiendo, y el servicio afectado se arregla sin fallos en cascada por toda la plataforma.

Añadir nuevos productos es añadir un nuevo servicio. Cuando se decidió construir Managed Kubernetes, no hubo que modificar un monolito ni encontrar dónde encajarlo en un código existente. Se construyó un nuevo servicio, se conectó al API gateway, y estaba en producción. Lo mismo con CDN. Lo mismo con clusters GPU cuando se lancen. La arquitectura está diseñada para esto.

CubePath Corre Sobre Lo Que Vende

Hay un detalle que define mucho la filosofía de CubePath: la plataforma corre sobre Kubernetes. El mismo Kubernetes que se vende como producto gestionado a los clientes.

Los microservicios se despliegan como contenedores en clusters de Kubernetes. La infraestructura está definida como código. Los despliegues pasan por pipelines de CI/CD. Se usan las mismas herramientas y prácticas que se recomiendan a los clientes porque se cree en ellas lo suficiente como para apostar la propia plataforma.

Infrastructure as Code en todas partes. Cada pieza de la infraestructura de la plataforma está definida en código y bajo control de versiones. Configuraciones de servidores, políticas de red, manifiestos de Kubernetes, reglas de monitorización. Todo vive en Git. Si se necesita recrear un servicio desde cero, se puede. Si se necesita revertir un cambio, es un git revert. No existe eso de "aquel servidor que alguien configuró a mano hace tres años y nadie sabe cómo funciona."

CI/CD en todo. Un merge a main lanza el pipeline. Los tests corren, las imágenes se construyen, los despliegues se ejecutan. No se hace SSH a servidores para desplegar código. No hay "días de despliegue" donde todo el mundo contiene la respiración. Lanzar código es algo que ocurre de forma continua, múltiples veces al día, porque el pipeline se encarga.

GitOps con ArgoCD. El mismo ArgoCD que CubePath ofrece como add-on en un click en Managed Kubernetes es el que se usa para gestionar los despliegues de la propia plataforma. Git es la fuente de verdad para el estado del cluster. ArgoCD vigila los repos y mantiene todo sincronizado. Si alguien hace un cambio manual en un cluster, ArgoCD lo revierte. Si se necesita hacer rollback, se revierte el commit y ArgoCD se encarga del resto.

Monitorización y observabilidad desde el día uno. Cada servicio sale con métricas, logging estructurado y tracing. Se sabe cómo rinde cada llamada API, dónde se gasta el tiempo, y cuándo algo está degradándose antes de que sea un problema visible para el cliente. Prometheus, Grafana, reglas de alertas. El mismo stack que se ofrece como add-on es el stack que se usa internamente.

Esto no es solo alineación filosófica. Hace que CubePath sea mejor gestionando Kubernetes para sus clientes porque lo gestiona para sí mismo cada día. Los problemas que se resuelven para la propia plataforma son los mismos problemas que enfrentan los clientes, y las soluciones que se construyen a menudo acaban convirtiéndose en funcionalidades del producto.

La Filosofía DevOps Que Lo Une Todo

Las herramientas importan, pero la cultura detrás importa más. CubePath opera con una mentalidad DevOps que es parte central de cómo funciona la empresa:

Los que lo construyen, lo operan. Los ingenieros no escriben código y se lo pasan a un equipo de operaciones. Las mismas personas que desarrollan un servicio son responsables de desplegarlo, monitorizarlo y estar de guardia por él. Esto crea un bucle de feedback natural: si tu código causa alertas a las 2 de la mañana, escribes mejor código.

Equipo pequeño, output grande. Gracias a la inversión en automatización, CI/CD e Infrastructure as Code, un equipo de ingeniería pequeño puede gestionar una plataforma que sirve a miles de clientes en múltiples regiones. No se quema plantilla en despliegues manuales, configuración manual de servidores ni respuesta manual a incidentes. Los sistemas manejan el trabajo rutinario, y los humanos se centran en construir cosas nuevas.

Todo es reproducible. Sin servidores snowflake, sin configuraciones manuales, sin "en mi máquina funciona." Cada entorno, desde desarrollo hasta staging y producción, está definido en código y se puede recrear cuando haga falta. Esto da confianza para experimentar, porque siempre se puede volver a un estado conocido.

Falla rápido, recupérate más rápido. Con CI/CD, rollbacks y observabilidad adecuados, el coste de probar algo nuevo es bajo. Si un despliegue introduce una regresión, se detecta en la monitorización, se hace rollback en segundos y se arregla. Esta velocidad viene de la inversión en herramientas y arquitectura, no de tomar atajos en calidad.

El Resultado: CubePath Lanza Productos Más Rápido

Toda esta arquitectura, el enfoque API-first, los microservicios, la plataforma Kubernetes, la cultura DevOps, se compone. Cada nuevo producto es más rápido que el anterior porque la base ya está ahí.

Cuando se construyó Managed Kubernetes, no se partió de cero. El API gateway estaba ahí. El sistema de autenticación estaba ahí. La integración de facturación estaba ahí. El stack de monitorización estaba ahí. El pipeline de CI/CD estaba ahí. Se construyó la lógica específica de Kubernetes como un nuevo microservicio, se enchufó a la plataforma existente, y estaba en producción.

Cuando se construyó CDN, lo mismo. Nuevo servicio, misma plataforma. API lista el día del lanzamiento, integración con el panel lista el día del lanzamiento, monitorización lista el día del lanzamiento.

Esta es la ventaja compuesta de construir la propia plataforma. Cada producto que se lanza hace que el siguiente sea más fácil. Y como la API es la base, cada producto es automatizable desde el día uno. Ningún cliente tiene que esperar a que "se añada soporte API más adelante." Ya está ahí, porque la API es como se construye todo.

Compara eso con un proveedor usando un panel de terceros. Cada nuevo producto es una integración personalizada, un hack encima del sistema de otro, una feature request que puede o no ser implementada por el vendor del panel. Su velocidad está limitada por las prioridades de otro.

La velocidad de CubePath está limitada solo por lo rápido que su equipo pueda escribir buen código. Y con la plataforma que se ha construido, eso es bastante rápido.

La Inversión Más Difícil Es la Que Más Retorno Da

Construir un API y panel de control propio ha sido lo más difícil que se ha hecho en CubePath. En los primeros días, cada competidor ya estaba vendiendo servicios mientras el equipo seguía escribiendo endpoints de API y diseñando esquemas de base de datos. Habría sido mucho más fácil comprar un panel y empezar a vender inmediatamente.

Pero cada mes que pasa, la distancia entre lo que CubePath puede hacer y lo que puede hacer un proveedor con un panel de terceros se hace más grande. CubePath puede lanzar un producto nuevo en semanas. Ellos necesitan esperar a que su panel lo soporte, o pasar meses construyendo una integración personalizada. CubePath puede cambiar la experiencia de cliente de un día para otro. Ellos están limitados por el framework de UI de otro. CubePath puede ofrecer una API consistente y totalmente documentada en cada producto. Ellos tienen un patchwork de integraciones que pueden o no funcionar juntas.

El coste inicial fue real. Pero la ventaja a largo plazo es algo que no se puede comprar ya hecho. Es el tipo de ventaja que solo viene de construirlo desde cero, ladrillo a ladrillo, endpoint a endpoint.

Y esto no ha hecho más que empezar.