HP y la CMDB Federada

Recuerdo que hace poco más de un año comencé este blog hablando de lo dificil que iba a ser ver implementado de una forma real y efectiva el concepto de FCMDB . Poco más tarde, escribía otro artículo buscando la base de estandarización que haría falta, y mencionaba como estandard emergente e interesante el DCML y me llamaba la atención que HP no estuviese en la lista de participantes del consorcio que estaba desarrollando este estándard.

Pasó un tiempo y HP compró Peregrine y entonces todos los rumores apuntaban a que la CMDB de HP sería la de Peregrine, porque el AssetCenter parecía ser "el producto estrella", pero entonces HP compró Mercury y los planes cambiaron: en el último HP Technology Briefing al que pude asistir, hace apenas un mes, se hicieron unas cuantas presentaciones muy interesantes sobre la uCMDB (Universal CMDB), producto que HP coloca en el centro de su estrategia de integración entre los diferentes "centers" y que implementa realmente el concepto de CMDB Federada (confieso que fui muy escéptico ante todo aquel que desde HP me hablaba de federación hasta que fui a Berlin y lo vi).

Pero en esas presentaciones pregunté por los estándares utilizados para modelar la CMDB y la respuesta fueron algunas siglas propietarias, el presentador no conocía ni de la existencia del DCML ni (¡sorprendentemente!) de la iniciativa conjunta entre los grandes fabricantes que se inició el año pasado (ver este post y relacionados).

Pero en realidad todo se estaba cocinando... salía aroma a FCMDB de la cocina de HP, pero los pinches no sabían qué estaba preparando el chef.

Hoy se ha dado la noticia y es fresquita: HP ha comprado OpsWare, uno de los esponsores de DCML, fabricantes de un producto llamado OpsWare OMDB (Operational Management Database) y líderes indiscutibles (junto a nLayers) en la automatización/descubrimiento de CPDs y BackEnd

Vamos, que HP está decidida a posicionarse en el mundo del descubrimiento (tienen ya 3 o 4 productos), de la automatización del cambio (perdón! de los cambios ;-) (para esto tienen tambien al menos 2 o 3) y de la CMDB (otros 3 o 4 productos en el portfolio).

De todas formas, siempre hay que escuchar todas las versiones de la historia, y aqui queda un enlace al artículo "HP buys my company Opsware for more than $1.6 billion in cash" en el blog de Marc Andreesen, uno de los fundadores de OpsWare y poseedor de un más que interesante curriculum.

Como yo decía, hace 1 año faltaban 4 ó 5 para ver una FCMDB en marcha y madura... ahora sólo faltan 3 ó 4.

Un nuevo ¿impulso? a la FCMDB

Hace casi ya un año que comenzaba este blog con unos artículos al respecto de los conceptos que se barajaban entonces sobre la Federación de la CMDB.

A las pocas semanas de publicar esos primeros artículos, aparecía una nota de prensa en la que se comentaba la alianza de "los grandes" para crear un estándard orientado a la federación de la CMDB y así lo reflejaba en el artículo Desenfocado , que no me dejaba para nada las cosas claras.

Ha pasado casi un año, y leo en IT Skeptic un artículo (ácido, como siempre por allí) comentando que ya han publicado (con meses de retraso) el primer whitepaper conjunto para la federación de CMDBs.

El IT Skeptic entraba a saco en su artículo, pero antes de comentar nada o de creerme las cosas que allí se explican, pensé que sería mejor bajarme el whitepaper, leerlo y opinar con cierto conocimiento de causa, así que aprovechando un viaje en metro me lo lei calma y ahora puedo opinar.

¿¿¿Para eso 9 meses de retraso y la union de 6 de las empresas "grandes" ???

Sinceramente, si en Abril del año pasado lo veía desenfocado, ahora lo veo negro. Si han juntado a lumbreras de estas seis compañias para parir semejante simplicidad (no es que esté mal, simplemente es que para escribir eso no hacían falta 9 meses), para construir un estandard "de verdad" no nos quedan años ni nada...

Más reflexiones sobre la FCMDB

Le sigo dando vueltas a la idea de la FCMDB. Comentando las opiniones con algunos amigos, llegamos a la conclusión de que si la federación de directorios ha sido posible es gracias a que existen estándares para la definición de directorios y para el intercambio de información estructurada entre ellos, así que lo que necesitamos es que existan estándares para la consulta y definición de la CMDB.

Bien pensado, si hemos sido capaces de evolucionar hacia SOA, ¿por qué no podríamos tener consultas entre entornos que nos den la información extendida y para asegurar que las diferentes herramientas son capaces de comunicarse entre ellas disponer de algun tipo de estandard al respecto de la construccion de la CMDB?

Este es uno de los curiosos puntos débiles de ITIL (que tendremos que analizar en un artículo específico): ITIL no es un estandard, no es una norma ni una metodología; es un estándard de-facto y un conjunto de buenas prácticas. Así que no especifica exactamente qué contenidos o qué formato debe tener la CMDB y por lo tanto no establece un marco común para que los fabricantes de productos se adhieran.

Pero claro, el Sr. Google lo sabe todo. Buscando buscando, he llegado a una iniciativa realmente interesante y que, a priori, me parece que tiene mucho sentido y que es la vía para alcanzar la idea de la FCMDB: el DCML o DataCenter Markup Language. Se trata de la definición de una especificación que debe permitir describir un datacenter, su entorno y sus componentes. Literalmente, dice algo así como "DCML provides both an inventory of data center elements and the desired functional relationship between them. "

