Alojamiento en la nube frente a alojamiento web: cómo elegir

La mayoría de las empresas que comparan el alojamiento en la nube con el alojamiento web tradicional ya tienen su sitio web alojado en algún sitio y están tratando de decidir si merece la pena pasar por las molestias que supone el cambio. Esta guía compara ambas opciones en cuanto a gestión del tráfico, tiempo de actividad, responsabilidad en materia de seguridad y coste a tres años vista; explica paso a paso en qué consiste realmente una migración y te da razones para quedarte donde estás cuando esa sea la mejor opción.

En resumen: con el alojamiento tradicional, tu página web se aloja en un solo servidor. El alojamiento en la nube la distribuye por un clúster. El clúster gestiona mejor los picos de tráfico y los fallos de hardware. El servidor único es más sencillo, más barato en la gama baja y totalmente adecuado para un gran número de páginas web. La opción que te convenga dependerá de cuánto te cuesta una hora de inactividad y de lo irregular que sea tu tráfico.

¿El alojamiento en la nube es diferente del alojamiento web?

Verás que se presentan como dos cosas opuestas. Pero no lo son. El alojamiento en la nube es un tipo de alojamiento web, igual que un VPS es un tipo de alojamiento web. Nadie pregunta si quiere un sedán o un coche.

La comparación a la que la gente se refiere en realidad es entre el alojamiento en un único servidor y el alojamiento en un clúster de servidores. Esa es una distinción real con consecuencias reales, así que en el resto de esta guía usaremos «alojamiento tradicional» para los modelos de un solo servidor y «alojamiento en la nube» para los que están en clúster.

Si quieres que te expliquen la arquitectura subyacente en sus propios términos, incluida la diferencia entre la nube pública y la privada, empieza por lo que es el alojamiento en la nube y cómo funciona. Esta guía parte de esos conocimientos básicos y se centra en la toma de decisiones.

¿Qué se considera alojamiento web tradicional?

En esta categoría hay tres modelos. Se diferencian en el nivel de prestaciones que te ofrecen, no en si incluyen virtualización, ya que dos de los tres la utilizan.

Alojamiento compartido alberga muchas páginas web en un mismo servidor físico, compartiendo un conjunto común de recursos de CPU, memoria y disco. Los recursos no están reservados para ti, por lo que si una página vecina está muy cargada, puede ralentizar la tuya. Para una página web estática tipo folleto, un portafolio o un blog con poco tráfico, esa compensación suele estar bien y el precio lo refleja.

Alojamiento VPS divide un servidor físico en instancias virtuales aisladas mediante un hipervisor, cada una con su propia CPU, memoria y almacenamiento reservados, además de acceso de root. El rendimiento es más predecible que en el alojamiento compartido porque los recursos que se te asignan son solo para ti. El límite lo marca la máquina física subyacente: puedes ampliarte hasta el límite de ese servidor, pero no más allá.

El VPS te ofrece una opción de gestión que es más importante de lo que la mayoría de los compradores espera. Un VPS gestionado incluye un panel de control, y el proveedor se encarga de las actualizaciones del sistema operativo y de la seguridad. Un VPS no gestionado te deja todo el control en tus manos. La misma infraestructura, pero con una división del trabajo diferente. Nuestra guía sobre el alojamiento VPS gestionado frente al no gestionado explica dónde debería estar la línea divisoria para cada tipo de equipo.

Servidores dedicados te ofrecen una máquina física completa: procesadores de nivel empresarial, memoria ECC, almacenamiento RAID y control total, hasta la configuración de la BIOS y el kernel. No se comparte nada ni se abstrae nada. Eso hace que el rendimiento sea constante y que seas responsable de una máquina que no cuenta con copias de seguridad automáticas en caso de fallo del hardware.

¿En qué se diferencia el alojamiento en la nube?

El alojamiento en la nube ejecuta tus máquinas virtuales en un conjunto de servidores físicos, en lugar de en uno solo. Las diferencias prácticas se derivan de ese único cambio arquitectónico.

Cuando un nodo deja de funcionar correctamente, la plataforma puede trasladar tu instancia o poner en marcha una de sustitución en cualquier otro punto del clúster, en lugar de dejarte sin conexión a la espera de que llegue un técnico. Cuando necesitas más memoria, la capacidad ya está disponible en el pool, así que añadirla es tan sencillo como hacer una acción desde la consola, en lugar de tener que pedir más hardware. Cuando el tráfico llega de forma irregular, la carga se distribuye entre los nodos en lugar de concentrarse en uno solo.

