1 sept. 2011

El hardware costoso en las PYMES y la mala Arquitectura de Software


Salvo rarisimas ocasiones la compra de hardware costoso en las PYMES (Pequeñas Y Mediamas Empresas) es justificable, esto pasa mas comunmente cuando se adquiere un software mal diseñado y peor programado. En estos casos son los propios desarrolladores del sistema quienes sugieren la compra de un hardware 'moderno' que sea compatible a su sistema.

A continuacion relatare algunas experiencias de campo:


CASO 1

- En alguna ocasion visite un supermercado que apenas tenia 4 cajas, y algunos usuarios administrativos, dando un total de 10 usuarios en la red. La queja era: "El sistema es muy lento, a pesar de seguir las indicaciones del fabricante del software, sigue siendo muy lento". A este negocio lo hicieron adquirir las computadoras mas rapidas del mercado en esa epoca (3.2 Ghz & 1 Gb RAM) para las cajas y un servidor de marca conocida con bastante memoria y un buen procesador. Los cajeros se quejaban que incluso al vender, en el momento de escanear un producto tardaba un par de segundos en traer el resultado; a veces mas. El area de soporte tuvo la idea de aumentar la memoria al servidor lo cual por supuesto no mejoro absolutamente nada la situacion.


¿Cual era el problema?

En realidad era un problema bastante comun y facil de detectar para cualquier arquitecto de software, su manejador de bases de datos estaba basado en archivos (punto a punto) lo cual hacia que la busqueda de informacion y en general todo el motor de la base de datos se encontrara del lado del cliente (en las cajas), esto hacia que se trasladaran grandes cantidades de datos y el cuello de botella fuera la red, basta recordar que el limite que imponen las redes de 100 mbps (12 mb por seg.aprox) se distribuian entre los 10 usuarios. Por esto el aumentar la memoria del Servidor no servia de nada, ya que este se limitaba a compartir la carpeta donde se localizaban los archivos de la base de datos, asi que lo unico que hacia era 'prestar' el disco duro. Todo esto, con el costo en velocidad y seguridad que representaba.

Las unica sugerencias que se podia dar era:
   1) Cambiar el sistema por uno con arquitectura cliente-servidor
   2) Aliviar la situacion agregando una tarjeta de red al servidor y distribuyendo los usuarios entre ellas, y; si habia la posiblidad agregar un arreglo de discos (raid 0)



CASO 2

Una PYME con 10 usuarios en la red, 7 usando un software empresarial el cual esta bastante lento. La excusa de los 'expertos' fue la misma de siempre: "la base de datos es muy grande y son muchos usuarios". El administrador del sistema me muestra un servidor muy robusto, de marca reconocida incluso con sistema redundate (doble fuente de poder y doble tarjeta madre). Tenian reportes que se obtenian en 20 mins. A mi parecer ese servidor debia ser suficiente para dar servicio agilmente a 100 usuarios (con el software correcto).

En este caso el software si era cliente-servidor pero hacian un uso muy pobre del lenguaje SQL; en donde en lugar de enviar una consulta que obtuviera los datos desde todas las tablas que se requerian, relacionandolas adecuadamente. Para un solo reporte se enviaban centenares de consultas con el resultado ya descrito.

La solucion logica era pedirles al equipo de desarrollo optimizar sus consultas adecuadamente.



CASO 3 (Mi cliente)

Una comercializadora mayoristas con una pequeña red de 12 usuarios, funcionando alrededor de 9 años con una base de datos de poco mas de 1 gb., un Servidor HT 3.2, con 2 gb de RAM, Disco SCSI 2, Red 100 mbps. Todo iba bien hasta que el servidor empezo a fallar al encenderlo (se apagaba al final del dia y se encendia a las 5 am aprox. al iniciar operaciones). Para la revision del servidor les prestamos un equipo bastante modesto, era un equipo sin marca de los conocidos como 'clone' de apenas 1.8 Ghz y 512 de RAM.

Revisamos el servidor y se determino que el problema era que se perdia la configuracion de los dispositivos en el 'bios'; entre ellos el disco duro y por eso no podia arrancar, se cambio la bateria y funciono sin problemas. Despues de algunos dias de pruebas se devolvio al cliente y se regreso la base de datos.

