¿Comprar un servidor, alquilarlo o usar la nube? Decidir aplicación por aplicación

Cuatro modelos que las ofertas deben distinguir claramente

Comprar un servidor significa, en principio, ser propietario de un equipo. Puede estar en su propia sala de equipos o en un centro de datos con costes de alojamiento físico. La electricidad, los repuestos y todo el ciclo de vida siguen necesitando organización. Comprar puede tener sentido para cargas constantes a largo plazo, pero inmoviliza capital y exige expectativas realistas de capacidad y vida útil.

Con un servidor dedicado alquilado, un proveedor facilita la máquina física. El contrato especifica con qué rapidez se sustituyen los componentes averiados, qué soporte existe y si se administra el sistema operativo. Un servidor virtual, en cambio, comparte una plataforma física con otros sistemas. Su rendimiento garantizado y los límites del paquete deben encajar con la aplicación.

La nube puede referirse a esas máquinas virtuales, pero también incluye bases de datos gestionadas, almacenamiento de objetos y servicios orientados a aplicaciones. La diferencia es, por tanto, algo más que un pago mensual. Afecta al trabajo técnico que realiza usted y al que realmente asume el servicio. Un término comercial como «gestionado» no responde a esa pregunta sin una descripción concreta del servicio.

Seis preguntas antes de la primera comparación de precios

• ¿Cómo es la carga? El uso interno constante, los picos estacionales y los proyectos temporales necesitan reservas diferentes.
• ¿Dónde se generan los grandes conjuntos de datos? Si se procesan vídeos a diario en la oficina, el recorrido hasta la capacidad de cómputo importa tanto como la propia capacidad.
• ¿Qué debe seguir funcionando si se corta internet? Escriba de forma concreta los flujos locales esenciales.
• ¿Quién opera el sistema? La disponibilidad, las sustituciones del personal y los conocimientos forman parte de la decisión.
• ¿Cuánta interrupción y pérdida de datos se toleran? Esto determina las copias de seguridad y la recuperación.
• ¿Cómo se podrán extraer después los datos y la aplicación? Exportación, formatos, identidades y reconstrucción deben funcionar conjuntamente.

Documente las respuestas para cada aplicación. Un servicio de archivos, un sistema de gestión empresarial y un portal público suelen tener requisitos diferentes. Trasladar los tres por el mismo motivo puede pasar por alto una dependencia local o pagar por una flexibilidad que un servicio de funcionamiento constante no utiliza.

Una matriz de decisión con contraargumentos reales

Pondere los criterios solo después de completar la ficha de requisitos. Si una máquina de fabricación debe seguir trabajando cuando se interrumpe internet, es una condición obligatoria, no una puntuación baja dentro de una clasificación general. Entre las opciones restantes pueden equilibrarse esfuerzo, coste y adaptabilidad. Una clasificación matemática no debe ocultar la falta de idoneidad.

Tres aplicaciones, tres decisiones posibles

Primer ejemplo: un estudio de diseño maneja archivos de proyecto grandes casi exclusivamente en una ubicación. En las pruebas, transferir datos a servicios remotos es el mayor factor de tiempo. Podría encajar un servicio local de archivos con una copia externa restaurable de forma independiente. Esto requiere una sala adecuada, mantenimiento y un plan de sustitución. La decisión cambiaría si el equipo pasara a trabajar principalmente desde ubicaciones distribuidas.

Segundo ejemplo: un portal público de reservas tiene picos irregulares y un pequeño equipo interno de TI. Una plataforma gestionada de aplicaciones con base de datos puede asumir tareas, siempre que el software esté diseñado para ella. Deben comprobarse los costes por reserva, la exportación de datos y los límites del servicio. Un servidor virtual de tamaño constante funcionando las veinticuatro horas también sería nube, pero no aprovecharía automáticamente esta oportunidad.

