Pensamientos de Aztlek

Este no es la primera vez que escribo sobre sistemas heterogéneos, ya los había mencionado en ¡Qué la heterogeneidad NO es el problema, es el aislamiento!,pero es que hay tantos mitos alrededor de éste concepto y es satanizado tanto que es necesario volver sobre el asunto. Además, hay algunos conceptos que apenas he mencionado en anteriores escritos.

Una aclaración, cuando hablo en este escrito sobre sistemas estos tienen la connotación particular de sistemas computacionales digitales, que incluye desde los sistemas de información hasta los drivers del sistema operativo. Si bien muchas de las reflexiones en este escrito sólo son válidas en esta connotación restringida, en algunos casos, puede funcionar con el concepto más general con las debidas inducciones (pero para serte franco no me he puesto ha pensar sobre el asunto).

Como siempre, he preparado un mapa con los conceptos y sus interrelaciones que pongo a continuación.

Mapa conceptual de la heterogeneidad de los sistemas

Los sistema heterogéneos tienen características operativas distintas, por ejemplo, se pueden tener dos sistemas: el de nómina y el financiero y resulta que uno está hecho en Delphi con SQLServer y el otro con Java y con Oracle DB. Cada uno tiene características operativas distintas, pues operan sobre distintas plataformas software. Ahora, esto no quiere decir que no puedan interoperar, de hecho es necesario hacerlo pues la nómina impacta en el sistema financiero y la heterogeneidad no es el problema, de hecho estos dos pueden comunicarse mediante un servicio web y mediante él intercambiar los datos necesarios.

¿Pero esto cómo se logra? Es necesario que los sistemas heterogéneos cumplan con estándares abiertos y estos sean como se definen en, ¿Qué es un estándar abierto?, esto es, que NO sea un «estándar» controlado por una sola compañía, sino al contrario, que sea administrado por un organismo de estandarización sin ánimo de lucro, que sea  independiente de las partes interesadas (incluidas las empresas), que tenga procedimientos abiertos que permitan la participación incluyente de todas las partes y que el estándar en sí esté libre de derechos de propiedad industrial y de autor (por ejemplo, sin patentes).

Utilizando estos estándares abiertos, es posible la interoperabilidad entre sistemas heterogéneos, y esto se hace mediante un middleware. No es suficiente el cumplimiento de estándares, por que dos sistemas pueden cumplir dos estándares abiertos pero distintos y en ese caso la función del middleware es hacer una «traducción» entre esos estándares.

Pero el middleware va más allá de una función de traducción, éste debe tener al menos dos conjuntos de funciones que se pueden agrupar en: ser un intermediador y ser un separador interfaz-implementación. Estos dos conceptos, su fortaleza y flexibilidad ya los traté en los artículos:  El poderoso concepto de la intermediación y El antiguo pero siempre actual concepto de separación interfaz-implementación, respectivamente.

Pero lo que considero más importante es un concepto que viene de los ecosistemas naturales. Los entornos de sistemas computacionales digitales están alcanzando una complejidad tal que ya se están tomando conceptos de otros sistemas aún más complejos para modelarlos y entenderlos. Los ecosistemas. Pero, no es sólo un problema de complejidades relacionadas, sino que también presentan muchos isomorfismos. Es tan notorio estos isomorfismos que inclusive en el documento Reference Architecture Foundation for Service Oriented Architecture Version 1.0 que es la base para los middleware orientados a servicios, consideran estas arquitecturas como un ecosistema (ver pág. 11 del documento citado), pero esto no es simplemente una metáfora elegante, sino que es un modelo que explica y predice el comportamiento de estas arquitecturas.

Pero volviendo a la capacidad se sobrevivir a cambios catastróficos, esta capacidad aumenta más que linealmente cuando se tiene una mayor heterogeneidad en un ecosistema.

Por ejemplo, veamos dos escenarios: en el primero se tiene un único SGBD (Sistema de Gestión de Base de Datos), y en el otro escenario se tienen dos. Digamos que aparece algún tipo del malware que afecta a uno de los SGBD, éste de una marca y versión particular, pues el malware aprovecha agujeros de seguridad específicos. Y no podemos decir que no estamos expuestos, pues solo un computador enterrado en las profundidades de la tierra en una caja con una capa de acero acero, otra de plomo y dentro una jaula de Faraday; un sistema totalmente aislado puede ser afectado por malware. Por ello, hay que trabajar con la suposición de que esto puede pasar. Volviendo a nuestros dos sistemas, en que el caso de un único SGBD y que es atacado por este malware y no sobrevive. Como resultado tenemos comprometida toda operación de la organización. Y es la cabeza del jefe de tecnología la primera que rueda.

Pero en el segundo escenario, en el que tenemos dos SGBD y ataca el malware, uno de los dos SGBD sobrevive. Y aquí tenemos otros dos casos: En el primero, el negocio está repartido funcionalmente en los dos SGBD, en el segundo caso uno es un espejo del otro. En el primer caso, que sería donde más impactaría un evento catastrófico como el de nuestro malware solo una parte del negocio se vería comprometida. ¿Qué tan grande? Pues depende de como se halla hecho la partición de datos. Pero, indudablemente será mucho menor que el escenario de un sólo SGBD.

El escenario ideal en el cual los dos SGBD son un espejo, pues no necesita mayor explicación. En éste toda la operación del negocio sobrevive y apenas si se notará.

Pero es necesario decir que la heterogeneidad no sólo son ventajas, hay que reconocer que hay un costo administrativo asociado para mantenerla (cosa que parece no importar en los ecosistemas naturales, pero si en los artificiales). Por ello es pertinente la siguiente pregunta.

¿Cuanta heterogeneidad debe tener nuestros sistema? Es una pregunta compleja de responder pues depende de las características particulares del sistema. Pero obviamente, la heterogeneidad mínima es de dos subsistemas. Además, es también recomendable que se haga a varios niveles, por ejemplo en: los SGBD, frameworks de desarrollo, middleware, buses de servicios y otros.

La conclusión de este escrito está muy relacionada con la del articulo ¡Qué la heterogeneidad NO es el problema, es el aislamiento!, y es que la heterogeneidad es saludable en los sistemas de una organización, debe ser usada, el problema es cuanta y esto deber evaluado para que los costes no superen los beneficios.