“Sube todo al cloud” fue el mantra de la década pasada. “Repatria todo on-premise” es el contramantra de ahora. Las dos posturas absolutas se equivocan por la misma razón: tratan una decisión de ingeniería como una cuestión de fe. La pregunta correcta no es cuál es mejor en abstracto. Es cuál encaja con esta carga concreta, con este presupuesto y con esta normativa.
Vamos a definir los términos sin humo y luego a darte un marco para decidir.
El cloud público gana cuando la carga es variable e impredecible: picos estacionales, proyectos cortos, entornos de prueba que se levantan y se tiran. Pagas solo lo que usas.
El cloud privado gana cuando la carga es estable y sostenida 24/7. Una base de datos que corre todo el año a plena capacidad es mucho más barata en hardware reservado que alquilada por horas. Y luego está el egress: sacar datos de un hiperescalar se paga, y en cargas con mucho tráfico de salida ese coste oculto puede igualar al del cómputo.
Regla práctica: carga predecible y constante tiende a privado; carga elástica y esporádica tiende a público.
Si necesitas elegir el hardware, la versión exacta del hipervisor, la topología de red o tener acceso físico, el privado es el único que te lo da. En público vives con las abstracciones del proveedor, lo cual está bien hasta que un caso límite choca con ellas.
El cloud privado ofrece rendimiento dedicado y latencia predecible: sin vecinos ruidosos, sin variabilidad. Para bases de datos transaccionales, cargas de baja latencia o IA con GPU sostenida, importa. El público es excelente cuando lo que necesitas es escalar a lo ancho rápido, no exprimir cada microsegundo.
Aquí la pregunta se vuelve jurídica. Sectores regulados (sanidad, banca, sector público) tienen requisitos de ubicación del dato, trazabilidad y soberanía. Un hiperescalar estadounidense, aunque tenga región europea, sigue sujeto a la CLOUD Act. Si tu normativa exige jurisdicción europea estricta, el cloud privado en datacenters de la UE simplifica mucho el cumplimiento de ENS, RGPD y NIS2.
Hazte estas preguntas por cada carga (no por la empresa entera):
| Pregunta | Si la respuesta es “sí”… |
|---|---|
| ¿La carga corre estable 24/7? | Privado |
| ¿Los picos son impredecibles o esporádicos? | Público |
| ¿Hay datos sujetos a soberanía estricta? | Privado |
| ¿Necesitas escalar a cero entre usos? | Público |
| ¿Genera mucho tráfico de salida (egress)? | Privado |
| ¿Es un experimento o proyecto corto? | Público |
Lo normal es que distintas cargas den respuestas distintas. Por eso casi nadie acaba 100% en un sitio.
La mayoría de empresas medianas terminan en híbrido por pura lógica, no por moda: la base de datos crítica y los datos sensibles en privado europeo, el frontend elástico y los entornos de desarrollo en público. El truco está en gobernarlo: una sola estrategia de identidad, red conectada con baja latencia, y disciplina de FinOps para que el público no se desboque.
El híbrido mal hecho es lo peor de ambos mundos: la complejidad del privado más la factura sorpresa del público. El híbrido bien hecho es lo mejor de ambos.
No hay ganador universal. Hay cargas que piden privado, cargas que piden público y una mayoría que vive mejor repartida. Lo que sí hay es una forma equivocada de decidir: copiar lo que hizo otro o seguir el titular de moda. Mira tus cargas una a una, aplica el marco y decide con datos.