Hoy desarrollaré un tema “intenso” y controvertido. Estoy seguro que a muchos les va a “picar” y otros estarán de acuerdo.

Explicaré por qué razón considero que la mejor sugerencia que puedo hacer es “No contraten hosting ¡Por Favor!” y qué implica eso.

No es que estoy en contra de los hosting, durante mucho tiempo lo he utilizado.

Pero cuando descubrí la libertad que permite contratar un VPS, entendí muchas cosas.

Entendiendo el contexto de fondo

Lo que desarrollaré a continuación no es un ataque a quienes proveen hosting (un servidor para muchos sitios webs diferentes), sino una reflexión sobre el contexto en el cuál es apropiado o no contratarlo u ofrecerlo.

Luego de exponer las razones técnicas, me referiré a las razones económicas que aquello implica.

Y finalmente una reflexión final uniendo ambas.

Cuándo un hosting es ideal

Considero que un hosting es ideal para demostrar el potencial de Internet para promover lo que ofrece nuestro cliente.

Un sitio web muy simple, el típico de presentación de un profesional u organización: Quién es, Qué hace u ofrece, Su historia, y Formulario de contacto. Lo más elemental.

En un servidor seguro, cuyos “vecinos” tienen un buen comportamiento (no son potenciales “spamers”, por ejemplo). Y con desarrollos que no tienen fallas de seguridad ni errores que puedan hacer caer al servidor.

Cuándo un hosting es seguro

Cuando:

Se tiene la absoluta certeza que lo almacenado como código es estable, con un mínimo de errores posibles (mejor si carece de ellos).

Se sabe que todos los dominios alojados en él, no serán potenciales generadores de SPAM.

Hay una absoluta certeza de “enjaulamiento” (o aislación) de los diferentes espacio contratados (los vecinos).

Y, mínimamente, tiene un monitoreo de “uptime” (tiempo en línea), “potencial issues” (potenciales problemas), y actualizaciones de seguridad junto a “upgrades”.

Cómo se logra lo anterior

Pues, éstas son todas “bondades” que se logran en un VPS (Virtual Private Server, Servidor Privado Virtual) administrado por nosotros mismos.

Si somos proveedores, como sugiere el artículo de referencia, podemos contar con al menos 2 VPS:
Uno para los proyectos que están bajo nuestra absoluta órbita…
El otro, pactado de antemano, que alojará los desarrollos de terceros y (en mi opinión) terminan siendo “tierra de nadie”.
Éste último es un “hosting”.

Pero, si vamos al caso práctico, ni vale la pena ofrecer un “hosting” excepto tengamos control de lo que se aloja. Y esto puede provocar resquemores en los potenciales clientes. Luego, si quieren control: ofrecer un VPS exclusivo donde puedan hacer lo que deseen sin romper nada ajeno.

¿Entonces el hosting no sirve?

No digo que “no sirva”, sino que es un modelo de negocio que se ve superado por la técnica y se sostiene por una razón económica y de comodidad.

Veamos los casos por separado:

Caso CLIENTE

Supongamos que contratan mis servicios para actualizar o desarrollar un sitio (no importa en este momento su complejidad). La primer pregunta que le hago al cliente es si tiene o no un servicio de hosting contratado.

Si la respuesta es afirmativa, me veo obligado a relevar las características técnicas del servicio (versión de PHP y las bibliotecas disponibles, Apache o NGINX, MySQL/MariaDB o Postgres, Procesador, RAM, Almacenamiento, Carga del servidor, etc.) para evaluar si lo que debo implementar funcionará o necesita alguna mejora o instalación adicional.

Y en este punto los conflictos pueden aparecer: que mi cliente no quiera pagar más, que el proveedor no colabore con la instalación de lo que sea necesario, o modificar la configuración de algún demonio o del php, por nombrar las más comunes; y ahí empiezan los problemas. ¿Quién es el responsable?.

Caso PROVEEDOR

Doy vuelta el tablero, y el cliente ahora es un diseñador o programador que quiere hacer el alojamiento de su proyecto y no le apetece liarse con montar un servidor.

