← Back to podcast Podcast

Devs Lives #30 Eduardo González | El camino del DevOps

Listen to episode
Open on iVoox

Transcripción

[No identificado] (00:00:22): Bienvenidos a Devs Lives, episodio número 30. Bueno, finalmente hemos llegado al episodio que todo el mundo estaba esperando, incluso nosotros, porque, bueno, representa ya la cifra del mes. O sea, si hubiésemos cogido todos los podcasts y los hubiésemos ido poniendo de uno en uno al día, hubiésemos cumplido nuestro primer mes. Aunque no es cierto, llevamos ya bastantes meses grabando con muchísimo trabajo detrás. Quiero agradecerle a todas las personas que nos han ayudado dando feedback,

[No identificado] (00:00:57): Dailos con las grabaciones, consejos de Ayu y de Jessica con respecto a cómo editar, Jorge con el tema del audio, Carlos Ble también nos ha dado muchísimo feedback sobre cómo comentar las cosas en el podcast. Y, bueno, las personas que hemos entrevistado, cómo no. Y no solo ellos, sino las personas que nos estáis escuchando, que al final estamos aquí, gracias a vosotros y todo el equipo de Devs Lives. O sea, sé yo. Tenemos que agradecer que semana a semana sigáis aquí apoyándonos y dándonos feedback.

[No identificado] (00:01:39): Y es por ello de que muchas personas me habían comentado que a quién iba a entrevistar en este episodio número 30 porque era algo como especial, ¿no? Cada día después siempre mucha gente me había dicho, oye, seguro que va a ser alguien muy top, seguro que buscas a alguien especial y demás. Y lo cierto es que sí. Pero igual no es el tipo de referente que las personas estaban buscando. No es la persona más famosa del mundo. No es alguien que ha escrito un montón de libros.

[No identificado] (00:02:14): Pero sí que es una persona que tiene un gran corazón. Es una persona que tiene una historia detrás muy bonita. Que es una persona muy humilde y que tiene una historia de perseverancia detrás que creo que es muy admirable. Y es por ello que se merece, con todas las letras, el episodio número 30 para él. Tenemos hoy con nosotros a Eduardo González. ¿Qué tal, Edu? ¿Cómo estás? Sea usted muy bienvenido. Hola, Adri. ¿Qué tal? Nada. Muchísimas gracias por invitarme. Y nada. A ver si se me baja un poco el rojillo de los mofletes.

[No identificado] (00:02:55): Nada, hombre. Yo sí que es verdad que a veces empiezo a decir y me emociono, pero es lo que siento, ¿no? Y yo qué sé, al final desde que nos conocimos, va a sonar todo muy relación romántica, desde que nos conocimos. Lo único que tengo son buenos recuerdos. Y cuando hay personas que me han contado tu historia, porque tú no me la has contado nunca directamente, siempre has ido por otro, pues la verdad es que es eso, ¿no? Es decir, oye, yo si tengo que ir con él a algún lado, voy hasta el final del mundo. O sea, creo que tienes muchísimo que aportar y…

[No identificado] (00:03:36): Joder, creo que es un placer y un orgullo tenerte aquí. Nada, Adri. El placer es mío. Yo me siento, vamos, súper orgulloso y contento de estar compartiendo este espacio contigo, con tantos cracks que has entrevistado y tantos grandes profesionales. Vamos. Bueno, me siento súper, súper, súper agradecido. Bueno, pues aquí estamos para eso. Y nada, voy a contar un poquito de ti, pero no te vas a liberar de la primera pregunta como todo el mundo. Pero voy a ir rompiendo un poquito el hielo porque, bueno, sé que vienes de estudiar el ciclo,

[No identificado] (00:04:13): De los salesianos, actualmente trabajas en tema de DevOps, te flipa el tema de la ciberseguridad. Hay palabritas por ahí como DevSecOps. No sé si… Pero bueno, que eres una persona que tiene su chiche y creo que pueden salir cosas súper interesantes de esta conversación. Y vamos a ello, vamos a intentar destriparlo todo. Así que se viene la primera pregunta. ¿Estás preparado? Listo, listo para ella, por supuesto. Bueno, pues cuéntanos un poquito quién es Eduardo González. Vale, Adri. Pues mira, por hacerte un resumen, Eduardo es un chico que le apasiona la tecnología en general

[No identificado] (00:05:02): Y que le gusta la seguridad, los sistemas y las comunicaciones en especial. Ese es, digamos, el resumen y lo que yo creo que más me define. Y luego, pues quizás otra palabra que a mí me gusta mucho, dicho mejor,

[No identificado] (00:05:26): Aprendiz de todo, maestro de nada, ¿no?

[No identificado] (00:05:30): Pues como resumen creo que te he identificado bastante bien y sobre todo esa última parte me encanta y te la he copiado más de una ocasión, tengo que ser sincero, porque es muy bueno, ¿no? O sea, aprendiz de todo y maestro de nada, porque siempre van a haber cosas que aprender, siempre llegarán personas nuevas que lleven más tiempo o menos en el sector o en la vida, que te pueden aportar cositas, ¿no? Y siempre se puede aprender de todo el mundo. Hasta de la persona que acaba de nacer siempre hay gestos que dices, ostras, ¿cómo funciona la vida, no?

[No identificado] (00:06:04): Y siempre tenemos ese punto de no somos maestros, pero también tenemos ese conocimiento y la gente se puede nutrir de ello al final.

[No identificado] (00:06:14): Yo creo que es algo que yo he hablado con más gente de nuestro sector y demás, ¿no? Y es lo típico de cuanto más conoces, más te das cuenta de cuánto desconoces. Correcto. Entonces, a medida que vas avanzando en el camino del saber,

[No identificado] (00:06:34): Pues te vas dando cuenta de todo lo que queda por delante. Sí.

[No identificado] (00:06:40): Es un punto también eso, ¿no? Porque, o sea, el tema del ego, ¿no? Es como, ¿dónde fijas esa línea de dónde está el ego? De no lo sé todo. O sea, ¿hasta qué punto llegas? Y creo que a muchas personas les pasa que empiezan, tienen esa sensación de, ¡buah, mira todo lo que estoy aprendiendo! ¡Mira todo lo que estoy aportando! ¡Mira todo lo que tú, tú, tú, tú! Empieza a subir el ego, empieza a subir el ego, empieza a subir el ego y ¡tras! Va a atacar y dice, vale, pues igual no estaba yo tan bien y toca volver a empezar, ¿no?

