Compartir a través de


Capacitar a los desarrolladores a través de autoservicio con barreras de protección

El autoservicio con límites de protección es el principio de capacitar a los equipos de desarrollo para tomar sus propias decisiones dentro de un conjunto de parámetros bien definidos o barreras de protección. Las barreras de protección están establecidas y acordadas por las partes interesadas clave. Las partes interesadas pueden incluir seguridad, operaciones, equipos de arquitectura en toda la organización.

Con el autoservicio con barreras de protección, los equipos de desarrollo conservan la autonomía para tomar decisiones de desarrollo de forma independiente. La automatización y la directiva ayudan a las partes interesadas a garantizar que la seguridad, el cumplimiento, las operaciones, los estándares y los costos se administran correctamente. La habilitación de esta automatización requiere colaboración entre líneas de equipo para que los desarrolladores, operadores y especialistas puedan hacer más, sin sacrificar la gobernanza necesaria. A continuación, los desarrolladores pueden centrarse en ofrecer valor empresarial lo más rápido posible.

[Le decimos a los desarrolladores] no se preocupe de cómo funciona todo, simplemente de activarlos o desactivarlos, rellenarlo, colocar una cadena en lo que necesite hacer y es básicamente autoservicio en ese sentido, donde tienen un archivo Léame y tienen entradas, salidas y pueden colocar en lo que les guste. - Daniel, Ingeniero en la nube, Fortune 500 Media Company

El objetivo de proporcionar una experiencia de autoservicio para las rutas de acceso asfaltadas es reducir el trabajo del desarrollador, al tiempo que proporciona visibilidad a los equipos de desarrollo, las operaciones y la administración. La idea es que cree una experiencia para una tarea determinada que tenga una curva de aprendizaje mínima, gracias en parte a sus funcionalidades subyacentes de automatización y agregación de datos. Además de actividades como el aprovisionamiento de infraestructura, estas experiencias pueden proporcionar acceso a funcionalidades críticas para la observabilidad, la directiva, la administración de incidentes, etc. La idea se extiende a la detección y el uso compartido de API internas, SDK, junto con herramientas y servicios compartidos. Estas experiencias reducen la sobrecarga para que los equipos de desarrollo puedan centrarse en realizar las cosas.

Las plataformas de desarrollo internas permiten a los desarrolladores actuar como clientes de escaparate digital

Las plataformas de desarrollo internas proporcionan funcionalidades similares a los escaparates digitales de negocio a negocio. Las tiendas digitales están diseñadas inherentemente para ayudar a sus clientes a autoservicio. Pueden controlar más rendimiento que los frentes de tienda tradicionales, ya que proporcionan maneras de descubrir y cumplir los elementos que son interesantes sin tener que hablar con nadie. Con esta analogía, los desarrolladores son el cliente y la plataforma de desarrollo interna proporciona experiencias de autoservicio similares. Al igual que un minorista, operadores, ingenieros de plataforma y otros roles, luego configurar un catálogo de elementos que los desarrolladores pueden solicitar que estén diseñados para dar cabida a los límites de protección de la organización.

Por ejemplo, puede pensar en un desarrollador que solicita acceso a una nueva herramienta como si estuvieran realizando un pedido de escaparate digital. Al igual que un pedido, una vez enviada la solicitud, el desarrollador quiere poder realizar un seguimiento del progreso y saber cuándo se ha completado. En segundo plano, la solicitud debe enrutarse automáticamente al proveedor de suministro correcto para satisfacer la necesidad. Puede considerar uno de los sistemas de integración y entrega continuas (CI/CD) como proveedor de suministro, una herramienta de GitOps o una plataforma de aplicación prescriptiva como segundo, y una herramienta de automatización de flujos de trabajo para procesos manuales como un tercero. En todos los casos, el desarrollador puede autoservicio de elementos de un catálogo bien definido de la misma manera.

Usar todo como patrón de código

El uso de la infraestructura como código (IaC) a través de canalizaciones de entrega continua (CD) y herramientas de GitOps es una parte importante de la habilitación del autoservicio. IaC con CD permite usar Bicep, Terraform, gráficos de Helm y otras herramientas para crear y destruir recursos en la nube a petición. Dado que la configuración de la infraestructura en la nube se administra igual que el código en un repositorio de código fuente, puede aplicar todas las ventajas de un repositorio git, como la seguridad y la auditabilidad.

El aprovisionamiento de herramientas y infraestructura comunes no es la única ventaja de un enfoque de IaC. Puede adaptarlo como patrón de código para otros escenarios, incluida la seguridad como código y directiva como código (a través de herramientas como Azure Policy y Open Policy Agent). Siguiendo esta técnica, se inserta un archivo de configuración, normalmente YAML o JSON, en el repositorio, en cuyo punto se desencadena un flujo de trabajo que procesa el archivo. Estos archivos pueden ser un repositorio de aplicaciones como dependabot.yml o CODEOWNERS, o bien se pueden mantener en un repositorio central independiente. Incluso puede ampliar esto en sus propios escenarios para hacer que todo sea realmente como código (EaC) una realidad.