Y ahí me veo reflejado en el caso anterior, tener que consultar los requerimientos de su desarrollo para satisfacerlos según su demanda y, esta es la parte importante, rogar que su código no tenga errores o fallas de seguridad.

¿Y qué fallas de seguridad podrían ser? La más peligrosa: el nefasto “copiar y pegar” código, armando un Frankenstein de siete cabezas que podría desde tirar abajo el rendimiento del servidor hasta utilizar bibliotecas en PHP nativo, Python o JavaScript ofuscado que hacen lo que necesitaba y, a cambio, deja puertas abiertas para vaya uno a saber que oscuros fines.

Y… Si. Que sea paranoico no descarta que me estén persiguiendo. Reza un popular refrán. ¿Qué haré entonces?¿Hacer un análisis forense de todo lo que suban? No es ni práctico ni comercialmente viable.

Aún haciendo ese trabajo descomunal de escudriñar el código, supongamos que está involucrado WordPress, ¿Cómo podríamos saber a ciencia cierta que instala inocentemente un plugin o theme malicioso? No tiene sentido.

¡Marche un VPS!

Tampoco es que sea tan liviano el asunto. Mantener un Servidor tiene sus puntos oscuros y complejos cuando la demanda empieza a subir.

Con esto digo que es pasar al siguiente nivel en la escala técnica del negocio.

Veamos sus ventajas

Siempre partiendo que somos proveedores tanto de un cliente final como de uno que a su vez resuelve a un tercero (mayorista):

Tener los proyectos aislados, unos de otros,
Por consiguiente, si un proyecto “rompe” o “afecta” el rendimiento del servidor, sólo ese proyecto se verá afectado y no todos los que comparten ese servidor,
Por lo tanto, el aislamiento del problema es más sencillo,
A su vez, más fácil de identificar la falla y resolverla, otra vez, sin comprometer otros proyectos.
Escalar los requerimientos según la necesidad concreta de cada caso, para más o para menos;
Poder hacer un seguimiento de rendimiento más preciso.
Si la IP se ve comprometida por el motivo que sea, sólo se verá afectado el proyecto de ese servidor y no todo el resto que la compartiría.
Es válido incluso, pensar en un servidor para cada “mayorista”, alertando esta novedad y que sea cauto con sus acciones porque puede afectar a sus otros proyectos. Y ahí estará nuestra experiencia y estrategia para aglutinar proyectos o no según su complejidad y requerimientos.

Y otras ventajas más sutiles, quizás…

Pero…

Siempre los hay, tiene su compromiso (que no es ni contra, defecto o desventaja):

Elegir un sistema operativo “estricto” que nos haga pensar antes de instalar algo. Mi elección es CentOS (áspero si se viene de una permisiva distribución Debian o sus derivadas) ,
Ordenar la instalación para no crear conflictos o errores de dependencias,
Llevar un registro de los pasos dados y convertirlos en un procedimiento de implementación que se sigue a rajatabla y se modifica según evoluciona el sistema operativo.
Realizar un hardening, es decir:
- configurar el firewall cerrando puertos que no se utilizarán,
- abriendo otros para poner los servicios en puertos no estándar (por ejemplo, correr el FTP del puerto 21 al 30021) y descartar ataques por fuerza bruta,
- configurar servicios de acceso remoto, como para la base de datos o SSH, con un límite de intentos seguidos,
- evitar que ciertos servicios no necesarios no se inicien con el sistema, preferentemente desinstalarlos si no tienen dependencias y se instalaron automáticamente.
Asegurar los accesos:
- Quitar al usuario root de los accesos remotos de todos los servicios (es de manual);
- Mover los puertos comunes a valores personalizados, como dijera antes;
- El nombre del usuario con posibilidad de escalar a root sea alfanumérico, largo y sinsentido aparente, con una contraseña alfanumérica, con mayúsculas, minúsculas, símbolos y una longitud considerable;
- Reducir la cantidad posible de intentos en un lapso mínimo de tiempo a valores sensatos y lógicos (3 intentos en 120 segundos, por ejemplo);
- Utilizar bloqueos de IP temporales por una hora, y permanentes luego de una cantidad de bloqueos temporales (3 bloqueos temporales y pasa a permanente);
- Tener reglas de fortaleza lo más sensatamente altas para las contraseñas de usuarios nuevos;
Tener un plan de actualización periódico; y para actualizaciones críticas, que sea automático;
Que ante determinados eventos de relevancia, el sistema informe vía correo electrónico (mínimo) la novedad para una acción inmediata.