[No identificado] (00:07:17): Y es por eso que yo digo mucho lo de no se puede juzgar a alguien por una cosa puntual de un momento en concreto. La vida es algo que pasa y hay momentos de la vida donde tienes una opinión, un punto de vista que después te cambia totalmente por X. Y ese X es el batacazo. Y no hay solo un batacazo, hay muchos a lo largo del tiempo. Con lo cual, pues mira, al final lo importante es llevarnos un par de golpitos de vez en cuando y poder retomar y decir, oye, que queda mucho por aprender, ¿no?

[No identificado] (00:07:49): Que no estoy yo en ese pico soberano de conocimiento donde ya no tengo nada más que aprender. Siempre habrán cositas que mejorar y que perfilar y que seguir poco a poco, ¿no? Pues sí, al final, Adri, el tema del ego me parece súper interesante. Creo que es un enemigo silencioso que nos enfrentamos todos los días, quizás. Y que, bueno, creo que es uno de los principales enemigos a combatir porque es realmente quien nos lastra para seguir avanzando. Así que creo que, bueno, pues hay que tener cuidado, ¿no? Sí.

[No identificado] (00:08:27): Bajo mi punto de vista aparece silenciosamente sin que te des cuenta y de repente dice, uy, ¿dónde estoy? Y también creo que es súper importante de cara a dos cosas. Primero, los roles en el equipo. Y segundo, la etiqueta de desarrollador que tengas, ¿no? O sea, por ejemplo, no es lo mismo cuando tienes ego siendo un junior que cuando tienes ego siendo un senior porque la percepción de los demás va a ser totalmente distinta. Cuando llega alguien que es más junior y tiene ego es como, a ver, para el carro que no viene aquí.

[No identificado] (00:09:04): Y cuando es alguien senior quien tiene ese ego, pues es como, ostras. Y al final, eso nos lleva al segundo caso que te comentaba que es el equipo. Al final, ese ego individual acaba repercutiendo en cómo funciona el equipo en el día a día y acaba siendo inviable. Y eso te acaba creando equipos de desarrollo o equipos de trabajo súper disfuncionales. No sé. Ya que hablas de equipos, podríamos conectar un poco, ¿no? Con el rol del DevOps y lo que trata de derribar. Sí.

[No identificado] (00:09:37): Y bueno, al final, el ego es algo que siempre va a estar presente, que nos lo vamos a encontrar en mayor o menor grado. Pero bueno, el DevOps, obviamente el ego no sabe, ¿no? Pero sí que tiene una misión que es la de derribar los hilos entre el desarrollo y las operaciones y hacer que ambas engranen lo mejor posible, ¿no? Entonces, bueno, pues creo que es muy importante.

[No identificado] (00:10:16): Es la misión que buscan cumplir.

[No identificado] (00:10:24): Ahora que hablaste de DevOps y un poco cuál es esa misión, ¿no? Igual habrá personas que siempre oyen ese DevOps, DevOps, DevOps, pero no saben exactamente lo que es, ¿no? Igual tú que eres uno, pues aparte de la misión puedes definir un poquito más cuál es ese rol, ¿no? Un poquito más en detalle de, oye, DevOps es esto. Y lo bajamos a tierra, que la gente sepa mejor lo que es. Pues fíjate que el tema del DevOps es algo en nuestro sector casi que filosófico, ¿no? Porque depende con quién hables y demás, te dirá una cosa, te dirá otra.

[No identificado] (00:11:03): Incluso depende de en qué organización estés. Se entiende de una manera, se entiende de otra. Pero yo, mi visión personal es que todos deberíamos ser DevOps. Es la única manera real de que no haya silos entre desarrollo y operaciones.

[No identificado] (00:11:22): Pero luego la realidad real de las empresas es bien diferente, ¿no? Al final, a día de hoy, es un rol o se le tiende a ver más como un rol.

[No identificado] (00:11:33): Y luego, pues mira, tienes el SRE famoso. Tienes ahora, justo esta semana o la semana pasada, leía por algún lado que ahora ya lo guay no es ser DevOps, sino que ahora hay que ser ingeniero de plataformas. En fin, que en función de con quién hables y demás, pues te dirá una cosa u otra. Al final, pues también tiene mucho que ver el tema de las buzzwords, ¿no? DevOps fue durante mucho tiempo una buzzword en la industria, hasta que ya se normalizó un poco. Y ahora que ya no es una buzzword, pues ahora seguimos buscando otras, ¿no?

[No identificado] (00:12:13): Otras, ¿no? Como para etiquetar y siempre decir, mira, mira qué guay.

[No identificado] (00:12:18): Exactamente. Pero en cuanto a cultura, mira, justo eso me mola que lo hayas sacado, porque de ser ingeniero de infraestructura, habíamos dicho, o sea, fue como lo nombraste, ¿no? Más o menos. Sí, es ingeniero de plataforma. Eso, ingeniero de plataforma. O sea, es como que es algo súper cerrado de, yo voy a ser ingeniero de plataforma y me voy a dedicar a los despliegues, a las pipelines, a la securización, etc, etc, etc, pero todo como muy cerrado a algo. Y justo lo que tú habías dicho antes, que es DevOps, y como yo también lo considero, ¿no?

[No identificado] (00:12:55): Es algo que es que todos deberíamos de ser DevOps. Una persona que es full stack debería tener conceptos de DevOps. Una persona que es backend debería tener conceptos de DevOps. Y en general, ¿no? Es como la cultura de desplegar el trabajo que se ha realizado, ¿no?

[No identificado] (00:13:18): No veo yo la necesidad de tener algo cerrado y enfocado única y exclusivamente en eso, porque pierdes toda la parte de lo que es stream programming. O sea, no tienes un equipo, no tienes personas multidisciplinares, sino que tienes a alguien encasillado en algo y que no puede o no debe salir de ahí. Es como, ¿y entonces qué beneficio tienes cuando esa persona no esté? ¿Quién la reemplaza? O sea, cuando enferme, porque enfermará, o cuando pille una baja de paternidad, porque simplemente, yo qué sé, mil cosas, o sea, vaya de vacaciones, que es que no se despliega. O sea, la infraestructura no hay quien la toque.