Mi primer pregunta al gerente general fue si notaron que el sistema se volvio mas lento, a lo cual respondio que no hubo diferencia; por demas sorprendido fui a las cajas y pregunte a los usuarios y algunos indicaron que ni siquiera sabian que nos habiamos llevado el servidor.

En realidad yo esperaba que la diferencia no fuera grande, pero nunca imagine que a ese nivel de uso (10 usuarios) no se notara diferencia alguna. A la fecha fue el ultimo soporte tecnico a casi 2 años de ocurrido y las visitas posteriores han sido para agregar usuarios y funcionalidad al sistema.



 Mi Oficina

- En mi propia empresa hasta hace dias contabamos con un 'servidor' que adquiri seminuevo con uno de mis proveedores hace alrededor de 4-5 años, era una PC Pentium a 2.4 Ghz, 512 RAM y 40 Gb en disco , el cual mejoramos a 2 Gb de RAM y 250 Gb de disco. Esto era suficiente para tener instalado Windows Server 2008, SQL Server 2008, Sharepoint y por supuesto manejar nuestra base de datos empresarial (ventas, compras, inventarios, facturacion). Ademas nuestro pequeño servidor tenia instalado un sistema de vigilancia con 4 camaras, guardando la grabacion las 24 hrs en el mismo disco duro.
Equipo exacto que teniamos como servidor

Solo fue hasta hace dias que cambiamos a un servidor de 2 nucleos, y esto no fue motivado por necesidades de procesamiento, ni almacenamiento. Mas bien, se determino que despues de cambiar impresora laser y adquirir una mas a color, el unico equipo antiguo era el servidor y se planeaba aumentar el uso de el, instalando aplicaciones como Visual Studio Team Server.



CONCLUSIONES

Desde una optica tecnica muy simple; si una consulta a mi base de datos para obtener las ventas del dia (folio, cliente, importe, impuestos, condiciones de pago) me toma 30 ms y procesar 2 peticiones simultaneas de este proceso aumenta un 50% (1) el tiempo de ambas consultas  a 45 ms c/u, dando un total de 90 ms, aumentando exponencialmente con cada consulta simultanea que se procesa, supondria que con una decena de usuarios lo maximo que puede ocurrir es que todos ellos requieran una consulta al mismo tiempo, justo en el mismo segundo. En donde para tal caso obtener el resultado tardaria un par de segundos o unos cuantos a lo maximo.

Parece que ultimamente hacen falta arquitectos, hay muchos programadores, pocos son buenos y menos son buenos arquitectos. Creo que la comprension del hardware es lo que permite optimizar y generar aplicaciones que sepan aprovecharlo. Por otro lado, la mayoria se arroja a aprender un lenguaje de programacion, sin haber entendido antes la plataforma y filosofia en la cual estan basados.

Hasta ahora en las PYMES con datos muy 'relevantes' o con mayor transacionalidad la solucion que adoptamos para asegurar sus datos ha sido agregar un disco duro, al cual se acumulan un par de respaldos por dia, con lo cual en caso de perdidad total del disco duro en produccion,  se volverian a capturar los registros de ventas, compras, inventarios, cobranza, bancos, de medio dia de operacion, lo cual dificilmente supera el medio millar de transacciones distribuidos entre una docena de usuarios.

Por supuesto que aqui nos referimos exclusivamente al procesamiento de datos empresariales, puede haber excepciones, donde una PYME requiere procesador video, renderizar, o diseños arquitectonicos que justifiquen tal gasto. Dicho esto, hoy en dia los equipos 'basicos' disponibles en el mercado tienen una capacidad de procesamiento muy por encima a los requerimientos de la mayoria de las PYMES.

Cuando me consultan sobre los requerimientos de equipo para algun sistema de mi autoria, la respuesta tipica es: "el equipo nuevo mas pequeño en capacidad esta sobrado para los requerimientos" o "cualquiera que tenga windows XP y 512 de RAM".

No existe una regla para indicar el gasto maximo en equipos para un sistema, pero siempre desconfie de alguien que de entrada pide renovar todo el equipo. Recuerde: "UN SISTEMA DESARROLLADO CORRECTAMENTE REQUIERE MENOS EQUIPO YA QUE TRASLADA LA MAYOR CARGA DE PROCESAMIENTO AL SERVIDOR".


(1) El aumento de un 50% por cada consulta simultanea que se suma a la ejecucion, es un dato hipotetico.
 * Se omiten acentos intencionalmente.