Como cada año, ayer 15 hice un análisis de mi modelo de negocio y proveedores. Decidí compartir lo relevante, y quizá escriba más sobre esto en las próximas semanas, explicando cómo terminé involucrado en el hospedaje web y los problemas que he observado en México desde 1995 hasta hoy, divididos por etapas y con sus puntos en común además de los problemas de recurso humano técnico/comercial que puede contratarse en México. Me preocupa especialmente que, a los 19 años, estaba más preparado para enfrentar problemas reales que muchos graduados en sistemas hoy en día. Tengo 53. Sí, hay términos nuevos, pero no saben reconocer problemas cuando los tienen enfrente.
De momento, mi servicio es de PROGRAMADOR/DEVOPS que por lo general deriva en muchos casos a darles o manejar formalmente sus servidores cuando salvo a los clientes de un desastre. Si quieren. La segunda vez que les falla la plataforma de host no aceptan un consejo me quito de en medio después de explicar por escrito su problema. (ejemplo 2023 posible cliente «profesional técnico» (según el), lo hackean y me insulta cuando le digo que es porque tiene debian 7 y un apache de 2015) y que hay que empezar por cambiarlo de server. Y no es raro que acabe haciéndome cargo de sus servidores, por razones de confiabilidad y precio. Con un cliente del 2012 ahora manejo sitios de 14 razones sociales suyas. No solo de la que tuvo el problema.
Desde el año pasado, he notado una reducción en el número de proveedores viables para varios proyectos de Misión Crítica. Tener servicios Managed (con apoyo adicional 24 horas del proveedor)en la nube es ideal cuando cuentas con personal que realiza actividades Managed (si es necesario )mientras tú descansas o duermes.
Usaré iniciales, aunque «He» podría ser Hostinger, pero no lo es.
Todo empezó En 2023, el proveedor K no respondió en dos días a una ampliación que necesitaba. Por el tipo de ampliación, mis opciones se reducían a O, He y S. El proveedor O maneja spammers, lo cual no era una opción. He no tiene presencia en la zona geográfica que necesito. Así que mi elección era entre dejar K y probar S, o migrar a He. Opté por probar S.
Tras cambiar a S, empecé a notar problemas de rendimiento con el ballooning, es decir, menos memoria de la que estaba pagando. Lo validé desde una docena de servidores y en sitios web externos. De repente, tres sitios propios y los monolitos dejaron de responder, alrededor de las once de la noche. Envié un correo para reportar el problema, pero dos horas después decidí regresar a K, a pesar de haberlo dejado por la falta de respuesta a la ampliación. Sé que S es un revendedor de He, pero al mismo tiempo es un moderador influyente en un foro importante de hospedaje web. Cuando S empezó a reclamarme por preguntar en dos lugares mas si alguien tenia problemas, yo había movido la información. No podía dejar a los clientes siete horas fuera. El pensaba que si. No dio explicación de causa. Solo me reclamó a mi (se restableció según el pero yo ya no estaba en ese server). Mientras tanto yo estaba de regreso en K y levanté de manera pública el pedido de cancelación de servidores. Ese proveedor S, por la suma de las circunstancias ya lo considero un peligro y no permitiría que un nuevo cliente se encuentre allí. Y si quiere estar ahí para siempre el cliente, no entraría al proyecto. No puedo hacerme responsable de un proveedor que falla de esa manera. Ballooning, agresividad y falta de soporte. Contratas soporte (managed), no pretextos ni reclamos después de siete horas.
Aproximadamente en agosto del año pasado 2024, tuve un incidente medianamente serio con un proveedor S. No contestó en siete horas. Tuve que activar mi plan de respaldo y migrar varios Terabytes, volviendo al punto de partida de un año y medio antes. Siempre he intentado manejar tres proveedores.
Para mi tipo de operación y volumen, especialmente por mi política de respaldos diarios, Amazon y Azure resultan excesivamente caros. Es como si fueran un método para hacer que no puedas irte. Para quienes manejan menos volumen, hay otras opciones, pero muchos eligen lo malo y conocido. Godaddy, por ejemplo, es terrible en hosting y sus reglas de dominios pueden hacer que pierdas el control de tu dominio si alguien, con mala intención, presenta cierto tipo de denuncias. Hace unos años, hubo un reporte y un contra-reporte (no me ocurrió a mí) en el que le detuvieron el servidor a una persona por no responder en 17 segundos a la queja original. Sí, segundos. Así de irracionales son. Además, su rendimiento es infame. Eso no es ser estricto. Es simplemente un error de criterio que es muy peligroso cuando eres un proveedor que maneja información crítica. Y no puedes permitir que tu propio proveedor haga eso.
El tráfico web de algunos de mis clientes es orgánico, ya que sus propios clientes los buscan, no depende de una estrategia de marketing digital, que a mi parecer es un negocio absurdo e imposible. Tal como vamos, con el auge de las LLM que cometen errores y la desaparición de información y foros especializados, nos acercamos al resurgimiento de un internet basado en servidores propios en múltiples ubicaciones, en lugar de la nube centralizada. Los proveedores medianos ya no son tan confiables. Lo que antes llamaban servidores dedicados.
Las soluciones intermedias que prosperaron de 2012 a 2024 están decayendo. Desde mediados de este año, solo me quedan dos opciones reales: Vultr y K (si sigue siendo funcional). En caso de emergencia, He. Sin embargo, la solución más sensata es que si el cliente tiene oficinas en México o Guadalajara, use Vultr como replicador, pero con el hosting principal en su propia planta. Como tercera opción, se podría tener un espejo reducido en Vultr.
El problema no es solo la falta de proveedores, sino el ballooning y la falta de personal experimentado. En ocasiones, he tenido problemas con Liquidweb y otros proveedores que estuvieron a punto de borrar información sin justificación. O el caso de Wiredtree que, siendo una de las marcas más reconocidas a nivel mundial, perdió entre el 80% y 90% de sus clientes en dos semanas. Por suerte, me di cuenta al segundo día y migré a tiempo.
Hay otras opciones como Vultr que se pueden usar bien, pero no son managed. Sin embargo, para clientes más pequeños, no son tan críticos. Lo que observo es una decadencia generalizada en el servicio que desactiva a los proveedores, y eso me pone en una situación difícil. No económicamente, sino en términos de encontrar soluciones fiables. No se trata de decir que «el kali yuga ha empezado», pero sí que cada vez será más difícil para los nuevos técnicos y DevOps evitar las nubes de Amazon o Azure, que son demasiado caras, de costo variable y que crean mas problemas y riesgos que beneficios para el tamaño de las soluciones que se manejan en México para empresas medianas. El año que viene será interesante.
Escribiré otro mensaje pronto acerca del mercado mexicano (en el que estoy desde 1999 mas o menos) y porqué la necesidad de servicios managed.