[No identificado] (00:13:59): No tiene sentido, ¿no? Eso para un equipo es como súper problemático.

[No identificado] (00:14:05): Sí, a ver, por sentar un poco las bases de toda esta historia, pues todo viene, todos sabemos, típicos, sí, los operaciones, desarrollo. Los desarrolladores hacen su código y no quieren saber nada de infraestructura ni de cómo se despliega y viceversa. La gente de sistemas, infraestructura, no quiere ver una línea de código y fuera, ¿no? Entonces, dentro de ese panorama, ¿qué es lo ideal? Pues, como te digo, que todos fueran DevOps para que todos entendieran perfectamente lo que conlleva un lado y lo que conlleva otro. ¿Qué pasa? También es cierto que hablas con gente y te das cuenta que quizás

[No identificado] (00:14:50): Pedir que todos sean DevOps o que todos seamos DevOps es utópico desde el punto de vista que requiere un conocimiento transversal muy grande. Quiero decir, que una persona te desarrolle y que te ponga en producción, hay un elenco de skills ahí que es muy difícil abarcarlo.

[No identificado] (00:15:17): Entonces, es razonable y es entendible que al final la realidad en las empresas se haya convertido en lo que es, ¿no? Que es que al final, pues, la gente sabe del desarrollo, la gente sabe de infraestructura, la gente sabe de seguridad y al final es inevitable, ¿no? Que cada uno se especialice. Y más en lo nuestro que, como sabemos, tiene millones de cosas, millones de roles, etc. Sí, totalmente de acuerdo. O sea, es inevitable que las personas se vayan especializando en algo. Pero creo que lo que hay que romper es esa barrera, ¿no? O sea, de, no, yo soy Fronen y solo toco Fronen.

[No identificado] (00:16:04): A mí Backend no quiero verlo. ¿Por qué? O sea, a ver, yo no te digo que te consideres Full Stack, pero que si en algún momento puntual hay que tocar algo de Backend, pues que no tengas un rechazo absoluto de decir, yo eso no lo hago. Si hay que desplegar, no, no, yo no lo despliego. Yo toco mi JavaScript y mi CSS y problema tuyo. Porque precisamente eso es un bloqueo y crea dependencias en los proyectos. Y para mí, el como yo lo consigo es, vamos a formar un equipo donde se solucionen problemas. Problemas de negocio, no problemas técnicos.

[No identificado] (00:16:37): Entonces, cuanta más comunicación y más sinergia haya, mejor. Por supuesto que no todo el mundo puede saber de todo. Pero, oye, no tengo ese rechazo acercarme a la persona de DevOps y aprender y entender lo que está haciendo. No te digo que yo sea capaz de replicarlo, pero entenderlo porque es que hay detrás, incluso eso me va a ayudar a que yo en mi día a día pueda hacer cosas que hilen mejor con lo que está haciendo. Creo que esa es la cultura per se de un equipo y es la cultura DevOps también.

[No identificado] (00:17:09): De, oye, yo estoy por aquí para facilitar esa comunicación de un lado a otro y que las cosas hilen bien. Si no es lo que te digo, lo veo como equipos encasillados. Y hay que desplegar. Vale, avisa al equipo de infra, de plataforma, para dos días después. Ah, sí, vamos a desplegar. Mira que hemos encontrado un bug. Hay que hacer el rollback. Vale, y el bug cuando se va a corregir. Ah, no, después de acá vamos rollback, el equipo tendrá la rama de no sé qué. Otros dos días. Y es como, esto no fluye. O sea, empiezas a tener bloqueos constantes

[No identificado] (00:17:40): Y después si añadimos parálisis por análisis y otros términos así como super guays y super molones de vamos a justificar porque se está retrasando esto, pues terminas que un bug se ha solucionado y puesto en producción como tres semanas después, ¿no? No tiene mucho sentido para mí. Ojo, lo hablo desde mi punto de vista. Pues sí.

[No identificado] (00:18:05): ¿Qué más cosas podemos comentar de esto? Pues que el DevOps también busca la reducción del factor humano mediante la automatización. Al final el factor humano es siempre un riesgo que está presente y más cuando se opera, por ejemplo, a mano, ¿no? Entonces, DevOps trata de todo lo que es automatizable, pues que se automatice para que no quede en manos de una persona haciendo procedimientos manuales, sino que sea siempre lo mismo, el mismo procedimiento y no haya espacio a que una persona pueda cometer un error. Me parece super importante y aquí voy a empezar ya con las historias de…

[No identificado] (00:18:52): Bueno, antes de empezar yo con las historias de abuelo, porque eso va a dar para largo, pero tú tienes alguna anécdota de esto de decir, ostras, es que antes tenía que hacer auténticas burradas repetitivas para desplegar o simplemente para hacer un merge de una rama y a día de hoy ya lo hago de otra forma por suerte o porque nos hemos currado la automatización.

[No identificado] (00:19:25): Pues mira, Adri, ¿sabes qué ocurre? Que creo que soy lo suficientemente joven como para ver dentro de la industria en un momento donde estas cosas ya se tenían más o menos claras, pero sí que podemos hacer una comparación con el pasado, ¿no?

[No identificado] (00:19:46): Antes, hacer un rollback o escalar una infraestructura eran cosas que se hacían a mano. Hacer un rollback era cosa que tenía su costo. Ahora, en muchos casos, es lanzar un pipeline. Sí.

[No identificado] (00:20:09): Aquí también podríamos hablar de otro de los grandes oráculos que es la infraestructura como código, ¿no? El tener una infraestructura que sea reproducible, que esté…

[No identificado] (00:20:24): Escalable. Representada como código, que sea escalable y demás, antes era muchísimo más complejo. Claro. Ahora todo esto, pues, al final, hasta tu infraestructura, el código de tu infraestructura se puede taggear en Git, puedes hacer rollback para atrás, reaplicar y demás, ¿no? Sí. Y lo mismo para el código de las aplicaciones, ¿no? Eso para mí, antes, era un imposible, porque, primero que nada,

[No identificado] (00:20:58): Gracias por hacerme sentir tan viejo. He dicho, soy tan joven en la industria, diciendo, ostras, qué viejo, me estoy volviendo.

[No identificado] (00:21:06): Vale, no. Pero quitando eso, sí que… Yo tengo anécdotas, ¿vale?

