Las primitivas

El autor de Puppet, Luke Kanies, habla en el capítulo sobre esta herramienta en The Architecture of Open Source Applications que basaron la arquitectura de este framework en piezas primitivas. Al igual que se diseñó la arquitectura de Amazon como se comenta en este fantástico artículo sobre 10 lecciones que aprender (o que aprendieron) de los 10 años que recientemente ha cumplido AWS.

La idea es muy clara y reveladora: Diseñan piezas muy pequeñas y simples que se puedan conectar perfectamente entre ellas y que se pueden componer para construir sistemas más grandes y complejos. La ventaja principal de las piezas primitivas es que son tan pequeñas y básicas que se pueden utilizar en cualquier entorno y cualquiera puede entender su funcionamiento y trabajar con estas primitivas en muy poco tiempo.

Son los ladrillos de una casa, tan básicos que para la gran mayoría no hay ningún problema en levantar un muro. Pero a la vez, estas piezas tan pequeñas, como las letras, permiten construir sistemas muy complejos con significado propio como las oraciones. Estos sistemas se pueden conectar entre si porque sus primitivas son interconectables y se pueden ampliar o reducir. Se pueden descomponer en sistemas más pequeños (palabras) e investigar qué primitivas han tomado parte en el proceso para analizar la trazabilidad.

Obviamente es complicado llevar a la práctica el concepto de primitivas. Que cada organización tenga que diseñar y desarrollar piezas genéricas que encajen en cualquier entorno no es fácil ni de imaginar. Pero merece la pena tener la idea en la cabeza. Al fin y al cabo, la corriente de los microservicios que ha surgido a raíz de construir monstruos enormes va en la dirección de replantear el software para desarrollar sistemas que sean más fáciles de componer y descomponer. Como piezas de Lego.

Anuncios

Lecciones de diseño desarrollando Puppet

Dicen que es muy bueno leer código de otros. Un paso intermedio es leer cómo otros han diseñado ese código y para esto hay un libro espectacular: The Architecture Of Open Source Applications en el que desarrolladores cuentan entre otras cosas cómo han evolucionado arquitecturas y software que diariamente usamos como Git, Puppet, MediaWiki o Hadoop.

Leyendo el capítulo de Puppet se puede uno encontrar cómo este framework ha ido progresando con los principios de diseño de buen software muy en mente tales como bajo acoplamiento, alta cohesión, inyección de dependencias…

Declararon los recursos (archivos, programas…) como primitivos del framework y definieron una capa Resource Abstraction Layer desde la que usar los recursos independientemente del sistema operativo o la implementación de su uso. Se esforzaron por darle la posibilidad al usuario de Puppet de enfocarse en lo que necesita más que en cómo lograrlo.

Desarrollaron los clientes Puppet sin dejarle acceso a los módulos (encapsulamiento) entregándoles su configuración correspondiente. Así, cada cliente sólo conoce su configuración sin conocer la configuración de otros servidores evitando de esta manera que un cliente cree dependencias en servidores de los que no debería depender.

Más adelante en el texto comentan que el nodo Master Puppet recibe las necesidades de un nodo y más que configurarlo lo clasifica, cosa que me recuerda mucho a la orientación a objetos: Crear varias clases con la misma interfaz pero diferente comportamiento en la implementación, en lugar de tener sólo una clase y un montón de condiciones para definir el flujo dependiendo de la configuración.

Desarrollando un software para gestionar recursos en diferentes máquinas, se encontraron con la misma problemática de gestionar recursos en el código y poco a poco fueron desarrollando su propio framework (dentro de Puppet) de inyección de dependencias llamado Indirector que con el paso de las versiones ha llegado a gestionar todas las dependencias de la aplicación completa.

Y para terminar el texto concluye dándonos una gran lección sobre desarrollo de software:

Lastly, it took us too long to realize that our goals of simplicity were best expressed in the language of design. Once we began speaking about design rather than just simplicity, we acquired a much better framework for making decisions about adding or removing features, with a better means of communicating the reasoning behind those decisions.