Platform Engineering y la supuesta muerte de DevOps.

Hace ocho años publicamos en Paradigma un post llamado “Qué es DevOps y sobre todo qué no es DevOps”, que a fecha de hoy sigue siendo uno de los más leídos en nuestro blog.

El éxito continuado de ese artículo no hace sino confirmar la importancia y el impacto que ha tenido esta forma de trabajar desde mediados de la década pasada (principio de la transformación digital de las grandes compañías españolas), y que sigue vigente hoy día, ya que casi diez años después hay muchas compañías que aún ahora están comenzando a afrontar ese proceso.

De ahí mi frustración, que algún lector seguro que comparte, cuando hace unos meses empezó a circular por Internet este meme:

¿Cómo puede ser? ¿Después de años evangelizando acerca de las bondades de DevOps, y cuando aún quedan tantas compañías por asimilar el mensaje y el cambio que conlleva, ahora llega Platform Engineering a decir que DevOps ha muerto?

¿Qué es eso de Platform Engineering? ¿Es una moda o me lo tengo que tomar en serio? ¿Ha muerto DevOps de verdad? En este post vamos a tratar de dar respuesta a estas preguntas.

Un poco de historia

Rebobinemos para ponernos en contexto. No es el objeto de este artículo centrarnos en ello, pero recordemos cómo surgió DevOps:

DevOps vino a resolver la enorme ineficiencia en la colaboración de las áreas tradicionales de desarrollo y sistemas, encarrilando a las organizaciones hacia la automatización de despliegues y al santo grial del continuous delivery, tan importante para romper monolitos, evolucionar a arquitecturas cloud native y competir con los más avanzados en el mundo digital.

Montar un stack de continuous delivery e implantar una organización para trabajar en DevOps ha sido un proyecto core en la transformación digital de muchas compañías a las que hemos ayudado en la última década, llevándolas hacia los conceptos de plataforma PaaS e infraestructura como código, que permiten que los equipos de desarrollo se centren en lo realmente importante para ellos: su aplicación de negocio.

Son muchas las compañías y los equipos que han vivido este proceso, han completado con éxito los primeros proyectos, PoCs y MVPs cloud, y han saboreado por fin la libertad y la eficiencia del principio “you build it, you run it”.

¿Qué ha pasado entonces? ¿No era esta la tierra prometida? ¿Por qué se habla de platform engineering y de la muerte de DevOps?

La realidad es que nuestra experiencia en estos últimos diez años, en los que hemos acompañado a muchas compañías, grandes y pequeñas, en el viaje hacia Cloud y DevOps, nos dice que hay un patrón que se repite y que podríamos representar así:

Cuando creen que han llegado a la cima de la montaña, muchas compañías ven que esa montaña estaba ocultando otra que solo se ve cuando has culminado la escalada de la primera. Y esta segunda montaña aparece por dos motivos:

Complejidad de la tecnología

La tecnología en el ámbito cloud ha evolucionado exponencialmente en los últimos años. La CNCF (Cloud Native Computing Foundation), una fundación de software de código abierto que respalda y promueve el uso de tecnologías cloud native, mantiene un landscape o mapa del ecosistema de cloud native que incluye proyectos open source, productos y servicios, cuya visualización a día de hoy produce vértigo:

Esta auténtica explosión de productos, frameworks, herramientas, etc., que no deja de crecer, ha multiplicado la carga cognitiva requerida de los equipos técnicos, hasta tal punto que es a día de hoy uno de los problemas más importantes de la ingeniería del software:

Buscar una persona experta que domine o al menos se maneje de forma competente en todas estas tecnologías, y más en el mercado actual de talento, es enormemente complicado y se convierte en un drama para compañías que han hecho una enorme inversión en sus plataformas cloud y de pronto se encuentran con que sus equipos no tienen las capacidades suficientes para trabajar en ellas.

Es en este momento cuando el “You build it, you run it” que hace unos años se percibía como un soplo de libertad y aire fresco, ahora se percibe más como un grito o una condena: “You build it… you run it!”.

De la prueba de concepto a la transformación masiva del negocio

El segundo factor tiene que ver con el escalado. Cuando se implanta DevOps o se monta una plataforma cloud PaaS en una organización, lo normal es no hacer un big bang, sino comenzar con una prueba de concepto o un MVP.

Para ello no se elige un proyecto o equipo al azar, sino que normalmente se selecciona un proyecto sin mucha presión de negocio liderado por un equipo que formamos con las personas más motivadas a moverse a cloud, que habitualmente son también las más capaces y las que llevan leyendo o formándose en cloud por su cuenta más tiempo.

Sin embargo, cuando después de cantar victoria con ese primer o primeros proyectos, que tan buen resultado han dado, decidimos amortizar la inversión moviendo masivamente el resto de proyectos o productos de la compañía a la plataforma cloud, nos encontramos un escenario muy diferente:

• Equipos que lejos de estar motivados son reacios al cambio, dificultan cualquier iniciativa de transformación digital y tienen, además, un nivel de capacitación mucho menor al de los primeros equipos.
• Proyectos donde el margen para fallar o producir un impacto operativo por la migración a cloud es mucho menor.
• Una plataforma o varias plataformas que conforman un ecosistema cloud cada vez más complejo que eleva cada vez más la barrera de entrada al mundo cloud/devops.

No son pocas las compañías que después de una fuerte inversión en una plataforma cloud y una implantación de un modelo de trabajo DevOps, se encuentran con que no son capaces de escalar el modelo a toda la organización.