[No identificado] (00:21:12): De estar trabajando en Java y para poder hacer un despliegue, tener que coger un aplicativo, un war, ¿vale? Uf, punto war. Sí, sí. El control de versiones no ser un Git, sino ser otra cosa.

[No identificado] (00:21:35): Bastante… Introduzca tecnología no usada a día de hoy. Y tener que, una vez hechos los cambios y sabiendo lo que era, para poder desplegar la aplicación y no romper, tener que ir al entorno en concreto, descargarme ese war, generar yo el war en local, abrirlo y decir, esto fue lo que se cambió, lo sacaba del war, meterlo en el otro war, volver a subirlo por FTP y hacer las pruebas manuales y decir, ojalá todo vaya bien. Ah, y ejecutar los scripts de base de datos.

[No identificado] (00:22:12): Eso para mí eran odiseas y cuando empecé a descubrir un poco toda esta filosofía de DevOps y en general, otras formas de hacer las cosas fue como… ¡Gracias! O sea, ya cuando hay que hacer un despliegue no me tiemblan las piernas. O sea, simplemente, oye, esta rama se compila porque va a compilar en todos lados igual y lo que voy a subir es este código y no mezclas raras de ramas que una y otra está ahí, está taggeado, así que hacer rollback todo guay. Además,

[No identificado] (00:22:47): El repo a través de las pipelines lo hace solo y yo no tengo que descargarme, enlocar nada y hacer nada. Y otros sistemas como pueden ser las migraciones de base de datos van en el proyecto, taggeadas también, con lo cual despliegue, se ejecuta todo solito. Ya está, ya está. Y sí, tengo los test automáticos y es como maravilla. Llego al final y es como, ¡ah! ¡Qué maravilla! Al final, al final eso que ha conseguido, que reducir incertidumbre,

[No identificado] (00:23:13): Aumentar la confiabilidad, etcétera, etcétera, que son cosas que son muy importantes y difíciles de manejar. Y incluso me atrevería a decir que reducir costos. Hombre, hombre, claro, de hecho, es otra de las cosas que no siempre, pero que suele tratar de hacerse desde la perspectiva DevOps es la reducción de costes. Empezando quizás por lo más evidente que es infraestructura elástica, que ahora, pues, si no tienes la necesidad de tener 50 servidores encendidos, pues no los tienes. Tienes 5 y vas escalando poco a poco según va aumentando la demanda y demás. Eso

[No identificado] (00:23:58): Es algo que a mí me parece una maravilla. Y más cuando tienes el cloud, tienes Amazon, tienes Azure, tienes N clouds que te permiten consumir metal bajo demanda y escalar para arriba, escalar para abajo. Sí, y en picos en concreto. Claro. En picos, aunque los picos concretamente son difíciles de manejar porque, claro, al final el autoescalado tiene una capacidad de reacción. Si de repente tú pasas de tener 100 a tener, yo qué sé, un millón de peticiones, el autoescalado no es instantáneo y no es mágico. Claro.

[No identificado] (00:24:47): Lo ideal para el autoescalado es un incremento progresivo.

[No identificado] (00:24:52): Que eso pues no siempre ocurre en internet y normalmente cuando cuando sabes que vas a tener un pico lo que haces es preescalar. Preescalar para ya tener la infraestructura preparada para aguantar un pico. Puede ser ejemplo que todos tenemos en vista pues el momento de comprar entradas de algo que justo sale a la venta las entradas empieza todo el mundo de F5 pues normalmente en ese tipo de casos se preescala la infraestructura para que dé como para aguantar eso. Sí.

[No identificado] (00:25:25): Pero fuera de eso el autoescalado es maravilloso. Claro. Es maravilloso. También eso cuando estás trabajando con temas de streaming dando un servicio en concreto ¿sabes? Que es como muy detectable y dices oye yo sé que mientras voy a estar haciendo la reproducción o haciendo el streaming de esto que es en directo el pico usuario va a ser mayor que cuando lo vean a posteriori bajo demanda ¿no? De que van a ir a ver un vídeo en concreto o sea el balance de tus servidores es totalmente distinto. Yo incluso estaba pensando también

[No identificado] (00:26:05): Es un ahorro monetario a nivel de recursos humanos. Quiero decir no es lo mismo que aunque yo invierta en que alguien genere esa automatización una vez está hecho esa automatización está generada y habrá que pulirla y iterarla pero en cuanto a tiempo es menor que el decir hay que hacer un despliegue a la semana y los despliegue suponen tres horas. Tres horas de un equipo o una persona en el mejor de los casos es dinero porque es a la semana cuando miras y haces retrospectiva a final de mes y dices oye pues

[No identificado] (00:26:45): 15 horas de una desarrolladora o de un desarrollador dedicado única y exclusivamente a hacer despliegue es una pérdida podía haberse aprovechado ese tiempo en otra cosa porque es una tarea repetitiva y además como tú bien decías que puede contener fallo humano o sea me parece un avance un avance muy importante y que por suerte no tengamos que volver a sufrir de ese tipo de cosas. Yo cuando pienso de este tema siempre recuerdo el tema en concreto de la infraestructura como código que antes hacer operaciones hacer infraestructura desplegar infraestructura era manual tirando SSH por todos lados y tal y claro al final era un trabajo que

[No identificado] (00:27:39): Quiero decir cuando tú eres desarrollador tú tiras líneas para adelante y esas líneas se quedan en un git y alguien las pica y ahí se quedaron picadas pero en el lado de infraestructura no ha sido así porque tú hacías algo y

[No identificado] (00:27:57): Si mañana tenías que volver a repetirlo pues tiene que volver a repetirlo manualmente y si la persona se va se lleva

[No identificado] (00:28:09): Eso entonces

[No identificado] (00:28:12): La infraestructura como código como digo concretamente ha permitido también que incluso ese trabajo de infraestructura se quede reflejado se pueda acumular no sé si es quizás la manera más adecuada de expresarlo pero es la manera de acumular el trabajo y que se haga y se queda ahí y mañana viene otra persona y puede ver perfectamente que es lo que está que es lo que está ahí modelado y demás claro es que en el mejor de los casos lo que podrías antes es encontrarte una documentación de un proceso a seguir y de ábrete el manual y es así como se despliega

