Nerdearla · 27:47 · https://www.youtube.com/watch?v=nGeiH6GSIuU
0:03 [música] Buenas tardes, ¿cómo están? Bueno, yo soy Juan, ya estuve en Ardearla hace algunos años. Hoy voy a presentar una charla que se llama No sos Netflix, cuando tu sistema no necesita escalar a un millón de usuarios. Bueno, ¿quién soy? Eh, soy alguien que trabaja con tecnología desde hace muchos años, de hace unos 20 más o menos, empezando con algo más eh amateur y avanzando en diferentes roles. En los últimos años estuve trabajando mayormente como eh ingeniero y después de eso como manager de ingeniería de software.
0:50 Actualmente estoy trabajando hace unos 5 años en RELP como software manager y también en los últimos años comencé a profundizar un poco mi interés en lo que es seguridad informática y estoy trabajando también algunas cuestiones académicas y personales y laborales en lo que es seguridad. Bueno, un poco para resumir y para contarles un poquito que estuve haciendo estos años.
1:16 Como les decía, estuve, esta es la tercera vez que estuve en Norde, si no recuerdo mal. Eh, los años fueron 24, 25 y 26. Eh, una de mis primeras charlas importantes fue en Picón, en España, o sea, por el 2016 en Alenaría.
1:32 Este año voy a estar otra vez, 10 años después en Barcelona, dando una charla que va un poco en el mismo lineamiento de lo que vamos a ver hoy acá, que es un poco contarles mis experiencias respecto de liderazgo de grupos, de desarrolladores, de cómo manejar tecnología en TUEN de una forma coherente y segura. E bueno, también fui jef de conferencia, fui responsable de Picón en Argentina hace ya muchos años.
2:01 Eh, estuve trabajando últimamente en algunos preprints y papers relacionados a criptografía y seguridad, como les contaba. Y bueno, este año también escribí, yo ya había tenido algunas colaboraciones respecto de de algunas revistas nacionales, internacionales, mayormente sobre sistemas, Linux, más del lado de administración de sistemas. un perfil bastante
2:25 amplio en cuanto a mis intereses y conocimientos, pero bueno, eh puntualmente este año este sería mi primer libro que se llama Sistemas complejos en escala o a escala. Y bueno, ahí también hablo un poco de todo este tipo de cuestiones que me están interesando estos últimos años como seguridad, escalabilidad, resiliencia, observabilidad, etcétera, respecto de de sistemas críticos. un poco un resumen de lo que estuve trabajando estos últimos años.
2:51 Bueno, esta charla tiene un un título que se me ocurrió que es bastante simpático y es No sos Netflix. Y de esta idea que estuve pensando bastante respecto de no sos Netflix, es decir, no sos un una empresa o una organización gigantesca que necesitas escalar para un dos 10 o 20 millones de usuarios. Y luego de pensar mucho en escalabilidad y en este tipo de de cuestiones, tuve varias ideas al respecto.
3:22 Eh, y una de las más importantes es que escalar no es solamente soportar millones de usuarios. Escalar también es poder tener un código que lo pueden trabajar cinco desarrolladores al mismo tiempo. Es poder tener un microservicio que no se cae cada 2 horas. [resoplido] Es saber qué es lo que está pasando en en tu sistema en tu. Es muy común hacer una funcionalidad, desplegarla, creer que está funcionando, posiblemente están funcionando, pero está funcionando mal, no estás viendo los logs, no estás viendo tu cadena de observabilidad, quizás ni tenés cadena de observabilidad.
3:55 Eh, entonces empecé a pensar un montón de cosas respecto de situaciones que son comunes hoy, muy comunes y sobre todo con el uso de la IA o el mal uso de la IA en un caso, eso se aceleró y es el hecho de que por ahí nos ponemos a pensar o a cuidar cosas que no son las más importantes y nos ponemos o nos preocupamos respecto de escalar para 1 millón de usuarios y en realidad vas a tener 200 y puede ser que esos 200 más sean críticos.
4:23 Entonces, tu sistema tiene que estar bien hecho y tiene que estar bien hecho para 200 usuarios, no para 3,000. Entonces, un poco las ideas que que derivaron de esta idea inicial de Nos Netflix y la escalabilidad es la idea de escalabilidad respecto de ingeniería. Muchas veces nos estamos preocupando por ver la latencia de un microservicio y capaz que no tenemos cubierto el one de la ingeniería, de, no sé, brancheo, estrategias de brancheo, estrategias de desarrollo, eh formas de de encarar una aplicación, bueno, cosas muy básicas, ¿no?
4:57 Y por otro lado, otra idea derivada y es un poco donde yo he estado trabajando mucho estos últimos años es en sistemas que son críticos, pero no necesariamente son para 10 millones de usuarios o cinco o uno, quizás son para 20 usuarios. Y en ese caso puedo mencionar sistemas de tendering, sistemas de cuestiones médicas, sistemas que manejan dinero.
5:21 Bueno, yo estuve trabajando mucho estos últimos años en este tipo de cosas y un poco quiero contarles mis experiencias y mis ideas al respecto de cómo poder trabajar bien en estos contextos. Bueno, e una pregunta de arranque que es como un trigger, ¿no? Y bueno, muchas veces por ahí empezamos a decir, "Vamos a usar cubernetis o vamos a usar microservicios y vamos a usar cuatro zonas de disponibilidad y vamos a gastar,000 de AWS y en realidad probablemente puedas cubrir todo eso teniendo cinco Linux en 5 S2 con un eninx y alguna cosita más.
5:54 Vas a gastar no 20,000 sino 100 y vas a tener un control total de lo que hacés. vas a tener un equipo que es acorde a tu necesidad, no vas a estar haciendo sobre ingeniería y vas a estar enfocado en lo que tenés que estar enfocado, porque en esas 5 S2 o en un frontend o algunos servicios, algunas cosas más, hay un montón de cosas que que tenés que ver y que es muy probable que no estés viviendo eh o no las estés teniendo tan en cuenta en muchos casos.
6:21 Como mencionaba un poco lo que derivó esta idea inicial de de pensar en que no necesitas siempre escalar para un millón de usuarios, es que la escala no es lo mismo que la criticidad y muchas veces se tratan de igual manera, son cosas diferentes. A modo de disclaimer es una charla muy opinionada, pero muy argumentada también. Sí, no es una lista de mejores prácticas. No vengo acá a enseñar lo que tienen que hacer. Eh, no vengo a decir, "No uses esto, no sé aquello."
6:45 No es una charla eh a favor ni en contra de la IA. Es una charla que busca contar experiencias y cosas que me han dado resultado a lo largo de estos años en escenarios críticos y bastante desafiantes. ¿De dónde sale un poco? Y la charla va a estar dividida en estas cuestiones, ¿no? En los tipos de escalabilidad, en aplicaciones que son críticas y que por ahí nos estamos fijando en en donde no tenemos que estar mirando.
7:13 Hay cosas que son más importantes para revisar antes que que estar tratando de imitar lo que hace Netflix. Bueno, eh hay cosas que son muy críticas y que pueden ser para cientos o miles de usuarios, no millones posiblemente, incluso menos. Quizás puede ser para un sistema, puede ser muy crítico y quizás lo vayan a utilizar 20, 30, 50 usuarios.
7:35 Podemos estar hablando, como les decía, de sistemas eh públicos, de sistemas que manejan dinero, sistemas de salud, logística. Bueno, hay un montón de ejemplos y hay un montón de cosas en cada capa, por citar rápidamente algunas de ellas que deben estar muy bien tratadas. Por ejemplo, en una arquitectura moderna, el frontend, su despliegue, el back for frontend, si es que se usa, es decir, elas adentro que funcionan bajo ese patrón, los microservicios, toda la infraestructura que utilizamos alrededor de eso, eh la nube, cómo usamos la nube, cómo escalamos esa nube.
8:09 Muchas veces por ahí a veces me toca hacer alguna consultoría o me hacen alguna pregunta y y por ahí a veces la persona dice, "Bueno, no, esto está tiene autoscaling, entonces me quedo tranquilo porque si necesito algo va a escalar." La realidad es que no. Claramente no. Puede ser que vos tengas un auto scaling, pero que no pueda reaccionar a la velocidad que vos necesitas reaccionar. Entonces, por ahí el aprovisionamiento tiene que ser distinto. Bueno, todo ese tipo de edge cases que normalmente no los vas a ver si no te pasaron, eh, son los lugares en donde me interesaba abordar o al menos tratar de abordar.
8:42 No digo que los voy a poder abordar todos claramente, pero ese es un gran ejemplo cuando uno por ahí siente esta eh sensación de seguridad falsa y es de las peores cosas que te pueden pasar en tecnología. Entonces, una de las cosas que decía, antes de pensar en escalar a un millón de usuarios, pensemos en escalar al sexto developer y que pueda trabajar bien. Sí. Entonces, creo que todo esto de la escalabilidad, y esto lo pienso profundamente, está muy dado desde el punto de decir, "Okay, yo quiero escalar y en algún momento tener, no sé si un millón de usuarios, pero al menos tener mi sistema para que pueda escalar haí una cantidad crítica que pueda surgir."Lo primero que vas a tener que hacer para eso es el ABC de ingeniería.
9:25 Tenés que hacerlo bien. Sí, vas a tener que poder armar toda tu base para que después tu sistema pueda escalar. Si no, eso no va a suceder. Entonces, el primer problema que vas a tener si no sé entrás a un laburo nuevo o sos consultor o tenés que desarrollar una nueva aplicación, tu primer problema no va a ser cómo usar Docker o cómo usar Cubernetis o o si vas a usar Cafka o si vas a hacer algo distribuido o cómo vas a manejar las bases de datos de determinada manera ante las escrituras y ante la lectura, etcétera.
9:56 Vas a tener que ocuparte de que primero funcione lo básico, ¿sí? de que tengas un sistema de brancheo coherente, de que se adapte a tu negocio, de que se adapte a tu producto, a tu equipo, tener testeo, tener estrategias de precomits, tener estrategias de 6D, tener un montón de cosas que van a ir reduciendo mucho sus errores. Si lo que tenemos que tratar de hacer es reducir a lo más chiquito que podamos los errores, sobre todo errores básicos, errores tontos, ¿no?
10:26 Entonces, para pensar en algún momento a la escala crítica, lo primero que vas a tener que hacer es revisar todas las cuestiones que están antes, muchísimo antes, y tienen que estar bien hechas. Y realmente es muy común que eso no pase. No digo que en todos lados, no digo que siempre, pero muchas veces hay equipos de ingeniería que gastan miles de dólares, que se gasta un montón de dinero y todo funciona mal. Eh, si hay que hacer un cambio lleva 3 semanas o sabes que si tocas determinadamente se rompe todo y muchas veces nos acostumbramos a vivir con eso y está mal, claramente está mal.
10:57 Entonces, eh esto es lo que tiene que escalar primero. Sí, todas estas cosas que yo estoy diciendo las ves en cualquier libro de ingeniería, en cualquier libro de diseño de sistemas. No te tenés que ir al eh whiteboard de Google para decir, "Bueno, okay, voy a entender cómo funciona esto."Arrancar por por lo básico, arrancar por estas cuestiones que que además tienen mucha complejidad.
11:19 Entonces, eh esta es otra frase que me vino de experiencias previas que he tenido y poder tener cinco, ocho, 10 nivel deopers un equipo mediano chico que que pueda trabajar bien también es escala, que no se estén pisando, que estén trabajando bien, que el sistema de brancheo y de despliegue funcione bien, eh límites claros, los honers que estén claros, etcétera. E
11:45 bueno, acá yo pongo un ejemplo muy básico, pero digo cuestiones de estrategias de brancheo que que sirvo no me voy a detener en esto porque tenemos poquito tiempo y quiero poder cubrir todo, pero lo doy como ejemplo de cosas muy básicas, cosas eh muy core que muchas veces no se respetan, que no se tienen que no se tienen en cuenta y y que llevan a que tu sistema nunca vaya a poder escalar, incluso si no necesitas.
12:10 Es probable que nunca necesites tus 2 millones de usuarios con lo que te estás preocupando mientras el microservicio no arranca y tenés cinco usuarios que no los puedes atender. Pero no importa, además de querer mostrar esa dicotomía, lo que me interesa también es
12:24 tratar de ayudarte con la experiencia que yo he tenido en diferentes lugares para que puedas llegar a manejar bien tu sistema para la gente que necesitas. Y si después te escala a 500.000, 1000, 1 millón o 10 millones de usuarios, bueno, mejor vas a estar listo para eso. Eh, otro tema clave que no va a ser el el centro de esta charla, pero que es super importante mencionar, es el tema de la IA.
12:49 Hoy en día la escritura de código, ya hasta Uncle Bob lo dice, no es más el cuello de botella, no es más el problema, eh, pero todo lo que está alrededor sí sigue siéndolo. Eh, han visto que en estos años se mudó un poco esta idea de los desarrolladores van a morir todos a el hecho de decir, "No, van a trabajar de otra forma, ¿no? Eh, y es que en realidad es eso."El otro día leí a alguien que que respeto mucho y decía, "Escribí una aplicación, no miré una sola línea de código, pero me llevó unas 6 horas lograr la primer parte que funcione bien." ¿Por qué?
13:18 Y bueno, porque tenemos que empezar a a trabajar en todo lo que está alrededor. Testeo, CCD, desintegración, seguridad, seguridades del código, escalabilidad, etcétera. Entonces, la lo importante que yo, por ejemplo, en mis equipos lo que digo es buenísimo, fomentamos el uso día, nos encanta, nos parece increíble, nos parece que realmente es algo distópico, pero necesito un honor, necesito que alguien sea el responsable de esto y necesito sobre todo que se entienda qué es lo que está pasando,
13:47 porque otro de los cuellos de botella que ahora están que están sucediendo, que ya no son más el desarrollo del código, eh son, por ejemplo, o es por ejemplo el tema de que tenemos una aplicación gigante que no entendemos o Tenemos módulos que los escribimos muy rápido, pero no sabemos qué hacen o no sabemos cómo lo hacen. Bueno, todo es tipo de cuestiones también miden una cara de la escalabilidad que normalmente no es medida. ¿Sí? Entonces, e construir rápido también es escalar, pero hay que hacerlo bien.
14:15 Entonces, tenemos que poder generar rápido, aprovechar todo el tuleo que hoy tenemos disponible. Es increíble. Yo por ahí charlo con algún desarrollador y le digo, "La verdad es como tener superpereres, es realmente algo espectacular lo que sucede hoy, pero tenemos que saber usarlo y sobre todo qui tenemos decisión sobre un equipo, sobre cómo trabajo un equipo, tenemos que ser muy responsables con eso." Sí. Entonces es fundamental como core poder generar rápido, no hacer cualquier cosa, entender lo que está hecho y hacerlo bien.
14:43 Sí, el hecho de que vos no tengas que escribir el código no quiere decir que eso te asegure que lo vas a hacer bien. Hacerlo bien va a requerir un montón de otros pasos. Sí. Eh, eso va a permitir también que y especialmente en este momento de mucha guía y demás, tu sistema pueda escalar utilizando todas las cosas estado del arte y todas las tecnologías que que tenemos al alcance. un poquito la la frase que está un poco de moda es esta como de anda, pasa, pero nadie sabe ni por qué pasa ni por qué funciona, ¿no?
15:14 Entonces por ahí de repente nos acostumbramos a ver un PR de, no sé, 10,000 líneas o 20,000 líneas o cosas que son totalmente excesivas que es imposible de poder revisar y bueno, eso no debería pasar. Entonces ahí te tenés que apoyar en los 6D. Podés usar los mismos agentes o lls para que verifiquen código de acuerdo a normas que vos tengas. Podés trabajar por tamaño, bueno, puedes hacer un montón de cosas, ¿sí? Pero siempre tenés que tener a alguien que sepa qué es lo que está pasando.
15:43 No podemos tener como un blackbo box que no tenemos ni idea por qué se utilizó, no sé, pandas o o cómo se hizo tal o cual cosa y aprovechar ese potencial. Sí. Después, por ejemplo, otro de los grandes temas que muchas veces yo hace un ratito les contaba este ejemplo de alguien me decía una vez, bueno, pero va a escalar porque tengo un autal y no no necesariamente. Vos por ahí tenés un pico que el autale no llega a provisionar y no te sirve.
16:06 Sí, otro problema muy conocido y también a veces pasa si no sabemos bien lo que estamos haciendo, un poco lo que desprendía recién de lo que hablábamos de la IA, eh muchas veces son las sorpresas, o sea, un una mala factura de AWS o de Bull Cloud o lo que sea, eh, por haber hecho un mal manejo te puede destruir eh una startup o te puede destruir un proyecto que esté iniciando o te puede generar un gran problema eh a vos mismo como líder o a vos y a tu equipo.
16:38 Entonces, también la escalabilidad es tener un control de tus recursos y especialmente en recursos que son críticos a nivel dinero como eh como es el cloud y como son también los tokens, ¿no? Entonces ahí tenés que tener estrategias claras de outcale, tenés que tener estrategias muy claras de budget, de alertas, agregar alertas tuyas, o sea, entendé tu propia necesidad, entendé especialmente cuando algo se está haciendo de las manos.
17:03 No te enteres al otro día cuando te mandan el mail avisándote que pasaste un un límite que tenías establecido. Hay un montón de formas de hacerlo. Sí, yo no me voy a detener en ellas, pero es muy importante poder eh tener un control de eso, tener ownership muy claro de eso. Sí.
17:18 Después ahí habla un poquito de lo que es logs y demás y venía a esta palabra que es tan importante y muchas veces muy ignorada que es la observabilidad. A nosotros nos ha pasado descubrir en sistema problemas que que sucedían antes de que el usuario se entere.
17:34 Y no, no es magia, o sea, simplemente que tienes una traza que arranca en el fronen o arranca en tu cliente de lo que sea y hace todo el caminito y lo podés seguir y puedes ver qué pasó, en qué lugar y en qué cosa y y puedes atajar un montón de cosas. Ahí también le puedes metería, puedes hacer una revisión de logs o una revisión de traces, eh, lo cual es fantástico porque eso antes era muy tedioso de hacer, hoy lo puedes hacer muy fácil, muy barato y muy rápido.
17:58 Entonces, aprovechar ese tipo de cosas que te van a dejar tener un sistema muy sólido y que te va a permitir escalar lo que vos necesites. Acelerar un poquito porque si no me voy a quedar sin tiempo. Bueno, la seguridad, yo he dado una charla de seguridad el año pasado, creo que fue acá y como les decía, estoy trabajando ya hace algunos años con esto como foco. Trata de que tu sistema sea seguro. Hoy en día muchas cosas son muy baratas.
18:22 Es muy barato escribir test con la guía, es muy barato darle normativas de seguridad. le puedes decir as top 10 que son eh como el un guía de una organización que te dice dónde tenés que poner el focus y con el tipo de aplicación o lo que estés haciendo. Bueno, no voy a a a entrar en todos esos temas, pero la seguridad está en todos lados.
18:42 Entonces, una un esquema seguridad del código en tus configuraciones de cloud, en tus eh en tu frontend, en tu backend, en tus microservicios, en tus landas, eh es fundamental también para poder escalar. Bueno, acá llegamos a la parte dos, acelerando un poquito de los que le contab de lo que les contaba de que hay muchos sistemas que son críticos y no tienen escala o tien una escala muy chica. Bueno, ¿qué vuelve a un sistema que sea crítico?
19:08 Por ejemplo, trabajar con datos de personas, tener que tener cierto tipo de cuestiones legales que tenés que respetar porque tenés datos que son sensibles, porque son datos médicos o cuestiones relacionadas con dinero o tenés que algún tipo de cumplimiento normativo, eh, o manejas algo que no debe de velarse antes de tal fecha en, por ejemplo, en cuestiones de públicas, de algún tipo de proceso público. Entonces, hay más, pero bueno, podríamos pensar como en diferentes tipos de combinaciones posibles dentro de esta escala.
19:41 A mí lo que me atrajo para esta charla, además de lo que les contaba, los diferentes tipos de escalabilidad que hay, es el tema de sistemas de baja escala y alta criticidad, que son en los que yo estuve trabajando en los últimos 10 años. Sí. Eh, no importa de qué, puede ser cualquier tipo de sistema como esto que estuvimos diciendo, donde tenés pocos usuarios, pero tenés que hacer las cosas muy bien. Entonces, el margen de error es muy chiquito.
20:08 Entonces, tenés que tener, por ejemplo, muy controlados tus deploys, tenés que tener tu equipo muy entrenado para que pueda trabajar de acuerdo a reglas claras. Si trabajas con yo te recomiendo que sí lo hagas, por supuesto, hacelo bien y hacerlo de una forma coherente.
20:22 Tené tus reglas para frontend, para backend, para cloud. tratar de tratar a tu código de infraestructura, eh, o mejor dicho infraestructura como código, ¿sí? Que las cosas tengan previsibilidad. Pensar que si algo malo puede pasar, va a pasar, porque sucede eso. Eh, yo he perdido tres backups en tres lugares distintos en un mismo día. eh tener un modelo de amenaza definido, ¿sí? Servite de los LM si te lo permite tu compañía donde vos trabajes o tu proyecto.
20:53 Eh, si te permite trabajar, digamos, si podés subir el código y podés trabajar, que normalmente se puede porque tenés planes que tienen muy claro el trato de datos y demás, eh, pero utilizarlo para hacer un pente interno whitebox adentro de tratar vulnerabilidades dentro del código utilizando la IA. tratar alguna gente para tratar de atacarlo, para encontrar problemas.
21:15 El el gap que vas a reducir es increíble, ¿eh? Y en estos sistemas se agradece mucho porque no es que no puedas tener errores, pero tenés que tratar de que no sucedan errores porque si hay un error puede ser algo muy grave y posiblemente es un equipo muy chiquito, capaz de cuatro, cinco, 10 personas.
21:32 Bueno, eh otro gran ejemplo en lo personal a mí los microservicios me gustan mucho, eh, a mí las monolitos en general no me gustan, pero sí lo que yo sugiero es que si vas a utilizar microservicios sepas lo que tenés que hacer. Puedes usar microservicios para un equipo de cinco o 10 personas, para algo chiquito lo puedes hacer. Quizás muchas veces la recomendación pueda hacer resolverlo con lambdas, resolverlo con un monolito modular. Bueno, pero digo, si ya tenés más de algunos servicios, digo, para dos cosas, no lo no uses un microservicio, claramente,
22:07 pero si ya la cosa empieza a escalar o si sabes que en el mediano plazo escala, hacelo, pero hacelo bien, hacelo de una forma coherente, trata de no tener que repetir cosas por todos lados, tratar de ordenar tu equipo de cara a eso, ¿eh? Y siempre fíjate si te sirve, digo, evitar hacer algo sin saber por qué, solamente porque te lo dijo el blog de ingeniería de no sé quién. Bueno, lo mismo si vas a usar cubernetis o o demás.
22:27 Idea importante, simple, distinto de frágil, ¿sí? O sea, a mí en los últimos años me tocó trabajar con sistemas sólidos y super chiquitos. Sí. Eh, bueno, arquitecturas simples y serias, arquitecturas que van a funcionar, no reinventes nada. O sea, en general todo está inventado y y no tenés que ponerte creativo en ciertas partes. Bueno, ¿qué es lo que sí importa? Yo acelerando un poco para no quedarme sin tiempo. Que tu sistema sea confiable, un poco lo que hablábamos, que las cosas anden antes de pensar en 10 millones de usuarios, fíjate que los 10 microservicios que tenés no se caigan cada 15 minutos, tengan errores 500 por todos lados y demás, que sea seguro.
23:07 Usá desde el código, eh, empuj tus devs a que trabajen con seguridad del código. Si sos deb y no tenés un equipo, hacelo para vos mismo, para tu laburo o para tu proyecto. Hoy en día es muy fácil, insisto, con los LMS y demás hacer las cosas bien. Si, antes por era bastante más costoso. Tratar tu sistema ser recuperable. Me ha pasado tener que recuperar una instancia WS completa de cero. Sí. y no tenés nada y tenés que levantar todo, usa eh imágenes de de tus servicios, tener
23:38 backups de tus landas, etcétera, que sea mantenible, que no sea una pesadilla tener tu sistema andando, ¿sí? que puedas intercambiar piezas, que se va a alguien y viene alguien y que eso no sea una situación problemática, que pueda ser auditable de acuerdo al tipo de ley que te tengas que atar o que tengas que cumplir. A veces puedes tener más libertad, a veces menos, pero tratar que tu sistema sea totalmente aitable y que tenga una trazabilidad.
24:04 Bien. Eh, bueno, ya el tema de la IA ya lo lo tratamos y acá algunas cuestiones eh a tener en cuenta ya para ir terminando. La complejidad no es tu enemigo. Eh, el tema es que vos puedas hacer lo que necesites y que cuando necesites ser complejo lo hagas porque realmente sea lo que necesitas. Sí, hoy en día se trabaja mucho a través de modelo de de capas tipo por empaste. hago algo que anda más o menos, lo voy mejorando, lo voy mejorando.
24:30 Cuando ya está en cierto punto de que las cosas están bien, hago un release, separar lo que trabajas local de lo que vas lanzando, etcétera. Eh, tratá de ser predecible, ¿sí? y trat modular posible, trata de utilizar las cosas, insisto, cuando necesites, no antes, no ha una sobreingeniería, que que es realmente muy malo. Eh, bueno, acá te dejo algún algunos algunas ideas de de lo que estuvimos charlando. Ya estamos cerquita del final, ¿eh? Entonces, tres ideas para para lunes como esta especie de chiste que pongo, pero bueno, algunas cosas que quiero que te lleves y ya para ir cerrando, eh, escala no es lo mismo que criticidad.
25:13 Sí, escalabilidad, como decíamos, puede ser tener 10 millones de usuarios, pero también es poder trabajar 10 personas en un código y hacerlo bien de forma ordenada y eficiente. Eh, el one de la ingeniería tiene que estar, ¿sí? O sea, para pensar en algún momento poder crecer, tenés que hacer bien todas las cosas previas o lo mejor que puedas. Sí, hoy día muchas cosas, insisto, en este concepto, son baratas de hacer en cuanto a tiempo, en cuanto a dinero, gracias a la inteligencia artificial. Aprovechala. Inteligencia artificial, úsala bien. Sí.
25:42 No, no hagas cosas que no entendés que son, por más que parezcan super brillantes, porque eso va a ser un problema en el mediano y largo plazo. Ponete complejo cuando necesites, ¿sí? No solo por hacerlo. Si realmente necesitas una estructura compleja que la tienes que escribir en ROS y hacer no sé qué cosa, hacelo, pero solo si lo necesitas. Eh, luego puede haber sistemas que son muy críticos y muy chiquitos o muy pocos usuarios, pero armaralos bien, armarlos bien.
26:08 Y un poco la idea esta que es en cierta forma como una provocación, pero como también lo fue el título en esos Netflix, diseñar para el sexto developer antes de pensar en que vas a tener 12 millones de usuarios porque realmente pasa mucho. Entonces, anda por pasos, ¿sí? y tratar de ir aprendiendo de cada experiencia que vas teniendo.
26:26 Obviamente yo hoy no estoy parado acá después de 20 años de carrera y las cosas que soy no las sabía antes, pero hoy tenemos un montón de fuentes de para poder aprender. Hoy aprender es muy barato también en términos de dinero y de tiempo. Entonces, eh depende de vos básicamente. Y la idea que que quería que que se lleve que ve esta charla que está un poco dirigida a mucho público, está dirigida a gente de un board, puede ser a un manager, a un developer, es como bastante amplio el público, eh, porque creo que para a todos le sirve un poco, ¿no?
26:58 O sea, le puedes servir a tu jefe para ver que te pide, te puedo servir a vos para ver que le sirve a tu colega de frontend. E así que bueno, nada, espero que que les haya gustado, que les haya servido. Es una charla en la que estuve pensando mucho. Va a haber varias charlas, eh, no en ardearla, pero sí en varias charlas la que estoy trabajando y varias ideas respecto de esto. Es un tema que me interesa y que creo que es de mucha utilidad para todos.
27:21 Así que bueno, gracias eh gracias Nardearla. Ahí tienen mi mail personal, tienen mi blog también si les interesa contactarme. Y bueno, nada, gracias Nardarla por este esta oportunidad, esta nueva oportunidad y bueno, nos vemos en la próxima. Gracias.