La ingeniería de plataformas está ganando terreno entre las organizaciones de ingeniería de software de alto rendimiento, y por una buena razón. Plataformas internas para desarrolladores (IDP) puede aumentar la productividad del desarrollador, eliminar los cuellos de botella de Ops, reducir la carga cognitiva del desarrollador y hacer cumplir la estandarización por diseño. ¿Pero la mejor noticia? Ahora hay una manera mucho más fácil de construir un IDP de nivel empresarial efectivo que está generando mucho revuelo en la comunidad de ingeniería de plataformas.
Aunque cada plataforma se ve diferente, surgen patrones comunes entre las configuraciones efectivas. En la conferencia PlatformCon 2023, Stephan Schneider, socio asociado de expertos digitales, y Mike Gatto, ingeniero senior de DevOps en McKinsey, compartieron cómo sintetizaron diseños de plataformas del mundo real de cientos de organizaciones en modelos estándar.
Estos modelos han sido la base de la arquitectura de referencia para las plataformas de nivel empresarial. Las organizaciones ahora tienen un modelo estándar, probado, escalable y repetible a seguir que es aplicable a cualquier elección de herramienta. Y eso le permite crear rápidamente IDP acortar el tiempo de comercialización (TTM), mejorar las mejores prácticas de la cadena de suministro de software, impulsar el crecimiento de los ingresos y mantenerse por delante de la competencia. ¿Entonces cómo funciona exactamente?
Según McKinsey, existen cinco planos principales que componen diferentes áreas de la arquitectura de la plataforma que incluyen ciertas funcionalidades.
Nota: Los componentes y herramientas que se mencionan a continuación se aplican a la aplicación Configuración basada en AWS, pero todos son intercambiables. Se pueden implementar arquitecturas de referencia similares PCG, Azur, OpenShift o cualquier configuración híbrida. Utilice esta referencia como punto de partida, pero prefiera incluir componentes que ya existen en su configuración.
- Nivel del plano de control del desarrollador Contiene las principales «interfaces» que los desarrolladores pueden usar cuando usan la plataforma. Siguiendo el principio de diseño del camino dorado, es mejor dejar los cambios de la interfaz al desarrollador dependiendo de la carga de trabajo. Y mantener intactos los flujos de trabajo de los desarrolladores existentes tanto como sea posible mediante el código predeterminado.
- El Nivel de plan de integración y entrega contiene herramientas que crean, almacenan, configuran e implementan solicitudes desde el plano de control del desarrollador.
- El Nivel del plan de recursos contiene todos los componentes de recursos necesarios para ejecutar la aplicación. Los recursos se pueden configurar como código utilizando herramientas como Terraform.
- El Plan de Seguimiento y Registro proporciona métricas y registros en tiempo real para aplicaciones e infraestructura. Los desarrolladores pueden usar este avión para la observación, el monitoreo y la toma de decisiones basadas en datos.
- El Avión de seguridad gestiona los secretos y la identidad para proteger la información confidencial, como el almacenamiento, la gestión y la recuperación de seguridad de claves y contraseñas de API.
Los equipos de plataforma son responsables de conectar los componentes individuales de la aeronave entre sí, así como de un avión a otro. También deben probar y refinar el flujo de la arquitectura de extremo a extremo para garantizar una experiencia de desarrollador fluida (DevEx).
Aumentando los Caminos Dorados
Para comprender cómo funcionan juntos los blueprints y los componentes de esta arquitectura, es útil seguir una implementación desde el impulso inicial de git hasta la aplicación en ejecución. El «camino de oro» hace referencia a las herramientas y los flujos de trabajo que utiliza el equipo de la plataforma para estandarizar y acelerar la entrega de software. Los caminos dorados deben definirse de una manera que mejore DevEx y preserve la libertad de los desarrolladores para salirse del camino cuando sea necesario. Aquí es donde entra en juego Humanitec Platform Orchestrator. Los equipos de ingeniería de plataformas usan Platform Orchestrator para diseñar caminos dorados y definir convenciones claras para su organización. Los desarrolladores describen los recursos que necesitan para ejecutar sus cargas de trabajo utilizando la puntuación de especificación de carga de trabajo de código abierto (o UI, CLI, API).
Veamos cómo funciona todo esto.
Ruta Dorada 1: Desarrollo
Supongamos que un desarrollador desea propagar los cambios realizados en una carga de trabajo al desarrollador.
El camino dorado se vería así:
- Un desarrollador modifica una carga de trabajo y git inserta el código.
- La canalización de CI recibe y ejecuta el código.
- La imagen se construye y almacena en el registro de imágenes.
- Se notifica a Platform Orchestrator. Crea las configuraciones de infraestructura y aplicaciones necesarias y prepara todos los componentes para la implementación mediante la ejecución de un modelo de ejecución RMCD (lectura, enlace, creación e implementación).
- Fase de lectura: el orquestador interpreta la especificación de la carga de trabajo.
- Fase de partido: el orquestador elimina el contexto (etiqueta de CI o metadatos) e identifica los recursos apropiados para conectar la carga de trabajo.
- Crear fase: el orquestador crea configuraciones de aplicaciones aplicando la especificación de carga de trabajo al perfil de carga de trabajo.
- Fase de expansión: el orquestador orquesta los recursos y realiza la implementación o subcontrata a sistemas de CD dedicados.
Camino dorado 2: Creando un nuevo recurso
Digamos que un desarrollador necesita un ArangoDB, pero la configuración aún no lo sabe. La gestión de configuración dinámica (DCM) permite a los desarrolladores expandir o personalizar los recursos disponibles simplemente agregando una definición de recurso a la línea de base general de la organización. Al igual que con la implementación de Dev, Platform Orchestrator se encarga del resto.
Golden Path 3: Actualización de un recurso
Esta es un área donde los ingenieros de plataformas pueden usar la plataforma para mantener un alto nivel de estandarización en toda la organización. Supongamos que un ingeniero de plataforma desea actualizar todos los recursos de Postgres, en todas las cargas de trabajo que dependen de ellos, a la última versión de Postgres. Para lograr esto, los ingenieros de la plataforma:
- Actualice la definición de recursos de los recursos de desarrollo de Postgres. Si Postgres está configurado en Terraform, solo es cuestión de actualizar el módulo de Terraform. Si no, contratarían al conductor.
- Si es necesario cambiar las entradas y salidas, actualice la definición del recurso Proveedor de terraformación del orquestador
- Encuentre qué cargas de trabajo dependen del orquestador de la plataforma en «dev Postgres». Esto se puede hacer haciendo ping a la API de Orchestrator o mirando la interfaz de usuario.
- Autocompletar la implementación en todas las cargas de trabajo que dependen del tipo de recurso «Desarrollador de Postgres».
De esta forma, la nueva versión se implementa en todas las cargas de trabajo y aplicaciones.
Comience su viaje de plataforma de la manera correcta
Así que ahí lo tienes. Independientemente de su configuración, la arquitectura de referencia de IDP discutida por McKinsey es un cambio de juego completo para las organizaciones que comienzan su viaje de ingeniería de plataforma. No solo enseña a los equipos de plataforma los principios de diseño de IDP probados, sino que también muestra cómo encajan los componentes arquitectónicos y cómo diseñar grandes patrones de interacción para ingenieros y desarrolladores.
Al crear caminos dorados para un mayor autoservicio de desarrolladores, los equipos de la plataforma pueden optimizar la forma en que trabajan los desarrolladores y reducir la necesidad de trabajo manual y operaciones de tickets, lo que permite que los equipos de operaciones se centren más en realizar mejoras en lugar de solicitudes ad hoc. . Al seguir estos patrones de diseño comprobados, puede asegurarse de que su IDP satisfaga sus necesidades de desarrollador y sus objetivos comerciales generales.
Mi equipo en Humanitec, inspirado por el discurso de McKinsey, creó varios documentos técnicos, no solo para AWS, sino también para GCP y Azure. Muestran cómo se integran las aeronaves y los componentes, muestran cómo los desarrolladores, las operaciones y los equipos de plataforma pueden usar la plataforma y brindan más ejemplos de caminos dorados. Puede navegar por las tres arquitecturas de referencia de la plataforma por encabezado aquí.
