1. Ambientes efímeros con
IaC y DevOps
Ricardo Gonzalez Vargas
Microsoft Regional Director
AWS Solutions Architect
Chief Technology Officer – Clouxter
@rgonv
2. Ricardo Gonzalez Vargas
• Ingeniero de Diseño y Automatización electrónica – MSc Ing
Sistemas y Computación
• 20 años+ en arquitectura de soluciones y procesos de
desarrollo de software
• Diferentes verticales: Industria, Financiera, Salud, Seguridad,
Telecomunicaciones, Digital Marketing, Cloud Services
@rgon
v
Cloud Adoption & Acceleration
Machine Learning
Digital Marketing
Blockchain
5. https://ricardogonzalez.me
DevOps?
• Filosofía, Practicas y Herramientas
• Aumentan la capacidad para entregar aplicaciones
y servicios a gran velocidad
• Evolución y mejoramiento de productos a un ritmo
mas rápido que las organizaciones que utilizan
procesos tradicionales
• Permite a las organizaciones servir mejor a sus
clientes y competir de manera mas efectiva en el
mercado
6. https://ricardogonzalez.me
Valores y Pilares de DevOps – CAMS
Valores
- Cultura: Gente > Proceso > Herramientas
- Automatización: Build, Test, Deploy, Infraestructura como Código
- Medición: Medir TODO
- Compartir (Sharing) : Colaboración/Retroalimentación
Pilares
- Automatización de Infraestructura
- Entrega Continua
- Ingeniería de Confiabilidad
8. https://ricardogonzalez.me
Integración Continua - CI
• La integración continua, es un practica que lleva a los
equipos de desarrollo a registrar en los repositorios
de control de versiones pequeños cambios en el
código frecuentemente. El objetivo técnico es un
mecanismo consistente y automático de compilar,
empaquetar y probar aplicaciones.
• Beneficios:
• Velocidad
• Visibilidad
• Mayor colaboración
• Mejor calidad del software
• Costo
11. https://ricardogonzalez.me
Infraestructura como Código - IaC
• Infraestructura como Código (IaC) es la gestión de
infraestructura (networks, virtual machines, load
balancers, connection topology) en un modelo
descriptivo, usando el mismo mecanismo de
versionamiento utilizado en el ciclo de vida del código.
• Beneficios:
• Reducción del “Environment Drift”
• Idempotencia
• Velocidad
• Reducción del Riesgo
• Costo
• Mantenibilidad y documentación
14. https://ricardogonzalez.me
Ambientes Tradicionales
• Existe un ambiente estático que espera recibir los
artefactos resultados de los pipelines en un
ambiente compartido. Generalmente tienen
algunos inconvenientes:
• Deterioro progresivo
• Inconsistentes
• Imposibilidad de reproducir problemas
• Mantenimiento largo y costoso
• Encolamiento
• Desperdicio
• Tiempo inutilizado
15. https://ricardogonzalez.me
Ambientes Efímeros
• Se crean por demanda de manera consistente para
diferentes etapas del proceso de CI/CD
• Compilación y prueba unitaria
• Build, ejecución de pruebas unitarias
• Guardar artefactos probados
• Pre-cocinar ambiente de staging (En caso de VMs):
• Lanzar imágenes base
• Provisionar software base/middleware
• Instalar aplicación (artefactos probados)
• Guardar la imagen lista
16. https://ricardogonzalez.me
Ambientes Efímeros
• Se crean por demanda de manera consistente para
diferentes etapas del proceso de CI/CD:
• Compilación y prueba unitaria
• Build, ejecución de pruebas unitarias
• Guardar artefactos probados
• Pre-cocinar ambiente de staging (En caso de VMs):
• Lanzar imágenes base
• Provisionar software base/middleware
• Instalar aplicación (artefactos probados)
• Guardar la imagen lista
17. https://ricardogonzalez.me
Ambientes Efímeros
• Pruebas de integración y Calidad
• Se lanza el ambiente de staging
• Ejecución de pruebas
• Se apaga el ambiente de staging
• Pruebas funcionales, de carga y seguridad (pueden ser
diferentes etapas)
• Se lanza el ambiente de staging
• Ejecución de pruebas
• Se apaga el ambiente de staging
• Despliegues en producción Blue/Green approach:
• Mapeo de variables de entorno/configuración
• Lanzar ambiente de staging
• Replicación/Redirección de datos
• Redirección de DNS
• Desaprovisionar ambiente antiguo de producción
23. https://ricardogonzalez.me
Conclusiones
• A diferencia de on-premise, el modelo de consumo
de la nube debería hacernos cambiar la manera en
que pensamos la utilizacion de recursos
• Me cuesta tener encendido los recursos
• Las acciones manuales solo producen errores y costos
• La velocidad se logra con automatización
26. GRACIAS !!!
Ricardo Gonzalez Vargas
Microsoft Regional Director
AWS Solutions Architect – Black Belt
Chief Technology Officer – Clouxter
@rgonv
https://ricardogonzalez.me
@rgon
v