Vale la pena comprobarlo en lugar de darlo por hecho: no todo lo que se vende como «alojamiento en la nube» incluye conmutación por error en clúster. Los servidores virtuales de un solo nodo suelen comercializarse bajo la misma etiqueta. Pregunta específicamente qué pasa con tu carga de trabajo si falla el servidor físico en el que se ejecuta.

¿En qué se diferencian el alojamiento en la nube y el alojamiento tradicional?

	Alojamiento web tradicional	Alojamiento en la nube
Arquitectura	Una máquina física	Grupo de máquinas agrupadas
Aumentar la capacidad	Cambio o migración de hardware	Acción en la consola, minutos
Fallo de hardware	Tiempo de inactividad hasta que se repare o se restablezca	La carga de trabajo se traslada o se reinicia en otro sitio
Picos de tráfico	Limitado por el techo de esa máquina	Absorbido en todo el cúmulo
Control del servidor	Limitado al control total	Control total del entorno
Modelo de costes	Cuota mensual fija	Tarifa por consumo o tarifa fija en planes gestionados
Alcance geográfico	Un único centro de datos	Hay varias regiones disponibles
El que mejor se adapta	Cargas de trabajo constantes y predecibles	Cargas de trabajo desiguales o cada vez mayores

¿Cuál gestiona mejor los picos de tráfico?

El alojamiento en la nube, y la diferencia es mayor justo en el momento en que más cuesta.

En un solo servidor, tu límite máximo queda fijado el mismo día que lo compras. Una campaña que va más allá de lo esperado, el lanzamiento de un producto, una publicación que se vuelve viral: todo esto se topa con un muro que no puedes ampliar mientras sigue llegando tráfico. El resultado habitual no es un fallo del sistema. Es que los tiempos de respuesta suben de 200 milisegundos a cuatro segundos, aumentan los abandonos en el proceso de pago y nadie se da cuenta de lo que ha pasado hasta que llegan los datos analíticos a la mañana siguiente.

La infraestructura en clúster gestiona eso de otra manera. La capacidad ya está disponible en el pool antes de que la necesites, la carga se distribuye entre los nodos y añadir recursos durante un evento es algo factible, no solo teórico.

La razón para optar por el alojamiento tradicional en este caso es clara: si tu gráfico de tráfico es prácticamente plano, esta ventaja te sirve de muy poco. La elasticidad es un seguro, y un seguro que nunca vas a usar no es más que un gasto.

¿Qué sigue funcionando cuando falla el hardware?

Los discos duros se estropean. Las fuentes de alimentación se estropean. Esto es algo habitual, no una excepción, y la diferencia entre los dos modelos está en lo que pasa después.

El alojamiento tradicional garantiza la fiabilidad mediante la redundancia dentro de un mismo servidor: matrices RAID que protegen el almacenamiento, y fuentes de alimentación y rutas de red redundantes en el centro de datos. Esto cubre los fallos de los componentes. Sin embargo, no cubre el caso de que el propio servidor se caiga, y la conmutación por error a un segundo servidor es algo que tienes que configurar y mantener tú mismo, si es que llegas a configurarlo.

Las plataformas en la nube incorporan la conmutación por error en su arquitectura. Cuando falla un nodo, el plano de control reasigna la carga de trabajo sin que nadie tenga que abrir un ticket.

Una aclaración sobre una idea muy extendida: la alta disponibilidad no es lo mismo que una copia de seguridad. La conmutación por error te mantiene conectado aunque haya un fallo de hardware. Pero no va a arreglar una implementación mal hecha, una tabla de base de datos que se haya borrado o un archivo comprometido. Para eso necesitas copias de seguridad de verdad, con su propia política de retención y su propio almacenamiento, separadas de la infraestructura que protegen. Los equipos que ven los clústeres como un sustituto de las copias de seguridad se dan cuenta de la diferencia en el peor momento posible.

¿Quién se encarga de la seguridad en cada uno de ellos?

Es aquí donde estos dos modelos suelen describirse de forma errónea, incluso por parte de los profesionales.

El alojamiento tradicional distribuye las responsabilidades según el plan que elijas. En el alojamiento compartido, el proveedor se encarga de casi todo, y eso es parte de lo que estás pagando. En un VPS no gestionado o en un servidor dedicado que gestionas tú mismo, las actualizaciones del sistema operativo, las reglas del cortafuegos, el control de acceso y la respuesta ante intrusiones son cosa tuya.

El alojamiento en la nube funciona según un modelo de responsabilidad compartida, y a menudo se malinterpreta cómo se reparten las responsabilidades. El proveedor se encarga de la seguridad de las instalaciones, el hardware y el hipervisor. Tú te encargas de la seguridad del sistema operativo, las aplicaciones, los datos y el acceso. La infraestructura en la nube no aplica parches a tu sistema operativo por ti. La aplicación automática de parches es un servicio gestionado, que se vende por separado o incluido en un plan gestionado, pero no forma parte de la arquitectura de la nube.