[No identificado] (00:28:50): Ta ta ta ta ta ta ta ta ta ¿qué pasa con esos documentos? Que cuando lo repites por cuarta quinta vez pasas del documento te va saltando cosas y es cuando llegan los fallos ay es que me ay es que me olvidé ay es que no ay es que escribí mal y eso es un problema pero es una realidad o sea hay que ser conscientes de que al ser una acción repetitiva y vas a ya empiezas a ego no es un ego agresivo es un ego más pasivo pero es un ego de decir si esto ya me lo sé tú tú uy me equivoqué ¿no?

[No identificado] (00:29:20): Y es ahí donde está el problema a día de hoy creo que eso te genera muchos beneficios porque si tú te vas bueno vale o sea igual sí que hay que tener documentado algún tipo de proceso o explicarlos por qué se han tomado esas decisiones pero si quieres entender el proceso de despliegue o saber qué infraestructura está involucrada tú tienes en código cualquier persona que sea capaz de entender ese código va a llegar y va a decir ah sí aquí tienes esto esto esto esto esto esto esto si va acompañado de un porqué oye chapo porque dices ¿y por qué tienes esta base de datos?

[No identificado] (00:29:55): No mira está esta base de datos pero esta decisión técnica aquí ah vale o sea es como que la comunicación fluye de otra forma o sea al final creo que es lo de siempre ¿no? O sea transmitir conocimiento de la forma más pasiva posible o sea sin invertirle de tanto tiempo y que sea algo entendible para todo el mundo eso hace que tu infraestructura sea también sostenible ¿no? Que cualquier persona tenga la capacidad de llegar ver y entender eso lo veo súper súper interesante pues sí luego siempre queda la parte de operar que a veces no queda más remedio que operar que salte una alarma

[No identificado] (00:30:38): De uso de disco de que se está llenando el disco y toca pues darse ahí cabezazo y solucionarlo ¿no? Pero creo que esa parte que queda de operatoria y así que

[No identificado] (00:30:54): Siempre se pueden automatizar cosas pero habrá algunas

[No identificado] (00:30:59): Que no vas a poder automatizar o que a lo mejor ni siquiera has contemplado y por lo tanto de repente aparecen y te va a tocar

[No identificado] (00:31:07): Remangarte y operar a mano ¿no? Pero

[No identificado] (00:31:12): De ahí para abajo

[No identificado] (00:31:14): Me resulta interesante eso de de cuando tienes que operar ¿no? Porque tú tampoco o sea hay cosas como estoy viendo que el disco duro se va a llenar pues vamos a ampliarlo o vamos a a migrarlo o a replicarlo

[No identificado] (00:31:33): Pero supongamos que hay otro tipo de problemas más problemas no previstos como puede ser el tema de de bugs ¿sabes? Que ya no es algo de infraestructura sino que es de código per se suele ser lo más crítico porque ya incluso como como devops pues poco puedes hacer más allá de hacer un rollback de la versión quizás pero cuando cuando cuando hablamos de bugs en aplicaciones desde luego que si rollbacks si si se hacen rollbacks o también ahora está de moda el tema del forward que es arreglar hacia adelante y demás

[No identificado] (00:32:18): Pero bueno desde el punto de vista de infraestructura aparte de los temas de alta disponibilidad y este tipo de cosas luego pues ya puedes meter el pie en cosas más complejas ahí está todo el tema de ingeniería del caos que Netflix le dio muchísima caña a ese tema en su momento ellos hacían pruebas de disponibilidad de tirar regiones completas de Amazon y ellos seguían operando

[No identificado] (00:32:47): Y encima o sea por introducirte el concepto la ingeniería del caos lo que trata es de hacer inyección de fallos en los sistemas y aplicaciones y encima muchas veces de manera aleatoria entonces tú tienes por ahí un agente en las máquinas o lo que sea que de repente te deja la máquina sin conexión o de repente hace que se te corrompa un disco

[No identificado] (00:33:14): Diferentes pruebas y bueno al final eso ayuda a aumentar la resiliencia de la infraestructura y demás ¿no? Y eso en producción o sea coges aposta en producción y te cargas algo para iterar sobre ello eh sí Netflix si no me recuerdo lo hacía directamente en producción sí la vida y el estrés con razón le ponen la palabra a Kao o sea lo que pasa es que llegar a ese punto pues requiere que las cosas estén muy bien hechas y demás ¿no? Ahí no se llega de la noche a la mañana claro antes estábamos hablando de una aplicación sencilla con un balanzador de carga en medio

[No identificado] (00:33:58): Pero la realidad actual de los sistemas y las aplicaciones no es esa claro claro claro y no todo el mundo lo necesita tampoco quiero decir hombre por supuesto aplicaciones muy modestas que

[No identificado] (00:34:14): Por ejemplo vamos a hacer eh monkey chaos ¿no? Vamos a hacer aquí ¿para qué? Si eres la tienda de la esquina o sea no es por desprestigiarla pero no vas a tener una carga de un millón de usuarios vas a tener eh los veinte cincuenta usuarios de del barrio que te van a hacer la compra por internet van a ir allí en concreto solo a recoger las bolsas no necesitas ese tipo de sistemas necesitas que sí que tu aplicación tenga disponibilidad las horas operativas o por internet pero pero ya está o sea no eh sobre ingeniería a tope sí sí sí sí sí sí

[No identificado] (00:34:54): Que igual que hay sobre ingeniería en el código puede haber sobre ingeniería en en devops también para que vas a automatizar procesos que haces una vez cada año por ejemplo o sea igual tienes otras cosas que priorizar salvo que sean cosas muy críticas como el cambio de año que tú sabes cuando cuando se termina el año y empieza el día siguiente el año nuevo ahí empiezan los sudores pero

[No identificado] (00:35:19): Ya y ahí por ejemplo en devops porque hemos hablado de de un poco todo lo que es el concepto y todo lo que es satelital como un poquito escalar y como no pero hay otro tema que hila mucho con con lo que a ti yo sé que te mola que es el tema de de la seguridad entonces eh

[No identificado] (00:35:43): Si te parece para para empezar vamos a bueno ¿por qué te mola el tema de la seguridad? Informático porque al final fueron tus comienzos ¿no? Y ¿cómo llegas ahí? Ya después hablaremos de cómo se integra eso con el tema de de devops más adelante pero empecemos por el tema de seguridad bien pues mira resulta que el tema mío con la seguridad viene porque fue quizás el tema de entrada eh mío en la informática yo eh fíjate que vine a tener internet en mi casa cuando cuando ya estaba en el instituto primero la eso si no mal recuerdo y para mí yo recuerdo aquello eh

