Episode Transcript
[00:00:00] Speaker A: Hola a todos y bienvenidos a un nuevo episodio de nuestro podcast. Hoy contamos con un invitado especial, tenemos a Pablo con nosotros. Pablo, ¿Qué tal estás?
[00:00:09] Speaker B: Muchas gracias por invitarme.
[00:00:11] Speaker A: Muchas gracias por venir con nosotros. Y Damián, ¿Qué tal? ¿Cómo estás?
[00:00:14] Speaker C: Bien, bien, gracias a Dios. Encantado de estar acá en otro capítulo.
[00:00:18] Speaker A: Hoy creo que va a ser un capítulo interesante. Vamos a hablar también de uno de los temas que más comentado tenemos en la comunidad DevOps, los Kubernetes, las pipelines, cosas interesantes, también un poquito de cosas de seguridad, así que estar atentos porque vamos a tope, porque tenemos un experto de todo ese tema con nosotros. Y te quería empezar un poco con una pregunta así un poco que al Víctor del pasado le hubiera sido muy útil, que es cuando, si tú recuerdas, Pablo, cuando la primera vez que estuviste investigando un poco sobre Kubernetes, el tema de los containers y demás, ¿Qué consejos le darías al Víctor del pasado o al Pablo del pasado que se encontró con Kubernetes para aprender sobre el tema y cómo desarrollarse mejor en todo el tema de Kubernetes?
[00:01:14] Speaker B: Buena pregunta. Yo cuando empecé, lo primero que me costó diferenciar de un contenedor por empezar por contenedores era decir, joder, para mí era una máquina virtual. Yo venía del mundo más del pentesting, de aplicaciones web, más de desarrollador también, y me acababa de costar entender eso de que al final los contenedores como tal funcionan como un proceso y lo aíslas, lo replicas y es fácilmente extrapolable a cualquier servidor. Claro, de ahí a Kubernetes había que entender también cómo funcionaba individualmente cada contenedor para saber cuál era el funcionamiento.
Pero al final sobre todo es paciencia, porque al principio sobre todo Kubernetes apabulla un poco, son muchos objetos, es un poco complejo, la verdad, pero por suerte hoy en día tenemos muchísimas herramientas para probarlo sin instalarlo, muchos tutoriales dinámicos que en su día yo creo no teníamos nosotros y que facilita mucho la cosa. Pero bueno, que paciencia, que al final, como todo, cuesta un poco al principio, pero luego en cuanto lo entiendes, va rodado.
[00:02:19] Speaker A: Eso es. Y al final yo suscribo lo de la paciencia y también lo de que la gente se centre un poco en lo importante, porque Kubernetes es súper amplio, tiene un montón de tecnologías, es súper adaptable, que es lo bueno y lo malo de la tecnología, pero sobre todo sigue su parte buena y que se centre en al principio sus deployments, sus config maps, sus servicios y demás y que sepa lo que tiene que hacer en su aplicación y luego ya irá mejorando, que si no puede ser un caos absoluto al principio de información.
[00:02:54] Speaker B: Sin duda. Y luego me lo preguntan mucho porque me dicen, oye, ¿Tengo que aprender Docker para entrar a Kubernetes? A ver, mejor que tengas unas bases sólidas, porque muchos se meten a la aventura igual. Muchas veces el mismo desarrollador por lo que sea, le toca tener que aprender Kubernetes para desplegar su propia aplicación, ya sea un error de la empresa, que no tenga roles que den soporte DevOps o no, hay que tener unas bases muy sólidas de contenedores. Y luego no viene mal saber Unix, que muchas veces lo mismo creo un contenedor y no he hecho un comando de Unix en mi vida. Y es como, hombre, no tienes por qué, pero se entiende mejor, porque luego cuesta mucho aprender sin las bases, porque aprendes a prueba y error y tampoco es la mejor manera de aprender.
[00:03:35] Speaker A: Y algún comando que otro vas a.
[00:03:36] Speaker B: Tirar ya voy avisando segurísimo.
[00:03:40] Speaker A: Y al final, continuando un poco con el tema de Kubernetes y cómo ha ido tu evolución, porque bueno, nos has contado antes que tú venías un poco de la parte de seguridad y que te interesa un poco este tema. ¿Cómo viviste tú o cómo hiciste tú esa transición para alguien que esté pensando en transicionar y que le interese, ¿Cómo hiciste tú esa transición desde seguridad hasta hasta DevOps?
[00:04:06] Speaker B: Pues un poco arbitrario, porque yo me dedicaba sobre todo, ya te digo, al pentesting y claro, cuando vas a montar laboratorios, vas a desplegar cosas, sobre todo en seguridad, pues tienes que montar una máquina virtual que tenías que replicar todos los servicios.
Y yo creo que me enamoré un poquito de este mundillo o pivote más a la parte de Bobs, cuando vi que con un contenedor y dos comandos ya lo he montado al instante prácticamente. Es verdad que los contenedores tienen algunos problemas para replicar cosas que las máquinas virtuales sí que pueden hacer, pero dices, joder, qué potencial de montarlo al instante. Y ya cuando vi que eso junto con Docker, Swan o Kubernetes, además de montar tu conteo, lo puedes lanzar por ahí, distribuirlo, me pareció como qué maravilla, es como sonaba música clásica en mi cabeza de qué bien funciona, qué armonioso todo.
Y un poquito eso hizo que me enamorara más la parte esta de DevOps, más la parte de producción, de despliegue también.
Y pues lo fusioné un poquito con la seguridad, hacer ese mixto de devsecops más que me dedico ahora.
[00:05:13] Speaker C: Pero contame un poco cómo es tu día, Estamos hablando de Kubernetes, DevOps, de seguridad, ¿Qué haces en el día a día? Contanos un poco.
[00:05:22] Speaker B: Depende mucho el día a día. Yo trabajo al final en una empresa muy grande y hay roles muy específicos de DevOps, que ya hacen todos los pipelines y hacen sus labores y hacen todas las integraciones y demás. Entonces yo ahora mi día a día es más dedicarme junto con los equipos a ayudarles a mejorar los pipelines, a trabajarlos, ayudarles a gestionar las vulnerabilidades que resultan de todas las herramientas de seguridad que hay en sus componentes, los pipelines que lanzan.
Y luego pues también ayudo, sobre todo ahora este año estoy más enfocado en la parte de producción y me encargo más sobre todo esta parte de Kubernetes, afinar etiquetas, recursos autoescalados, todo el tema de proofs para que las aplicaciones funcionen bien, su autorreparación, autosaneamiento, como quieras llamarlo.
Es complicado decirlo sin tirar de todos los anglicismos, pero lo voy a intentar.
Entonces, más sobre todo esta línea. Entonces tengo un perfil un poco muy mixto, muy varadito al final, porque hago DevOps, hago seguridad, hago SRE un poco, entonces estoy un poco a varias cosas, pero bueno, es verdad que un rol más puro de Secops igual está más centrado en integrar las herramientas de seguridad, pero ya te digo, no me toca tanto en el día a día, aunque lo he hecho, pero no es mi día a día.
[00:06:41] Speaker C: Vale, y dime una cosa, nosotros hablamos mucho de finops generalmente.
Me gustaría saber si en tu equipo se habla eso, ¿Tienen procesos de fino?
[00:06:56] Speaker B: Pues a ver, yo por suerte no tengo que preocuparme mucho del presupuesto, porque es verdad que lo que hablamos antes, pues puede venir alguien a tirarnos las orejas y hacemos malas cosas, pero no tenemos a nadie dentro del equipo técnico, no tenemos a nadie integrado. Pero sí que dentro de los equipos en sí hay personas que se encargan de los presupuestos y nosotros normalmente trabajamos con un presupuesto prefijado, una estimación inicial y no nos ceñimos de ahí, no nos salimos mucho de ahí. Claro, es verdad que con todo el tema de autoescalado para subir, bajar, réplicas y demás, pues no tenemos falta esa madurez de que hablamos de que no estemos integrados con una política igual muy flexible de precios y de momento está ahí el auto escalado por si algún día hay picos y entiendo que esos picos, pues bueno, los pagaremos, tendremos que pagarlo o alguien nos tira las orejas, pero por lo menos las aplicaciones no se caerán. Pero lo dicho, por suerte no me tenía que preocupar de esa parte a día de hoy, pero bueno, sí que ahora lo estamos viendo más desde el punto contrario, en vez de preocuparnos por gastos inesperados, al revés, decir, oye, pues mira, hemos sobreescalado, sobredimensionado la infraestructura o los componentes y recursos que necesitamos en nube, vamos a intentar ajustarlos y con este escalado quedarnos tranquilos de que el día de mañana podremos responder pero ajustando los costes a día de hoy que no necesitamos tanto y eso es más, estamos más en esa línea yo creo de ajustar costes que de preocuparnos por lo que gastamos.
[00:08:30] Speaker A: Eso es, al final es lo que hablábamos también en un podcast con Víctor Farsic, que lo dejaremos por ahí en algún enlace, que lo que se centraba más es que al final una aplicación bien optimizada en contenedores es una aplicación muy eficiente a nivel de costes porque estás intentando sacar lo máximo posible de tu arquitectura, no está sobredimensionando y luego el auto escalado te permite que esa optimización que has hecho para un coste, vamos a decir, base en negocios, implica que esa, que esa aplicación escala es porque el negocio está escalando. Bueno, porque el negocio lo necesita de alguna manera. Si eso está bien hecho y entonces estás creciendo exponencialmente y eso no es un problema. Al final tener eso en cuenta siempre de que una aplicación con buena performance implica que es una aplicación optimizada a nivel de coste en mayoría de los casos. Otra cosa es que tengas un coste base que sea ridículo y que tu CPU esté al 10% o menos y te dé igual.
[00:09:30] Speaker B: Sí, eso sin duda. Sí, sí, totalmente de acuerdo.
Entonces ahí estamos. Luego la parte de optimización, pues bueno, luego ya siempre es muy interpretable pero bueno, se intenta, se intenta trabajar sobre todo la reserva de memorias, la reserva de recursos y claro, nosotros trabajamos en banca y los requisitos muchas veces de seguridad y de disponibilidad son altos. Entonces claro, igual no dices, voy a sobredimensionar por sobredimensionar, pero sí que tienes que usar replicación en zonas, tienes que aplicar ciertas cosas que además tiene un coste bastante alto y normalmente vamos holgados de recursos por si acaso. Intentamos por lo menos, pero bueno, en algunas cosas sí, en algunas no, como todo.
[00:10:16] Speaker A: Y al final, una cosa que te quería yo preguntar, porque es un problema bastante frecuente y no sé si tenéis alguna manera de afrontar lo que es cuando vosotros estáis dimensionando una aplicación a nivel de gestión de recursos, cuando defines un poco los límites, las peticiones de los recursos de Kubernetes, etc.
Cuando luego te lo vas a llevar a una carga en la nube, una carga en un servidor, que dices, mira, pues me hacen falta esta instancia o esta otra. ¿Tenéis algún proceso, alguna manera de decir la estimación de oye, vamos a coger esta instancia porque es mejor? Porque si por ejemplo, imagínate, metemos cuatro réplicas aquí en una instancia y vamos a tener normalmente cuatro réplicas, esta es la mejor instancia, ¿No sale más eficiente alguna manera de trabajar en eso?
[00:11:02] Speaker B: A ver, no tenemos un proceso más allá del sentido común y la prueba error, pero realmente nos toca mucho dentro de lo que tenemos. Ya decimos, mira, hemos lanzado la aplicación, la llevamos probando X tiempo, en Devpre ya se nos han integrado aplicaciones en estos entornos, pues tenemos este gasto base. Y luego hay otro matiz que sobre todo para Kubernetes, que nos llevamos la primera leche, es que claro, tú instalas una herramienta de monetización, luego herramientas de seguridad, tanto para la parte de runtime como todo el tema de ingesta de logs y demás, y claro, todas estas suelen funcionar en tipo demon set, es decir, que montan una réplica por cada nodo y suelen gastar bastante, sobre todo las de seguridad. Entonces dijimos, mira, vamos a dejar de escalar con 17 nodos muy pequeñitos y vamos a empezar a tener solo cuatro, cinco o seis nodos, pero muy grandes. Entonces claro, si tienes muchos demon set, siempre recomiendo, vete a nodos muy potentes y que tengas menos, porque es que si no vas a tirar recursos por todos lados escalando, porque al final cuando tiramos los pequeñitos un 30% de cada nodo se nos iba en los demon set, esto no es gestionable, esto no es escalable, entonces pues ese tipo de cositas las aprendimos sobre la marcha, igual existe gente más seria que yo, que nosotros, con unos procesos más claros de esto o más experiencia que nosotros y lo haría mejor, pero al final hay que probar. Y luego la otra cosa que hacemos o que intento hacer con todas las aplicaciones que manejamos al final son pruebas de estrés, vamos a cargarla, vamos a ver cuáles son sus cuellos de botella, vamos a ver cuándo fallan, porque igual no tiene sentido levantar 17 réplicas de este servicio por su diseño y tiene más sentido tener menos réplicas con más RAM, al final eso hay que afinarlo, siempre está la buena praxis de no tener pods de más de 2 GB de RAM, no sé quién lo escribió, pero es un poco lo que se comenta y habrá de todo y hay veces que al revés, que te renta más una aplicación con mucha RAM cacheada, con mucha carga y que haya menos réplicas, todo eso es jugar, cada aplicación es un mundo, no siempre tiras de todo, servicios gestionados, entonces todo lo que tengas que mantener tú como en Kubernetes, yo creo que hay que testearlo y si no testeas mal, vamos hacia GAS. Es complicado.
[00:13:23] Speaker A: Totalmente, no sé si hay un proceso.
[00:13:26] Speaker B: O conocéis vosotros.
[00:13:29] Speaker A: Yo en el último trabajo que hice para reescalar, había una calculadora de instancias que tú ponías como la petición estimada y cuánto iba a consumir de memoria y de CPU y cuántos nodos, luego dependía el número de nodos y demás y te sacaba la selección de cuál era la distancia recomendada en cada provider, luego si pongo el link a la descripción a mí me fue bastante útil. ¿Y he de decir que a mí me pasó exactamente lo mismo, o sea, yo por no estaba empezando con el fino, se que voy a salvar aquí la empresa de costes no sé qué, y claro, hice unos nodos súper pequeñitos porque dije si es que no está no, esta aplicación es que debería ser un serverless, pero bueno, eso es otro tema, pero era un Kubernetes, hacía tal, no sé qué, y claro, teníamos el sistema de monitorización había cambiado y ahora estaba todo metido en el clúster con sus promicios, sus grafanas, sus argos y sus todo, y pasó exactamente eso, claro, yo no paraba de sacar de repente digo pero por qué tantos nodos? Digo, no entiendo nada. Y claro, era porque las cargas de trabajo en cuanto había una no entraban porque había tantos sidecar que es que era mucho más sidecar que tal. Entonces me dijeron, no, tienes que cambiar esto porque salta un montón, digo, con la leche, si es que me hace falta un nodo, digo, si nos hace falta medio, ¿No? Digo, pero si es que lo consume más. Los sidecars qué tal, que muy bien, oye, que hacían falta, pero me quedé flipando cuando lo.
[00:14:57] Speaker B: Es verdad, al final a mí me encanta Kubernetes como plataforma, pero hay veces que es como matar moscas a cañonazos de tengo mi aplicación, le voy a insertar aplicaciones por fuera, que eso es lo precioso, lo que dices tú de sidecar, pues le pones un Istio, le pones lo que sea, empiezas a meterle cosas al clúster y qué guay, más funcionalidades, pero claro, acabas de hacer un X que en un entorno on prem en un servidor normal con docker y dos contenedores, lo hubieras hecho con 10 veces menos gasto de recursos muchas veces.
A mí me gusta Kubernetes mucho, pero a veces es como muy overkill, un poco de, oye, sobredimensionado qué vas a desplegar, si vas a lanzar una aplicación para 10.000 peticiones con una base de datos y dos cosas, pues igual no hace falta y te puedes ir a un ECS. Aún lo que dices tú, entiendo cuando dices serverless de un servicio gestionado de contenedores, que por debajo realmente sea Kubernetes también lo que haga el proveedor, pero a ti te abstrae de eso y a nivel de coste entiendo que va significativamente menor también, ¿No?
[00:16:00] Speaker A: Pues bueno, por supuesto, y además, y además es más fácil de gestionar, o sea que hay mucha gente que se pone a gestionar su propio clúster y le das muchos easies o cualquier servicio gestionado con esa base, ya muchas aplicaciones podrían ir tirando sin tener que hacerte tanta infraestructura, que al final. Y por cierto, y por comentar, el que dijo lo de que No hacía falta 2 GB de RAM, probablemente no desplega una aplicación de Java en su vida.
[00:16:31] Speaker B: Claro, hay de todo. Sí, sí, sí. Y luego, pues sobre todo ahora con el tema de IA, que igual Kubernetes no es el mejor sitio donde desplegar contenedores enfocados a modelos, aunque es verdad que puedes conectarlas, puedes conectar nodos con GPUs y debería ir bastante bien.
Pues vemos aplicaciones a veces, no en mi área quiero decir, pero he visto aplicaciones que gastan mis gigas de RAM, que cómo voy a lanzar, ¿Quién me ofrece a mí esa capacidad?
Tiene razón, vamos, porque a veces se marcan sobre todo, o por lo menos lo que veo yo, se marcan políticas globales de una compañía, mira, este es nuestro stack tecnológico, lo vamos a hacer así.
Hay aplicaciones que no puedes hacer todo a Kubernetes o todo a, no puede ser todo sota, caballo, rey, hay que ser un poco flexible también, dentro que se pueda.
Y luego dentro de eso, que me lo preguntan también mucho en los cursos, es cuándo uso Kubernetes o cuando uso Docker, y a la mayoría de la gente le digo, oye Docker, digo Docker porque al final es como el pan mismo que se ha quedado Docker la marca, pero usa containers, usa Docker engine, Podman, lo que te dé la gana, hazte un Compose y si necesitas rebalancear, montate tres servidores, ponte un balanceador de carga o ponte auto escalado también los nodos de C si quieres irte a nube, es decir, lo puedes hacer de mil formas seguramente más sencillas que irte a Kubernetes. Kubernetes es para hacer cosas más monstruosas, pero claro, es verdad que se pone un poquito de moda también y es como a toda Kubernetes, que está muy guay, que a mí me encanta también, soy el primero en querer ponerlo, pero muchas veces hay que saber cuándo ir y cuando no.
[00:18:11] Speaker C: Exacto, eso tenemos mucho razón. Bueno, pero es la flexibilidad que nos da la nube y todas estas tecnologías y es también mucho lo que estaba diciendo, a veces no hay otra que intentar y tratar, o sea, no poner algo muy chico y no poner algo muy grande, pero al final es mucho el código y lo que está haciendo con eso y de ahí vas viendo.
Pero escuché que te escucho diciendo, repitiendo todo el tema ese de cursos, ¿Vos tenés cursos?
[00:18:46] Speaker B: Sí, bueno, yo dentro de esta honorable labor que Hacemos aquí en YouTube, en redes sociales, pues principalmente empecé a crecer más cuando hice un curso de Docker y ahora estoy haciendo un curso de Kubernetes y bueno, entremezclo con varios temas y demás, alguno de seguridad, alguno de contadores principalmente, y sí, al final recibo bastante feedback de estos cursos y la mayoría son este tipo de dudas, aparte de que Kubernetes la gente anda más perdida, pero sobre todo la de cuándo ir a un sitio u otro, les preocupa la alta disponibilidad y muchas veces les da miedo ya Kubernetes o van a Kubernetes por joder, necesito alta disponibilidad. La alta disponibilidad siempre ha existido antes de Kubernetes y en la nube puedes hacerla de mil formas distintas o incluso ya te la garantiza el proveedor con ciertas cosas.
Entonces muchas veces ir a nube, perdón, ir a nube, ir a Kubernetes, pues ya te digo, a veces es contraproductivo, porque la carga de trabajo supone a las personas formarse, Si eres un experto bien, pero si no sabes, tendrás un tiempo brutal hasta que te adaptes y te llevas leches por todos lados hasta que tu aplicación vaya como se espera.
[00:20:02] Speaker C: Me imagino el recibo el fin de.
[00:20:04] Speaker A: Mes, cuando se tira el auto escalado y todo el susto de ese corraíto de AWS, no hace mucha gracia a.
[00:20:15] Speaker B: Veces la gota.
[00:20:20] Speaker A: Además porque es muy puñetero, porque en la preview no se ve cuánto te ha costado. Que yo siempre voy, o sea, claro, sobre todo pues gente como nosotros que tiene cuentas personales para hacer proyectos de prueba y demás, entonces tú estás ahí, de repente te llega AWS Build y no pone cuánto, es como me tengo que meter con una tensión, digo, es el correo que más rápido leo, leo más rápido que nuestra newsletter, ¿Sabes?
¿Es que te lo juro por Dios, porque digo, a ver qué ha pasado?
[00:20:49] Speaker B: Te quedas ahí con el suspense.
[00:20:50] Speaker A: Sí, claro, es que son muy claros, digo, deben de tener un open rate esta gente que flipa, ¿Sabes? Ese correo de visión, el más abierto.
[00:20:57] Speaker B: Del mundo, es impresionante.
[00:21:01] Speaker A: Bueno, dejaremos el enlace. Ahora hablando en serio de la newsletter, si alguien, un correo que es más divertido que el que te manda Amazon a final de mes, os lo dejaremos allí junto con los enlaces del curso de Pablo, que la verdad es que seguro que están geniales. Y siguiendo un poco con temas, conceptos de Docker y cosas así, el tema de las pipelines, que al final todo va un poco, o por lo menos en mi camino y probablemente no sé si en el tuyo, todo ha ido un poco interconectado, empiezas ahí a hacer tus contenedores, Dockerfiles, tal, no sé qué, y claro, los tienes que desplegar en algún lado y para desplegarlo no puedes hacer todos los días a mano, sino que tienes que hacer unos pipelines. Y yo sobre todo últimamente con todo este tema de Argo, del GitOps que está poniendo un poquito más de moda y que parece un approach así, ¿Como has visto tú la evolución de cuando tú empezaste a hacer pipelines y los primeros pues eso, que eran los scripts ahí warros como hacía yo o cómo está ahora, y cómo ves el cambio de las pipelines normales al GitOps y cómo se está gestionando todo eso?
[00:22:14] Speaker B: Yo cuando entré ya más a esto, por suerte ya de primeras disponíamos esto en mi empresa, en SSH Team, disponíamos ya de un GitLab y bastante y un mundo por explorar, aparte de monter un Jenkins en paralelo, pero dije bueno mira si ya lo tengo en el GitLab también dije pues el Jenkit lo voy a dejar un poco de lado, aunque también hemos trabajado mucho, pero bueno, lo primero que vi es la verdad que es un mundo qué guay, es que es automático, lo montas, lo despliegas constantemente, estás constantemente construyendo, desplegando, construyendo, desplegarDo, el contenedor garantiza que siempre funcione, la inmutabilidad del despliegue, problemas que antaño en FTP pues era complicado gestionar y sobre todo el tema de pues no me funciona esta versión rollback, obviamente las virtudes son claras, lo que sí que es verdad que cuando empezamos a trabajar con la parte de cyber, con toda esta parte de GitOps, trajo la metodología de Shift Left, es decir, vamos a llevar todos los controles de seguridad, que antes era una auditoría al año sobre el entorno productivo, pues vamos a llevarlo al entorno de desarrollo, al IDE, vamos a llevarlo a los primeros stage de los pipelines, Entonces claro, aquí empiezan ya a pasar pipelines de un minuto a pipelines de 10 minutos, porque ya hay que construirlo, hacer pruebas unitarias, integración funcional, si lo unes todo, pues seguridad de código, seguridad de terceros, seguridad del contenedor, si le metes el dust o analizadores dinámicos, claro, ya llega un momento que ya metes pilas de 20 minutos y ya te dirá el tío, joder, yo es que con el FTP en su tiempo hacia pon, daba un clip y lo despegaba, que no es la solución, pero es verdad que dentro de la agilidad hemos traído tanto al pipeline, que a veces es verdad que se empieza a sentir menos ágil, pero sí que es verdad que el control, la trazabilidad, porque todos los kits que quedan registrados, cada pull request, poder testearlo, eso es verdad que es una pasada, pero no es tan ágil ya como en su día disfrutábamos.
No sé si os lleváis esa perfección percepción vosotros también.
[00:24:19] Speaker A: Por mi parte sí, al final hay cada vez más cosas como en el lado. Sí que es verdad que bueno, todo el desarrollo creo que como tal está cambiando mucho, sobre todo con todo el tema de la IA, al final la carga como que lleva el desarrollo de la lógica de negocio, esas cosas dejan de ser tanto el problema, sino como todo lo que. Entonces cada vez se le va metiendo más cosas. Entonces al final, que yo creo que es un poco lo que pasó con todo este cambio de los empleos y demás, de que claro, ya saber desarrollar es un poco sí, vale, pero no tiene ese componente extra del trabajo, no vas a estar todo el día haciendo lógica de negocio, es muy difícil. Ahora hay un montón de cosas que para que una aplicación funcione de verdad y que sea útil, vas a tener que implementar, pues eso, saber hacer pipeline, saber hacer los requerimientos bien, el versionado, hacerlo automáticamente, que pase los checks, que sea eficiente en costes, que tú sepas desarrollarlo, etcétera, etcétera. Entonces al final entran un montón de cosas en cuenta que hay que saber hacer y que al final el proceso de desarrollo se vuelve menos ágil y tiene razón, dependiendo sobre todo las capas que pruebas y tienes que jugar ahí mucho, pero sí que es verdad que las aplicaciones cuando salen se puede iterar mucho más rápido con una aplicación ya completa, o sea, como que el resultado real que llegas es mucho más completo que antes cuando desplegabas una vez a la semana y era como recemos a todo lo posible para que esto salga bien.
[00:25:55] Speaker B: Sí, sin duda. Esa pérdida de agilidad gana en madurez, en robustez, es verdad que es al principio cuando ponen los pilares, una vez que va rodado, ha superado los controles de seguridad y ya te quedas más en un proceso vaho, en un proceso más recurrente de voy a actualizar versiones, voy a mantener el código. Es verdad que es más para andar por casa el problema. Yo sobre todo lo que veo cuando ayudamos a alguna empresa de terceros a integrar este tipo de controles es que parten de no haber hecho nada, de repente se juntan con 10 millones de vulnerabilidades por todos lados. Ponerse al día, ese ritmo de madurez, pues claro, frena mucho. Y ahí es cuando no se ve tanto el valor. Pero es verdad que es esencial, porque es que antes no se hacía. Y si ahora qué se hace puedes quitar agilidad, por lo menos se está haciendo, porque antes era no existe, no lo veo, pues no pasa nada. Y ahora por suerte o por desgracia, tenemos más normativas y se nota un montón. A nosotros cuando nos llaman desde nuestra empresa, necesitamos controles, auditorías, tal, pues hemos notado que baja más el pentesting, que ya no hay tanto pentesting manual o puro, sino y ahora nos pide más de ese hops, vamos a integrarlo, vamos a coger madurez, porque es una mejora continua y porque luego a mí me lo piden continuamente. Demuéstrame que no tienes vulnerabilidades, demuéstrame que tienes un control de calidad digno o una gestión de vulnerabilidades en tu empresa.
La normativa es más dura y hay que cumplirla.
[00:27:19] Speaker A: Al final, sobre todo al final pasa un poco lo mismo que cuando llega la revisión o la validación de seguridad, pues ya tienes casi, si implementas todo el flujo en tu día a día, ya tienes casi todo el trabajo hecho, salvo las cosas excepcionales que evidentemente van a salir. Pero en general tienes una base muy sólida.
[00:27:38] Speaker B: Eso es, cuando hay esa madurez, lo que dices, tienes la base sólida. Es más, incluso tienes la autonomía, porque en una empresa pequeña igual es más normal, una empresa mediana, pero una empresa grande normalmente hay unos procesos muy brutos para desplegar, con un control muy exhaustivo y con una burocracia bastante densa. También creo en la banca somos expertos en esto.
Y claro, el hecho de tener un end to end con las pruebas de seguridad integradas y demás, te permite la autonomía de mira, voy a desplegar y ya estoy cumpliendo con toda la normativa de la casa, ya estoy cumpliendo con la parte de ciber, con la parte de calidad de código, con la parte de nuestras propias pruebas. Entonces al final te vas tranquilo, tienes un pipeline de 20 minutos, pero te vas tranquilo de que va a funcionar casi siempre y que encima está bien, está limpito todo.
[00:28:28] Speaker A: Por hablar un poco del tema de seguridad, que lo has mencionado bastante y no lo hemos tocado casi, un poco cómo ves la integración de las herramientas de seguridad últimamente y esta evolución de revisiones, pentesting, más a lo digamos, de pasar de hacerlo una vez cada X, muy heavy, muy lento, ahora que es todo mucho más ágil, porque yo he visto sobre todo que hay mucho más análisis de código como tal, mucho más impacto de seguridad en esa parte y más en tema del análisis de los contenedores y el ecosistema cloud, por supuesto, o sea, dónde si estás abriendo tráfico, si no las políticas, etcétera, etcétera. ¿Cómo lo estás viendo tú que está evolucionando eso?
[00:29:15] Speaker B: A ver, la nube, quiero decir, desde mis perspectivas a empresas que ya tenían maduro entornos on premise, han generado más problemas que soluciones muchas veces, claro, vas a un entorno de nube que tienes que gobernar de cero, no digo que una vez que esté maduro no sea una bendición, pero claro, partes de que tienes que volver a adaptar todas las políticas, lo que has dicho, definir todo el tema de grupos de roles y una organización grande es súper complicado, tener un gobierno férreo también.
Por suerte junto a los pilates también se ha llevado la parte de Terrafor también para usar las políticas o aplicar las políticas también vía pilates, vía código. Y también ha generado o genera más capas de abstracción, que está muy guay tenerlo como código, pero implica que la gente se recicle, se forme eso a nivel de nube y de políticas también tema de infra, pero ha generado bastante trabajo el hecho de gobernar los proyectos. No es una parte que a mí me toque, lo dicho, pero yo dentro de la gorra más de CISO que he podido tener, me ha tocado más la de contenedores. Y desde la perspectiva de contenedores lo mismo, venga, vamos a contener todas las aplicaciones.
Claro, muchas veces los equipos desconociendo qué pasa a contenedores, implica que tú como desarrollador también te estás haciendo responsable de las librerías de terceros de ese contenedor, porque claro, antes despegas una máquina virtual, tu equipo UNIS lo mantiene actualizada la máquina virtual, pero ahora eres tú el que estás constantemente desplegando parte de la infraestructura, parte del sistema operativo, de tu código, de tus dependencias, vaya, y eso muchas veces no se percibe. Entonces migrar a nube, containers y demás, a los equipos les ha generado también algo más de estrés en tema de ciber también, pero bueno, como todo es coger ritmo, luego entiendo que sea más maravilla, pero los beneficios a corto no se ven tan rápido como te venden. No, vete a la nube. Que es fácil desplegar, sí, pero que despliegues fácil la infraestructura significa primero que no haya que gestionarla, que no haya que actualizarla y que no haya que gobernar la seguridad de la nube, que también tiene otro riesgo. Estás en nube pública y puedes exponer más fácilmente servicios a Internet que no deberías, como en on premise, coges el firewall, capas todo y vas abriendo a voluntad. En nube puedes hacer lo mismo, pero hay que.
En fin, ya me entendéis. Hay que tener en cuenta otras casuísticas, además de tener perfiles más especializados que no existen o que no existían hace cinco años, que cobran más o por supuesto, bien merecido, pero también supone más gasto al proyecto.
[00:31:55] Speaker A: Al final es un cambio de paradigma total, con toda la tecnología que eso conlleva, todo el conocimiento nuevo que tienes que poner de lo que estabas acostumbrado a eso. Y bueno, si alguien quiere aprender un poco de nube, nosotros también estamos intentando ayudar a la gente con ese tema y por eso también hemos sacado un curso de AWS con CDK, con un compañero también que hace también bastante contenido como tú, así que lo dejaremos también abajo en la descripción. Así que material de sobra para aprender tanto los Kubernetes. Si ya combinas el Kubernetes con el tema de CDK que nos cuenta Rubén, podemos tener, ya te vuelves un container developer en AWS.
Buenísimo.
Pues nada, Pablo, ha sido un placer tenerte. Espero que la gente haya conseguido valor de cosas que nos han pasado a ti, a mí, a Damian, durante nuestra experiencia del cloud. Y nada, mucha suerte a la gente con los contenedores y gracias por haber venido.
[00:33:04] Speaker B: Hombre, por supuesto, muchas gracias a vosotros por invitarme. Espero que haya sido constructivo, productivo, que es verdad que he sido más negativo que positivo en algunas cosas, pero bueno, la tecnología está ahí, tiene oportunidades muy interesantes, pero claro, es una advertencia más de saber usarlas con cabeza también. Y nada, hoy espero veros en otra ocasión.
[00:33:25] Speaker C: Seguro, seguro. Fue súper interesante, gracias por compartir con nosotros todo. Y creo que es uno de los capítulos donde tenemos más homework, así que lean, regístrense, lean todo y que van a aprender mucho seguro.
[00:33:40] Speaker A: Ahora le vamos a mandar los enlaces a Carlos para que no se enfade. Y los tenga todos controlados y listo.
Pues nada chicos, un placer y nos vemos en la próxima.
[00:33:52] Speaker B: Un saludo, un placer. Muchas gracias. Hasta luego.
