A la hora de alojar tu web/aplicacion en internet deberás plantearte una serie de cosas:
¿Es mi aplicación ligera?
No es lo mismo una aplicación que haga cosas sencillas y sea capaz de servir cientos de peticiones por segundo, que un CMS/CRM que pueda atender en el mismo hardware 1 ó 2 peticiones por segundo.
¿Cuántos usuarios reales va a tener desde que se lance y como van a crecer estos durante los primeros dos años?
No te tires a la piscina por ser excesivamente optimista. Tampoco seas un rata. Si los planes más optimistas dicen que el primer año vas a tener 50 mil usuarios, y se trata de un número de usuarios controlados (no es una aplicación pública que pueda hacerse viral y crecer descontroladamente), intenta no dimensionar para dar cabida a un millón. Es más importante conocer de antemano la respuesta a la pregunta 3.
¿De qué forma escala mi aplicación?
Consulta con el diseñador/programador como puede escalar la aplicación. ¿Soporta separar sus servicios en distintas capas? ¿Puedes en un momento poner frontales web adicionales y no tener problemas con la gestión de sesiones, por ejemplo? Saber como escalar la aplicación puede evitarte morir de éxito o tener un plan para responder a un crecimiento inesperado de la base de usuarios.
¿Has hecho pruebas de carga de la aplicación? ¿Se han detectado slow queries SQL?
¿Desde dónde va a acceder la gente a esta aplicación?
Si tu clientela va a ser mayoritariamente de México por ejemplo, no te interesa un datacenter lejano. Servir a sudamérica desde Europa te da 200 ms de latencia en las comunicaciones, que se añaden a CADA paquete tcp, tanto en ida como en vuelta. Medio segundo es perceptible, creeme.
Si tu aplicación va a ser principalmente accedida desde Europa, busca hosting en Europa, si es para América, búscalo en Miami o Dallas, si es en Asia, busca en Korea o Singapur. Otra opción, si tu aplicación es global y ya tiene un número de usuarios interesante, es crear euro.midominio.com, america.midominio.com y asia.midominio.com y redirigir a la gente a base de DNS, Anycast. Hay muchas opciones.
¿Qué política de backups tienes? Has probado a simular una restauración completa y ver si tus backups valen de algo?
Tener tu infraestructura en un sitio super fiable y seguro solo te da la mitad de seguridad. Poder recuperarla en caso de que caiga un meteorito o la empresa quiebre de un dia para otro, es la otra mitad de tu tarea. Monta temporalmente en otro sitio una pequeña replica de lo que tienes en producción y prueba a ver si una restauración hace que todo sea funcional. Recuerda que tus backups deberían ser siempre offsite para evitar la desgracia del meteorito 😉
¿Cuándo utiliza la gente tu aplicación?
Debes identificar claramente las horas pico y valle de uso de tu aplicación, sobre todo si funciona en unos horarios comerciales definidos comerciales. Puede que tus 30 usuarios al día de media se conviertan en 120 constantes durante 8 horas. Esto impacta directamente en el dimensionamiento de tu plataforma.
¿Quién va a poder acceder a la aplicación?
Aunque las medidas de seguridad siempre hay que aplicarlas, puedes ser algo menos restrictivo si tu aplicación es solo accesible a los clientes via VPN, por ejemplo. Si todo internet va a poder husmear en tu aplicación tienes muchas mas posibilidades de que alguien te haga una inyección SQL o encuentre alguna vulnerabilidad en el codigo.
¿Quién va a mantener la aplicación?
Se trata de un proyecto con «entrega de llaves y nos olvidamos»? Quien va a parchear los bugs que salgan? Quien va a adaptar la aplicación para adaptarla a los cambios que impongan revisiones de seguridad o actualizaciones de sistema operativo? (Ej: Quien va a cambiar el código PHP para que esas funciones de php 5.3 que ahora son deprecated sean compatibles con php5.5?)
¿Quién va a mantener/parchear/actualizar el sistema operativo?
Mantener al día los equipos exige estar pendiente de listas de correo con avisos de seguridad, estar al día de vulnerabilidades y conocer bien tu plataforma. ¿Quien va a estar pendiente de esto? ¿Quien monitoriza tus sistemas?
¿Quién va a mantener el hardware?
Si tu servidor es tuyo en propiedad y lo envías en colocation a un datacenter (pagas por el espacio, alimentación y conectividad), deberás tener presente que una avería de disco duro la pagarás tú, y vas a ser tú quien tenga que comprar un disco de reemplazo para enviarlo (pagando los portes) allí para su reemplazo. Si una fuente de alimentación pega un petardazo y quema la placa, va a ser tu problema y estarás caído el tiempo que tardes en reemplazar la placa o el servidor completo.
Recomendaciones para elegir un hosting web
Si tu página es ligera o estática (solo html o php muy ligero) puedes irte perfectamente a un hosting web compartido. El problema es que cuando uno funciona bien, suele correrse la voz y acabar saturado a los pocos meses (morir de éxito). Por ejemplo, hace un tiempo te habría recomendado Red Coruña, sin embargo de unos meses para acá solo leo cosas malas de ellos.
Dentro del hosting dedicado de servidores, existen los administrados y no administrados.
Servidores dedicados administrados:
Delegas la administración del equipo a personal de la empresa de hosting. Suelen cobrar lo mismo que un dedicado + una cuota mensual. Si eliges esta opción revisa si el SLA que te ofrecen cumple tus expectativas. Asegúrate también de si son ellos quien hacen backup y restore de todo. Si hay ataques de hackers o de denegación de servicio, es tarea suya solucionarlo, aparte de prevenirlo de forma proactiva, claro.
Esta opción puede resultar interesante por el ahorro de tiempo a posteriori. Depende de si es admisible que los empleados del hosting tengan acceso a tu aplicación / datos, aunque debes recordar que son profesionales que si hacen algo raro se juegan su puesto de trabajo…
Servidores dedicados no administrados:
Tu administras y monitorizas el equipo. Reserva tiempo para ello cada semana y refléjalo en la cotización que pases a tu cliente. El servidor es alquilado, así que si alguna pieza se rompe (normalmente discos duros o fuentes de alimentación), el hoster te lo reemplazará. Busca un servidor que disponga siempre de controladora RAID hardware con batería, así como de doble fuente de alimentación. Pagas un extra pero te cubres ante fallos eléctricos potencialmente dañinos para tus datos.
En este caso tú gestionas tus planes de backup y restauración. Es la opción que más me gusta, pero absorbe tiempo.
Servidores virtuales:
Por experiencia, las plataformas virtuales suelen estar sobresuscritas. Un hoster de cloud juega con que el uso de sus servidores virtuales no suele estar en el 100% para provisionar más CPUs o memoria virtual de la que disponen. No es raro ver que servidores físicos con 16 CPU se encuentran ejecutando servidores virtuales que suman en total 60 CPUs virtuales. Depende del criterio del administrador (y de quien maneje los presupuestos de compra) del cloud cuanto se sobresuscribe. Si tu aplicación es muy intensiva con disco o con CPU, ten presente que el rendimiento que vas a obtener de tu servidor virtual no va a ser siempre el mismo. ¡Cuenta con ello!
No por esto las plataformas virtuales son poco recomendables, pero su mejor destino es aplicaciones dinámicas que escalen en función del uso de forma dinámica. Por ejemplo, mi aplicación está pensada para escalar horizontalmente añadiendo equipos simplemente, y voy a programar que se lancen 20 instancias small de Amazon a las 7 de la mañana y se apaguen a las 18, ya que fuera de esas horas no las usa nadie.
No uses cloud tipo Amazon como si fuesen un dedicado. Sale caro, carísimo. Mantener una instancia medium de Amazon encendida 24/7 puede costarte lo mismo que un servidor dedicado con 10 veces la potencia que la instancia de AWS.
En todos los casos, puedes tener mala suerte de las siguientes formas:
- Te asignan una dirección IP de alguien que en el pasado la habia utilizado para hacer el mal.
- Has contratado soporte pero resulta que no es 24/7. Te encuentras con una llamada avisando de que el servicio está caído y no puedes hacer nada porque no estás dentro de la ventana de servicio de la empresa de hosting.
- Ejemplo: Estas en un hosting y te dan la dirección IP 1.2.3.4. Hace 6 meses, el cliente Spam Brothers SL tenia un servicio que enviaba correo masivo alojado en este hoster y desgraciadamente esta ip está en muchas listas negras. Es posible que tengas que pedir que te la cambien por otra limpia.
- Te asignan una dirección IP de alguien que en el pasado era objetivo de muchos ataques.
- Ejemplo: Hace tiempo la SGAE tenia una subpágina alojada en este hoster, en la ip que te han dado. Hay algun hacker empanao que no se ha dado cuenta de que la SGAE ya no está en esa IP y empieza a lanzar ataques a esa ip antigua, sin darse cuenta de que ahora es tuya…
- Alguien que comparte hosting contigo es objetivo de un ataque de denegación de servicio y te ves afectado.
- Ejemplo de daño colateral DoS (Denial of Service) de aplicación: La empresa Aluminios Manolo aloja una web en una infraestructura compartida contigo, un hosting web de los baratos. Su rival Aluminios Pepita quiere tumbarle la web tras observar que el buscador de su pagina la ralentiza a poco que se envíen 3 consultas simultáneas (probablemente por búsquedas mal diseñadas o falta de índices en algunas tablas). El caso es que ponen un script a realizar 50 búsquedas concurrentes en la web de Aluminios Manolo y le saturan la aplicación/CPU. Tu compartes esas CPUs y probablemente veas tu web afectada.
- Ejemplo de daño colateral DoS (Denial of Service) de red: Alguien envía 50 gigabit por segundo de tráfico de red mediante un ataque de amplificación DNS y satura la conexion a internet de tu hoster. Esto es más probable cuanto más pequeña sea la empresa que aloja tu servicio.
- En un hosting dedicado te asignan un servidor que alguien dio de baja porque le daba problemas, y no lo han testeado bien. No es la primera vez que leo que a alguien le dan un servidor dedicado con un disco duro que falla cada X tiempo, o que experimenta errores de memoria de cuando en cuando.
- En un cloud te toca un servidor físico que está más saturado que otros, o cuyos «habitantes» hacen un uso de recursos más intensivo. Tu mejor opción es pedir que te muevan a otro servidor físico. Suelen hacerlo.
- El mayor problema que suelen tener plataformas compartidas, cloud en especial, es el IO, o rendimiento del almacenamiento. Monitoriza el IOWait para ver si estás teniendo problemas de contención en el almacenamiento.
Un sitio interesante donde leer mucho sobre opiniones y ofertas es:
http://www.webhostingtalk.com (versión en inglés)