Guía práctica para entender los Golden Paths.

Después de hablar sobre cómo lanzar una plataforma como un producto y qué características debería tener, en este post te dejamos una guía práctica para entender los Golden Paths. Para clarificar el concepto de Golden Paths, vamos a explorar un ejemplo de cómo construir un Golden Paths para introducir bases de datos relacionales como una nueva capacidad en la plataforma.

Entendiendo el escenario

Una pesadilla en la adopción de microservicios

Tu organización ha emprendido una iniciativa de modernización con el objetivo de mejorar dos dimensiones críticas: la velocidad de entrega y la escalabilidad. El CTO ha identificado la arquitectura de microservicios como el motor principal para alcanzar estos objetivos de negocio.

Como parte de esta iniciativa, los equipos de desarrollo han recibido plena responsabilidad sobre su stack técnico, empoderados por un enfoque DevOps y uno de los principios fundamentales de los microservicios: la capacidad de seleccionar la mejor tecnología para su caso de uso específico.

Inicialmente, este enfoque parecía ideal. Los equipos de desarrollo comenzaron a liberar funcionalidades usando diferentes lenguajes de programación y seleccionando varios datastores para sus microservicios.

Mientras que muchos equipos confiaban en Postgres para casos de uso relacional y Redis como key-value store, otros equipos comenzaron a adoptar tecnologías como DuckDB, MySQL, MongoDB y ElasticSearch.

El camino aparentemente correcto para la arquitectura de microservicios

• Autonomía tecnológica: los equipos estaban empoderados para seleccionar la tecnología adecuada para cada microservicio, permitiéndoles entregar funcionalidades aisladas, sin acoplamientos, escalables de manera independiente y optimizadas para el rendimiento.
• Cambio cultural hacia DevOps: los equipos eran responsables de ejecutar lo que construían, impulsando la automatización y desplazando el despliegue hacia la izquierda.

Las consecuencias no deseadas

Sin embargo, lo que inicialmente parecía el camino correcto, rápidamente llevó a un descontrol tecnológico que se convirtió en la raíz de varios problemas críticos:

• Aumento de la carga cognitiva en los equipos de desarrollo.
  • Los equipos tenían que gestionar la implementación de varios datastores, incluyendo observabilidad, backups, disaster recovery, escalabilidad, tuning y más.
  • Esta complejidad añadida desviaba su enfoque de la entrega de valor de negocio.
• Desafíos para equipos de seguridad y compliance.
  • La diversidad de tecnologías requería diferentes enfoques de seguridad y compliance, complicando los esfuerzos para asegurar consistencia y control en toda la organización.
• Preocupaciones operativas para SREs:
  • Los equipos de SRE se enfrentaban a la gestión de un amplio abanico de tecnologías, cada una con SLAs estrictos.
  • Esto añadía riesgo operativo y complejidad, afectando la estabilidad y confiabilidad de los servicios en producción.

Resultados negativos

En lugar de lograr los objetivos previstos de mayor velocidad de entrega y escalabilidad, la organización enfrentó varios contratiempos:

• Velocidad de entrega más lenta y problemas de escalabilidad:
  • Dificultades para escalar equipos o rotar contributors debido a la especialización necesaria en cada stack tecnológico.
  • Problemas para contribuir en ciertos servicios por la diversidad tecnológica.
  • Dificultades para encontrar nuevos miembros con las habilidades requeridas en este complejo entorno.
  • Equipos y colaboradores se quedaban atrapados en servicios específicos o stacks tecnológicos, reduciendo la agilidad general.
• Riesgos operacionales:
  • Dificultades para cumplir con SLAs debido a la complejidad de gestionar servicios en producción.
  • Aumento de la deuda técnica, dificultando las actualizaciones y el mantenimiento del stack tecnológico a lo largo del tiempo.
• Bloqueos de compliance y seguridad:
  • Equipos que ralentizan o bloquean nuevas funcionalidades debido a preocupaciones operativas o de seguridad, dificultando el progreso general.

Platform Engineering al rescate

Frente a estos desafíos, la organización reconoció la necesidad de estandarizar y reducir la dispersión tecnológica. Respecto a los datastores, se tomó la decisión de que cualquier servicio operativo que requiriese un datastore relacional debía usar Postgres.

Inicialmente, se planteó crear un equipo cross para centralizar la configuración y el despliegue de estos servicios comunes.

Sin embargo, el CTO se dio cuenta de que el problema no consistía únicamente en gestionar componentes técnicos individuales, sino en comprender el rol de una base de datos relacional dentro de la arquitectura organizacional. Entender qué implicaba configurar y desplegar una instancia de Postgres para su organización (estandarización de configuraciones, convención de nombres, cumplimiento de buenas prácticas y políticas, etc.), así como para su sector industrial.

Principales aprendizajes del CTO:

