Introducción

Desde hace un tiempo se viene escuchando hablar de TCO. El término es utilizado generalmente en el ámbito de gestión y control de proyectos como una medida del costo real de un proyecto. En este artículo daremos una mirada al tema desde un punto de vista un poco distinto, intentando responder a la pregunta de qué significa esto de TCO para el administrador de tecnologías.

¿Qué es TCO?

TCO significa “Total Cost of Ownership” (Costo Total de Propiedad), y consiste en una metodología desarrollada a fines de los años 80 por Gartner Group en un esfuerzo para controlar los crecientes costos involucrados en la administración de la infraestructura de tecnología en las empresas. La premisa fundamental de TCO es que los costos iniciales directos de cualquier proyecto son solo una pequeña parte de los costos totales del mismo. En esta metodología se indica que además de estos, existen costos iniciales indirectos, además de costos posteriores directos e indirectos. Veamos brevemente en que consisten estos tipos de costos.

Los costos directos son aquellos que derivan de manera directa de la ejecución del proyecto. En esta categoría tenemos ítems como compra de hardware y software, salarios, etc. En general, los costos directos son relativamente simples de cuantificar.

En contraste, los costos indirectos tienen una relación más lejana con el proyecto, lo que los hace más difíciles de cuantificar. Se encuentran en esta categoría ítems como pérdida de productividad, tiempo de aprendizaje de una nueva plataforma o tecnología, dificultades para mantener la infraestructura del proyecto, etc.
Los costos iniciales son aquellos en que se incurre al momento de iniciar un proyecto, tales como la compra de hardware, mientras que los posteriores ocurren durante el desarrollo y/o explotación del mismo, tales como las mantenciones de hardware. Los costos posteriores pueden clasificarse adicionalmente en puntuales y recurrentes dependiendo de si ocurren solo una vez, o si aparecerán frecuentemente en el proyecto.
Pero suficiente de palabrería y vamos al grano. ¿Qué significa para todo esto para el administrador de sistemas?

El papel de la administración de sistemas

Al igual que en cualquier proyecto, en un proyecto de tecnología se dan todos los tipos de costos mencionados, y los sistemas que soportan la tecnología requieren de algún grado de administración que tiene un costo. Este costo debe ser incorporado al proyecto con el fin de evaluar de manera correcta y realista la viabilidad del mismo.

La selección de la plataforma tecnológica sobre la que desarrollar un proyecto es uno de los puntos que mayor impacto tiene sobre el costo total del proyecto, ya que además de cubrir buena medida de los costos iniciales del mismo, tiene un efecto significativo sobre los recursos que serán necesarios para administrar el sistema. Sin embargo, dados los montos involucrados en la puesta en marcha de dichas plataformas, no es poco frecuente que los costos de administración sean considerados como un tema menor en comparación con los costos de adquisición. Esta última postura ha llevado a muchas empresas a construir soluciones en base a software open source por su tremendamente atractivo costo inicial sin evaluar correctamente el proyecto, obviando los costos escondidos u ocultos que esta práctica pueda llegar a tener.

En la práctica…

Veamos un par de ejemplos de proyectos que se pueden realizar con tecnologías open source como una alternativa a las soluciones que utilizan Windows Server System, y veremos como el tema de costos iniciales no conlleva los ahorros espectaculares que una mirada superficial exhibe.

Autenticación integrada

Una de las funcionas más requeridas en cualquier ambiente informático con más de 1 persona y 1 equipo es la capacidad de hacer uso de un mismo conjunto de credenciales de autenticación en cualquier sistema de la red, ya se trate de dos puestos de trabajo, acceso a una intranet o un sistema de gestión integral. Windows Server System proporciona esta funcionalidad por medio de Active Directory, que en su mas reciente encarnación en Windows Server 2003 R2 incorpora la capacidad de autenticar equipos y usuarios en sistemas UNIX, dejando finalmente atrás una de las mas serias desventajas que tenía la plataforma para operar en ambientes multiplataforma.

Por su lado, buena parte de la funcionalidad de Active Directory puede ser proporcionada utilizando herramientas open source, lo que evitaría incurrir en los costos de licencias de Windows Server, CAL, software assurance, etc. Pero veamos un análisis más detallado para tener el cuadro completo antes de decidir.

