4 elementos clave de Platform Engineering.

En este post vamos a desentrañar los conceptos clave de Platform Engineering. Hemos dividido los elementos esenciales de una forma fácil de entender, incluso si estás empezando. Exploraremos qué significa tratar tu plataforma como un producto, por qué contar con una Internal Developer Platform (IDP) facilita el trabajo, cómo la estructura adecuada del equipo mejora la eficiencia y en qué consisten los “Golden Paths”. Al final, tendrás una comprensión sólida de estas ideas fundamentales y, con suerte, algo de inspiración para pensar en una estrategia de plataforma para tu propia organización.

Introducción a los elementos clave de Platform Engineering

Platform Engineering introduce varios elementos clave diseñados para crear un entorno más eficiente y amigable para los equipos de desarrollo:

1. Mentalidad de producto.

• Tratar la plataforma como un producto implica iterar continuamente en base al feedback y a métricas de rendimiento.
• Esto asegura que la plataforma se mantenga relevante, fácil de usar y capaz de satisfacer las necesidades de la organización a lo largo del tiempo.

2. Internal Developer Platform (IDP).

• La IDP es el núcleo de Platform Engineering, actuando como un centro donde los equipos de desarrollo pueden acceder a todos los recursos necesarios, desde infraestructura hasta herramientas de observabilidad. Al simplificar el acceso, la IDP mejora la productividad al reducir el tiempo dedicado a tareas no esenciales.

3. Un equipo de plataforma y una nueva topología de equipos.

• La colaboración efectiva entre equipos es fundamental para Platform Engineering. Al estructurar los equipos de acuerdo con sus funciones y flujos de trabajo, Platform Engineering reduce la carga cognitiva y permite que los equipos alineados en flujos de entrega de valor se centren en entregar valor de negocio al abstraer la complejidad.
• Un equipo de plataforma unificado permite tomar decisiones y desarrollos coherentes relacionados con la plataforma en toda la organización.

4. Golden Paths o abstracciones.

• Son flujos de trabajo predefinidos y estandarizados que simplifican tareas comunes.
• Al ofrecer enfoques basados en buenas prácticas, los Golden Paths crean bases escalables y confiables para reducir la carga de decisión en los equipos de desarrollo, acelerando el proceso y asegurando la consistencia.

Mentalidad de producto

Adoptar una mentalidad de producto para la plataforma significa tratarla como un servicio en evolución continua en lugar de como un proyecto único. Este enfoque se centra en satisfacer las necesidades de los equipos de desarrollo a través de actualizaciones e iteraciones regulares basadas en el feedback y en métricas de rendimiento.

Elementos clave de una mentalidad de producto

• Diseño centrado en el usuario: construir la plataforma pensando en los usuarios finales. Interactuar regularmente con los equipos de desarrollo para entender sus necesidades y puntos de dolor, asegurando que la plataforma realmente apoye sus flujos de trabajo.
• Bucle de feedback continuo: recopilar y actuar sobre su feedback regularmente para informar la hoja de ruta de la plataforma. Esto mantiene la plataforma alineada con sus necesidades reales.
• Métricas de rendimiento: rastrear indicadores clave de rendimiento (KPIs) como tasas de adopción, tiempo de salida al mercado y satisfacción del equipo de desarrollo. Utilizar estos datos para guiar decisiones y priorizar mejoras.
• Desarrollo iterativo: liberar actualizaciones y nuevas funcionalidades de manera continua, cada una informada por las opiniones de feedback y los datos de rendimiento. Este enfoque ágil asegura que la plataforma evolucione para satisfacer necesidades cambiantes.

Experiencia del equipo de desarrollo

Al igual que la experiencia de usuario (UX) minimiza la fricción entre una herramienta y los objetivos del usuario, Developer Experience (DevEx) se centra en mejorar la productividad y satisfacción de los equipos de desarrollo. En el contexto de una plataforma-como-producto, DevEx trata de crear un entorno en el que los equipos de desarrollo puedan trabajar de forma eficiente y eficaz, con mínima fricción entre la plataforma y el objetivo final de entrega continua de valor.

