Respuesta Rápida:
El hosting es donde tu aplicación corre físicamente; el despliegue es cómo el código nuevo llega ahí. Las opciones van desde hosting compartido económico hasta plataformas como Kubernetes, descrita por su documentación oficial como "una plataforma portátil, extensible y de código abierto" para contenedores. La diferencia entre un negocio que pierde clientes en cada actualización y uno que no, no es el hosting que paga — es el patrón de despliegue que usa.
Puntos Clave:
- Hosting vs despliegue: hosting es la infraestructura donde corre tu sitio; despliegue es el proceso de publicar código nuevo sin romper lo existente. Dos disciplinas distintas con costos y riesgos distintos.
- Kubernetes no es para todos: según la documentación oficial, Kubernetes ofrece autoescalado, autocuración y balanceo de carga — pero también advierte que "no despliega código fuente" ni provee bases de datos. Es una plataforma de orquestación, no una solución llave en mano.
- Blue-green permite revertir en segundos: Martin Fowler describe el patrón blue-green deployment como mantener "dos entornos de producción, lo más idénticos posibles", de modo que un cambio del enrutador deshace cualquier despliegue fallido.
- Feature flags separan código de funcionalidad: los flags permiten lanzar una función a 1%, 5%, 20% y luego 100% de usuarios — y si algo falla en el 1%, "se puede revertir al instante" sin un nuevo despliegue.
- Vercel automatiza despliegues por commit: según la documentación de Vercel, "cada commit o pull request activa automáticamente un nuevo despliegue" con una URL única para vista previa antes de promoverlo a producción.
Cuando un dueño de negocio le dice a su desarrollador "solo súbelo a internet", está pidiendo dos cosas distintas que la mayoría de las personas asume que son la misma. Una es hosting: dónde vive físicamente la aplicación. La otra es despliegue: cómo el código nuevo llega a ese hosting sin tirar lo que ya está funcionando. Confundir estas dos cosas es la razón por la cual sitios profesionales se caen los viernes a las 5pm, pedidos no se procesan durante el Black Friday, y formularios de contacto silenciosamente dejan de funcionar después de cada actualización.
Este artículo separa los dos conceptos en términos que un dueño de negocio puede usar para hacer mejores preguntas a su equipo técnico — sin importar si estás en Houston, Cypress, Monterrey o Bogotá. No necesitas escribir código. Necesitas entender qué estás comprando.
Hosting: Dónde Vive Tu Aplicación
Hosting es el lugar físico donde tu sitio o aplicación corre. Existen cuatro categorías principales, y la diferencia entre ellas determina cuánto pagas, qué tan rápido se cae cuando algo falla, y qué tanto control tienes cuando necesitas escalar.
1. Hosting compartido
Es la opción más barata. Tu sitio comparte un servidor con cientos o miles de otros sitios. Funciona para blogs personales y sitios de pequeñas empresas con bajo tráfico. El problema: si el sitio de otro cliente del mismo servidor recibe un pico de tráfico o un ataque, el rendimiento del tuyo cae también. Cuando se cae, no hay nada que puedas hacer salvo esperar a que el proveedor lo arregle.
2. VPS (Servidor Virtual Privado)
Tu sitio corre en un servidor virtual aislado dentro de un servidor físico más grande. Tienes recursos garantizados y control sobre la configuración. Es la mejora natural cuando un sitio supera al hosting compartido. Requiere conocimiento técnico para mantenerlo seguro y actualizado.
3. Serverless
No alquilas un servidor — pagas solo por cada ejecución de tu código. Ideal para sitios con tráfico irregular o aplicaciones que solo corren cuando un usuario hace una acción. La documentación de Vercel describe que con su plataforma, "cada commit o pull request en un repositorio Git conectado activa automáticamente un nuevo despliegue", combinando hosting serverless con un flujo de despliegue automático.
4. Kubernetes y orquestación de contenedores
Según la documentación oficial de Kubernetes, es "una plataforma portátil, extensible y de código abierto para gestionar cargas de trabajo y servicios en contenedores que facilita tanto la configuración declarativa como la automatización". Permite ejecutar aplicaciones complejas que se autoescalan, se autocuran cuando un componente falla y se balancean automáticamente entre múltiples servidores. Es la elección para aplicaciones de gran escala — y un exceso costoso para casi todo lo demás.
Advertencia sobre Kubernetes:
La propia documentación de Kubernetes aclara qué NO hace: "Kubernetes no despliega código fuente y no construye tu aplicación", "no provee servicios a nivel de aplicación, como middleware, frameworks de procesamiento de datos, bases de datos, cachés ni sistemas de almacenamiento de clúster", y "no dicta soluciones de logging, monitoreo o alertas". Si alguien te ofrece "Kubernetes" como solución mágica para tu negocio pequeño, está vendiendo orquestación sin contestar las preguntas reales sobre tu base de datos, tu monitoreo y tu pipeline de despliegue.
Despliegue: Cómo el Código Nuevo Llega Sin Romper Nada
Tener un buen hosting no garantiza que las actualizaciones no rompan el sitio. El despliegue — el proceso de publicar código nuevo — es una disciplina aparte. Los negocios que se actualizan sin caídas usan patrones específicos. Los que se caen, no.
Hay tres patrones que vale la pena entender: blue-green deployment, despliegues canary, y feature flags. Los tres existen para resolver el mismo problema: lanzar funciones nuevas sin que los clientes vean errores.
Patrón 1: Blue-Green Deployment
Como describe Martin Fowler en su explicación clásica del patrón, el despliegue blue-green se basa en mantener "dos entornos de producción, lo más idénticos posibles". Uno (blue) está activo recibiendo tráfico real. El otro (green) está inactivo. Cuando hay una versión nueva, se prepara en green y se prueba ahí. Cuando todo está listo, "se cambia el enrutador para que todas las solicitudes vayan al entorno green — el blue ahora queda inactivo".
La gran ventaja es la reversión instantánea. Según Fowler, el enfoque "te da una forma rápida de revertir — si algo sale mal, regresas el enrutador a tu entorno blue". Para un negocio que procesa pedidos en línea, esa capacidad de revertir en segundos en vez de en horas es la diferencia entre perder cinco pedidos y perder quinientos.
Cuándo blue-green vale la inversión:
- Tu sitio procesa transacciones de dinero real (e-commerce, reservas, pagos)
- Una hora de caída cuesta más que el costo de mantener un segundo entorno
- Tus actualizaciones de código suceden varias veces por semana
- Tu equipo técnico necesita revertir rápido sin "apagar incendios" en vivo
Patrón 2: Despliegues Canary
El despliegue canary lanza la nueva versión a un pequeño porcentaje de usuarios primero. Si todo va bien, se aumenta el porcentaje gradualmente. Si algo falla, solo ese pequeño grupo se ve afectado y se puede revertir antes de que el resto note nada. Es como probar agua con un dedo del pie antes de saltar.
Este patrón depende de feature flags para funcionar de forma segura — y ese es el siguiente tema.
Patrón 3: Feature Flags — Separar Código de Funcionalidad
Los feature flags son interruptores de software que activan o desactivan funcionalidades sin necesidad de desplegar código nuevo. La documentación de featureflags.io los describe como "formas de controlar el ciclo de vida completo de tus funciones", desde el desarrollo hasta el retiro.
En la práctica: lanzas una función nueva con el flag apagado para el 99% de usuarios y encendido para el 1%. Mides cómo responde ese 1%. Si todo va bien, subes a 5%, después a 20%, después a 100%. Según la documentación de featureflags.io, este enfoque permite que "si algo sale mal en el lanzamiento al 1%, puedes revertirlo al instante" — sin un nuevo despliegue, sin código modificado, sin esperar a un equipo de emergencia.
Los flags también sirven para entrega segmentada. La documentación de featureflags.io describe los flags de permisos como controles que "regulan la visibilidad de funciones basadas en atributos del usuario (nivel, geografía, estado beta)" — lo cual es exactamente lo que necesita un negocio que quiere ofrecer una función premium solo a clientes que pagan más, o probar una nueva versión solo con clientes de una región específica.
El Mito del "99.9% de Uptime"
Cuando un proveedor de hosting promete "99.9% de uptime", suena impresionante. La realidad matemática: 99.9% permite aproximadamente 8 horas y 45 minutos de caída al año. Si tu sitio procesa $50,000 al mes en pedidos, esas 8 horas pueden representar varios miles de dólares perdidos — y eso suponiendo que el proveedor cumpla con su SLA.
Cada nueve adicional (99.99%, 99.999%) reduce el tiempo de caída exponencialmente, pero cuesta exponencialmente más. La pregunta correcta para un dueño de negocio no es "¿qué uptime ofrecen?", sino "¿cuánto cuesta para mi negocio una hora de caída en mi peor momento — un viernes de Black Friday, una promoción en horario peak, un anuncio en redes sociales?". Esa cifra determina cuánto vale invertir en arquitectura.
Preguntas Frecuentes
¿Cuál es la diferencia entre hosting y despliegue?
El hosting es el lugar físico donde tu aplicación corre — servidores, redes y almacenamiento. El despliegue es el proceso de mover una nueva versión de tu código a ese hosting sin romper lo que ya funciona. Un negocio puede tener excelente hosting y aun así sufrir caídas si su proceso de despliegue es deficiente.
¿Qué es Kubernetes y mi negocio realmente lo necesita?
Según la documentación oficial, Kubernetes es una plataforma portátil, extensible y de código abierto para gestionar cargas de trabajo en contenedores. La mayoría de pequeños negocios no lo necesita. Está diseñado para aplicaciones que requieren múltiples servidores, autoescalado y orquestación compleja. Si tu sitio sirve menos de 100,000 visitas al mes, hosting más simple resuelve el problema con mucho menos costo y complejidad.
¿Qué es un despliegue blue-green y por qué importa?
Como describe Martin Fowler, el despliegue blue-green mantiene dos entornos de producción lo más idénticos posibles. Uno está activo (blue), el otro se prepara con la nueva versión (green). Cuando green pasa las pruebas, se cambia el enrutador y todas las solicitudes van a green. Si algo falla, se regresa el enrutador a blue. Permite revertir en segundos.
¿Qué son los feature flags?
Los feature flags son controles de software que activan o desactivan funciones sin desplegar código nuevo. Permiten lanzar una función a 1% de usuarios primero, luego a 5%, 20% y 100% — y si algo va mal en el 1%, se puede revertir al instante sin tocar el código de producción.
¿Qué significa realmente "99.9% de uptime"?
Un acuerdo de nivel de servicio (SLA) del 99.9% permite aproximadamente 8 horas y 45 minutos de caída al año. 99.99% permite 52 minutos. 99.999% permite poco más de 5 minutos. Cada nueve adicional cuesta exponencialmente más. La pregunta correcta no es "¿qué uptime ofrecen?" sino "¿qué tan caro es para mi negocio una hora de caída?"
"El hosting que pagas no determina si tu negocio se cae. El proceso de despliegue que usas, sí."
- Diego Medina F, Fundador de MerchandisePROS
Qué Significa Esto Para Tu Negocio
Si tu sitio se cae cada vez que tu desarrollador "sube cambios", el problema no es el hosting — es la ausencia de un patrón de despliegue. Si tu Core Web Vitals son lentos y los clientes abandonan antes de llegar al checkout, el problema tampoco es solo el hosting — es una combinación de configuración, código y proceso que requiere auditoría.
El servicio de Consultoría de Sitio Web de MerchandisePROS audita exactamente estos puntos: configuración de hosting, velocidad de Core Web Vitals, proceso de despliegue actual, riesgo de caída, y qué patrones (blue-green, feature flags, despliegues canary) tienen sentido para tu volumen real de tráfico. No instalamos Kubernetes solo porque sí. Recomendamos el patrón más simple que resuelve tu problema con la menor superficie de riesgo. Entregamos un reporte específico con la lista de cambios prioritarios — no una propuesta vaga de "modernizar la infraestructura".