[No identificado] (00:36:24): De forma muy especial porque fue como un boom fue de repente tener acceso a internet tío o sea tú imagínate todo lo que eso conlleva ¿no? El poder escribir en google y satisfacer todo tu tu curiosidad y claro por alguna razón siempre los el tema de ¿qué me puedo ocurrir? ¿qué me puedo ocurrir por por tener acceso a esta herramienta? Claro y entonces al hacerte esa pregunta empiezas a profundizar y fue lo que a mí me me enamoró el el empezar a por ese camino a ir descubriendo ir poco a poco metiéndote y avanzando en en esa senda del conocimiento o sea

[No identificado] (00:37:15): A mí me pasaba eh justamente eso también ¿no? Cuando empecé a toquetear ordenadores y tal siempre más que por mí era la típica frase de de mis padres de mira a ver si vas a romper el ordenador decía ostras y claro el tener eso y tener internet a mano decía vamos a ver qué puede pasar oye si yo hago esto ¿qué puedo ocurrir? Si yo o sea y empiezas a buscar y empiezas a ver y primero le pierdes el miedo pero empiezas a entender ¿no? Es como vale ahora que entiendo esto sé qué cosas pueden pasar y qué cosas no pueden pasar

[No identificado] (00:37:51): Cuando empiezo a programar bueno pues le pierdo el miedo a que salvo que haga una burrada no me voy a cargar el ordenador salvo que yo qué sé me ponga a trabajar aquí abajo a nivel y empiece a trabajar con con memoria y acabe petando la RAM o el disco duro pero lo más que puede pasar es que bueno que se reinicie el ordenador y ala y ya está perdón pues sí de hecho de hecho Adri el

[No identificado] (00:38:16): Inicialmente la gente que que los inicios de internet se dedicaba a temas de seguridad la palabra hacker esta que que se ha convertido prácticamente en una buzzword también

[No identificado] (00:38:28): Era gente que en realidad lo que tenía era mucha curiosidad y era gente que lo que hacía era ir un poco más allá interesarse por qué es lo que hay debajo ¿no? Y una vez sabes lo que hay debajo pues tratar de buscarle los tres pies al gato por decirlo de alguna forma claro eso es algo que por desgracia en lo que es la industria actual de ciberseguridad se ha perdido ese romanticismo en el hacking se ha perdido y ahora bueno pues ya es algo

[No identificado] (00:38:58): Más enterprise por decirlo así pero pero la esencia original del hacking es esa de hecho Jopé si tú te lees el manifesto por ahí el famoso manifesto hacker pues pues es precioso leerlo y es una oda a la curiosidad prácticamente ¿no? Claro y de ahí pues pues fui avanzando y fui descubriendo el maravilloso mundo de la tecnología también llega a ser cosas electrónicas

[No identificado] (00:39:29): Mi madre con los primeros arduinos

[No identificado] (00:39:34): Tengo anécdotas tuyas que me han contado ahí en el ciclo con un arduino haciendo cosas y diciendo oye oye ven que te voy a enseñar

[No identificado] (00:39:43): Pues sí bueno te mola el tema de la seguridad empezaste por ahí llegaste al ciclo fue una puerta abierta y a día de hoy pues hay un término que es el de DevSecOps que mencionábamos antes y lo comentábamos fuera de cámara y para mí fue como esto es otra palabra mágica de estas una buzzword porque otra etiquetita más a tener en cuenta pero me pareció súper interesante importante porque

[No identificado] (00:40:13): Al final la seguridad es algo que está presente en todo nuestro día a día

[No identificado] (00:40:20): Y que muchas veces no le damos bueno

[No identificado] (00:40:23): Dependerá también de la persona pero en líneas generales no se le da la importancia necesaria hablábamos también fuera de cámara de cierta incidencia que hemos tenido bueno que he tenido hace poco no voy a ir desvelando fuera aquí cosas pero que lo he reportado y demás y pues parece que para la empresa en concreto a la que se lo he reportado no es importante es como bueno pues si tus datos están ahí suerte por ti y es como pero a ver

[No identificado] (00:40:58): No o sea son mis datos tú lo has dicho son mis datos quítalos y no no hay cierta aceptación ¿no? Entonces

[No identificado] (00:41:07): Este mundo que es la seguridad y este mundo que es el DevOps converjan en sí es como mira que desde el punto de infraestructura y desde el punto de servicio y de cómo ir a todo la seguridad está presente mencionabas antes también las conexiones por terminal vía SSH ¿no? Que antes las teníamos que hacer y es una persona con un post-it ahí ¡paf! Pegado usuario y contraseña y te ha llegado cualquier persona por elante es como ¡ah! Este ¡ah! Este no no o sea obviamente en tema DevOps esto va a ir un pasito más allá pero

[No identificado] (00:41:43): Que tiene su yo que sé no sé igual seguramente para mí el término es nuevo pero tú eres capaz de introducirlo muchísimo mejor que yo que lo que o sea ¿qué es DevSecOps ¿no?

[No identificado] (00:41:56): Lo primero que cuando cuando escucha DevSecOps es como chacho y no teníamos suficiente con desarrollo de operaciones ahora encima seguridad huele huele a hombro orquesta

[No identificado] (00:42:12): Muchísimo y huele a otra buzzword más de la industria pero bueno yo te voy a dar mi visión del tema al final creo que era un paso

[No identificado] (00:42:26): Natural natural y de hecho sí que creo que hay un poco de marketing en la palabra porque de entrada cuando haces DevOps deberías ya de tener en cuenta la seguridad y en general en cualquier cosa puesto que al final es transversal ¿no?

[No identificado] (00:42:46): Pero bueno

[No identificado] (00:42:49): Por dar una definición un poco más concreta DevSecOps lo que trata es de añadir

[No identificado] (00:42:56): Seguridad a todo el ciclo de desarrollo del software desde