Esa distinción es la razón principal por la que los equipos en expansión acaban optando por una infraestructura gestionada. El trabajo de seguridad no desaparece cuando te pasas a la nube. Simplemente pasa a quien tú decidas que se encargue de ello.

¿Cómo se comparan los costes a lo largo de tres años?

El alojamiento web tradicional te cobra una tarifa mensual fija. Ya sabes cuánto es y lo pagas tanto si usas toda la capacidad como si no. El error más común es contratar más capacidad de la necesaria, ya que los equipos calculan su capacidad en función de un pico de tráfico que se da dos veces al año.

El alojamiento en la nube suele facturarse por consumo: la potencia de cálculo, el almacenamiento y la transferencia de datos se facturan como partidas separadas que varían de forma independiente. El coste inicial es más bajo, por eso suele ser la opción predeterminada para los proyectos nuevos. La transferencia de datos es la partida que más suele sorprender a la gente, porque es la más difícil de estimar antes de que haya tráfico de producción.

Hay un tercer modelo que conviene conocer: los precios fijos en la infraestructura en la nube. Los planes de nube privada gestionada incluyen la infraestructura, un límite de transferencia definido y el servicio de asistencia en una sola cuota mensual, a cambio de la posibilidad de pagar menos en un mes con poco uso a cambio de una factura que puedes prever.

Para ver el análisis completo de costes, que incluye datos de una encuesta sobre gastos inesperados en la nube y el umbral de utilización a partir del cual sale a cuenta la tarifa fija, echa un vistazo a nuestra comparación entre servidores en la nube, servidores dedicados y nube privada gestionada.

¿Qué lugar ocupa la nube privada gestionada entre ambas?

Los dos modelos anteriores te obligan a tomar una decisión que muchas empresas no quieren tomar. El alojamiento tradicional te da un hardware que nadie más toca y te pide que te encargues de gestionarlo. El alojamiento en la nube te ofrece flexibilidad y te sitúa en una infraestructura compartida con una factura que varía.

La nube privada gestionada existe porque ese intercambio se puede evitar. Funciona con mecanismos de nube, virtualización, agrupación de recursos y aprovisionamiento bajo demanda, todo ello en hardware reservado para un solo cliente y gestionado por el equipo técnico del proveedor.

¿Qué cambia esto en la práctica?:

• Tu carga de trabajo se ejecuta en un hardware que no compartes con ningún otro cliente, así que la competencia por recursos procedente de fuera de tu organización no es un factor a tener en cuenta.
• El tamaño de las máquinas virtuales se puede ajustar sin necesidad de pedir nuevo hardware, así que el aumento de capacidad es un cambio programado y no un proyecto de migración.
• La aplicación de parches, la supervisión, las copias de seguridad y la respuesta ante incidentes son responsabilidad del proveedor, así que las responsabilidades de seguridad que se han descrito antes no recaen en tu equipo por defecto.
• El precio es una cantidad fija mensual que incluye la infraestructura, el límite de transferencia y la asistencia técnica.

InMotion Cloud utiliza este modelo en hardware que es propiedad de InMotion y que gestiona la propia empresa, y te atiende directamente un ingeniero sénior desde el primer contacto, en lugar de tener que pasar por una cola de tickets de primera línea.

¿Qué pasa realmente cuando te pasas al alojamiento en la nube?

Esta es la parte que la mayoría de los artículos comparativos se saltan, y suele ser en lo que se basa la decisión.

Una migración tiene cuatro fases, y el riesgo se concentra en una de ellas. Te cuento que una migración tiene cuatro fases, y el riesgo se concentra en una de ellas.

Preparación. Haz un inventario de todo lo que se ejecuta en el servidor actual: la web, las tareas cron, los webhooks, el correo electrónico, los certificados SSL y cualquier integración que apunte a tu dirección IP. Una tarea cron olvidada es la clásica sorpresa que te puedes llevar tras la migración.

La gestión del DNS. Aquí es donde se gana o se pierde el tiempo de inactividad. Los resolutores de DNS almacenan tus registros en caché durante el tiempo que les indica el TTL, así que un TTL de 24 horas significa que algunos visitantes seguirán conectándose al servidor antiguo durante un día entero después de que hayas hecho el cambio. La solución es reducir el TTL con antelación, y hay que hacerlo con suficiente tiempo para que los valores antiguos almacenados en caché caduquen primero. La documentación de DNSCloudflare recomienda reducir los TTL con al menos 24 a 48 horas de antelación, a ser posible igualándolos a tu valor actual más largo. Nuestra guía de migración de DNS te ofrece un plan por etapas que reduce los TTL progresivamente durante la semana previa al cambio.

