Presentación DevOps

1. DevOps Tuning y Mejora
Continua
Gabriel Jaime Noreña Ramirez

2. DevOps y arquitectura empresarial
Las empresas han entendido el peligro de las deudas técnicas. Es decir, la
sobrecarga adicional que surgen cuando software mal diseñado, mal probado y
defectuoso se acepta para ganancia a corto plazo.
La deuda arquitectónica es similar a la deuda técnica y
igualmente problemática. Las decisiones arquitectónicas
deficientes pueden limitar seriamente la capacidad de una
organización para avanzar hacia estilos de entrega más
ágiles.

3. Sin una buena arquitectura de TI se desarrolla
software “marginal”
En muchos aspectos, esto es análogo a muchas calamidades de diseño
arquitectónico hechas por TI en el pasado.

4. Construido durante muchas décadas, los diseños rígidos de aplicaciones
monolíticas se han vuelto difíciles de escalar y requieren mantenimiento costoso,
además tienen grandes problemas de integración y nos quedan sistemas que son
inadecuados para satisfacer las necesidades de los negocios digitales modernos.
Eso no quiere decir, sin embargo, que los enfoques de diseño moderno son la
panacea. Los actuales introducen nuevos problemas arquitectónicos, no menos
importante, la gestión de las dependencias y la complejidad de la monitorización.
Sin una buena arquitectura de TI se desarrolla
software “marginal”

5. La Arquitectura Empresarial (AE) debe adaptarse al
tiempo
Muchos profesionales de DevOps sostienen que las prácticas y los marcos
pesados de AE no han evolucionado para igualar el ritmo de agilidad.
El desarrollo de estilo iterativo significa esencialmente un producto final muy
diferente de la idea inicial, lo que requiere una transición de las arquitecturas
“escritas en piedra” a una mezcla más fluida basada en decisiones en constante
evolución.

6. Grandes Desarrolladores ≠ Grandes Arquitectos
-Los problemas de escalabilidad y rendimiento necesarios para abordar la estrategia
empresarial de triplicar la base de clientes y aumentar las puntuaciones de satisfacción se
descuidan porque el desarrollo sólo se concentra en ofrecer más funcionalidades.
-Los desarrolladores adquieren recursos de nube públicos para acelerar las pruebas de
aplicaciones, pero no consideran enmascarar los datos personales del cliente cuando utilizan
los datos. Como resultado, las organizaciones (especialmente aquellas en industrias
altamente reguladas) corren el riesgo de incumplir leyes que pueden causar fuertes
sanciones financieras.
-Debido al sesgo técnico basado en equipos, un grupo de desarrollo elige una base de datos
NoSQL sobre una tecnología ya utilizada. La tecnología existente habría satisfecho sus
necesidades (aunque con compromisos), pero su sesgo tecnológico ha aumentado
significativamente la carga de soporte en las operaciones de TI.

7. Nuevas Directrices y Principios
Al incorporar la experiencia de los arquitectos de las empresas dentro de los
equipos de DevOps, las organizaciones pueden mantener el ritmo de entrega de
software sin introducir caos. Sin embargo se debe limitar la re-ingeniería
arquitectónica y proporcionar a los grupos de desarrollo un conjunto mínimo de AE
para evitar la deuda técnica y arquitectónica.
AE puede ayudar a los desarrolladores a identificar rápidamente problemas críticos
de diseño de software.

8. Nuevas Directrices y Principios (Recomendaciones)
-Evite los materiales de calidad inferior o no soportados
-Las nuevas tecnologías no deberían reubicar viejos problemas
-Supervisar y gestionar subcontratistas

9. Acciones para establecer Arquitectura Empresarial
en los programas de DevOps
-Comunicación: Para dar a conocer la importancia de las prácticas y estándares de
arquitectura flexibles. Esto implica un acercamiento más estrecho con los
desarrolladores para asegurar que se tomen las decisiones correctas sobre
herramientas.
-Colaboración: En ambientes dinámicos y ágiles, es natural que los equipos
pequeños se enfoquen únicamente en su propio proyecto y no consideren el
contexto empresarial más amplio. Los arquitectos empresariales deben aplicar una
gobernanza flexible para asegurar que todos los interesados estén involucrados en
la toma de decisiones sin que el sistema se vuelva excesivamente burocrático.

10. DevOps y la seguridad de la información
En la actualidad DevOps busca involucrar otras disciplinas que tradicionalmente se tenían en
cuenta tarde en el ciclo de vida del desarrollo de software. Esto es especialmente importante
con respecto a la seguridad de la información.
A primera vista, parece que los objetivos de DevOps y la seguridad están en desacuerdo.
Considerando que DevOps llama a aumentar la entrega de software de alta calidad, la
seguridad y el cumplimiento busca un control cuidadoso y deliberado para garantizar que el
negocio no se está abriendo a las vulnerabilidades.
Y con una montaña de reglas y regulaciones para apoyar, no es sorprendente que la
seguridad podría fácilmente ser considerada como otro cuello de botella en los procesos de
lanzamiento y despliegue.

11. Prácticas
-Haga que todos sean responsables de la seguridad
-Demostrar cómo DevOps mejora la seguridad
-Cambiar la forma de ver la seguridad

12. Características esenciales de DevOps en seguridad
Un programa de DevOps de seguridad trasciende más allá de reaccionar y arreglar
problemas de seguridad a proteger el negocio mientras las aplicaciones son
diseñadas, desarrolladas y probadas.
-El cliente primero
-Equipo alineado
-Participación proactiva
-Investigación continua

13. DevOps e ITIL
Como mucha gente puede pensar, ITIL no se opone específicamente al
pensamiento ágil y DevOps.
Apreciar donde la coexistencia es práctica y el inmenso valor que los procesos ITIL
establecidos pueden entregar un programa de DevOps, especialmente los
procesos ITIL (por ejemplo, la gestión de incidentes y problemas).
Por ejemplo. Esto puede proporcionar un conocimiento considerable del
comportamiento y el rendimiento de una aplicación en particular, lo que puede
informar a los desarrolladores de las mejoras no funcionales necesarias.