Platform Engineering: la industrialización de DevOps

Platform engineering viene para ayudarnos a escalar esa segunda montaña y resolver esos problemas que acabamos de describir. Es un término con una traducción difícil y que además encontramos definido de múltiples maneras diferentes, todas ellas complicadas de entender.

Sin pretender hacer una definición canónica o completa, podríamos decir que platform engineering es una disciplina que permite industrializar y escalar el uso de las plataformas y modelos de trabajo cloud en una organización.

No es, por tanto, una solución tecnológica, sino una disciplina que aporta capacidades a la plataforma cloud de una organización, a través de diversas tecnologías, prácticas y metodologías.

Los pilares de platform engineering son cuatro:

1 Golden Paths

Un golden path (o paved road) proporciona una solución de referencia a una necesidad específica de los equipos de desarrollo, encapsulando las particularidades de la organización y abstrayendo al desarrollador de la toma de decisiones.

Los golden paths permiten reducir la carga cognitiva y la complejidad técnica de la plataforma para el desarrollador. Un golden path puede resolverse en forma de decisión técnica, abstracción al desarrollador o incluso como una política.

El golden path aporta consistencia y estandarización adaptados al contexto y al momento de la organización.

2 Experiencia de desarrollo

El objetivo de la UX es reducir la fricción entre una herramienta y el objetivo de un usuario, a través de la eliminación de obstáculos, rodeos o incomodidades.

DevEx se enfoca en la experiencia de los desarrolladores aumentando su productividad y satisfacción. Además, debe eliminar fricciones entre la plataforma y el objetivo último de entrega continua de valor a través de:

• WorkFlows: los golden path se encargan de mejorar la experiencia del desarrollador en su flujo habitual de trabajo.
• Herramientas: a través de CLIs o UIs, como los developer portal. Es importante que la experiencia del desarrollador usando esas interfaces también sea cuidada.
• Documentación: guías de desarrollo y procesos de on-boarding a la plataforma.

3 Team topologies: modelo de colaboración de plataforma

Team Topologies propone una contra-maniobra de la ley de Conway para encajar la arquitectura de organización con la arquitectura de software.

Propone una organización basada en una relación del equipo de plataforma con los siguientes equipos:

• Equipo de aplicación (stream aligned team): alineado con un flujo de negocio formado por equipo cross funcional y con capacidad de entrega continua de incrementos sin dependencias bloqueantes. Se relaciona con el equipo de plataforma en forma as a service: consumo de capacidades con colaboración mínima.
• Enabling team: equipo que asiste a otros equipos en la adopción o implantación de tecnología o procesos en un período de transición o aprendizaje. Su relación con estos otros equipos es facilitating: ayuda a otro equipo para eliminar impedimentos.
• Complicated subsytem teams: equipos que tienen skills específicos demasiado complejos para ser asumidos por un equipo stream-aligned o de plataforma. Se relaciona con los demás equipos en modo collaboration: trabajo conjunto entre equipos.

Team Topologies está diseñado para que los stream aligned teams puedan entregar valor en ciclos cortos. El resto de equipos dan cobertura al stream aligned team para que pueda entregar valor de forma continua.

Los equipos stream aligned son los que tienen el contexto hasta el final de la cadena de valor del desarrollo, evitando modelos de hands-off (ticketOps) que implican pérdida de contexto y conocimiento.

4 Product Mindset

La obsesión de todo Product Manager es construir un producto que cumpla las expectativas del usuario y que tenga una adopción acorde.

Una plataforma debe construirse con una mentalidad de evolución iterativa, releases frecuentes, captura del feedback y medición del éxito.

Conclusiones y consejos para implantar Platform Engineering

En conclusión, y respondiendo a la pregunta con la que arrancábamos este post, DevOps no ha muerto, de ninguna manera, pero sí ha encontrado muchas dificultades prácticas a la hora de escalar en las organizaciones, que Platform Engineering resuelve.

Y no, Platform Engineering no es una moda, sino un proceso de industrialización y escalado de plataformas cloud por el que toda compañía que quiera mover su core a la nube tendrá que pasar antes o después.

Y por eso, finalizamos este post con tres consejos que esperamos que te ayuden a poner en práctica todo lo que hemos contado:

No te dejes llevar por el hype

Como hemos visto antes, las tecnologías cloud están en continua expansión; es aún muy pronto para tomar decisiones de riesgo. No te dejes llevar por mensajes de marketing y sobre todo no reinventes la rueda: si tu problema es válido y legítimo, aparecerá una tecnología open o comercial para resolverlo. El landscape evoluciona muy rápido. Si puedes esperar seis meses, hazlo.

Una vez decidas elegir, intenta simplificar las decisiones y adaptar la elección de tecnologías al contexto único de tu organización (tamaño, industria, objetivos…).

Aborda la plataforma como un producto, no como un proyecto

Abordar una plataforma como un proyecto supone gestionar el riesgo en secciones de tiempo excesivamente grandes.

No hay posibilidad de mejora continua porque la plataforma no está en uso hasta el final. Es fácil caer en sesgos cognitivos como “Sunk cost” o “Too big to fail” que empeoren aún más la situación.

Déjate acompañar por un experto... cuyos intereses confluyan con los tuyos

Buscar asesoría de compañías y expertos que hayan vivido este viaje antes que tú es vital para el éxito en un panorama tan complejo como el que hemos descrito. Pero eso sí, intenta rodearte de asesores que no tengan sesgos ni agendas propias que puedan no coincidir con las tuyas.

Atribución imagen de portada Creative Commons