2. El desafío
Anterior |  | Siguiente

## 2. El desafío

El desafío principal para Argentina.Com es alcanzar un tiempo de vida para el servicio de acceso telefónico a redes de al menos 99.95%, o menos de 5 horas de caídas al año. Debido a la alta rotación y volatilidad que existe en este negocio, las cosas deben funcionar correctamente para que el usuario no cambie -voluntariamente o no- de proveedor de acceso a internet o de número de teléfono utilizado para conectarse. El negocio del “dialup”, como se le conoce en su denominación inglesa, requiere una estructura de soporte para tratar con las grandes operadoras de telecomunicaciones problemas telefónicos y de calidad de servicio, junto con una infraestructura técnica donde la latencia y la pérdida de paquetes deben minimizarse debido a la naturaleza UDP de los servicio de Radius y DNS, y donde el DNS recursivo debería estar siempre disponible.

Esto tambíen implica tener un tiempo de vida alto en los servicio de POP3 y SMTP, junto con el servicio de webmail. Para POP3 y SMTP se estimó la necesidad de “uptime” igual que para el servicio de “dialup”, mientras que para el servicio de webmail se pensó en un porcentaje de 99.5%, lo que significa alrededor de dos dias por año sin servicio o de caída.

Decidimos migrar el correo a una solución propietaria de código abierto que debería ser horizontalmente escalable y cuyos sistemas antivirus y antispam pudieran soportar más de un único tipo de “backend” o de almacenamiento de correos.

La feroz competencia en el mercado del correo electrónico gratuito, principalmente iniciada por las recientes mejoras introducidas por Hotmail, Yahoo! y Gmail, hacían necesario diseñar el nuevo sistema con al menos 300M de espacio de usuario en disco para cada usuario, pero a un coste inferior a 3 dólares americanos por GB incluyendo cierto grado de redundancia. Hay que tener en cuenta que el hardware que puede disponerse en “rack” es difícil de encontrar en Argentina y que resulta ser entre un 30 y un 40% más caro que en los EEUU. Nuestro líquido financiero para adquisición de equipos en dos años fue de 75.000 dólares americanos, lo cual es una fracción muy pequeña de las inversiones acometidas por nuestros competidores directos.

Respecto al servicio antispam, era necesario desarrollar un producto que pudiera competir con los sistemas ofrecidos por los grandes. Dadas las hostiles condiciones que impone la existencia del spam (ataques de diccionario, spams con alto grado de ofuscación y refinamiento, “phishing”, troyanos, correos-bomba, etc.) resulta muy complicado alcanzar tiempos de “uptime” excelentes y al mismo tiempo repeler dichos ataques. Uno debe también ser cuidadoso para que el usuario no pierda correos debido a falsos positivos en la estrategia de clasificación, para que no se le inunde con spam o notificaciones de spam y para que el correo peligroso no alcance la carpeta de entrada de los usuarios. Por último, el sistema de correo debe protegerse para que los “spammers” no lo utilicen en su provecho para enviar spam.

El paradigma del código abierto normalmente requiere la adquisición de grandes equipos de administradores de sistemas, operadores y programadores que se encarguen de aplicar parches, corregir “bugs” e integrar plataformas. El paradigma opuesto es también costoso debido a las caras licencias de software, la necesidad de hardware cada vez más caro y debido al elevado número de empleados encargados de proporcionar soporte. Así que el desafío era encontrar la mezcla correcta entre recursos monetarios y humanos escasos, alta estabilidad y grado de predicción, y un desarrollo rápido y fiable. En Buenos Aires resulta difícil encontrar profesionales de las ciencias de la computación bien entrenados, la mayoría de los cuales viven y trabajan en el extranjero, mientras que los restantes poseen trabajos estables dentro de las instituciones del gobierno o en grades compañías.

Anterior |  | Siguiente
Argentina.com : Un estudio de caso | Inicio | 3. La solución FreeBSD

Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista <questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.