[No identificado] (00:43:01): El momento de escribir código hasta el momento de ponerlo en producción ¿no? Vale entonces ataca bastante pues al al tema del desarrollo seguro Security by Design seguridad por diseño y todo este tipo de cosas y al final pues trata y busca de esforzar la seguridad en eso en todo el ciclo de desarrollo esa es un poco la definición del tema ¿no? Y o sea y funciona un poco en el día a día ese concepto me parece primero que nada estoy totalmente de acuerdo contigo que suena mucho marketing porque para mí esos son conceptos que también deberían ir de serio o sea si yo desarrollo algo

[No identificado] (00:43:50): Y soy consciente que no es seguro pues lo primero que debería hacer es levantar la mano y decir oye mira que esto no es seguro que esto que estamos haciendo aquí es una locura que si no soy consciente por supuesto que voy a necesitar que alguien con ese conocimiento me lo diga ¿no? Pero es importante tenerlo presente no es como ah bueno yo lo hago así y ya tiraré millas y mañana vendrán y mira no seguro oye si yo ya de por sí soy consciente pues levanto la mano yo como responsable de quien lo estoy haciendo ¿no?

[No identificado] (00:44:17): Hilar esto con todo lo que es

[No identificado] (00:44:22): Desarrollo de operaciones

[No identificado] (00:44:25): Se debería hacer también de per se pero bueno más allá de eso ¿cómo es el proceso del día a día? O sea tú llegas como desarrollador de operaciones y

[No identificado] (00:44:39): Lo integras de forma natural o hay algún tipo de proceso o un paso intermedio de vamos a hacer una auditoría o

[No identificado] (00:44:49): Un poco cómo va el tema normalmente cuando te pones a leer del tema

[No identificado] (00:44:55): Ves que se habla muchísimo de de herramientas por ejemplo en concreto un depsecops creo que si te pones a leer verás que va mucho de herramientas y al final tratan de todo lo que es automatizable desde el punto de vista de seguridad pues automatizarlo por ejemplo

[No identificado] (00:45:16): Meter un un hook en git para que no se te escapen secretos cuando haces un coming

[No identificado] (00:45:24): Automatizar el escaneo de los contenedores buscando

[No identificado] (00:45:29): Vulnerabilidades

[No identificado] (00:45:32): Automatizar el escaneo del código en busca de vulnerabilidades utilizando herramientas de análisis estático herramientas de análisis dinámico y demás

[No identificado] (00:45:42): Luego importante también reducir reducir el famoso shadow IT que el shadow IT no sé si lo conoces pero básicamente viene a describir cuando tú tienes una infraestructura muy grande ¿no? Pues a veces pierdes la visibilidad sobre todo lo que tienes quiero decir piensa en una empresa muy grande ¿no? Si

[No identificado] (00:46:10): De repente tienes el equipo de marketing te levanta una web y el equipo de seguridad no tiene ni idea porque ellos como equipo necesitan iterar mucho más rápido y por su cuenta te levantan un dominio lo que sea entonces ¿qué ocurre? Que eso se convierte en shadow IT porque es infraestructura que te pertenece pero de la cual tus equipos de seguridad no tienen conciencia de ello entonces es importante también pues buscar la manera de automatizar el

[No identificado] (00:46:43): Descubrimiento de tu propia superficie para tenerlo controlado porque no puedes proteger algo que no conoces que tienes sí tiene bastante sentido y sobre todo esa parte

[No identificado] (00:46:57): No he tenido la oportunidad de enfrentarme a ello de estar en un panorama tan grande donde se pierda el contexto pero sí creo que es un punto muy importante o sea desde luego no vas a tener a dos personas por ejemplo monitorizando todo lo que pasa en Google se levantarán webs de hecho nosotros somos consumidores de Google y desplegamos dominios y desplegamos aplicaciones servidores

[No identificado] (00:47:25): O sea ellos todo eso lo tienen securizado también creo que es uno de los buenos ejemplos no tiene por qué ser ni siquiera un equipo

[No identificado] (00:47:32): Interno de la empresa sino que puede ser un servicio que tú expones hacia internet y que la gente pueda consumir ¿no? De alguna forma tú le ofreces ese servicio de securización

[No identificado] (00:47:45): Sí suena suena interesante y creo que oye visto así

[No identificado] (00:47:51): Me mola me mola tiene tiene bastante sentido que todo eso pueda estar automatizado y piensa que tiene más sentido aún cuando estamos en un contexto de infraestructura elástica donde

[No identificado] (00:48:05): De repente tiene 50 servidores nuevos donde luego dejas de tenerlo entonces tu superficie de ataque que antes era estática de repente es dinámica claro entonces es importante controlar y mantener bajo control cuáles son tus activos pero bueno quizás eso sea solo una de las partes del DepsecOps pero bueno por resumirte pues eso tratar de ir dando seguridad en todo en cada uno de los pasos de desarrollo del software de la manera más fácil y directa pues a través de herramientas y luego también de forma cultural quiero decir tratando de esforzar la seguridad por diseño que es algo que no siempre se tiene en cuenta

[No identificado] (00:48:56): Y demás historias ¿no? Y y bueno yo sí que es verdad que en DepsecOps no he visto tanto el tema de auditoría porque al final aquí estamos hablando hablando de

[No identificado] (00:49:11): Del desarrollo de productos ¿no? Luego tendríamos aparte la parte de operaciones de seguridad que ya para mí sí que serían la peña que deberían de hacer auditoría red teams y demás ¿no? Sí

[No identificado] (00:49:25): Y nada pero es otro nivel sí son cosas diferentes esto va más de Application Security vale como como le suelen llamar ¿no? Vale vale vale vale tiene sentido oye pues Chapoy creo que además con los tips que has dado si hay alguna persona que que le guste y que que de verdad sienta ese ese DevOps yo creo que ya con toda la lista de pasos que has dado de contraseña securización de las plataformas cómo se despliegan los servicios creo que puede gestión de secreto gestión de secreto es también fundamental al final

[No identificado] (00:50:11): La mala gestión de secretos es mortal sí al final siempre tienes alguien que apunta en un post y tienes algo pues también esforzar política y demás y luego también el tema del compliance en plan si tu aplicación tiene que ser compliant con 27001 o con el esquema nacional de seguridad o con SOC 2 o con lo que sea pues no solo

[No identificado] (00:50:43): Hacer que que la aplicación llegue a ese punto sino mantenerlo claro porque como el software está vivo una cosa muy típica es que el compliance se rompe porque vale yo ahora mismo