Tercer ejemplo: una aplicación interna funciona de manera estable con una demanda bien conocida. La empresa no quiere mantener una sala de servidores, pero dispone de un proveedor para el sistema operativo y la aplicación. Un servidor dedicado alquilado o un servidor virtual con garantías adecuadas puede mantener un esfuerzo manejable. Aun así, hay que comprobar la recuperación real, la conectividad de los empleados y el alcance contractual de la sustitución del hardware.

¿Quién se ocupa de actualizaciones, copias y recuperación?

Para EC2, AWS asigna al cliente, entre otras cosas, el sistema operativo invitado y la aplicación instalada. El proveedor opera la infraestructura subyacente. La división cambia con otros servicios. Aplique este principio a cada oferta y pida que se identifique la responsabilidad en cada capa. AWS: modelo de responsabilidad compartida ↗

Una buena ficha operativa identifica un rol responsable del hardware, sistema operativo, base de datos, aplicación, acceso de usuarios y copias de seguridad. También contempla sustitutos, tiempos de respuesta y procedimientos de cambio. Evite expresiones como «probablemente lo hace el proveedor de alojamiento». De lo contrario, el vacío solo aparece cuando hay que restaurar una base de datos y cada parte responde únicamente de un fragmento.

RTO describe la duración objetivo de recuperación; RPO, la pérdida de datos tolerable expresada en tiempo. Estos objetivos se derivan del negocio. Por ello, la documentación de AWS distingue entre la disponibilidad de componentes individuales y la recuperación de una aplicación completa tras un fallo grave. AWS: planificar la recuperación ante desastres ↗

La flexibilidad tiene valor; los compromisos tienen consecuencias

Un entorno de pruebas que puede apagarse con poca antelación no necesita adquirirse con el mismo cálculo que una base de datos que funciona durante años. AWS describe distintos modelos de precios para cargas variables, uso a corto plazo y compromisos de uso más largos. Un compromiso puede reducir costes, pero solo si el uso prometido se produce realmente. Un descuento no sustituye una previsión de demanda. AWS: adaptar el modelo de precios a la carga ↗

Para cada opción solicite un cálculo con los mismos volúmenes de datos, tiempos de funcionamiento, plazos de conservación y tareas de soporte. Calcule también un mes de mayor demanda y el final del contrato. Los sistemas propios deben incluir sustitución del hardware; los servicios externos, exportación, transferencia y reconstrucción. Un precio de entrada aparentemente bajo puede verse de otro modo al considerar todo el periodo.

Demostrar la portabilidad con una pequeña prueba de exportación

Un botón de descarga no demuestra que sea posible cambiar de sistema. En una prueba, exporte un conjunto representativo de datos con la configuración necesaria e impórtelo en otro entorno independiente. Compruebe si se conservan relaciones, permisos, adjuntos y marcas de tiempo. Para una aplicación, esto también incluye el esquema de la base de datos, los servicios necesarios y la correspondencia de cuentas de usuario.

Mida también la duración. Una exportación hipotética de 2 TB mediante una conexión con 100 Mbit/s efectivos disponibles tarda unas 44.4 horas solo en transferirse, usando unidades decimales. A ello se añaden preparación, comprobaciones e interrupciones. Puede ser aceptable para trasladar un archivo, pero no para una recuperación rápida. Por tanto, la posibilidad de exportar y la de recuperar necesitan pruebas separadas.

Decidir con un piloto limitado

Elija una aplicación representativa y pruebe la opción preferida en condiciones realistas. El piloto necesita criterios medibles definidos previamente: tiempos de respuesta con un número acordado de usuarios, copia de seguridad completa, recuperación dentro del objetivo y un informe mensual de costes comprensible. Defina también cómo volver atrás antes de trasladar datos de producción.

Después de la prueba, registre la decisión en un documento breve: modelo elegido, responsabilidades asumidas, supuestos de coste, limitaciones aceptadas y próxima revisión. La mejor arquitectura es la que el equipo puede operar con fiabilidad y cambiar más adelante. Puede ser un modelo diferente para cada aplicación, siempre que las transiciones y responsabilidades permanezcan claras.