• No se trata de componentes individuales. El rol de la base de datos relacional debe concebirse de manera holística en lugar de simplemente centrarse en lanzar bases de datos.
• Los equipos de desarrollo necesitan un mayor nivel de abstracción. No se trata solo de ofrecer un único tipo de base de datos para casos relacionales; se trata de cómo la arquitectura aprovecha esta tecnología para entregar valor de negocio.
• La carga cognitiva es un problema real. Los equipos de desarrollo necesitan concentrarse en sus value streams para maximizar la velocidad de entrega y la eficiencia.

Platform Engineering debe abarcar toda la cadena de valor de extremo a extremo para entregar productos y aplicaciones a los usuarios finales de manera efectiva. Una capacidad de base de datos relacional en tu plataforma no se trata solo de ofrecer Database as a Service (DBaaS); se trata de comprender el papel de la base de datos relacional dentro de tu arquitectura y el valor de negocio que proporciona.

Reconociendo estos insights, el CTO lanzó una iniciativa de Platform Engineering para enfrentar estos desafíos.

Como parte de esta iniciativa, el equipo de plataforma asumió la responsabilidad de hacer que la capacidad de "relational datastore" esté disponible como parte de la Internal Developer Platform (IDP).

El objetivo es proporcionar a los equipos de desarrollo un Golden Path que les permita aprovechar eficientemente esta capacidad, reduciendo la complejidad y fomentando la estandarización en toda la organización.

Pensar en bases de datos relacionales como un Golden Path

Bases de datos en servicios operacionales

Un principio clave de la arquitectura de microservicios es que cada servicio gestiona sus propios datos. Los servicios no deben compartir un datastore para evitar acoplamientos no intencionales, lo cual podría resultar en dependencias que dificulten despliegues independientes y la escalabilidad.

Esta práctica requiere que los equipos de desarrollo puedan implementar bases de datos de manera rápida y sencilla, asegurando al mismo tiempo el cumplimiento con requisitos de seguridad y despliegue.

Sin embargo, desplegar una base de datos Postgres “ready for production” es una tarea compleja que involucra decisiones relacionadas con seguridad, despliegue, disponibilidad, backups, secrets, entre otros.

El Golden Path para bases de datos relacionales no debe exponer todos estos elementos a los equipos de desarrollo, pues esto incrementaría su carga cognitiva. En cambio, debe encargarse de estas necesidades para garantizar que sea el camino pavimentado hacia producción.

El Golden Path de la base de datos relacional debe encapsular todas las decisiones operacionales que se tomen en tu empresa para transformar un Postgres "out of the box" en un conjunto específico de configuraciones y decisiones que permitan operar una base de datos relacional en tu organización.

¿Qué necesitan realmente los equipos de desarrollo de la plataforma?

Los equipos de desarrollo no necesitan gestionar toda la complejidad de configurar y mantener bases de datos relacionales. Solo deben configurar los elementos que influyen directamente en el proceso de desarrollo, tales como:

• Computing size, almacenamiento, número de instancias
• Codificación
• Características opcionales como PostGIS

La plataforma, a su vez, proporciona una cadena de conexión a la base de datos, permitiendo que el servicio opere sin problemas dentro del framework de compliance de la organización. Esta configuración abstrae la complejidad de los equipos de desarrollo, permitiéndoles enfocarse en construir funcionalidades en lugar de gestionar infraestructura.

Simplificación de la configuración con atributos de alto nivel

Dado que los elementos que los equipos de desarrollo necesitan configurar son limitados, existe la oportunidad de simplificar aún más el proceso. El equipo de plataforma puede diseñar atributos de alto nivel para la capacidad que luego se traduzcan en las configuraciones de bajo nivel necesarias.

Por ejemplo, el equipo de plataforma podría tomar tres atributos:

• Computing size
• Almacenamiento
• Número de instancias

Y encapsularlos en un solo atributo de alto nivel llamado SIZE.

Este atributo podría usar valores como SMALL, MEDIUM, LARGE, EXTRA-LARGE, que el Golden Path traducirá a las configuraciones apropiadas para potencia de cómputo, capacidad de almacenamiento y número de instancias.

Beneficios de este enfoque

• Reducción de la carga cognitiva
  • Al reducir el número de decisiones que deben tomar, este enfoque minimiza la carga cognitiva. Los equipos de desarrollo solo deben elegir una configuración de alto nivel, dejando que la plataforma maneje los ajustes detallados.
• Ajustes específicos por entorno
  • Este método también permite que el equipo de plataforma ajuste las configuraciones subyacentes según el entorno sin requerir cambios por parte de los equipos de desarrollo.
  • Por ejemplo, una base de datos relacional extra grande puede ser significativamente más pequeña en entornos de desarrollo que en producción. Pero independientemente del entorno, los equipos de desarrollo siempre harán referencia a una base de datos relacional extra grande.

Los Golden Paths proporcionan un medio para reducir la carga cognitiva de diversas formas, preservando la capacidad de tomar decisiones de bajo nivel cuando sea necesario mientras se optimiza el proceso de configuración en general.

Al ofrecer estas abstracciones de alto nivel, la plataforma permite que los equipos de desarrollo se concentren en lo que mejor saben hacer: entregar valor de negocio.