Developer Experience (DevEx) es esencial para tratar la plataforma como un producto, enfocándose en eliminar las barreras que podrían ralentizar o frustrar a los equipos de desarrollo. Esto implica automatizar tareas repetitivas, simplificar procesos de despliegue y garantizar que todos los recursos necesarios sean fácilmente accesibles. Al simplificar los flujos de trabajo mediante interfaces intuitivas, integraciones fluidas y procesos bien documentados, la plataforma puede minimizar la fricción, permitiendo a los equipos alcanzar sus objetivos con poco esfuerzo y, en última instancia, mejorar la productividad y la satisfacción.

Garantizando relevancia a largo plazo

Una plataforma tratada como un producto permanece adaptable y escalable. Al interactuar regularmente con los usuarios y alinear los desarrollos de la plataforma con los objetivos empresariales, la plataforma se mantiene relevante y valiosa a lo largo del tiempo. Este enfoque no solo mejora la satisfacción del usuario, sino que también asegura que la plataforma siga siendo un habilitador crítico del éxito empresarial.

Internal Developer Platform

Las Internal Developer Platforms (IDPs) son la piedra angular de Platform Engineering, actuando como un lugar centralizado donde los equipos de desarrollo pueden acceder a todos los recursos que necesitan, desde infraestructura hasta herramientas de observabilidad. Al simplificar el acceso a estos recursos, las IDPs mejoran significativamente la productividad de los equipos de desarrollo, permitiéndoles centrarse en tareas esenciales en lugar de quedar atrapados en complejidades operativas.

Evan Bottcher encapsula este concepto al afirmar: “Una plataforma digital es una base de APIs self-service, herramientas, servicios, conocimiento y soporte organizados como un producto interno atractivo.” Como el elemento central de Platform Engineering, las IDPs permiten una experiencia self-service para las capacidades de la plataforma, adaptada a las necesidades de los equipos internos. Simplifican los flujos de trabajo, reducen la sobrecarga operativa y aceleran el tiempo de salida al mercado, lo que las convierte en esenciales para el desarrollo moderno de software.

Equipo de plataforma y topología

El concepto del equipo de plataforma y su rol dentro de una organización fue explorado a fondo en el influyente libro Team Topologies de Matthew Skelton y Manuel Pais, publicado en 2019. Este libro introdujo la idea de un equipo de plataforma unificado como una base fundamental para la entrega de software efectiva en organizaciones modernas.

Introducción al equipo de plataforma unificado

En Team Topologies, Skelton y Pais enfatizan que un equipo de plataforma unificado es esencial para crear una base sólida sobre la cual los equipos de producto pueden construir y entregar valor de manera más eficiente. La misión del equipo de plataforma es reducir la carga cognitiva en los equipos de producto al proporcionar un conjunto de capacidades self-service bien definidas que sean fáciles de consumir. Esto permite que los equipos de producto se concentren en su misión principal: entregar funcionalidades y mejoras a los usuarios finales sin quedar atrapados en las complejidades de la infraestructura subyacente.

Misión del equipo de plataforma

A medida que las organizaciones crecen, la naturaleza descentralizada de las prácticas DevOps tradicionales a menudo lleva a ineficiencias y complejidad. Platform Engineering ofrece una solución al proporcionar un enfoque más organizado y centralizado para gestionar el ciclo de vida del desarrollo de software. Esta centralización es vital para manejar las complejidades de los entornos de desarrollo modernos, donde mantener la agilidad y competitividad es crucial.

La misión del equipo de plataforma va más allá de simplemente ofrecer herramientas o infraestructura. Involucra la creación de una Internal Developer Platform (IDP) integral que abstrae y simplifica las complejidades de la entrega de software. Las responsabilidades clave del equipo de plataforma incluyen:

• Habilitar el self-service. El equipo de plataforma proporciona capacidades self-service que permiten a los equipos de producto desplegar, gestionar y monitorear sus aplicaciones sin depender de otros equipos.
• Estandarización y consistencia. Al ofrecer herramientas, procesos y entornos estandarizados, el equipo de plataforma asegura que todos los equipos trabajen dentro de un marco consistente, reduciendo la variabilidad y el riesgo de errores.
• Reducir la carga cognitiva. El equipo de plataforma asume la complejidad de gestionar infraestructura, pipelines CI/CD y otros elementos fundamentales, para que los equipos de producto puedan centrarse en el desarrollo de funcionalidades e innovación.
• Impulsar la mejora continua. El equipo de plataforma itera continuamente sobre la plataforma, incorporando feedback de los usuarios (equipos de producto) para mejorar las capacidades y la experiencia del usuario en la plataforma.

Colaboración en la nueva topología de equipos

En la topología de equipos propuesta en Team Topologies, el equipo de plataforma colabora estrechamente con otros tipos de equipos dentro de la organización, principalmente equipos alineados en flujos de entrega de valor y equipos habilitadores:

• Equipos alineados en flujos de entrega de valor. Estos son equipos orientados al producto que entregan funcionalidades y servicios directamente a los usuarios finales. El equipo de plataforma apoya a estos equipos proporcionando las herramientas e infraestructuras necesarias para desarrollar, probar y desplegar sus aplicaciones de manera eficiente. El rol del equipo de plataforma es asegurar que los equipos alineados en flujos de entrega de valor puedan operar con mínima fricción.
• Equipos habilitadores. Estos equipos se especializan en áreas como DevOps, seguridad o UX y trabajan junto al equipo de plataforma y los equipos alineados en flujos de entrega de valor para asegurar que se sigan las mejores prácticas. El equipo de plataforma colabora con los equipos habilitadores para incorporar su experiencia, asegurando que cumpla con los requisitos técnicos y de compliance de la organización.

El equipo de plataforma también debe mantener canales de comunicación abiertos con todos los demás equipos para asegurar que la plataforma evolucione en alineación con las necesidades de la organización. Los bucles de feedback regulares, los workshops y las sesiones de planificación colaborativa son esenciales para mantener la plataforma relevante y efectiva.

Un nuevo modelo de colaboración

Team Topologies introduce un nuevo modelo de colaboración que gira en torno a la fluidez en el cambio, la alineación de responsabilidades e interacciones de equipo bien definidas. El equipo de plataforma actúa como un proveedor de servicios interno, pero con una fuerte mentalidad de producto, en la que la plataforma se trata como un producto con su propia hoja de ruta, consideraciones de experiencia de usuario y ciclo de mejora continua.

En este modelo, el equipo de plataforma no es un guardián de acceso, sino un facilitador. El objetivo es empoderar a otros equipos para que entreguen valor de forma autónoma, asegurando al mismo tiempo que los estándares y prácticas de la organización se apliquen de manera consistente en todos los proyectos.

Golden Paths

Un componente crucial de Platform Engineering es el concepto de Golden Paths. Los Golden Paths son un método para exponer las capacidades y procedimientos de la plataforma de forma que sean fácilmente consumibles de forma interna. El objetivo es simplificar y optimizar estos procesos, permitiendo que los equipos se centren en su trabajo principal sin quedar atrapados en la complejidad.

Kasper von Grünberg ofrece una definición simple pero poderosa que captura la esencia de un Golden Path: “Cualquier procedimiento en el ciclo de vida de desarrollo de software que un usuario puede seguir con mínima carga cognitiva y que impulsa la estandarización.” Esta definición enfatiza el rol de los Golden Paths en reducir la complejidad y promover la estandarización en toda la organización.

A menudo, se hace referencia a los Golden Paths como abstracciones, ya que ambos términos transmiten los objetivos finales de simplificación y estandarización. A medida que los Golden Paths en tu plataforma crecen, forman un catálogo de servicios, creando efectivamente una API de plataforma: una colección de peticiones a la que los equipos pueden acceder internamente de forma self-service para interactuar con las capacidades de la plataforma.

Principios de diseño de los Golden Paths

Google proporciona una guía valiosa sobre el diseño de Golden Paths, destacando los principios clave a considerar:

1. Abordar los problemas de carga cognitiva.