Y la lista sigue, según el nivel de paranoia de cada uno.

¿Y esto cuánto me sale?

Esa es la pregunta que puede estropear un proyecto.

Si el cliente, final o mayorista, está buscando “precio” y nosotros queremos ofrecer “calidad”, nos metemos en una discusión que da para un artículo entero.

No se puede estar en la misa y en la procesión, por lo tanto hay que evaluar muy bien lo que se ofrecerá.

En mi hacer cotidiano, cambio la palabra “costo” por “inversión”. Y eso al cliente le cambia la visión. Pero hay muchos que sólo ven el número y no el alcance. Insisto, da para otro artículo.

En líneas generales, el hosting es mucho más barato desde el punto de vista monetario y operativo para el cliente. El “costo” para quien lo mantiene lo expuse antes.

El VPS exige una mayor inversión por parte del cliente; pero los beneficios son mucho mayores para ambos: el cliente tiene un incremento en “tiempo de servicio”, el proveedor mayor seguridad y estabilidad operativa.

Ya lo decía John Ruskin: “No existe casi nada en el mundo que un hombre no pueda hacer un poco peor y vender un poco más barato, y las personas que consideran sólo el precio son presa legítima de este hombre”.

Y la cita es más que oportuna. Sí, pongo en el banquillo de los acusados al “cliente”. Lo siento. Podemos estar de acuerdo en que no son “todos”; pero sí los que “nivelan para abajo”.

Participo en varios grupos en los cuales me sorprende una letanía recurrente y diaria: “Tengo problemas con mi proveedor X porque tengo tal problema. ¿Qué proveedor me recomiendan?”.

Aparecen sugerencias por doquier, basadas en experiencias personales en contra de X y a favor de uno nuevo. Curiosamente, ese nuevo, en algún momento fue acusado como X y ¿entonces?. ¿Se redimió? ¿Aprendió?… No lo sé. Pero pasa.

Conclusión

Es cierto que en los “negocios” el punto de la inversión es crítico.

También es cierto que a veces nos gana la ansiedad de dar lo mejor; pero el cliente no entiende el “business case” (caso u objeto del negocio) que implica “subirse” a Internet.

Es como que quiere tener una página completa en un diario local al precio de un octavo de hoja de un folletín barrial. Y sabemos que eso es poco probable, excepto tenga “letra chica” y “trampa”.

Esa “letra chica” se resume en:

Servidores compartidos saturados,
Servidores con poco mantenimiento técnico,
Instalaciones precarias, llenas de “por si acaso”,
Un “vecindario” poco controlado,
Reglas de uso laxas,
Un valor ridículamente bajo,
Poca profundidad en el análisis de la necesidad técnica,
Menor estudio del posible crecimiento de la demanda,
Etcétera, etcétera, etcétera…

Evalúen las necesidades reales de sus clientes, las reales de su solución, proyecten a conciencia…

Pero, por sobre todas las cosas: “¡No contraten hosting!”.

Agradecimiento

Hace unos años que entablé una constructiva amistad con Miguel García, un generoso e inmenso ser humano que me ha instruído, ayudado y colaborado para hoy poder escribir este artículo a conciencia.

Su artículo original, que me llevó a escribir éste, tiene ya 5 años y sigue vigente.

El presente no reemplaza aquél, sino que tiene la intención de actualizarlo y ampliarlo.

No contraten hosting ¡Por favor!