¿Cuál es el rol real de la base de datos relacional en tu arquitectura?

El equipo de plataforma necesita comprender el uso previsto y los resultados esperados de esa base de datos dentro del contexto arquitectónico más amplio. Por ejemplo:

• Patrón Outbox:
  • La arquitectura puede definir una solución basada en eventos utilizando Change Data Capture (CDC) sobre Postgres, siguiendo un patrón Outbox.
  • Esto asegura la publicación confiable de eventos al almacenarlos en una tabla dedicada que puede ser consumida de manera asíncrona.
• Patrón de vista materializada:
  • Esto implica pre-poblar vistas con datos provenientes de múltiples servicios.
  • Estas vistas pueden ser útiles cuando una solicitud requiere datos de múltiples fuentes, haciendo ineficiente la agregación en tiempo real.
• Envío de datos a warehouses analíticos:
  • La arquitectura podría definir vistas específicas que se envían en tiempo real a un warehouse analítico para análisis y reporting.

Al comprender el propósito específico y la misión de estos requerimientos técnicos, el equipo de plataforma puede crear Golden Paths más útiles. Este enfoque permite al equipo encapsular mejor la carga cognitiva para los equipos de desarrollo, incrementando el valor de la plataforma y mejorando su misión.

Alinear las capacidades de la base de datos relacional con los objetivos comerciales más amplios asegura que la plataforma no solo cumpla con los requisitos técnicos sino que también ofrezca resultados comerciales medibles. Este alineamiento estratégico es crucial para demostrar el valor de Platform Engineering a toda la organización.

Un nuevo modelo de colaboración convergiendo en el equipo de plataforma

Los Golden Paths pueden beneficiar a múltiples personas dentro de tu organización y deben diseñarse considerando no solo el feedback de diferentes equipos, sino también sus necesidades reales.

Introducir nuevas capacidades en la plataforma, como bases de datos relacionales, requiere un nuevo modelo de colaboración:

• Equipo de plataforma:
  • Captura necesidades y feedback de todas las partes interesadas, incluidos los equipos de desarrollo, operaciones, seguridad y arquitectura.
• Equipos de desarrollo:
  • Proveen feedback sobre lo que necesitan desde una perspectiva de desarrollo, asegurando que la plataforma cumpla con sus requerimientos.
  • Esperan un camino claro para construir más rápido con un acceso definido a herramientas soportadas.
• Equipos de operaciones y seguridad:
  • Definen necesidades para asegurar que la base de datos relacional sea compliant y esté lista para producción.
  • Esperan la implementación de políticas relacionadas con seguridad, observabilidad e incluso gestión de costes.
• Equipos de arquitectura:
  • Alinean las capacidades de la plataforma con los objetivos arquitectónicos generales de la organización.

Los Golden Paths son el centro de esta relación, como se muestra en el siguiente diagrama con un enfoque de ejemplo para un Golden Path de base de datos relacional:

El feedback continuo de los equipos de desarrollo, operaciones y arquitectura son fundamentales para asegurar que las capacidades de bases de datos relacionales evolucionen en respuesta a las necesidades comerciales cambiantes y los avances tecnológicos. Este diálogo continuo ayuda a mantener la relevancia y efectividad de la plataforma.

Golden Paths y niveles de abstracción

Las plataformas deben ser componibles, ofreciendo diferentes niveles de abstracción para maximizar la flexibilidad y la reutilización:

• Golden Paths de bases de datos relacionales:
  • Este puede ser el punto de partida, pero las plataformas pueden ir más allá creando abstracciones de nivel superior.
  • Por ejemplo, tu organización podría determinar que un servicio estándar debe incluir varios servicios cloud junto con la base de datos, como un repositorio o un messaging queue.
• Arquetipos de servicio:
  • Así como la arquitectura de software utiliza arquetipos, Platform Engineering puede encapsular la infraestructura necesaria para un servicio, compuesto por varios Golden Paths de bajo nivel.
  • Este Golden Path general despliega un servicio como un quantum arquitectónico significativo dentro de la organización.

Esta componibilidad maximiza la adopción de la plataforma al permitir que los equipos elijan el nivel de abstracción adecuado sin desviarse de los estándares establecidos y el camino pavimentado de la plataforma.

A medida que la tecnología evoluciona, la plataforma debe ser lo suficientemente flexible como para acomodar futuros cambios arquitectónicos o la adopción de nuevas tecnologías de bases de datos. Esta flexibilidad asegura que la plataforma siga siendo un activo valioso para la organización con el tiempo.

Si te interesa Platform Engineering y quieres seguir profundizando en este tema, aquí tienes contenido que puede resultarte interesante:

• Qué es Platform Engineering (y qué no es)
• 4 elementos clave de Platform Engineering
• Beneficios de Platform Engineering y cuándo deberías adoptarlo
• Obstáculos para la adopción de Platform Engineering y cómo superarlos
• Cómo lanzar una plataforma como un producto y qué características debería tener