• Reducir la carga cognitiva sobre la audiencia objetivo aprovechando la abstracción y ofreciendo documentación completa de inicio.
• El objetivo es simplificar la experiencia del equipo de desarrollo, haciendo que las tareas complejas sean más manejables.

2. Integrarse con las plataformas existentes

• Asegurar que los Golden Paths sean compatibles con las plataformas internas de desarrollo existentes.
• Por ejemplo, si un perfil desarrollador crea un nuevo servicio utilizando un Golden Path, este debería integrarse automáticamente con el catálogo de software gestionado por el equipo de plataforma.

3. Cubrir todo el ciclo de vida del desarrollo

• Iluminar todo el camino desde el desarrollo hasta la producción.
• Esto podría implicar proporcionar instrucciones para el desarrollo local, pipelines CI/CD y plantillas de infraestructura-como-código para entornos de staging y producción.

4. Proporcionar capacidades self-service

• Asegurar que cualquier perfil desarrollador en la organización pueda descubrir y usar los Golden Paths fácilmente, sin necesidad de un sistema de tickets.
• Empoderar a los equipos de desarrollo para que aprovechen estos caminos de forma independiente.

5. Trabajar al nivel adecuado de abstracción

• Ofrecer una abstracción clara sin ocultar la infraestructura subyacente.
• Bajo un modelo DevOps de responsabilidad compartida, los equipos de desarrollo necesitarán entender el stack completo de sus servicios para mantener, optimizar y depurarlos de manera efectiva.

6. Especificar y tener opinión

• Adaptar los Golden Paths para abordar las necesidades específicas de tu organización.
• Por ejemplo, si tu organización maneja principalmente migraciones “brownfield” (modernización de sistemas existentes), diseña Golden Paths que apoyen estos caminos de migración, en lugar de centrarse en nuevos servicios “greenfield” (nuevas implementaciones).

7. Mantener la flexibilidad

• Diseñar los Golden Paths para satisfacer las necesidades de múltiples audiencias.
• Por ejemplo, un Golden Path puede utilizar por defecto una base de datos SQL, pero debería permitir la sustitución por una base de datos NoSQL si fuera necesario.

8. Hacer que la adopción sea opcional (no una “jaula dorada”)

• Los Golden Paths deben ser un recurso, no una restricción.
• Los equipos de desarrollo deberían tener la libertad de elegir si adoptan un Golden Path según si satisface sus necesidades específicas.

Conceptos erróneos sobre los Golden Paths

A menudo, se asocia erróneamente el Platform Engineering solo con la simplificación de la infraestructura y DevOps, o se percibe como simplemente un portal para perfiles de desarrollo. Si tu organización se enfoca únicamente en estos aspectos, corre el riesgo de quedarse en la superficie del verdadero potencial del Platform Engineering, perdiendo su valor completo para el negocio.

• Platform Engineering como herramientas de infraestructura self-service. Algunas organizaciones se centran en crear herramientas self-service que dan a los equipos de desarrollo autonomía sobre la gestión de la infraestructura.
• Platform Engineering como un portal para el equipo de desarrollo. Otras se enfocan principalmente en mejorar su experiencia simplificando los procesos de codificación y despliegue.
• Platform Engineering como un mercado de componentes reutilizables. Algunas adoptan un enfoque de marketplace, construyendo un repositorio de componentes reutilizables como contenedores, datos y APIs.

Es esencial entender los objetivos y beneficios más amplios de Platform Engineering para evitar estos conceptos erróneos y desbloquear el potencial completo de una estrategia de plataforma.

Una estrategia de plataforma exitosa debería profundizar, con bases sólidas que generen un impacto significativo en toda la organización y no solo mejoras superficiales.

Modelo de contrato para los Golden Paths

Platform Engineering promueve una relación contractual entre su audiencia interna y la plataforma:

• Equipos de plataforma. Escriben y exponen los Golden Paths como parte de la API de la plataforma.
• Equipos de desarrollo / audiencia interna. Solicitan capacidades de la plataforma a través de esta API.
• Plataforma. Proporciona un plano de control para reconciliar las necesidades de la audiencia interna con el estado actual de la plataforma, asegurando una experiencia fluida.