Active Directory

La implementación de Active Directory tiene algunos costos iniciales directos, tales como licencias de Windows Server, CAL de Windows Server (si no alcanzara con las incluidas con la licencia de servidor). También está el costo indirecto que involucra el tiempo de instalación. Una instalación básica de Windows Server 2003 con Active Directory toma entre 1 y 3 horas, dependiendo de una serie de factores, pero es un proceso sumamente simple y con muy pocas posibilidades de error. Una estructura más compleja que involucre múltiples sitios, una topología de replicación compleja, unidades organizacionales, etc. puede tomar un par de horas más en su implementación (en cada servidor), además de un par de semanas en el diseño de una buena estructura de Active Directory. Se pueden encontrar algunos consejos para el diseño de una estructura Active Directory en el sitio de Microsoft Technet.

Luego de ser instalado, Active Directory es sumamente simple de administrar con las herramientas incluidas en Windows Server, o con herramientas de terceros. Por ejemplo, un usuario puede ser creado en unos pocos minutos en cualquier servidor Active Directory, y el sistema replicará esta información automáticamente a los demás servidores. Similar es la situación con grupos de usuarios, unidades organizacionales, equipos, etc., o con modificaciones y eliminaciones de los mismos.

Los diferentes componentes de Windows Server System tienen la capacidad de autenticar usuarios con Active Directory y otorgar permisos en base a esta autenticación, lo que permite el objetivo planteado de poder usar el mismo conjunto de credenciales en cualquier recurso, ya sea una estación de trabajo, una aplicación web, una aplicación cliente en .Net, una base de datos, correo electrónico, etc.

LDAP+Kerberos

Estos protocolos, utilizados en Active Directory, están disponibles para múltiples plataformas open source, y proporcionan las herramientas para implementar un esquema de autenticación integrada de similares prestaciones a Active Directory. En pro de la brevedad no nos extenderemos en los detalles de cómo implementar un esquema de este tipo, pero diremos que se encuentran en Internet múltiples documentos tipo HOWTO que indican como hacer esto, los que generalmente involucran configurar un servidor LDAP (OpenLDAP), un KDC de Kerberos, las librerías PAM y NSS apropiadas, instalación y configuración de clientes LDAP y Kerberos en los equipos de la red. Y todo esto es para un esquema simple, equivalente a un servidor con Active Directory. Si se agregan requerimientos de mayor complejidad, se hace necesario utilizar herramientas comerciales, o hacer modificaciones sustanciales a las herramientas descritas. Una de las funcionalidades principales de Active Directory que no es posible replicar con un esquema de este tipo son las modificaciones en modo multi master. OpenLDAP admite estructuras distribuidas, pero solo en modo master slave, con lo que un problema en el equipo master implica la pérdida de todas las funciones que realizan modificaciones, tales como cambios de password, creación de usuarios, etc.
Experiencias prácticas en la implementación de soluciones de este tipo indican que el tiempo de implementación de una solución simple no es inferior a 3 días. Finalmente, no se debe dejar de destacar que el esquema propuesto permite solo la autenticación de equipos sobre LDAP y Kerberos puros, no existiendo un cliente de este tipo para equipos Windows. Para poder incorporar equipos Windows a un ambiente de este tipo hay que agregar componentes adicionales para emular controladores de dominio Windows NT, y no Active Directory.

Una vez instalado, este esquema de autenticación requiere de administradores considerablemente más preparados, ya que las herramientas disponibles suelen ser bastante crudas, requiriendo de la preparación de archivos en formato LDIF, uso intensivo de herramientas de línea de comando con gran cantidad de parámetros, y pocos controles de sanidad de los mismos, lo que da una alta probabilidad de error humano. Si se trata de un esquema distribuido con múltiples servidores de autenticación, todos los equipos deben tener configurado cual es el equipo maestro sobre el que realizar operaciones de escritura, tales como cambio de claves. Esta información deben saberla también los administradores de este sistema, ya que la creación de usuarios, grupos, etc. solo se puede hacer en el servidor master.

