Cómo elegir hosting para una aplicación ASP.NET con SQL Server

Fije tres datos antes de comparar precios

Casi todas las malas decisiones de alojamiento en este escenario vienen de comparar precios antes de conocer los requisitos. Con tres datos en la mano, la mayoría de los planes se descartan solos.

• La versión del entorno de ejecución con la que compila su aplicación: .NET Framework 4.x o una versión concreta de .NET y ASP.NET Core.
• El motor y la versión de la base de datos, y si depende de características propias de SQL Server.
• El tamaño que tiene hoy la base de datos y el que va a tener en doce meses.

La versión del entorno de ejecución es el primer filtro

.NET Framework y .NET moderno no son intercambiables. Una aplicación en .NET Framework 4.x necesita Windows con IIS y no se ejecuta en un plan Linux. Una aplicación en ASP.NET Core puede ejecutarse en Windows o en Linux, pero el plan tiene que ofrecer la versión concreta que usted usa, y las versiones dejan de recibir soporte con el tiempo.

Hay un matiz que ahorra discusiones: si publica su aplicación como autocontenida, lleva su propio entorno de ejecución y depende menos de lo que el proveedor tenga instalado, a cambio de un paquete de despliegue más grande. Si publica dependiendo del entorno de ejecución compartido del servidor, la versión instalada por el proveedor pasa a ser un requisito duro. Conviene decidir esto antes de contratar, no después.

• Pregunte qué versiones están instaladas hoy y con qué criterio se actualizan.
• Confirme si puede seleccionar la versión del grupo de aplicaciones desde el panel.
• Si su aplicación es heredada, compruebe que la versión antigua sigue admitida y no solo tolerada.

La base de datos decide el plan más que la aplicación

En hosting compartido, el código suele caber sin problema; la base de datos es lo que se queda corto. Dos límites concretos importan más que cualquier otra cifra del plan: el tamaño máximo de cada base de datos y cuántas bases de datos puede crear. El primero define cuánto tiempo puede crecer el proyecto; el segundo define si puede tener un entorno de pruebas separado.

También conviene comprobar si SQL Server está incluido en el plan o se cobra como complemento, porque eso cambia el coste real. Y si su aplicación usa características que no todos los planes exponen —trabajos programados en el motor, procedimientos que requieren permisos elevados, o restauración de un respaldo completo—, pregúntelo antes: es más fácil cambiar de plan que reescribir la capa de datos.

• Tamaño máximo por base de datos, y qué ocurre exactamente cuando se alcanza.
• Número de bases de datos incluidas, pensando en un entorno de pruebas.
• Si puede restaurar un respaldo completo propio, y por qué vía.
• Si puede conectarse desde una herramienta de administración externa, y desde qué direcciones.

Cómo va a desplegar, y cómo va a volver atrás

El despliegue es la parte que se usa todas las semanas, así que conviene verificarla antes de contratar. Los planes compartidos de Windows suelen ofrecer FTP, FTPS, Web Deploy y, en algunos casos, despliegue desde un repositorio de código. Cualquiera de esas vías sirve; lo que no sirve es descubrir después de pagar que la única opción es subir archivos a mano.

La pregunta que casi nadie hace es la de volver atrás. Antes de contratar, decida cómo va a deshacer un despliegue que sale mal y dónde van a estar las cadenas de conexión y las claves: en el panel del proveedor como configuración de la aplicación, no en un archivo de configuración subido al servidor.

• Vías de despliegue disponibles y si se pueden automatizar.
• Cómo se revierte una versión, y si el proveedor conserva la anterior.
• Dónde se guardan las cadenas de conexión y quién puede leerlas.
• Si existe un entorno de pruebas separado o hay que crearlo como segundo sitio.

Los límites que obligan a cambiar de plan

Un plan compartido es una repartición del trabajo: el proveedor administra el servidor y usted acepta sus reglas. Esas reglas se notan en tres sitios. El grupo de aplicaciones puede reciclarse tras un periodo de inactividad, lo que hace lenta la primera petición siguiente. No hay acceso de administrador, así que no se instalan dependencias del sistema ni servicios propios. Y los procesos en segundo plano de larga duración no son un buen encaje: si su aplicación necesita un trabajador continuo, ese trabajador quiere otro producto.

Nada de esto hace que el hosting compartido sea mala opción. Lo convierte en una opción con un techo conocido, que es exactamente lo que conviene saber antes de pagar un año por adelantado.

• Reciclado del grupo de aplicaciones y su efecto en la primera petición.
• Sin acceso de administrador: no se instalan componentes del sistema.
• Tareas programadas y procesos en segundo plano: pregunte qué admite el plan.
• Crecimiento de la base de datos: el límite que llega primero.

El coste real del primer año

La tarifa que aparece destacada suele corresponder a contratar varios años por adelantado, y la renovación casi siempre cuesta más que el primer periodo. Para comparar dos planes de verdad hay que calcular el total del primer pago y el total de la renovación, con impuestos, y sumar los complementos que su caso necesita.

• Importe total del primer pago, con el plazo que lo justifica y los impuestos aplicables.
• Precio de renovación del mismo plan, que es el coste sostenido.
• Complementos que su proyecto necesita de verdad: base de datos adicional, certificado, copias, correo.
• Plazo de reembolso o prueba gratuita, para poder salir si la aplicación no funciona como esperaba.

Cuándo un plan compartido deja de ser la respuesta

Hay tres señales claras: necesita fijar versiones del sistema, necesita ejecutar contenedores, o necesita un proceso permanente además del sitio web. En cualquiera de los tres casos, la conversación correcta es sobre un VPS o una plataforma cloud, y el criterio de decisión cambia: deja de ser el precio del plan y pasa a ser quién asume la administración del servidor.

Esa administración es trabajo real y recurrente: actualizaciones del sistema, copias de seguridad verificadas, renovación de certificados y supervisión. Si nadie de su equipo va a hacerlo, un plan administrado más limitado le va a dar mejor resultado que un VPS desatendido.