¿Cómo se consumirán los Golden Paths?

Un aspecto clave del Platform Engineering es proporcionar formas flexibles e intuitivas para que la audiencia interna consuma las capacidades de la plataforma a través de los Golden Paths. Dado que los diferentes equipos y usuarios tienen necesidades y preferencias variadas, la plataforma debería ofrecer múltiples métodos para acceder a estas capacidades, asegurando que se integren fácilmente en diversos flujos de trabajo.

1. Portales de equipos de desarrollo

• Sirve como una interfaz fácil de usar que muestra las capacidades disponibles de la plataforma, facilitando a los equipos el descubrimiento y consumo de los Golden Paths.
• A través del portal, se puede explorar un catálogo de servicios, acceder a documentación e iniciar acciones con unos pocos clics.
• Este método es especialmente útil para perfiles menos técnicos o para aquellos que prefieren una interfaz visual.

2. Interfaz de línea de comandos (CLI)

• La CLI proporciona una forma rápida y adaptable de acceder a las capacidades de la plataforma, siendo una opción poderosa para los que prefieren interacciones directas basadas en comandos. Con la CLI, los equipos pueden ejecutar tareas rápidamente, automatizar flujos de trabajo y acceder a los Golden Paths de una forma que se integra a la perfección con sus herramientas y scripts existentes.
• Este método es adecuado para perfiles más técnicos que se sienten cómodos con operaciones en la línea de comandos y buscan eficiencia y control en sus flujos de trabajo.

3. Archivos YAML

• Para los equipos que prefieren la configuración-como-código, los archivos YAML ofrecen una forma sencilla de definir los parámetros necesarios para consumir las capacidades de la plataforma.
• Al proporcionar un archivo YAML con configuraciones esenciales, los equipos de desarrollo pueden integrar fácilmente los Golden Paths en sus pipelines CI/CD.
• Este enfoque es ideal para equipos acostumbrados a gestionar la infraestructura a través de configuraciones declarativas, ofreciéndoles una forma flexible y familiar de integrar los Golden Paths directamente en sus flujos de trabajo existentes.

Ofrecer múltiples formas de consumir los Golden Paths asegura que la plataforma satisfaga las diversas necesidades de sus usuarios. Algunos equipos pueden priorizar la rapidez y la simplicidad, mientras que otros pueden requerir más control y personalización. Al proporcionar diferentes niveles de abstracción e interfaces, la plataforma puede adaptarse a una amplia gama de casos de uso, impulsando una adopción más amplia y una utilización más efectiva de las capacidades de la plataforma.

Facilitando prácticas de GitOps

Una de las ventajas clave de proporcionar métodos de consumo variados es la capacidad de soportar prácticas de GitOps. GitOps enfatiza las configuraciones declarativas y el control de versiones, donde el estado deseado de todo el sistema se almacena en un repositorio Git. Los equipos pueden utilizar archivos YAML y CRDs de Kubernetes como parte de sus flujos de trabajo GitOps, asegurando que los cambios en las capacidades de la plataforma sean rastreados, auditables y aplicados automáticamente a la infraestructura.

Con GitOps, los equipos pueden integrar los Golden Paths directamente en sus pipelines CI/CD, donde los cambios en el repositorio Git desencadenan despliegues y actualizaciones automáticas. Este enfoque mejora la confiabilidad y la repetibilidad, ya que todas las interacciones con la plataforma se gestionan a través de código versionado.

Al ofrecer métodos de consumo flexibles que se alineen con los principios de GitOps, la plataforma permite a los equipos:

• Mantener trazabilidad: cada cambio en las capacidades de la plataforma se registra en Git, proporcionando un historial claro de quién realizó los cambios, cuándo y por qué.
• Automatizar despliegues: GitOps automatiza la aplicación de cambios, reduciendo la intervención manual y minimizando errores.
• Aumentar la seguridad y el compliance: al utilizar Git como la única fuente de verdad, las organizaciones pueden asegurar que todos los cambios sean revisados, aprobados y cumplan con las políticas de seguridad antes de ser aplicados.