Me ha llamado mucho la atención la lista de participantes en el proyecto: los sponsor members son BMC, CA, EDS, Opsware y Tibco. Justamente la lista de compañías que están hablando, escribiendo artículos y propagando el concepto de FCMDB. Si buscamos FCMDB en Google, la primera entrada es la de Resonance Group, la gente que produce nLayers y que es un gran partner de OpsWare.

Así, con el DCML empezando a crecer (ya está la primera especificación "en la calle") y con los fabricantes más importantes trabajando en ello (¿Por qué HP no estará en la lista? Habrá que preguntarlo) parece ser que los primeros pasos para que la FCMDB sea una realidad están dados; ahora viene la pregunta dura:

¿Cuánto tiempo tendrá que pasar antes de que DCML se convierta en algo tan extendido como el XML?

Fijémonos en lo que le está costando a SOA entrar en el mundo de las aplicaciones. Es algo que existe desde hace años, pero pocos son aún los productos que se puedan intercomunicar usando este modelo. Quizás falte aún unos 5 añitos antes de que veamos a los productos usando CMDB Federada basada en DCML y lo suficientemente extendidos como para que podamos decir que es una realidad (visionarios los hay siempre; de hecho ya hay productos usando DCML pero no podemos decir que estén precisamente extendidos).

En definitiva y como siempre: el tiempo y el mercado dirán lo que tengan que decir.

BIBLIOGRAFIA

Demystifying The CMDB
Federated database manages change

La CMDB Federada

Últimamente oigo hablar mucho del concepto de CMDB Federada (o FCMDB o Federated CMDB) y a más vueltas de cabeza le doy menos me atrae el concepto.
Claro, también puede ser que no lo entienda y simplemente en este artículo no esté haciendo nada más que dejar patente mi ignorancia, que también puede ser, por eso en la introducción a este blog se habla de miles de dudas y sólo de decenas de ideas.

¿Qué quieren decir los fabricantes cuando hablan de FCMDB?
Pues a nivel conceptual la idea es buena y tiene sentido: se trata de no tener duplicada la información sino "punteros" a donde se encuentra la fuente de la información puramente. Así, en una FCMDB en lugar de tener una base de datos con los 1.000 elementos de red que hay en mi red, lo que tengo es un enlace a la herramienta de descubrimiento de redes donde se mantiene el inventario (ojalá que automatizado) de estos elementos.

Claro, pero no sólo de redes se compone mi CMDB, así que también tendré que tener el enlace a las herramientas de inventariado de PCs, de servidores, de almacenamiento, etc, etc, etc. De esta forma, en lugar de tener una CMDB con miles de elementos que se han "sincronizado" (importado o reconciliado) desde los diferentes repositorios de las herramientas de inventario y de tener la obligación y la seria responsabilidad de mantener esta información debidamente actualizada, lo que tengo es una CMDB con toda una serie de "punteros" que me permiten obtener la información directamente desde su fuente.

Ah, interesante. ¿Entonces?
A este modelo, que a priori parece totalmente adecuado, a mi se me antoja que le fallan algunas piezas de base:

Para empezar está el hecho de que tenemos que tener claro que el objetivo de una herramienta de inventario técnico es ofrecernos, como dice un cliente mío, "datos para aburrir". Estos datos son obtenidos por las herramientas con el fin de facilitar el soporte, proporcionar preciosos reports que faciliten la vida de los administradores o incluso aportar datos de carácter menos técnicos pero que ayuden a tomar decisiones a alguien: marca, modelo, numero de serie, capacidad, componentes, estado, software instalado, procesos en ejecución, contenido de los ficheros de configuración; no se: un sinfín de datos que en mayor o menor medida le sirven a alguien para hacer su trabajo.

Pero la CMDB es la base de todos los procesos ITIL, y debe contener los atributos necesarios para soportar cada uno de los procesos que la compañía tenga implantados y los procesos ITIL son muchos y variopintos. ¿Acaso una herramienta de inventario será capaz de saber el número de factura del proveedor que me vendió el equipo? ¿Será capaz de decirme cómo se reparten los costes indirectos para el modelo de costes? Es evidente que no, así que esos atributos del Elemento de Configuración los tendré que ir a buscar a otra parte, o los tendré que aportar manualmente después de que un humano tome alguna decisión al respecto.

Y esta afirmación me lleva directamente a otro modelo: tengo una CMDB "de las de toda la vida" con la información que yo necesito y, cuando necesito información ampliada, la herramienta me proporciona las integraciones o funcionalidades necesarias para acudir a la fuente de información y consultarla. Algo así como "en la CMDB se almacenan los datos necesarios para soportar los procesos y si necesitas el inventario detallado hasta el último bit 'para aburrir' pulsas un botón y te llevo directamente a donde está esa información".

Por otra parte, está el hecho de que los fabricantes de herramientas que me permitan implementar una FCMDB son eso: fabricantes, o sea empresas que hacen una gran inversión en I+D y que esperan lucrarse con la venta de licencias y servicios alrededor de los productos desarrollados. La federación de los datos deja totalmente en manos de otros el contenido, la fiabilidad, la velocidad, la usabilidad y la "buena presencia" de mi CMDB y, por si fuera poco, resulta que es imposible federarse con todos los fabricantes de inventario, porque todo cliente tendrá siempre alguna fuente de datos hecha a medida (¿cuántas hojas Excel, ficheros de texto y ficheros Access hay sueltos por el mundo con la información más preciosa de las organizaciones IT?).

De esta forma, tengo que decir que no creo en la FCMDB multifabricante, abierta y genérica. Si que creo posible (y útil e inteligente por parte de los fabricantes) una federación "endogámica", en la que un fabricante desarrolle una CMDB que se federe con sus propios productos y quizás con los de sus mejores partners pero ¿se imaginan a HP federando su CMDB con IBM, CA y BMC?

Yo no.