Migración. Copia los datos en dos pasos: primero, una transferencia masiva con antelación; después, una sincronización delta en el momento del cambio. Deja el servidor antiguo en marcha y sin tocarlo. Cambia el registro A. Observa cómo se traslada el tráfico.

Verificación y reversión. Prueba las cosas que pueden fallar sin que te des cuenta: el proceso de pago, el inicio de sesión, la subida de archivos, el envío de correos electrónicos y las tareas programadas. Como el servidor antiguo sigue activo y el TTL aún es bajo, la reversión consiste simplemente en un cambio en el DNS, en lugar de una operación de recuperación.

Dos notas sobre el alcance. No cambies los servidores de nombres y el alojamiento en la misma sesión; los dos tienen un comportamiento de almacenamiento en caché diferente y solucionar problemas en uno mientras el otro está en marcha es un lío que puedes evitar. Y si el correo electrónico está en el mismo servidor, hazlo por separado, porque los sistemas de correo almacenan en caché y vuelven a intentarlo de formas que son menos flexibles que el tráfico web.

InMotion incluye asistencia para la migración en lugar de venderla como un servicio profesional aparte, y los planes de InMotion Cloud incluyen soporte para la migración de equipos que provienen de AWS, Azure, Google Cloud, VMware o entornos locales.

¿Cuándo conviene seguir con el alojamiento web tradicional?

A veces, la respuesta correcta es que ya tienes el alojamiento adecuado.

• Tu tráfico se mantiene realmente estable. La elasticidad que nunca utilizas es una función por la que estás pagando y de la que no te beneficias.
• La web es solo informativa. Una web con folletos, un portafolio o la web de un negocio local con un formulario de contacto no necesita una infraestructura en clúster.
• El tiempo de inactividad te cuesta muy poco. Multiplica una hora de inactividad por lo que realmente cuesta. Si esa cifra es pequeña, la necesidad de contar con redundancia es proporcionalmente menor.
• Con un solo servidor dedicado ya basta para la carga de trabajo. Las aplicaciones estables y con un alto nivel de utilización suelen funcionar de forma más eficiente y económica en hardware dedicado que en una configuración equivalente en la nube.
• Ahora mismo no tienes capacidad para hacer una migración. Una migración mal hecha sale más cara que el problema que se supone que debía resolver. Esperar a que haya un momento adecuado es una decisión totalmente válida.

¿Qué tipo de alojamiento se adapta mejor a tu negocio?

El alojamiento tradicional es ideal para pequeñas empresas con necesidades predecibles, sitios web estáticos y de carácter informativo, y cargas de trabajo constantes de alta utilización que caben perfectamente en un solo servidor.

El alojamiento en la nube es ideal para tiendas de comercio electrónico en las que el tiempo de actividad se traduce directamente en ingresos, para aplicaciones con cargas variables o estacionales, para equipos que necesitan activar y desactivar entornos, y para usuarios repartidos por distintas regiones en las que la proximidad del servidor influye en el tiempo de respuesta. InMotion cuenta con centros de datos en Virginia, California y Ámsterdam.

La nube privada gestionada es ideal para empresas en crecimiento que quieren hardware dedicado y una factura predecible sin tener que contratar a administradores de servidores, para equipos a los que ya les queda pequeño un servidor dedicado y buscan flexibilidad sin perder aislamiento, y para organizaciones que dejan un hiperescalador porque la factura dejó de ser predecible.

Tomar la decisión

Hay dos preguntas que te lo aclaran más rápido que una comparación de características.

¿Cuánto te cuesta una hora de inactividad? Esa cifra determina cuánta redundancia merece la pena contratar. ¿Qué grado de irregularidad tiene tu tráfico? Eso determina cuánta elasticidad merece la pena contratar. Si ambas respuestas son bajas, el alojamiento tradicional está cumpliendo su función y cambiar sería un gasto sin retorno.

Si ambas respuestas son relevantes, la siguiente pregunta es quién se encarga de la infraestructura. El alojamiento en la nube traslada el problema del hardware a tu proveedor y te deja a ti a cargo del sistema operativo, la seguridad y la supervisión.

Si buscas hardware dedicado, la flexibilidad de la nube y una cuota mensual fija sin que nadie tenga que encargarse de la administración de servidores, esa combinación es precisamente para lo que se creó InMotion Cloud, con el respaldo del hardware y la red que InMotion lleva 25 años gestionando por su cuenta.

¿No sabes muy bien en qué lado de la línea estás? Habla con nuestro equipo y compararemos tu configuración actual con lo que realmente necesitas.

Preguntas frecuentes