Finalmente, no todas las herramientas open source (o propietarias) que se pudiera requerir en un ambiente de este tipo soportan directamente este sistema de autenticación, por lo que hay que configurarlas específicamente para hacer uso de este, no siempre con los resultados más ideales. Por ejemplo, el servidor web Apache puede hacer uso de LDAP como plataforma de autenticación (con un módulo a tal efecto, mod_auth_ldap), o de kerberos (mod_auth_kerb) si se requiere de un sistema más seguro. Sin embargo, ambos mecanismos no son simples de implementar, y mod_auth_kerb no está incluido en el software base. La situación de otros programas es más compleja, habiendo algunos que requieren ser configurados para usar PAM y otros que definitivamente no ofrecen soporte para integrarlos en este mecanismo de autenticación “integrada”.

Mensajería

La mensajería es probablemente la funcionalidad más utilizada por los usuarios de computadores en el mundo, tanto en el hogar como en oficinas. Es tal el nivel de uso de la mensajería, que hay empresas que proporcionan equipos para usuarios que sólo los necesitan para tener correo electrónico. Por este motivo se ha seleccionado una plataforma de mensajería segura como el siguiente caso de análisis.

Exchange Server/Outlook

Muchas de las características discutidas para Active Directory son aplicables también a Exchange. Lo más relevante de la plataforma para efectos del tema que nos ocupa es el hecho que incluye funcionalidad de correo electrónico, agenda personal y compartida, calendario, etc. en un solo sistema completamente integrado, así como las herramientas necesarias para administrar la plataforma. Además de esto, incluye la capacidad de hacer uso de la plataforma ya sea con una aplicación cliente (Outlook) o a través de un navegador.

Las mejores prácticas establecidas por Microsoft para una plataforma Exchange segura dicen que se debe disponer de al menos un servidor front end al que se conectan los usuarios, y un servidor back end que almacena los mensajes, bases de datos de usuarios, configuración, etc. La comunicación entre ambos se establece de manera segura sin necesidad de instalar programas o componentes adicionales, y la conversión de uno a otro rol se lleva a cabo de manera simple y rápida.

La instalación de una plataforma Exchange Server, consistente de un servidor front end y un servidor back end toma unas 4 a 5 horas de tiempo. Si el sistema crece y se hace necesario agregar un nuevo servidor back end, el tiempo es de 2 a 3 horas, ya que toda la información de configuración para el nuevo servidor se encuentra almacenada en Active Directory.

Respecto a la administración del sistema, la plataforma incluye las herramientas necesarias para hacer todas las tareas, incluyendo la administración de cuentas, de manera muy simple, lo que permite delegar muchas de estas tareas en personal con menor grado de preparación. Adicionalmente, muchas de estas tareas han sido integradas con la administración de Active Directory, lo que permite una mayor simplicidad en las mismas.
Finalmente, cuando aparece alguna vulnerabilidad en Exchange Server, ésta es solucionada por Microsoft, y dicha solución se entrega a los administradores luego de un proceso exhaustivo de pruebas, lo que hace muy rara la ocurrencia de problemas al aplicar parches al sistema en producción. Adicionalmente, todos los parches para Exchange Server son anunciados en un conjunto reducido de canales, lo que facilita su seguimiento.

Postfix+LDAP+etc.

Para implementar una solución de similares prestaciones utilizando open source existen una serie de programas que es necesario integrar de maneras muy específicas. El primer paso en una implementación consiste en seleccionar cada uno de estos componentes. Por ejemplo, se puede utilizar diferentes programas para administrar los protocolos de correo electrónico, tales como qmail, postfix, etc. Lo mismo ocurre con los demás componentes como la base de datos de usuarios (LDAP, MySQL, PostgreSQL, etc.), el sistema de autenticación, la interfaz web, etc. La diversidad de herramientas es enorme, por lo que veremos solo una alternativa, pero las demás son similares en complejidad.

Para poder implementar una arquitectura similar a la descrita en las mejores prácticas que separe el front end del back end, se necesita primero una base de datos de usuarios en el back end (OpenLDAP) y un servidor NFS en el back end, y luego los programas de correo (postfix, courier-imap) y cliente NFS en el front end. La comunicación entre el front end y el back end debe ser encriptada para evitar problemas de seguridad. Una alternativa es utilizar OpenSSL, pero este mecanismo solo sirve para comunicar con el servidor LDAP en el back end. Para asegurar el protocolo NFS sería mejor hacer uso de IPSec, que es otra pesadilla de configuración en ambientes open source.

