A aquellos que estén familiarizados con el diseño software, especialmente el diseño orientado a objetos, les resultará seguramente familiar el término 'patrones de diseño'. Un patrón de diseño es algo así como un diseño genérico, un modelo de diseño repetitivo. una buena solución 'ya enlatada' para un problema común de diseño software.
Los patrones de diseño se hicieron populares (y tremendamente útiles) a partir del afamado libro 'Design Patterns. Elements of Reusable Object-Oriented Software' de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. El libro, debo decirlo, con el que creo que más aprendí de diseño orientado a objetos en su momento (un momento algo lejano ya).
Pero los patrones no tiene por qué limitarse a diseño de software orientados a objetos. Siempre que existan unas problemáticas frecuentes y similares en cualquier ámbito, y siempre que identifiquemos un tipo de solución válida para ese tipo de problemáticas, nos encontraremos ante un patrón.
Leyendo 'The DevOps Handbook' me encuentro con esta misma palabra, patrón ('pattern'), pero en un ámbito diferente, aunque todavía dentro del mundo del software. Se trata de tres patrones que tienen que ver más con la arquitectura y explotación de sistemas que con la ingeniería del software.
En el caso de los dos primeros patrones, el problema a resolver es cómo conseguir un despliegue frecuente (idealmente continuo) de nuevo software en producción con un riesgo tolerable. Para este problema, se nos proponen dos patrones: 'feature toggles' y 'dark launching' que, por cierto, pueden ser complementarios.
'Feature toggles' (conmutadores de características) consiste en dotar al sistema de unos elementos de configuración (por ejemplo vía fichero XML o JSON) que permitan realizar activación/desactivación o la apertura de las nuevas funcionalidades de forma controlada. Por ejemplo, se puede controlar a qué usuarios se les permite o no el acceso a la funcionalidad reciente, implementando políticas de número crecientes de usuarios como podría ser: al principio sólo el equipo de desarrollo, luego los usuarios de la compañía proveedora del servicio, luego un número limitado de clientes y, finalmente, toda la planta de clientes. También se puede utilizar para desactivar completamente una funcionalidad que se ha mostrado defectuosa o no escalable.
'Dark launching' (lanzamiento opaco) habla de desplegar en entorno de producción software y funcionalidad pero de modo que no son visibles para los usuarios finales, ya sea porque está desactivadas para ellos, ya sea porque no producen ninguna manifestación visible sino sólo trabajo en 'background' (por ejemplo, medidas y obtención de KPIs). En la sombra, el equipo de proveedor del servicio puede trabajar comprobando el funcionamiento correcto y las prestaciones y escalabilidad, antes de decidirse a desplegar 'en abierto'. Este patrón pude apoyarse en el de 'feature toggles' ya que pueden ser esos conmutadores de características lo que nos sirva para mantener la nueva funcionalidad como 'opaca'.
El tercer patrón cambia de tercio y se centra ahora más en una solución de arquitectura para permitir desplegar una nueva tecnología conviviendo con otra legacy.
'Strangler application' (estrangulador de aplicaciones') lo que propone es, simplemente, recubrir el 'legacy con un API, de forma que se concentre ahí toda la interacción entre la nueva tecnología o aplicación y la legada. De esta forma, se reduce drásticamente el acoplamiento entre ambas y se habilita una relativamente sencilla eliminación de la aplicación legada, si así lo decidimos, mediante una nueva implementación del API que recubría al legado. La re-implementación de esa API puede incluso, ser gradual, resultando en cualquier caso trasparente el ritmo de sustitución para la nueva tecnología o aplicación.
Probablemente, aquellos lectores duchos en ingeniería software y con experiencia real con sistemas reconozcan estos patrones, incluso aunque puedan no haber oído nunca el nombre que se les aplica. En mi caso particular, puedo decir que, en efecto, he conocido las tres estrategias en la práctica, aunque hasta ahora no las había catalogado como patrón ni conocía el nombre que las denomina.
Es lo que tienen los patrones: son soluciones comunes, y muchos profesionales probablemente han llegado a y aplicado las mismas conclusiones, incluso sin saber que otros colegas hacían lo mismo en otras compañías o proyectos.
El identificarlos como patrones hacen más fácil, sin embargo, entenderlos, comunicarlos e identificarlos la próxima vez.
Y con ese espíritu, y por lo que pueda ayudar, he escrito este post.
No hay comentarios:
Publicar un comentario