Thanks for keep sharing

Grande mi hermano! Un placer haber compartido en el Kubecon con vos y acá vamos por ese KCD Costa Rica!

Muy bueno! Gracias!

Muy buenos los videos y claros!

Estoy muy deacuerdo ahi lo que vale rescatar es Vault y Packer

Desde mi punto de vista la están "cagando" siento que parte de lo que hacía a terraform "bueno" es la cantidad de providers generados por la comunidad y otros proyectos Open Source. Con esta nueva licencia van a perder ese apoyo, al final un componente determinante en la popularidad de una tecnología es eso la Comunidad.

Ah por cierto, yo he escrito una libreria para que Pepito la use y de hecho ya tengo acceso a su cuenta de GCP !!!

El proceso de Google obviamente es lo indicado; lo bueno es que no es el unico, mas bien es uno entre muchos. Sin entrar en el detalle de la parte OWASP y IDS, que seguramente merece atencion pero incluye toda una serie de desafios debidos a como el cloud provider maneja las interfaces de red y como realmente capturar el trafico sin usar las herramientas propuestas por el mismo provider o sus integraciones, lo que me parece muy importante es mas a nivel de cultura que de herramientas como punto de arranque: incluir en pipelines y herramientas de verificacion del proceso de "build" una serie de practicas y tools capaces de identificar vulnerabilidades y aislar el 90% de los potential security issues es obligatorio. Como hemos visto juntos, un escaneo de cosas como contenedores, manifests, terraform hcl files y hasta archivos de configuracion de pipelines no es tan dificil a introducirse; una sola persona puede construir un sistema capaz de evidenciar los problemas y reportarlos. El punto es: quien cuidará de solucionar esos problemas ? Ser'a mas facil hacir una pipeline permisiva que notifique los problemas, pero quedaran sin asignarse ? Todo eso para remarcar el punto: el proceso de google, así como muchas buenas practicas son excelentes, pero sin una cultura y un entendimiento por parte de desarrolladores, devops teams, product managers y todos los que componen un equipo de trabajo, no sirven para mucho. Las buenas practicas y herramientas de monitoreo y prevencion estan a nuestro alcance sea cual sea la plataforma, pero para mi la conciencia de cada profesional es el limite. La mayoria de los que escucharan y pensaran en todo esto estará seguramente de acuerdo con el proceso, pero solamente un 10% lo implementará y propondrá en su entorno, y de ese 10% , solamente un 10% hará un uso responsable de todo esto. Donde ganan los grandes como Google, AWS y los demas ? En aplicarlo de verdad.

Lo facinante del TDD es que el test quien diseña el codigo, al tener test que fallan desde un inicio reta al desarrollador a crear codigo que cumpla con los criterios de aceptación en los cuales el test fue creado, crear test en el orden inverso, no representa ningun reto mas que crear test que validen lo que ya anteriormente validamos manualmente a la hora de crear el codigo, por ende solo estamos repitiendo el proceso de validacion manual que hicimos a la hora de crear el codigo primeramente.