Luego está la interfaz web, la que también debe residir en el front end, y comunicarse con el back end, ya sea directamente o a través de otros programas que residen en el mismo front end, siendo sujeto de las mismas consideraciones de seguridad en la comunicación antes descritas. La comunicación entre los clientes y el front end también debe ser asegurada. Todos estos canales de comunicación debe ser asegurado desde ambos extremos, lo que implica una gran cantidad de puntos en que algo puede salir mal, y que es necesario revisar cuando esto ocurre.

En un sistema como el planteado, el rol de un servidor como front end o back end queda definido por los componentes de software instalados en éste, por lo que el cambio de rol involucra prácticamente instalar el servidor nuevamente.

Experiencias prácticas en la implementación de una solución de este tipo han entregado tiempos de entre 3 días y 2 semanas para su puesta en marcha, considerando solamente la implementación, y obviando el diseño del sistema. La instalación de un servidor back end adicional es un proceso bastante laborioso, ya que además de instalar los distintos componentes de software, es necesario configurarlo manualmente, además de configurar los front end con la existencia del nuevo servidor back end para que puedan hacer uso de sus recursos.

La administración de esta pesadilla es otra pesadilla por si sola. La carencia de herramientas integradas sofisticadas hace que sea necesario el uso intensivo de comandos con una infinidad de opciones y parámetros. Cuando se encuentra un problema, es necesario revisar cada componente del sistema por separado, así como los canales de comunicación entre los mismos. Un sistema como el descrito es de tal complejidad, que a menos que este se encuentre documentado con sumo detalle, la ausencia de quien lo haya diseñado y construido puede derivar en una catástrofe de proporciones colosales para el sistema y la organización que lo utiliza.

La aplicación de parches para resolver vulnerabilidades que puedan afectar al sistema es otro problema monumental. Cada componente tiene su propia lista de anuncios, las que deben ser seguidas para estar informado de las mismas. Los parches suelen ser probados sobre el producto de manera aislada, ya que el equipo de desarrollo no dispone de todas las configuraciones en que su producto específico es utilizado, por lo que las pruebas que se deben hacer antes de aplicar un parche deben ser sumamente exhaustivas, idealmente en un laboratorio que replique el sistema completo, tal; como se encuentra en producción.
Finalmente, hay que destacar que la solución planteada sólo considera el tema de mensajería pura, y no las funciones adicionales comentadas como agenda compartida, calendario, etc. La implementación de estas funciones no hace sino agregar aún más complejidad en un sistema ya complejo, con el consiguiente aumento en los costos de administración de la plataforma.

Conclusiones

Si bien es imposible negar los beneficios financieros de corto plazo que entrega una solución basada en software open source, es imprescindible considerar en un análisis serio de la solución los costos que la administración de dicha solución implica. En este aspecto, el mayor costo inicial de una solución integrada se ve compensado con creces con la disminución de los costos de administración del sistema en el largo plazo.
Volviendo al tema que da inicio a este artículo, cuando se comparan soluciones open source y soluciones basadas en Windows Server System, es fundamental tener el costo total de la solución en mente, y no olvidar que la administración de diferentes soluciones tiene un efecto nada despreciable en dicho costo. Y hablando de costos, no hay que dejar de considerar el costo en calidad de vida y en ambiente laboral, que tiene para los propios administradores el disponer de herramientas que les hagan más fácil el desempeño de sus labores.
Otro tema importante, rara vez considerado, es la disponibilidad de un repositorio central de información sobre los productos y tecnologías involucrados en la solución utilizada. A este respecto, los recursos disponibles en Microsoft TechNet son una ayuda invaluable para los administradores. Aunque es cierto que los productos open source disponen de abundante información en Internet, ésta habitualmente se dedica a cada producto de manera independiente y no a las maneras en que distintos productos se interrelacionan, tema en el que el programa TechNet de Microsoft ha puesto un fuerte énfasis ayudando a los profesionales de tecnología a resolver sus problemas.

Agradecimientos

Mis profundos agradecimientos a Oscar Soto por su invaluable apoyo con la plataforma Exchange Server, sin cuya ayuda dicha sección no habría sido ni la sombra de lo que llegó a ser.