[No identificado] (00:50:59): Estoy guay o sea soy

[No identificado] (00:51:03): Estoy conforme 27001 pero mañana hago una nueva release y por cualquier cosa ya no

[No identificado] (00:51:11): Claro y viceversa ya no ya no es solo que ha hecho algo nuevo que ha roto con la compliance sino ha habido un cambio en la legislación que hay que aplicar como tal en la aplicación porque ya no matcheo había algún fleco que entra en conflicto que hasta ahora no lo había y si no hay un equipo que por eso mismo la importancia de que no sea una persona sino que sea una cultura si el equipo no está al tanto de ello es muy fácil que eso se cuele y que acabes teniendo un problema serio por por eso por por un cambio de de legislación

[No identificado] (00:51:55): Que al final ni siquiera es algo que el equipo haya hecho más sino cambios que vienen de arriba luego probablemente ocurra como con el resto de cosas que la realidad luego las empresas será muy diferente que habrá empresas que buscaran un Dexecops pensando que va a ser el hombro orquesta que va a saber de desarrollo va a saber de infraestructura y encima va a saber de seguridad y te van a pedir hacer un pentesting o cualquier historia

[No identificado] (00:52:20): En fin pues lo de siempre pero eso efectivamente eso va a pasar siempre y es un tema de de cultura pero al final cada persona es responsable de decir oye mira pues realmente lo que me estás pidiendo no es lo que significa o sea justo al principio hablábamos de eso de oye mira que es que yo soy frontend pero eso no implica que no tengas cierto interés para saber cómo se hacen las cosas de backend no es un rechazo total oye yo como Dexecop no rechazo el hecho de saber en qué consiste el pentesting y demás para poder integrarlo de alguna forma

[No identificado] (00:52:58): En nuestro día a día pero mi rol per se no es dedicarme a hacer pentesting a las aplicaciones porque es un concepto distinto o sea que si al final te gusta y es una oportunidad y quieres hacerlo por supuesto hazlo o sea es una oportunidad y puedes aprender de algo que te mola pero no es per se lo que significa la palabra o sea pero lo veo bastante bien oye pues creo que nos hemos llevado muchísimas cosas en el saquito hoy tengo que darte las gracias que nada hay pero pero no vamos a terminar sin pasar por las dos preguntas random de hoy ¿estás preparado?

[No identificado] (00:53:39): Listo bueno primera pregunta ¿estás listo de verdad? Listo listo bueno el serranito con tomate o sin tomate

[No identificado] (00:53:53): Yo sin tomate pero uff porque yo y el mundo vegetal no nos llevamos muy bien uff bueno a ver yo te diría que un auténtico andaluz te diría que que con tomate y con pimiento pero bueno venga te lo vamos a perdonar no soy yo quien para juzgar de hecho que no que no me escuchen andaluces porque se van a enfadar claro bueno pero la gente se puede enfadar por todo como yo digo

[No identificado] (00:54:23): La gente es libre de enfadarse y de tener dobles trabajos ¿por qué? Si te enfadas ya es uno y se te tiene que ir en el fondo en algún momento con un 4-2 doble trabajo esa iteración no vale

[No identificado] (00:54:37): Nada hombre son bromitas tontas y bueno la segunda pregunta seguro que no es la primera vez que te lo pregunta alguien ¿no? Pero yo en confianza aquí delante de nuestra audiencia te lo tengo que preguntar como te gusta el tema de la ciberseguridad

[No identificado] (00:55:00): Me hackeas la cuenta de facebook de mi novia

[No identificado] (00:55:05): La típica

[No identificado] (00:55:07): Bueno por supuesto o sea seguro que te han hecho esa pregunta alguna vez hombre yo creo que a toda la gente que que le gusta el tema y que se mueve en un entorno donde la gente sabe que te gustan esos temas siempre te lo te lo vienen a decir pero pero bueno la respuesta es es que quien te diga que sí rotundamente te está mintiendo para conseguir hacerlo se tienen que alinear diferentes cosas y y solo cuando se alinean igual puedes conseguirlo pero igualmente yo esas cosas no no las hago no

[No identificado] (00:55:51): Va en contra de mi política de persona es lo que yo digo o sea yo directamente mi frase si quieres la contraseña pídelo a ella porque te voy a tener yo que dar algo que ella no quiere o sea arréglatela que no es mi asunto ¿no? Efectivamente nada pero bueno es muy recurrida esa pregunta igual que la de oye tú que tú que eres informático y sabes de electrónica ya esa asociación automática informática electrónica ¿me arreglas el microondas? Sí exactamente es el mismo rollo sí es que como tienen pantallita y tal es lo mismo ¿no? Tú me arreglas el microondas oye pues que decirte

[No identificado] (00:56:33): Muchísimas gracias por haber estado aquí por compartir este ratito con nosotros ya te digo es para mí un honor y un orgullo que haya sido tú el episodio número 30 porque a pesar de los nervios y de de todo en general creo que eras una persona que sí o sí tenía que estar aquí y te estaré eternamente agradecido por ello nada Adri gracias a ti es un placer el placer es mío por supuestísimo y nada

[No identificado] (00:57:07): Aquí estoy para lo que yo humildemente te puedo ofrecer y nada que disculpa porque la verdad que estaba bastante tenso las cosas como son hombre puedes estar tranquilo porque no se ha notado pero te conozco y y bueno lo sé que es un gran reto pero oye que por mí seguramente la gente esté totalmente de acuerdo lo ha abordado o sea que enhorabuena a ti muchísima muchísimas gracias

[No identificado] (00:57:36): Y y nada por supuesto que vas a tener mucho mucho más que ofrecer ya te hablaré yo y te contactaré en privo para decirte oye te apuntas a este red y ya surgirán cosas pero bueno eso lo dejamos para otro episodio genial genial genial para las personas que nos habéis estado escuchando muchísimas gracias por estar aquí agradecería un montón que valoraseis pues el esfuerzo que que edu ha hecho hoy en contarnos todo esto porque además es un tema bastante pantanoso y difícil de explicar pero nuevamente creo que lo ha abordado y nada os invito a que os paséis por aquí en el en el episodio

[No identificado] (00:58:20): Número 31 nuevo episodio nueva semana a tope con todo así que muchas gracias por estar aquí nos vemos en el próximo episodio adiós