Los desarrolladores pueden hacer referencia a cada una de estas plantillas de EaC con un catálogo central que impulsa sus experiencias de autoservicio y fomenta los procedimientos recomendados de forma predeterminada.

Creación de plantillas correctas de inicio y establecimiento de una gobernanza correcta

En el desarrollo de software, buscamos la encapsulación, la modularidad y la composición al diseñar aplicaciones. Debe aplicar esta misma línea de pensamiento a la ingeniería de plataforma a través de plantillas. Por ejemplo, puede crear y usar un conjunto de plantillas iaC reutilizables y protegidas centralmente como bloques de creación para la infraestructura.

Crearemos módulos para nuestros [desarrolladores]... por lo tanto, en lugar de tener que escribir o preocuparse por cualquiera de los back-end, todo lo que deben hacer es preocuparse por su código de aplicación. - Daniel, Ingeniero en la nube, Fortune 500 Media Company

Combine IaC, EaC y plantillas de aplicación en una solución personalizada como código (EaC) que se extiende a otras actividades, como crear un repositorio de código fuente, inicializar código de ejemplo o proporcionar configuración y código de ejemplo para herramientas de observabilidad recomendadas. Estas plantillas de aplicación, EaC y IaC se pueden almacenar o hacer referencia desde una ubicación central y protegida, como un repositorio, el catálogo en Entornos de implementación de Azure (ADE) o Azure Container Registry (ACR) para la nube nativa.

Cuando las plantillas adecuadas de inicio se combinan con la gobernanza automatizada, el examen y la configuración de directivas, los desarrolladores permanecen directamente desde el primer día.

Gráfico de la introducción a la plantilla de ingeniería de plataformas y mantenerse a la derecha.

Las plantillas simplifican el desarrollo con prácticas automatizadas y seguras

Use plantillas de aplicación para arrancar las rutas de acceso definidas para varias decisiones y acciones clave que los desarrolladores toman durante el transcurso de un proyecto. Las plantillas correctas de inicio establecen prácticas de desarrollo seguras, reguladas y permiten a los desarrolladores empezar a trabajar rápidamente al habilitar la automatización que proporciona acceso a las herramientas que necesitan, configura las canalizaciones de CI/CD, aprovisiona la infraestructura y la pila de aplicaciones, y configura un repositorio completo con código fuente de placa reutilizable que incluye SDK necesarios o referencias a las API.

Al hacer que estas plantillas de aplicación hagan referencia a otras plantillas centralizadas (por ejemplo, plantillas de IaC), cada uno de estos bloques de creación individuales se convierte en plantillas adecuadas propias. Estas plantillas son fundamentales para habilitar experiencias de autoservicio, ya que no solo definen salidas, sino también opciones disponibles entre las que los desarrolladores eligen.

Las plantillas garantizan la gobernanza, la seguridad y la optimización de costos

Sin embargo, las plantillas deben hacer algo más que arrancar un esfuerzo de desarrollo. También deben establecer el control y la gobernanza a través del examen de directivas y seguridad necesarios para mantenerse justo durante el ciclo de vida del proyecto. Como otro ejemplo, las plantillas pueden configurar reglas de protección de rama que impidan combinaciones no autorizadas en producción. Dado que las plantillas capturan procedimientos recomendados y configuraciones comunes, son una de las técnicas clave para optimizar los costos entre herramientas, proveedores y equipos.

Ejecutar campañas adecuadas para crear comunicación bidireccional

Por último, a medida que aumente la confianza en las rutas de acceso asfaltadas, puede usar los bloques de creación individuales subyacentes que ha ensamblado en las plantillas de aplicación para mover las aplicaciones existentes a una ruta de acceso asfaltada. Dado que los clientes internos ya verán el valor de las rutas de acceso asfaltadas piloto, puede ejecutar una campaña interna para crear un cuadro de diálogo bidireccional con otros equipos de aplicaciones. Los desarrolladores pueden aprender a migrar su aplicación mientras que el equipo de ingeniería de plataformas aprende más sobre cómo mejorar la plataforma para ellos.

Gráfico de su propio recorrido

Dada la amplitud de las experiencias que sus funcionalidades de autoservicio podrían cubrir, es un enfoque importante para los esfuerzos de inversión y Planear y priorizar para que la plataforma de desarrollo interna ofrezca valor incrementalmente. El recorrido de cada organización para crear su plataforma de desarrollador interna es diferente y seguir una mentalidad de producto le ayuda a dirigirse primero a los lugares más críticos que necesitan experiencias de autoservicio.