Si has trabajado en IT durante los últimos 10 años, te habrás encontrado, de una forma u otra, con un término que se ha convertido en un mantra para muchas organizaciones. Estoy hablando de DevOps.
Para aquellos despistados que no sepan, a estas alturas del partido, qué es DevOps, voy a hacer una pequeña introducción, que aunque sencilla y obvia, pueda ayudar a entender porqué esta palabra se ha convertido en uno de los términos más utilizados en las áreas de IT.
Development Operations
Se trata de un movimiento, mucha gente piensa que es una metodología, pero lo cierto es que no podemos considerarlo como tal, ya que cada empresa desarrolla su propia cultura DevOps. Pero aunque esto sea una de sus virtudes, la libertad para implementar una cultura DevOps, también es uno de sus principales problemas, ya que aplicamos DevOps a una enorme cantidad de cosas, lo que genera cierta confusión.
Por simplificar la disertación, DevOps no va de reglas, va de personas y de incrementar el conocimiento que las áreas de IT tienen sobre los sistemas de información con los que trabajan.
En su libro “The Phoenix Project”, Gene Kim, Kevin Behr y George Spafford definen tres vías que han sido adoptadas por la comunidad para implantar la cultura DevOps en una organización:
- Entender el sistema como un todo
- Incrementar el feedback
- Experimentar y aprender de manera continua.
Otra cualidad de la cultura DevOps y que no podemos olvidar, es que debe estar totalmente orientada al negocio. Su objetivo no es cambiar la forma en la que las organizaciones trabajan y desarrollan tecnología. El objetivo de la cultura DevOps es impactar de manera positiva sobre el Negocio, que al fin y al cabo, es la verdadera razón de la existencia de la compañía.
Sin entrar más en detalle, hay mucha bibliografía disponible sobre la cultura DevOps, podemos establecer tres estadios básicos dentro del ciclo de vida de una solución, Desarrollo, Entrega y Operación. Los procesos desplegados en cada uno de estos tres estadios, conforman la cultura DevOps de nuestra organización.
- Desarrollo, incluye a todos los procesos relacionados con el desarrollo del código.
- Entrega, todo lo relacionado con los procesos de entrega del código para su despliegue en la infraestructura, incluida ésta.
- Operación, todos los procesos para mantener y monitorizar las soluciones.
En definitiva, implementar tu propia cultura DevOps en tu organización puede ayudarte a reducir la fricción entre los equipos de desarrollo y los de operaciones. También y más importante, reducir las fricciones entre los equipos de Negocio y Tecnología.
El tiempo ha demostrado que DevOps funciona y que las organizaciones son más eficientes gracias a un mejor alineamiento de los equipos que las constituyen. Pero, siempre hay un pero, DevOps nace y se desarrolla sobre un modelo de organización tradicional en el que los datos, los empleados, los recursos, el negocio, etc. Trabajan bajo el paraguas de la organización. ¿Qué ocurre si necesitamos incorporar a la organización a procesos que trabajen sobre modelos distribuidos? En los que los datos ya no están organizados como silos dentro de la organización. El código que manipula los datos ha sido desarrollado por otra organización o nuestros usuarios deben operar sobre aplicaciones que no están alojadas en nuestra organización.
Estoy hablando de escenarios en los que la tecnología Blockchain tiene mucho que decir. Por ejemplo, podemos hablar de consorcios que utilizan la tecnología Blockchain para mantener una fuente de la verdad confiable y segura, mediante el despliegue de redes permisionadas, en las que el gobierno del dato, el código y la infraestructura, son actividades claves para el éxito de la solución.
Nuevo paradigma, nuevas necesidades
Para entornos distribuidos entre varios participantes, como son las soluciones Blockchain, la cultura DevOps no funciona a menos que incorporemos un cuarto pilar. Es necesario implementar procesos de Gobierno, el cual será el pilar sobre el que desarrollar los tres pilares tradicionales de la cultura DevOps.
Debemos evolucionar la cultura DevOps hacia un modelo que soporte un entorno distribuido entre participantes heterogéneos, que permita asegurar, no solo el desarrollo, entrega y operación, sino el buen gobierno de cada uno de los pilares anteriores.
El principal reto de las soluciones blockchain basadas en tecnología permisionada, es la necesidad de generar modelos de gobierno tanto del dato, el código y la infraestructura. Ya que no se trata únicamente de utilizar los recursos IT para construir la solución, sino que dichos recursos deben implementar modelos de gobierno que permitan a los participantes del consorcio poder asegurar la viabilidad de la solución.
Como digo, la necesidad de los modelos de gobernanza, afectan principalmente a los entornos basados en consorcio permisionados, en el que los participantes deben solicitar el acceso. En tecnologías Blockchain sin permisionado, los modelos de gobernanza son más sencillos, por ejemplo en la red Ethereum, la política para desplegar código se basa en la capacidad para realizar una transacción y soportar el coste de la misma. Pero en entornos permisionados, se deben establecer unos procesos que permitan el gobierno del dato, el código y la infraestructura. De no ser así, nos enfrentaríamos a situaciones en las que la infraestructura Blockchain podría llegar a estar bloqueada, por ejemplo, sin la posibilidad de que los participantes pudieran desplegar código o tener acceso a ciertos datos.
Una de las ventajas de la tecnología Blockchain, es que podemos implementar estos modelos de gobernanza en la propia solución. Por tanto, los modelos se convierten en elementos de obligado cumplimiento por todos los participantes, siempre y cuando, dicha implementación sea coherente con las necesidades del consorcio.
Cualquier solución blockchain basada en entornos permisionados debe tener:
- Modelo de gobierno del dato, que permita establecer de forma clara, quién o quienes son los propietarios del dato, definición de los roles de acceso y el ciclo de vida del dato. A diferencia de otras tecnologías, Blockchain distribuye el dato en función de los modelos que se hayan diseñado e implementado. Esto significa que los datos no están únicamente en un sitio, sino que durante el ciclo de vida de la solución, se pueden mover de una infraestructura a otra. Lo que nos obliga a definir estos modelos de gobierno del dato, para poder garantizar que durante todo su periodo de vida, se cumplen los requisitos iniciales.
- Modelo de gobierno del código, la principal diferencia entre una solución basada en plataforma frente a una solución basada en tecnología Blockchain es que el código, al igual que el dato, se distribuye a lo largo de la infraestructura del consorcio y no existe un ente único que tenga la potestad de gestionar el código. Tenemos que recordar que el dato es la base sobre la que se construyen las soluciones. Pero el código es el elemento que trabaja con el dato, por lo que es necesario disponer de un modelo coherente del gobierno del código, que garantice el correcto funcionamiento de la solución. Este modelo no solo debe cumplir con los requerimientos iniciales de la solución, sino que debe asegurar que a lo largo de toda la vida de la solución, el código podrá ser desplegado de manera segura dentro del consorcio.
- Modelo de gobierno de la infraestructura, si bien, el dato y código son elementos en los que existe cierta discusión y conocimiento en las organizaciones sobre los modelos de gobierno, aunque desde una perspectiva centralizada. Es en la infraestructura IT donde las organizaciones carecen de experiencia para entornos distribuidos y descentralizados. Hasta ahora la infraestructura IT de la organización consistía en componentes gobernados por la propia organización, sobre los que tenía total control. El reto de una infraestructura distribuida que soporte los procesos de negocios de un consorcio, es que no existe el rol de gestor de la infraestructura, sino que dicho rol es compartido por los distintos participantes. Si ya es complicado poner de acuerdo a áreas de desarrollo y operación dentro de la propia organización, lo es aún más, si metemos en la coctelera a varias organizaciones con sus propios departamentos de desarrollo e infraestructuras.
Por tanto, los modelos de gobierno son imprescindibles para el éxito de cualquier solución basada en tecnología Blockchain permisionada y debe incluirse dentro del ciclo de vida de la solución, como un elemento base sobre el que construir el resto de componentes. Además es necesario que dichos modelos se implementen, no como acuerdos entre las distintas partes que se puedan incumplir, sino como reglas implementadas dentro de la solución, con el objetivo de que ninguno de los participantes tenga la posibilidad de saltarse los modelos de gobierno establecidos.
Algunos consejos a la hora de crear los modelos de gobierno:
- Cubrir todo el ciclo de vida de la solución, no únicamente la fase inicial de diseño.
- Incorporar mecanismos para la actualización las reglas del modelo, para que los participantes puedan adaptar los modelos a nuevas situaciones.
- Definir los mecanismos de consenso sobre los que el modelo tomará las decisiones.
- Identificar los riesgos a los que se pueden enfrentar los modelos de gobierno.
- Disponer de mecanismo para la desactivación ágil de bloqueos.
Y el más importante de todos los consejos a la hora de enfrentarnos a la creación de modelos de gobernanza, es que deben implementarse de manera gradual, con el objetivo de poder validar la viabilidad de la implementación que estamos realizando. La mayoría de los problemas a la hora de desplegar soluciones blockchain en entornos productivos, nacen de una mala implementación de los modelos de gobernanza que impiden el normal funcionamiento de la solución.
Tenemos que recordar que no nos enfrentamos a un problema de ingeniería, sino de gobernanza de una solución distribuida, en la que no solo la gestión del dato, el código y la infraestructura es distribuida, sino también la propiedad de los distintos componentes. Lo que requiere de un ejercicio serio y exhaustivo sobre la forma de diseñar e implementar los modelos de gobernanza.
Debemos construir las soluciones Blockchain sobre la base de los modelos de gobernanza y no implementarlos como un añadido. Porque esto supondría el fracaso, si no a corto plazo, sí a medio o largo, ya que podría terminar bloqueando la operación de la solución Blockchain.