Por Andrea C. Crawford – Ingeniera distinguida de IBM
DevOps no es nuevo.
La primera conferencia DevOps Days se llevó a cabo en Gante, Bélgica, en 2009. Hudson (el precursor de Jenkins) cumplió 15 años en febrero de 2020. Aunque ha pasado un tiempo desde los primeros días de DevOps (¿recuerda estos retrocesos de 2009 ?), hemos aprendido mucho. Hay temas perennes de DevOps que siguen siendo absolutamente relevantes. Sin embargo, la tecnología, la arquitectura, las plataformas, los negocios y las regulaciones han avanzado en la última década, es hora de un enfoque moderno de DevOps.
Lo que no ha cambiado en DevOps:
Aumentar la velocidad y la calidad de la entrega de software
Uniendo Desarrollo y Operaciones
Eliminar el comportamiento de “tíralo por encima de la cerca”
Ser responsable de un producto desde la ideación hasta la gestión del “Día 2”
Compatibilidad con Design Thinking, Agile y Lean
Qué ha cambiado en DevOps:
Expandir las partes interesadas para incluir más que Desarrollo y Operaciones (piense en Seguridad, Auditores, Ingeniería de Infraestructura) y, por lo tanto, expandir DevOps a la infraestructura y los activos empresariales.
El surgimiento y la maduración de contenedores y Kubernetes, estandarizan el “Sistema operativo en la nube” y permiten una mayor portabilidad entre proveedores y en las instalaciones.
La nube. Si bien la nube es más antigua que DevOps, las empresas están acelerando la adopción de la nube, estrangulando monolitos y reformulando la entrega para aplicaciones nativas de la nube.
Automatiza todo. Tenga una mentalidad de desarrollador hacia la prueba, la implementación de producción, las operaciones y evite todas las tareas manuales.
El manifiesto moderno de DevOps
Todo es código : infraestructura, configuración, acciones y cambios en la producción, todo puede ser código. Cuando todo es código, todo necesita DevOps.
Establezca recursos “confiables” : los activos empresariales, como imágenes, plantillas, políticas, manifiestos, configuraciones que codifican estándares deben regirse (con una canalización).
Apóyese en el privilegio mínimo : están surgiendo nuevos roles: ingeniero de clúster, ingeniero de imágenes, ingeniero de confiabilidad del sitio… defina roles con el acceso justo a los recursos “confiables” a los que acceden para realizar su trabajo, mitigar el riesgo y limitar la exposición.
Todo es observable : siente las bases de la IA para oleoductos recopilando y organizando datos de un oleoducto instrumentado.
Amplíe su definición de “todo” : DevOps no es solo para el código de la aplicación. DevOps puede aplicarse al modelo de aprendizaje automático (MLOps o ModelOps), integración (ciclo de vida de API), infraestructura y configuración (GitOps) y otros dominios. Amplíe sus partes interesadas para incluir seguridad y auditores… la próxima evolución para romper los silos.
Todo es código
El código es el modelo para las aplicaciones. El código fuente se almacena en un repositorio y tiene una canalización que transforma y coloca el código fuente en su entorno de tiempo de ejecución. Con la llegada de la nube, los contenedores y la adopción de k8, las configuraciones para aplicaciones, clústeres, enlaces de servicios y redes también se expresan como código (es decir, YAML). Las configuraciones aplicadas a través de una CLI son ciudadanos de primera clase. Conocidos como GitOps, ahora podemos traer los beneficios de las canalizaciones, la gobernanza, las herramientas y la automatización a las operaciones y esta nueva clase de “código”. Bienvenido al siguiente paso en Infraestructura como código. Cuando todo se convierte en código, todo puede tener su propia canalización, lo que lleva la TI de múltiples velocidades a un nivel completamente nuevo. Una canalización para aplicaciones, una canalización para configuración de aplicaciones, una canalización para configuración de clúster, una canalización para imágenes, una canalización para dependencias lib. Cada tubería tiene su propia velocidad y todas están desacopladas entre sí. Ver el mundo en tuberías!
Establecer recursos confiables
Hay recursos empresariales que se utilizan para ensamblar aplicaciones en la nube. Los activos heredados del pasado (imágenes de VM, paquetes de compilación, versiones de middleware, dependencias de lib) están evolucionando a imágenes, configuraciones de clúster y definiciones de políticas que se comparten en varios proyectos. Estos activos empresariales deben tener su propio ciclo de vida, canalización, gobernanza y ciclo de vida de implementación. Estos activos deben ser confiables y fáciles de consumir. Un activo de confianza debe administrarse en un repositorio con un conjunto claramente definido de actividades de canalización que fortalecen, protegen y verifican de acuerdo con los estándares empresariales y el cumplimiento normativo. Un activo de confianza debe tener un estado que indique que se puede consumir de forma segura. Una vez que se otorga a un activo el estado de confianza (haciéndolo a través de una canalización), debe publicarse para su consumo (esto podría ser tan simple como etiquetar una imagen en un registro). Los activos de confianza deben mantenerse y gobernarse activamente.
Apóyate en el privilegio mínimo
El Principio de Mínimo Privilegio (PoLP) establece que los sistemas, procesos y usuarios solo tienen acceso a los recursos que son necesarios para completar sus tareas. Con todo como código y activos de confianza identificados, comienzan a surgir nuevos roles y responsabilidades. Una imagen podría considerarse un activo confiable, se obtiene de un Dockerfile (administrado en un repositorio de código fuente). Ese Dockerfile pasa por una canalización automatizada que crea una imagen y ejecuta un escaneo y una prueba rigurosos que, en última instancia, insertan y etiquetan una imagen como “confiable” en un registro de contenedor privado empresarial. El rol de un ingeniero de imágenes podría surgir como una persona que crea, selecciona y administra los Dockerfiles que se introducen en la canalización de imágenes. Solo los ingenieros de imagen necesitarían tener autoridad de “inserción” en el repositorio donde se administran los Dockerfiles. Si La separación de funciones es una preocupación, el rol de ingeniero de imágenes puede estar restringido a aquellos que no tienen el rol de desarrollador, para mitigar el riesgo de que una persona tenga demasiada influencia sobre un contenedor de tiempo de ejecución. Se pueden definir nuevas personas para ingenieros de clúster, ingenieros de confiabilidad del sitio, etc., cada uno con un conjunto claramente definido de responsabilidades y privilegios.
Todo es Observable
La mecánica de llevar una idea a una función en ejecución en producción puede ser un proceso de larga duración. Hay eventos de canalización significativos que se recopilarán con el propósito expreso de crear métricas de canalización, calcular medidas de entrega, correlacionar eventos de canalización con eventos operativos y establecer una línea de vida de características forenses para auditores y seguridad de TI. Los conductos deben estar equipados con recopilación y organización de eventos. Un lago de datos de eventos en el que los análisis y los modelos de máquinas podrían construirse y vincularse con datos de gestión de cambios, incidentes y problemas en el “Día 2”. IBM AI Ladder comienza con Recopilar y Organizar, y eventualmente conduce a Analizar e Infundir capacidades cognitivas, en este caso, IA para canalizaciones.
Ampliar la definición de “Todo”
En el pasado, “todo” significaba código de aplicación y scripts de base de datos. Aquellos que avanzaron en la curva de madurez incluirían casos de prueba, scripts de monitoreo, scripts de infraestructura para tareas comunes y los pondrían bajo el control del código fuente. Ahora amplíelo. Los modelos de aprendizaje automático, las API e incluso las canalizaciones mismas son código. Escuchará términos como ModelOps, gestión del ciclo de vida de la API o canalización (¿PipeOps?), pero no se distraiga. Esa es solo la marcha constante del progreso y el deseo de brindar mayor velocidad y calidad a otras partes del ecosistema de TI. ¡DevOps para todos!
El Manifiesto moderno de DevOps es una combinación de la herencia y el estado moderno de entrega actual. Habrá más cambios para DevOps, el tiempo no se detiene. Estamos viendo un surgimiento y maduración de la IA, el aprendizaje automático, el borde y la cuántica. Habrá permutaciones para estos dominios que continuarán madurando y emergiendo.
¿Cómo adoptará su empresa el Manifiesto Modern DevOps?
¿Cómo adoptará su empresa el Manifiesto Modern DevOps?
Comentarios recientes