Cliente servidor: ¿una solución o un mito?

El crecimiento de la base instalada de PC operada a partir de su aparición, junto con el desarrollo y estandarización de las redes de área local, abrieron un mundo de posibilidades a la computación nunca antes vista.

El proceso es muy largo, pero sin duda el hijo pródigo de este fabuloso abanico de posibilidades fue la arquitectura cliente servidor. El mensaje fue: «pongamos a cada equipo a hacer lo que mejor hace». Lo natural del planteo, y el énfasis de prácticamente todas las empresas del mercado en ser parte de este modelo (una fiebre parecida a la que hoy provoca la santa trinidad: Internet, Intranet, Extranet) hacían preveer un éxito rotundo y arrasador. En pocos años desaparecerían los centros de cómputos con sus añejos dinosaurios, para ser sustituidos por legiones de pequeños servidores dedicados a tareas específicas, accedidos por clientes inteligentes, que les dejarían las tareas más pesadas, para realizar ellos las tareas menos importantes.

Pero la arquitectura cliente servidor no consiguió resolver de forma definitiva dos grandes problemas: en primer lugar la distribución dinámica de la carga y en segundo lugar la administración de los sistemas.

Distribución dinámica de la carga

El modelo original cliente servidor, tenía como una de sus premisas, la inteligencia de cada uno de sus integrantes para darse cuenta de que una tarea es demasiado pesada, y su habilidad para derivarla a un servidor, que debería tener más capacidad para ello. Esto debía realizarse en forma automática y sencilla.

Mas allá de las numerosas soluciones aportadas a este problema, ninguna fue lo suficiente buena como para dejarlo definitivamente cerrado, y la muestra elocuente de ello es por un lado el tamaño abultado de los PC cliente, y por otro el infinito proceso de configuración y tuning de los sistemas y aplicaciones para que la performance sea medianamente aceptable.

La promesa de la arquitectura cliente servidor de una distribución de la carga de trabajo entre los distintos equipos que componían el sistema en forma dinámica y transparente, nunca dejo de ser eso: una promesa.

La administración de los sistemas

Cliente servidor es una arquitectura esencialmente distribuida, en todos los sentidos, incluida la administración. La seguridad, los respaldos, las configuraciones, se transformaron de una tarea centralizada, en una interminable recorrida cliente por cliente.

Nuevamente, a pesar de los esfuerzos gigantescos de todos los proveedores por aportar soluciones de fondo a este problema, todavía hoy no hay una estrategia satisfactoria.

La instalación de un protector de pantalla puede dejar a un PC cliente fuera del sistema. El respaldo de los datos almacenados en los clientes, depende de los clientes y lo que es peor, de los usuarios de los clientes, y en la mayoría de los casos, la instalación de mejoras o nuevas versiones implica modificaciones en todos y cada uno de los clientes.

Network Computing, el legado del Cliente Servidor

Hoy en día, la industria de la computación muestra varias tendencias en auge que hacen prever el cumplimiento de la promesa original de la arquitectura cliente servidor.

Primero, la moda del downsizing ha dado paso al resurgimiento de los centros de computos a la vieja usanza: las grandes corporaciones aprendieron que un equipo grande, sea este un Mainframe, un AS/400 o un gran equipo UNIX, es más seguro, confiable y facil de administrar que cientos o tal vez miles de servidores distribuidos por todos los departamentos de la empresa. Con esto nació un nuevo segmento de mercado: Server Consolidation.

Segundo: la omnipresencia de los browsers y la aparición de un standar universal que deja atrás el problema de los sistemas operativos, las plataformas y las incompatibilidades: las tecnologías vinculadas a Internet: tcp/ip, html, etc.

Tercero: Java, y mucho más allá de java, el concepto de applet: la primera tecnología real y eficiente para almacenar aplicaciones centralmente y ejecutarlas distribuídas en cualquier plataforma.

¿Que promete la computación en red?

Mas allá de la fiebre por Internet y el soporte para Java, que en muchos casos no es más que un deseo de no quedar fuera que la moda, sin llegar a la comprensión cabal de lo que ésto significa, se vislumbra en un horizonte cercano, el advenimiento de toda una familia de aplicaciones y soluciones que permitan un uso más racional y confiable de los recursos.

Si asumimos que cualquier PC tiene un browser que soporta Java, puedo entonces hacer realidad el viejo anhelo: almaceno centralmente datos y aplicaciones y ejecuto distirbuido. Los cambios, configuraciones, administración y seguridad se manejan centralizados, en el servidor. En tiempo de ejecución, y según lo que el programador halla decidido, el applet hará uso de los recursos del equipo en el que corre o de los del servidor.

La distribución de la carga sigue siendo un problema no resuelto definitivamente, pero las herramientas son más poderosas. Las modificaciones a programas y configuraciones no requieren trabajo en cada PC cliente. Alcanza con modificar los applets y la proxima ejecución los cambios cobrarán vida.

Es la vuelta a los orígenes, pero en un plano superior: las ventajas de la arquitectura Mainframe-Terminal tonta con las facilidades de un entorno gráfico y de las aplicaciones tipo PC.

Cliente delgado vs. NETPC vs. PC, una falsa disyuntiva

Los actores de esta transformación tienen obviamente intereses, y en la mayoría de los casos no son coincidentes. Por ejemplo: si bien la disyuntiva Java – ActiveXparece saldada en favor del primero, Microsoft contraataca con COM, abriendo nuevamente el debate. Es necesario ver más alla de los intereses de cada uno de los jugadores, para ver la importancia de cada una de las tecnologías.

En una instalación compleja, mídala en cientos de puestos de trabajo, cientos de miles de transacciones o metros de cables de red instalados, las aplicaciones resuelven desde la edición de textos hasta las tareas de misión crítica (transacciones en linea, actividades contra público, tareas en tiempo real, etc.), pasando por el correo, la interconexión con otras instalaciones y una infinidad de tareas.

La clave del problema no está en discutir si el cliente delgado va a tener o no diskettera, si se va a poder ampliar la memoria, o si es necesario que Java sea interpretado o ejecutado por un chip. La clave es que determinadas aplicaciones: las de misión crítica, las que involucran a toda la empresa (productividad no-personal), las de alto impacto en la seguridad, van a migrar a la arquitectura de computación en red. El resto, fundamentalmente la productividad personal, tareas que involucran grupos pequeños, etc. se conservarán como hasta ahora.

Todos los equipos, desde la Network Computer, pasando por la NETPC, hasta la estación de trabajo más potente, pueden jugar el papel de cliente delgado si la aplicacion a correr así lo requiere, y es el applet que se baja del servidor el que va a determinar el comportamiento de la aplicación en todos los sentidos. ¿Que importa entonces si el equipo tiene cero, cuatro o diez slots?

El Rey ha muerto ¡Viva el Rey!

Detrás de las bondades de la tecnología cliente servidor, se escondía una horda de enemigos de los «dinosaurios», que repetían a quien quisiera oirlo: todo problema se puede resolver con una cantidad suficiente de PC. La vida mostró que que esto no es cierto. ¿No estaremos frente a una nueva horda que opina que todo problema se resuelve con una cantidad suficiente de applets?