Streaming en Youtube at https://www.youtube.com/watch?v=pm7DzYLVgkw hasta el minuto 48
Las metodologías DevOps y herramientas de infraestructura como código prometían simplificar el manejo de nuestros servidores, aumentar nuestro valor a negocio y en general, mejorar nuestra vida como ingenieros.
Pero la realidad es que la complejidad parece seguir en aumento, es cada vez más difícil testear todo correctamente y a veces parece que haciendo las cosas a mano vivíamos mejor.
En esta charla haremos un repaso de estos temas, plantearemos posibles soluciones, comentaremos algunos retos que todavía nos quedan y desde luego espero convencer a la audiencia de que volver atrás no sería una buena solución
2. Consultor Independiente en Rigor Alliance
Ex-CTO Holaluz & Tech Lead de Hailo, Wonga, SocialPoint, Ulabox
Organizador devops.barcelona, php.barcelona, HUG Barcelona
@ricardclau
Ricard Clau
3. ¿Por qué esta charla?
Sensaciones habituales
Veo problemas similares en muchas empresas (colaborando o charlando con CTOs)
Todo es cada vez más complicado y al principio cuesta que los beneficios superen el coste
Están apareciendo nuevos retos y no sabemos bien cómo afrontarlos
Mi visión pragmática
Ni hay “silver bullets” ni todas las empresas están en el mismo momento
No todo el mundo usa Terraform para todo ni tienen todo en K8s en producción
Creo que no hay marcha atrás en adopción de DevOps y Infra-as-code
5. DevOps - Promesas
▪ Desarrolladores y Sistemas / Operaciones trabajando juntos
▪ Deploys más rápidos y seguros, agilidad en la infraestructura
▪ Automatización prácticamente total con, eventualmente, No-Ops
▪ Entornos totalmente unificados y iguales
▪ Ahorro de costes significativo a medio y largo plazo para la empresa
6. DevOps - Realidad
▪ Nuevos silos, nuevas squads, menos colaboración que antes
▪ Seguimos teniendo pipelines demasiado lentas
▪ Todo es cada vez más complejo, veo difícil no-ops a medio plazo
▪ Sigue siendo difícil probar algunas cosas antes de ir a producción
▪ Incremento de costes considerable, cuanto menos, a medio plazo
7. Infra as Code - Promesas
▪ Se acabaron los steps manuales
▪ Reducción de costes y aumento de velocidad
▪ Reducción de riesgos: entornos idénticos, estabilidad, escalabilidad,
accountability, documentación, seguridad…
▪ Tests más realistas antes de ir a producción
8. Infra as Code - Realidad
▪ Las cosas no son más fáciles, demasiadas abstracciones
▪ Complicado tener entornos completos (datos, APIs 3rd parties, coste…)
▪ Algunas cosas siguen pudiendo probarse solo en producción
▪ Los default de las herramientas no siempre son seguros o PCI compliant
▪ Raramente empezamos de 0, y cuesta integrar cosas existentes
▪ Muchas veces quizás acabaríamos antes con un clic en la console
9. Keep calm!
▪ No hay soluciones mágicas
▪ Volver a tiempos pasados no parece una buena idea
▪ Quedarse en el pasado tampoco, y además, afecta al hiring
▪ Vamos a ver algunos truquillos y estrategias!
11. Colaboración Dev - Ops
▪ Los equipos de DevOps / Platform aislados no funcionan casi nunca
▪ “Alguien DevOps” asignado a equipo Dev te hace avanzar, pero cuesta
unificar sin un equipo central
▪ Idea: Combinar equipo “core” responsable de unificar criterios, tooling,
metodologías y que sus miembros “contagien” a los Devs en proyectos
▪ Equipos de desarrollo con ciertos permisos y ser autosuficientes
▪ Hay que cuidar mucho los procesos de selección
14. Producción - Ese lugar mitológico
Aspiracional
Producción debería ser una key del hashmap de configuración (aspiracional)
Ejercicio Disaster Recovery ¿Somos capaces de levantar producción desde 0 en otra región?
Testear antes de ir a producción
Las pruebas de rendimiento no sirven sin las bbdd igual de llenas
No podemos hacer tests end to end sin tener todos los servicios externos
Los patrones de tráfico real son MUY difíciles de reproducir
Si podéis, añadid A/B testing y rollout gradual a subset de usuarios
15. DevSecOps
▪ Levantar infraestructura es cada vez más fácil… y es muy habitual dejar la
seguridad hasta el final. Hay pocos profesionales full-time!
▪ Los valores por defecto de muchas APIs no son seguros, y los ejemplos que
corren por Internet tampoco suelen cuidarlo
▪ Cada vez hay más herramientas y cada vez son más fáciles de usar
▪ Creo que es uno de los challenges principales de los próximos años!
17. Configuración de Containers & VMs
Docker, Packer, Ansible, Vagrant...
▪ Con los archivos Dockerfile podemos configurar lo que queremos instalar en
nuestros contenedores
▪ Con Packer podemos generar imágenes en cualquier plataforma cloud o de
virtualización. Todavía es una herramienta muy válida!
▪ Ansible era la tool de moda hace pocos años, con el auge de Docker y K8s ha
quedado un poco relegada. Todavía muy útil para configurar VMs
▪ Con Vagrant podemos configurar VMs en local de forma simple. Un poco en
desuso debido a las nuevas arquitecturas de microservicios
18. Infraestructura
Terraform, Cloudformation, Pulumi, CDK...
▪ Confesión: Soy MUY fan de Terraform, lo uso a diario desde la versión 0.4
▪ Uséis lo que uséis, por favor, intentad dejar de hacer las cosas a mano!
▪ El sistema de providers de Terraform y lo fácil que es crear uno ha hecho que
a día de hoy tengamos conectores para casi todo lo que es automatizable
▪ Si usáis alguna de las otras tools, perfecto! Pero si no habéis empezado a
definir vuestra infraestructura con código, Terraform os ayudará
▪ La tool, en realidad, es lo de menos, ya que hay que saber de la plataforma!
19. DevSecOps
Vault, Sentinel, Terrascan, Snyk, SAST analizers...
▪ Hashicorp Vault es muy potente pero requiere aprendizaje y práctica
▪ Quizás para empezar podemos usar el Secrets Manager de nuestro cloud,
tools como Ansible Vault para ofuscar secretos.
▪ Tools como Snyk permiten analizar vulnerabilidades en los contenedores
▪ Terrascan o Sentinel (Terraform Enterprise) analizan reglas en archivos .tf
▪ Hay muchos analizadores SAST que podéis poner en vuestra pipeline para
detectar problemas, secretos commiteados, linting de código, etc...
21. Containers vs VMs
▪ K8s es un orquestador de contenedores muy potente y complejo, si podéis
usad soluciones como EKS, GKE, AKS…
▪ Si K8s os parece muy complejo, valorad alternativas como Nomad o ECS
▪ Si tenéis poca experiencia con contenedores, empezad por cosas sin estado
(webapps, etc…) y bases de datos en VM o servicios tipo RDS
▪ Esas VM pueden ser creadas y modificadas con Packer + Ansible
22. Terraform con infraestructura existente
▪ Raramente empezaremos en una cuenta vacía de AWS, keep calm!
▪ Podemos usar data resources o incluso ids (VPC, Subnets, SGs…)
▪ Terraform import permite importar casi todo (depende del provider)
▪ https://github.com/GoogleCloudPlatform/terraformer (terraform inverso!)
▪ No es necesario migrar todo a Terraform de golpe!
23. Terraform cada vez más grande
▪ Intentad partir los estados en múltiples estados (red, aplicaciones, entornos,
recursos compartidos…)
▪ Usad modules (propios o open-source) para no duplicar código y para
unificar naming, tagging, etc
▪ Cuidado con modules muy complejos o abusar de dynamic blocks
▪ Seguid a @antonbabenko (http://bit.ly/terraform-youtube)
24. Infrastructure Drift
▪ Es bastante inevitable, al principio, tocar cosas a mano
▪ Terraform refresh nos puede ayudar a “consolidar”
▪ Parte del drift puede venir por nuevas versiones de APIs / providers
▪ Habilitad Cloudtrail (o equivalentes)
▪ https://driftctl.com/ (y otras herramientas similares)
26. Optimismo
▪ Nunca había sido tan fácil probar nuevas piezas de infraestructura
▪ Nunca había sido tan fácil configurar servidores con código versionable
▪ El movimiento DevOps aún es joven y tiene que acabar de ajustarse (Agile)
▪ Es una inversión importante pero si se hace iterativo hay resultados rápido
▪ No creo que nos falte trabajo durante una larga temporada!
27. Gracias
Si crees que te puedo ayudar o quieres charlar
ricard.clau@gmail.com | @ricardclau | https://www.linkedin.com/in/ricardclau/