Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Juan (00:00)
yo empezaba a estudiar sobre microservicios, recuerdo que había como un furor. Y en internet todo el mundo hablaba sobre microservicios y decían, las aplicaciones monolíticas están muertas. Si estás haciendo tu aplicación monolítica hoy en día, sos un mal profesional.
Y es curioso porque luego con el tiempo la gente empezó a notar que no toda aplicación tiene que ser así. hecho, yo me atrevería a decir que la gran mayoría de aplicaciones que vemos hoy en día en internet son monolíticas y está bien.
Bienvenidos sean todos a una de mis edición más de nuestro podcast, & Ops, el podcast donde tratamos de explicarte muchos conceptos que son complejos de una forma más simple y compartiendo todo lo que son nuestras experiencias a través de los años en el área de tecnología. Como siempre me acompaña mi buen amigo Douglas para poder darnos su punto de vista, un punto de vista muy experimentado.
y que ha vivido muchas cosas a lo largo de los años Douglas, ¿cómo has estado? ¿Qué tal? Tiempo sin verte Douglas ¿Qué tal?
Douglas (01:11)
Juan, ¿qué tal? No, mira, como siempre, gracias a Dios y como siempre lo he dicho, contento de tener estas conversaciones. Realmente que es bueno poder compartir experiencias o pensamientos y que les sean de valor a las personas que nos ven y nos escuchan, pero también es interesante ponerse a pensar.
en la cantidad de cosas que he aprendido en este proyecto, yo a nivel personal. Uno de las conversaciones que tenemos, y obviamente desde tu perspectiva, o tu punto de vista, o cuando he logrado entender cosas que no había entendido, lo que tiene que ver con desarrollo de aplicaciones, sobre todo en backend, o a veces el uso de herramientas que vos has usado y yo no usaba y las he empezado a implementar en mi flujo y me han servido. Y también las cosas alrededor, Este tal vez no sea el tema principal.
pero las cosas alrededor, ¿no? Desde a veces que me has compartido un prompt de IA para preparar algo respecto al podcast, ¿no? Elición de contenido o cosas similares y es un prompt que lo implementé y me ha ahorrado muchísimo trabajo. ⁓ el trabajar en la... Esta semana estuve trabajando en unas cuantas mejoras a la página web. Tenemos página web, ¿verdad? Debenops.show. Porque pues yo tengo mucha experiencia.
hosteando aplicaciones web.
Y vos tenés mucha experiencia en backend de desarrollo. Sin embargo, ninguno de nosotros dos tiene experiencia en frontend y en desarrollo de lo que es la parte visual. Y ha sido bien interesante. Entonces, me alegra y me siento honrado de la forma en cómo me introducís, ¿verdad? Respecto a la experiencia que he adquirido, por gracias a Dios. Pero más allá, cuando recapacito, he aprendido también bastante de este proyecto. Y bueno, la idea es lo que sea que...
vamos a seguirlo compartiendo.
Juan (03:08)
Gracias Douglas, la verdad es que sí...
es interesante cómo vamos aprendiendo mucho del uno del otro y aprendemos de todos los que nos rodean. Por ahí he escuchado que somos el promedio de los que nos rodean y eso no sé si es así exactamente la cita, pero así es como yo lo recuerdo y creo que tienen razón. Has visto, Como si las personas que te rodean empiezan a leer libros, empezás a leer libros, empezás y los que te rodean salen mucho de fiesta.
Empezas a salir mucho de fiestas. Al estar aquí rodeado de, en este caso, de tu experiencia, también yo he aprendido mucho. Sí, sí, definitivamente. Bien, el día de hoy, Douglas, vamos a tener un tema bastante...
Douglas (03:51)
Aquí levantamos el promedio.
Juan (04:03)
Para mí es muy interesante, espero que para nuestra audiencia también lo sea, porque es un tema que lo hemos mencionado mucho a lo largo de los episodios.
es un tema que siempre le hemos dado un punto dentro de los tópicos que hemos hablado, dentro de los temas que hemos tocado y siempre mencionamos que es muy importante. Pero creo que no hemos hablado específicamente de esto y bueno, para los que están viendo, estoy seguro, hayan visto el título del video, pero para los que nos están escuchando es Arquitecturas de Aplicaciones, Arquitecturas de Software y es básicamente cómo vamos a estructurar todo
lo que es nuestra aplicación, cómo va a funcionar, cómo se va a comportar.
y vamos a ir viendo que este tipo de decisiones tienen una repercusión muy grande tanto así que a veces pasar de una arquitectura otra es muy complejo no es imposible porque bueno de hecho ya lo hemos hecho en algunas ocasiones pero definitivamente es algo que no querés hacer a mitad de camino querés definirlo una vez y cambiar solo en caso que sea necesario
Las arquitecturas de software Douglas te menciono que... Bueno, cuál es la finalidad de definir una estructura, una arquitectura en específico y ya vamos a ir hablando de cuáles son las arquitecturas que queremos mencionar el día de hoy. Pero la finalidad de estas arquitecturas y de hecho lo apunté por aquí para que no se me olvidara.
es que poder tener un mayor control sobre la escalabilidad y mantenibilidad. Escojí palabras bien así y yo, a mí me cuesta, pero bueno, las escogí y ya está ahí. Desde mi punto de vista, Douglas,
Douglas (05:49)
trabalenguas.
Juan (05:57)
una de las mayores ventajas o desventajas de todas las arquitecturas que existen es el hecho de poder expandirte o poder agregar o quitar funcionalidades de manera más fácil. Obviamente hay muchas más aristas con respecto a lo que es una arquitectura, también te permite no ya sea ahorrar costos incluso en ciertos pasos del desarrollo, ciertos pasos del...
del CI-CD pipeline que de hecho tenemos un episodio ya en el canal sobre esto pues si no lo han visto pero a nivel general tener una arquitectura ya predefinida y que ya todos sabemos para dónde tiene que ir una aplicación nos permite pues tener un mapa claro de cómo tenemos que ir dándole forma a nuestro producto porque al final les la arquitectura es para generar un producto que es el producto digital
Desde mi punto de vista, eso es Douglas, tener una arquitectura de software. Cabe recalcar, cabe mencionar y que cuando estamos hablando en este momento de arquitecturas de aplicaciones, no hay que confundirlo con la arquitectura que podemos tener a nivel de proyecto.
Por ejemplo, ¿qué otras arquitecturas existen por ahí? Como lo que es Domain Driven Design, Arquitectura Hexagonal o Clean Architecture. Bueno, en Frontend hay otros tipos de arquitecturas como lo que es Single Page Application, Multi Page Application y todas estas. En Frontend no tengo tanta experiencia con las arquitecturas. En este caso vamos a hablar Douglas de las arquitecturas que son más generales. Estamos hablando de la arquitectura.
principal de la aplicación de todo el sistema correcto. Esto va a abarcar desde cómo vamos a setear nuestras bases de datos, cómo se van a interactuar los diferentes módulos dentro del sistema y todo eso. ¿Te ha tocado Douglas en algún momento, no sé si para alguna empresa o para algún trabajo por aparte, tomar la decisión de qué arquitectura se va a implementar? O te ha tocado
Douglas (07:48)
de todo el ⁓
Juan (08:15)
cambiar alguna arquitectura de algún tipo.
Douglas (08:18)
Mira, qué pregunta más interesante. Mira, para sistemas que van a incluir desarrollo, no.
pues yo creo que la razón es obvia.
e influido en algunas ocasiones, sin embargo no es decisión final mía. Por supuesto en sistemas que tienen que ver únicamente con la parte de sistemas o la parte de operaciones, sí, pero pues ya estos no incurren necesariamente código y pues sí tiene que ver con arquitectar un sistema y por supuesto encaja dentro del tema de hoy. Pero en eso nos vamos a profundizar porque queremos que vaya más relacionado con
con el desarrollo de aplicaciones y no con arquitectura en general. Yo recuerdo arquitectar sistemas que enviaban correos electrónicos, por ejemplo, para campañas de correos electrónicos. Estoy hablando, ¿qué? 2009, ya día, No estaban estos servicios que hoy en día tenemos para enviar correos electrónicos y los que estaban eran extremadamente caros. Entonces nosotros arquitectábamos ese tipo de soluciones. Ahora...
Mira qué interesante, Juan, lo que estás diciendo. Y estaba un poco recordando algunas cosas que me generan un poco de gracia porque tienen cierta ironía. Nosotros las personas de sistemas, cuando se crea una nueva aplicación, nuevo software, una nueva herramienta, o sea, le hacen mejoras a una herramienta existente, la arquitectura final no tiene un impacto...
disruptivo necesariamente en nuestro día a día. Más adelante puedo profundizar un poquito en ello. Por supuesto que afecta, por supuesto que es importante y relevante. Pero no tienes impacto disruptivo, sin embargo...
Normalmente, al menos esta sido mi experiencia en todos los lugares que he fíjate que interesante, normalmente nos quejamos cuando se reúne el equipo que lo va a arquitectar, normalmente hay alguien que está haciendo el rol del arquitecto, puede que haya alguien del lado del cliente, etcétera, cuando se reúnen y no incluyen a nadie del área de sistemas o del área de operaciones, porque entonces cuando empieza la implementación y pidieron un cluster web y damos tres
cuatro o cinco instancias o damos un auto scaling group cuando ya están listos para publicar dicen fíjate que los archivos que subí no se ven
¿Pero por qué no se ven? No, no sé, yo subí el archivo y ¿dónde lo guardaste? No, yo lo guardé en el servidor, bueno, que es un cluster pues. Se guardó en uno de los servidores del cluster o en los demás no está. Ah, pero ocupamos guardar permanente, pero ¿por qué no lo dijeron cuando hicieron la solicitud de la infraestructura, no? Si nos hubiesen incluido, lo hubiésemos sabido y les damos opciones. Entonces, me resulta un poco irónico que nos quejamos porque no nos incluyeron, pero cuando estamos en esas reuniones
que nuestro aporte son pocos, aunque significativos, de nuevo, en muchas de estas reuniones identificado, mira, eso es un error bien común, que quieren subir archivos de manera permanente, que persistan a los, a cuando agregué jiquites máquinas al clúster o agregué jiquites pods, entonces venir a decir, entonces usemos un NFS, o usemos un stream, verdad, y entonces ahí la sugerencia, no, no, esto no lo puedes hacer de esta manera.
Juan (11:45)
Ok, sí.
Douglas (11:48)
o salen algunas locuras que quieren que... una vez me topé con alguien que quería y esto fue hace tiempo, que si fallaba... por ejemplo, voy a usar los proveedores de hoy en día para que la gente me pueda seguir, que alguien diga, si falla Cloudflare, que nos responda a Akamai. No, no se puede, es imposible porque tenés que tener el domino registrado, los nameservers solo en un lugar, pues, o sea, en la arquitectura de cómo funciona el DNS no...
Juan (12:07)
Ok
Douglas (12:16)
no es realmente posible, ¿no? ¿Verdad? Entonces... Sí... ¿Pero por qué no hacemos el failover? Bueno, no sé, realmente que te puedo asegurar que no funciona como crees, ¿no? aunque intervenimos poco y en la mayoría del tiempo a veces estamos aburridos, pedimos estar en esas reuniones cuando arquitectan la aplicación, el sistema, etcétera.
Juan (12:19)
Sonaba como una buena solución en su cabeza.
Douglas (12:41)
Y entonces, verdad, no nos va a impactar mucho y ahora vamos a hablar un poquito, pero esa ha sido mi experiencia mayormente con esto. Nunca he decidido porque no recae sobre mí, pero normalmente lo ideal he pedido estar en esas reuniones para poder aportar desde el lado de la infraestructura.
Juan (13:01)
Sí. Sí,
y bueno, solo para aclarar un poco, cuando mencionas que no tiene un impacto para nosotros, decís, te estás refiriendo al departamento de DevOps, SRE y Sysadmin,
Douglas (13:16)
sí, sí me refiero a nosotros en sistemas, en sysadmin, DevOps tal cual y no es que tiene cero impacto, hay un impacto, hay una diferencia pero tal vez a medida avancemos de nuevo esto me resulta un poco irónico a mí pero a medida avancemos te voy a explicar tal vez por qué es que no me hace una mayor diferencia que me pidas una base de datos para microservicios a que me pidas una base de datos para un monolítico, verdad, entonces ahí sí, para mí va a ser una base de
Juan (13:21)
Uh-huh.
Claro, claro.
es una base de datos.
Douglas (13:46)
Entonces puedo pensar en capas de seguridad, que vilance y verdad pero bueno, en fin, a medida que progrecemos lo comentamos para que la gente sepa que hay eso me estoy refiriendo cuando digo que el impacto no va a ser tan grande en la mayoría de los casos.
Juan (13:55)
Mm-hmm.
es cierto, sí. Es interesante cómo a veces el estar presente en la toma de decisiones, aún si la decisión no recae en uno, pero al momento de estar presente, podemos prevenir diferentes situaciones. A mí me pasa, me veo...
como cuál es la palabra, identificado con lo que estás mencionando, cuando me incluyen en las reuniones sobre el diseño de la página web o de la aplicación móvil, como todo el diseño, la parte gráfica, el front, gracias. Yo soy de backend y pues a primera vista parecería que yo no tengo mucho que aportar.
Douglas (14:43)
front end.
Juan (14:52)
Sin embargo, a medida que he ido participando en todo esto desde el inicio, me he dado cuenta que de hecho tengo un gran impacto, así como lo que mencionaste. Pareciera que cuando estás ahí uno dice, bueno, pero yo aquí no tengo nada que aportar. Sin embargo, hay momentos en los que uno puede identificar algo.
que para las personas que lo diseñaron es una gran idea y bueno al menos en el caso de Frontend se ve muy bonito y todo eso pero luego empezás a analizar y decís pero si lo hacemos así significa que yo del lado del backend tendría que hacer esto esto esto y esto eso incurriría en un mayor coste computacional o esto lo otro y empezás a dar los no dar trabas pero sí exponer las dificultades de hacerlo
Y eso incluso me ha pasado que como resultado hay que cambiar el diseño. es que bueno porque si no significa que al momento de la implementación cuando ya se estimaron todos los tiempos cuando ya ahí nos hubiéramos dado cuenta de que no se podía. Entonces es mejor hacerlo antes. Es como cuando dicen es mejor que haga falta que sobre y no que haga falta. Algo así.
Douglas (16:08)
Sí, sí, sí.
Juan (16:10)
Bien, ¿te parece si empezamos Douglas con el tema que tenemos y los ejemplos? Van a existir diferentes tecnologías, diferentes arquitecturas. estoy, recapitulé en este momento Douglas, tengo anotadas, tengo unas notas por aquí, para los que me están escuchando. Recapitulé las cuatro que creo que son las más interesantes o las más importantes hoy en día o las más comunes, tal vez.
Douglas (16:16)
supuesto, sí.
Juan (16:39)
Vamos a ir mencionando, las voy a mencionar y luego las vamos a ir detallando una por una. Las que tengo detalladas aquí serían arquitectura monolítica, arquitectura de serverless, tenemos un episodio sobre serverless por cierto, serverless y todo eso. Micro servicios, en el frontend está el equivalente de micro frontend, no voy a entrar en ese terreno porque de nuevo no tengo tanta experiencia en frontend.
Y la última arquitectura que me gustaría mencionar más adelante sería la de Event Driven Design o arquitectura basada en eventos. Todas estas arquitecturas estoy seguro que en algún punto hemos tenido experiencia con más o menos con alguna de ellas.
tanto nosotros dos Douglas como las personas que nos están escuchando, estoy seguro que han trabajado con alguna de ellas. Por ejemplo, serverless es muy popular para las personas, no sé si estoy sesgado en esto Douglas, pero me parece, perdón, que es bien popular con las personas que son freelance y se dedican a hacer aplicaciones móviles, aplicaciones front-end. Esa es mi percepción, puede que esté equivocado. Monolíticos, microservices y todo eso.
Vamos a iniciar entonces con la más común, con el clásico de clásicos que es una arquitectura monolítica. El OG de las arquitecturas, así me era. Esta arquitectura Douglas es una probablemente sin darnos cuenta, bueno al menos eso era así me pasó a cuando venía empezando a programar y a saber lo que era un sistema de software.
Douglas (18:03)
D.O.G.
Juan (18:25)
yo desarrollaba aplicaciones monolíticas sin saber que ese era el nombre porque esa es como la forma más intuitiva de trabajar es la forma en que nos hace sentido, si estoy haciendo una aplicación pues en el directorio ahí donde están los archivos de configuración y de código ahí voy a tener todo la autenticación
pasarela de pagos, galería de imágenes, alguna rama social que tenga la aplicación, va a en un mismo directorio, en un mismo repositorio. Y bueno, esa es como la clásica. Te voy a mencionar algunas ventajas que existen en Douglas.
La primera es que es muy ideal para el modelo para los MVP, para las aplicaciones que son MVP, que querés lanzar algo muy rápido, puede funcionar muy bien. Para aplicaciones también que no son tan complejas y ojo, esta afirmación poco compleja es compleja en sí misma.
porque qué es que determina la complejidad pero tal vez la métrica que nos puede servir es una aplicación que tenga pocos módulos o pocas piezas entre sí y de nuevo estamos iniciando no tenemos un mercado una audiencia tan grande ahí puede ser muy útil muchas startups la pueden utilizar porque de nuevo te da rapidez te da facilidad de que todo está en mismo lugar
Ya mencioné que es intuitiva, por ende es fácil, es fácil de desarrollar. Tienes en un solo directorio, en un solo repositorio, tienes todo el código. También, esto también facilita no solo el desarrollo, sino el despliegue de la aplicación, porque pues podemos hacer las pruebas unitarias, luego generas un solo binario, una sola imagen de Docker, cualquiera de las... de la manera que elijas para hacer el despliegue, pues es una sola.
Y también algo que es muy infravalorado en mi opinión Douglas es que es fácil de depurar. Es fácil de revisar cuando algo sale mal de nuevo porque está en un solo sitio, vas a una parte y ahí está. Entonces, esas son las ventajas que yo considero más significativas de este tipo de arquitectura monolítica.
Me gustaría escuchar tu opinión Douglas sobre aplicaciones monolíticas. ¿Te parece que son una buena idea iniciar con una aplicación monolítica? ⁓ ¿O no sé, has tenido malas experiencias con este tipo de aplicaciones? Tengo listadas algunas desventajas, pero no sé si has tenido malas experiencias con ella o algo así.
Douglas (21:13)
Fíjate que he tenido malas experiencias con todo tipo de arquitectura con la que he trabajado realmente y también he tenido buenas experiencias y a lo largo de los años he ido aprendiendo dónde está el problema. La mayoría de las veces el problema está entre el teclado y la CIA, ¿verdad? O sea, el usuario. Pero muchas veces también es problema del sistema como tal.
Juan (21:31)
Error de capa 8.
Douglas (21:41)
varias cosas, Juan, una de que se siente más intuitivo para aprender un monolítico, yo lo creo y tiene sentido para mí. De hecho, en mis años iniciales cuando programaba en Visual Fox Pro y Visual Basic, eran aplicaciones monolíticas,
Sin embargo, yo creo que nos parece fácil, Juan, porque así se enseñó, simplemente porque los libros, los textos, toman muchos años en actualizarse, sobre todo antes, tal vez hoy en día es más rápido que se actualicen cursos y la información, pero aún en las universidades se siguen enseñando.
Juan (22:02)
mmm
Douglas (22:15)
modelos antiguos porque el currículum sigue con esa lista de requerimientos. Entonces, como es lo que vimos, nos parece más fácil. Pero como los elementos son los mismos, alguien pudiera aprender en servicios. Por ejemplo, los elementos son esencialmente los mismos en arquitectura. ya lo vas a mencionar vos a medida avancemos. Pero eso con el aprendizaje.
Juan (22:30)
Ajá.
Douglas (22:39)
En cuestión de si es bueno o malo, fíjate que lo mencioné un poco en el episodio anterior donde hablamos de Kubernetes versus DockerSwarm, que yo siempre hago la distinción entre una aplicación simple y compleja, simple no necesariamente que es absolutamente simple, pero que tiene menos elementos.
Menos cosas que se mueven y complejas es que tiene mayores elementos, diferentes capas de caché, colas o lo que queras ponerle. Y también tenés aplicaciones grandes y pequeñas. ⁓ lo grande y pequeño tiene que ver con la cantidad de usuarios, con el uso, con el dinero que genera. Entonces no siempre va ligada la complejidad a una aplicación grande.
Juan (23:06)
Sí.
Douglas (23:28)
o la simplicidad a una aplicación pequeña. separando que la aplicación puede ser simple o compleja en cuestión de la tecnología que estás usando, la arquitectura, framework, etcétera, y que una aplicación puede ser pequeña o grande, basada en la cantidad de usuarios, el tráfico, el dinero que generan, etcétera. Yo creo que monolítico...
Juan (23:32)
Sí.
Douglas (23:51)
las experiencias malas que he tenido es cuando se vuelve una aplicación grande porque entonces ahí troubleshooting sí es más complicado porque entonces los logs o van en los logs del web por ejemplo de NGINX tengo request del módulo de usuarios tengo request de la parte de ventas tengo request de la parte de reportes etcétera entonces
y es una aplicación con bastante tráfico, el troubleshooting se vuelve complejo, ¿verdad? Pero cuando la aplicación es relativamente pequeña, es más fácil. Y en ese punto, si la aplicación es relativamente pequeña, si lo haces en servicios o microservicios, me va a complicar el troubleshooting ir a un montón de lugares, a tratar de seguir, a rastrear un error cuando la aplicación es pequeña.
aparte que cuando hostear un servicio, no estamos hablando de eso, no, pero lo estoy comparando, hostear servicios y microservicios comparado con monolíticos normalmente es más caro servicios y microservicios, pero la ganas en la flexibilidad que te da y ahí donde ganas mucho más dinero, no, pero de nuevo porque esperas que la aplicación sea grande, entonces para responder tu pregunta
Juan (25:05)
Sí.
Douglas (25:11)
Para mí, monolítico es muy bueno cuando la aplicación es mediana a pequeña. Puede ser el sistema interno, el sistema de recursos humanos, el sistema de empleados o nómina, o puede ser un blog o un wiki interno, o cualquier otro sistema puede ser también externo, pero cuando va a tener un tráfico alto.
Juan (25:17)
Sí.
Douglas (25:36)
Y no se espera que llegue a tener un tráfico alto o algo que sea demasiada adopción o que dependa de manera crítica el negocio de ella. No se proyecta ahí de nuevo. sea, el sistema interno de nomina y de empleados lo haces en monolítico, eso te sirve. Tengas cinco empleados o tengas 2.000.
Juan (26:02)
Sí.
Douglas (26:02)
le agregas más recursos, optimizas algunas cosas pero sigues trabajando con el monolítico. Entonces, para responder la pregunta de nuevo, para mí cuando en grandeza, no en complejidad porque es probablemente de los menos complejos, el monolítico cuando la aplicación es mediana o pequeña, el monolítico es mejor opción y de nuevo el monolítico tiene muchas...
muchas piezas que se mueven siempre, como monolítico aprendí yo a separar una aplicación en capas, pasar de instalar todo en un solo servidor a empezar a dividir las diferentes layers o capas, que base de datos, que cache, que web, que incluso capas de backend y frontend, verdad, recuerdo tiempos como esos haciendo proxy, entonces esa ha sido más o menos, Juan, mi experiencia con los monolíticos.
Juan (26:52)
Qué bueno. Me recuerda mucho a que también yo he experimentado. En su momento, recuerdo hacer varias aplicaciones monolíticas con el framework de Laravel, de PHP. Me gusta mucho ese framework porque te da, bueno, es una acción muy buena para todo lo que tiene que... Los haters de PHP, PHP. Dicen que este año muere PHP, pero bueno, todos los años dicen lo mismo.
Douglas (27:11)
Cuidado con los haters, De PHP. ⁓
Sí.
Juan (27:22)
La arquitectura de una aplicación, si bien está muy ligada al código y cómo vamos a desplegar la aplicación, también empieza a verse reflejada en muchas otras partes. Algo que muchas veces no tomamos en cuenta y bueno, es normal, Cuando uno viene empezando no pensas mucho en esto. En muchas empresas hay equipos específicos para...
que tomar la decisión sobre la arquitectura de un sistema, ya sea los managers o un grupo en específico. Pero algo que empezamos a notar cuando tenemos que tomar estas decisiones es que la forma de la arquitectura va a dictar cómo vamos a hacer el despliegue, cuántos servidores vamos a necesitar, cuántos recursos vamos a utilizar. Una de las primeras desventajas de la arquitectura monodilítica es que la escalabilidad
es un poco, digamos, limitada o incluso compleja. Va a ser más difícil escalar, en comparación con las otras arquitecturas, un sistema monolítico. También, en un sistema monolítico, los ciclos de despliegue...
normalmente suelen ser más lentos porque de nuevo una aplicación monolítica en un solo repositorio, una sola aplicación vamos a tener los diferentes módulos de pagos, autenticación, los perfiles, todo esto. Así que tenemos que asegurarnos que todas estas piezas puedan trabajar bien entre sí. Así que normalmente se suele hacer ciclos de despliegue un tanto más
de hecho lo más rápido que yo recuerdo en una aplicación monolítica que yo trabajaba se hacían los despliegues eran cada dos semanas más o menos y era una fecha específica si no tenías listo el issue o el cambio para esa fecha se postergaba para el siguiente siguiente ciclo
Entonces, bueno, eso es como una desventaja para un software, producto, un sistema que queremos que esté siendo actualizado constantemente. Creo que a todos nos gusta que cuando estamos utilizando una aplicación, ver que se actualizó y agregaron algo nuevo a los usuarios pues les gusta esto. Y bueno, como ya dije, al hecho de que están entrelazados los diferentes módulos,
esta es la desventaja que un solo módulo, una sola parte del código podría afectar a toda, la totalidad del sistema. Esta es una de las primeras desventajas que las personas en su momento empezaron a detectar y empezaron a idear otras opciones. Pero bueno, eso es la arquitectura monolítica.
También recuerdo Douglas, en cierto momento, cuando yo empezaba a estudiar sobre microservicios, recuerdo que había como un furor. Y en internet todo el mundo hablaba sobre microservicios y decían, las aplicaciones monolíticas están muertas. Si estás haciendo tu aplicación monolítica hoy en día, sos un mal profesional.
Y es curioso porque luego con el tiempo la gente empezó a notar que no toda aplicación tiene que ser así. hecho, yo me atrevería a decir que la gran mayoría de aplicaciones que vemos hoy en día en internet son monolíticas y está bien. Eso está muy bien.
Douglas (31:01)
Fijate Juan, que respecto a los contras que está dando, obviamente, que estoy muy de acuerdo con ellos, y es para expandir un poquito y de manera breve lo que yo mencionaba antes, que es de los retos que exige el monolítico y es donde ya ahí la aplicación comienza a ser grande de nuevo, entonces al hacer grande genera problemas y hay que cambiar el nivel de complejidad porque yo recuerdo muy bien casos donde, como es la misma base del código,
Juan (31:21)
No,
Douglas (31:31)
Entonces la misma aplicación donde están los usuarios haciendo compras es la misma aplicación donde está la gente interna agregando productos e inventario. Es la misma aplicación. Había bastante incremento de usuarios, entonces habría que agregar más instancias. aquel momento era todavía el tiempo de las VMs.
Juan (31:44)
Sí.
mmm
Douglas (31:56)
Habría que agregar
más instancias, entonces como tenía separado las capas, agregaba más servidores para los usuarios web, ¿verdad? Los de usuarios internos no los necesitaban, pero de repente la funcionalidad de reportes, ese le ponía exigencia a la base de datos.
porque hay un query complicado y ya se optimizó todo, pero es muy complicado. tienen pocos, solo son dos personas trabajando internos, esas dos personas crashaban la aplicación para los usuarios porque la base de datos se caía. Entonces ahora hay que agregarle más bases de datos, no para los usuarios web, sino para los usuarios internos, ¿verdad? Y ahí complicaba. ¿habían estrategias de crear un clóster web?
Juan (32:37)
Mm-hmm.
Douglas (32:44)
con un set de bases de datos para la web, verdad, y tener otras dos instancias con una réplica a la base de datos para lo interno, pero qué pasa, tanto como es la misma base de código, siempre estaba el código de la funcionalidad interna en los web haciendo carga, aunque no lo estés usando, no, es código que carga, y en la parte interna tenías el código que está para web haciendo carga, entonces...
Juan (33:04)
jajaja
Douglas (33:11)
esos son los dolores de cabeza que me está recordando ahorita con esta conversación, verdad, es hacia donde iba, es ahí donde entonces hay que ponerle un poquito más de complejidad, segmentar más que nos vamos a empezar a beneficiar de otro tipo de arquitectura.
Juan (33:15)
jajaja
normalmente, y ojo, no tiene que ser así, normalmente muchos sistemas inician siendo un sistema monolítico y luego empezamos a migrar hacia una estructura o una arquitectura diferente. Bien, continuemos Douglas con la siguiente porque aún tenemos que hablar de las otras arquitecturas. La siguiente sería la arquitectura serverless.
y acá empezamos a ver que la arquitectura no es solamente el hecho de cómo está mi código, dónde están las diferentes piezas de mi código, sino que también ya incurre en qué plataforma voy a utilizar, qué servicios externos voy a contratar y muchas otras cosas. La arquitectura serverless, como mencionaba, es bien popular con muchos profesionales. Tenemos un episodio específicamente sobre este tema.
He olvidado el título de ese capítulo Douglas, pero por ahí está. Sí, dice algo. Ya lo olvide. Aún así, es una arquitectura que es muy interesante y a veces se puede entrelazar con otras arquitecturas.
Douglas (34:29)
Dice serverless algo.
Juan (34:43)
porque también nos permite tener procesamientos esporádicos, algo que ocupamos hacer que no tenemos que estar, no es necesario tener el servidor corriendo constantemente sino que de ciertas horas, ciertos momentos ahí podríamos tener un procesamiento, una funcionalidad y ahí serverless es muy bueno
También pues la gran ventaja del serverless, no tenemos que manejar nosotros los servidores, sus versiones, seguridad y todo eso, no tenemos que hacerlo. Una gran ventaja también es que tiene un coste barato inicial. No me voy a extender mucho en todo esto porque ya tenemos un episodio donde hablamos bastante sobre serverless.
Me gustaría también mencionar que las desventajas que tiene es que tiene Cold Starts cuando arranca la primera vez después de un período de tiempo prolongado a veces la aplicación tarda un poco más de lo que necesitábamos y esto puede ser desventajoso dependiendo del producto que tengamos tal vez no sea producto necesita que tengamos mucha velocidad por algún motivo
Nos encontramos con el famoso vendor log y ahora ya estamos amarrados a una infraestructura de un servicio.
y da la casualidad que luego sacó algo mucho mejor, la competencia, ya no podemos migrar. Eso es algo que me ha, paréntesis, eso es algo que me ha gustado de cómo se ha movido el tema de inteligencia artificial y es que hoy en día es muy fácil cambiar de modelo. Realmente no hay, sí hay diferencia en los modelos.
Douglas (36:24)
Si es cierto.
Juan (36:29)
pero no afecta tanto donde tenés y donde está tal vez ya cuando tenés contratos más grandes puede ser un problemita pero el modelo en sí funciona eso me gusta y bueno otra desventaja muy grande de los serverless es que a veces es un poco complicado de monitorear
tienen muchas herramientas de monitoreo que son muy buenas la verdad pero pues es complejo cuando queremos saber algo muy granular no puede ser un poco complejo en esta arquitectura pero de nuevo última vez que lo menciono pero ya tenemos un episodio sobre serverless así que no voy a entrar tanto en detalle aquí lo que me interesa lo que quiero hablar sobre esto Douglas
es que la arquitectura no se basa solamente en la aplicación, el lenguaje que voy a utilizar, en la base de datos que voy a utilizar, sino todo lo que va alrededor. Al definir una arquitectura eso nos dicta, bueno, en el caso de serverless ahora voy a utilizar, no sé, los servicios de Google, Firebase, así que voy a utilizar una base de datos no SQL. Eso cambia mucho, eso cambia todo lo que está dentro del sistema.
las validaciones que tenemos cambia todo lo mismo como monolítico en monolítico pues solo vamos a tener una base de datos donde van a estar todas las tablas obviamente va a haber redundancia, backups, todo esto pero a nivel conceptual es una sola base de datos
En cambio con las otras arquitecturas ya empezamos a ver que hay más cosas que se mueven, es diferente. por eso menciono, mencionaba Douglas al inicio que decidir esto desde el inicio es crucial porque va a dictar todo, a darle la forma a la aplicación que estamos desarrollando.
Pasemos a la siguiente. El otro que tenemos es microservices y aquí es donde ya empezamos a subir la complejidad técnica. Definitivamente es más complejo, pero tiene muchas ventajas. Como mencionaba en cierto momento, el tema de microservices era pues.
era lo hot, era lo nuevo del día y todo el mundo recomendaba microservices tenías una aplicación para inventario microservices tenías un clon de facebook microservices y así todo todo era microservices qué bueno que ya la industria maduro y ya no ya se sabe en qué momento utilizarla y cuando y cuando no verdad
Douglas (39:09)
Es que fue tan loco Juan, perdón, fue tan loco
porque yo recuerdo bien, empezó con servicios ¿no? y tenías el módulo de usuarios, pero ya empezaron con locura de microservicios y era que un servicio agregaba usuarios y el otro servicio leía si te devolvía usuarios y eran diferentes y yo empezaba a ver cosas que sonaban a locura pues, ya eso es hacerlo solo porque puedo.
no necesariamente porque es lo mejor y yo recuerdo esas etapas tanto con serverless, verdad, como con microservicios y estoy muy de acuerdo con lo último que dijiste, la industria se ha adaptado y ha madurado bastante y pues yo creo que está lo que tiene que ver con servicios y microservicios.
Juan (39:40)
Sí.
Douglas (39:54)
Probablemente para una aplicación compleja todavía es algo, bueno, no todavía, suena como que ya es viejo, como hoy en día con la tecnología todo, rapidito, se siente desfasado, ¿no? Pero microservicios y servicios es de las arquitecturas que sostienen, creería yo, la mayoría de aplicaciones complejas.
Juan (40:14)
Sí. Eso que mencionas, de hecho tiene el nombre de CQRS. Common Query Resource... No, recuerdo. Olvido el nombre completo, pero es CQRS. es, pues, de manera muy simplificada es dividir las lecturas de las escrituras. No incluí eso porque definitivamente es mucho más complejo que las otras dos que estamos viendo, microservices y eventos. Pero...
Lo que sucede es que todo tiene un por qué, todo tiene un un dónde un cuándo.
El problema radica cuando queremos utilizar estas soluciones muy complejas para algo que realmente no lo necesita. Y aquí lo que sucede es que nos empieza a limitar, nos empieza a atrasar. Creo que mencionabas en el episodio de Docker Swarm versus Kubernetes, personas que se iban por la solución de Kubernetes para algo que no lo necesitaban y tenían...
años y años con el roadmap de que se va a utilizar y no sucede. Esto pasa lo mismo con las arquitecturas. En el caso de microservicios, es como mencionaba, es como una evolución de los monolíticos y acá los microservicios empiezan a solucionar diferentes aspectos de una arquitectura monolítica.
es ideal para aplicaciones que son muy grandes y que tienen equipos distribuidos. A veces los equipos pueden ser no ser tan grandes, puede ser un equipo de dos o tres personas, pero hay muchos pequeños equipos que están trabajando en diferentes partes del sistema o en diferentes productos de la misma empresa. Bueno, por ejemplo Google es una empresa pero tiene diferentes productos. Hay empresas que hacen lo mismo.
También nos permite tener una escalabilidad más granular. Obviamente por la naturaleza de los microservicios donde una aplicación se encarga solamente de una cosa. Eso nos permite que esa única aplicación podemos escalarla más o menos que las otras partes de nuestro sistema. Me estoy dando cuenta Douglas que no he hablado exactamente de qué es microservicios.
creo que vale la pena mencionarlo brevemente microservicios es seccionar nuestro sistema lo que teníamos antes en monolítico donde una aplicación tenía todas las funcionalidades empezamos a quitar pequeñas partes de nuestro sistema y hacemos aplicaciones aparte estas aplicaciones pueden ser como mencionaba Dula hace un momento la aplicación de usuarios esa aplicación se va a encargar de todo lo que tiene que ver con los usuarios de nuestro sistema total
Luego tenemos otra aplicación, otro servicio que se encarga de los pagos. Esta aplicación tiene alguna referencia de los usuarios pero no le interesa la información total de los usuarios y se encarga solamente de pagos. Aceptar, rechazar, devoluciones, reembolsos, todo eso. Esos son los microservicios de manera simplificada.
Douglas (43:29)
Entiendo, Juan, que y me vas a corregir si me equivoco, entiendo que también parte del microservicio obviamente es cada una de estas aplicaciones ahora tiene su propio code base, no comparten el código, por ende tienen su propio deployment, su propio ciclo de mantenimiento, se ocupan guardar información que obviamente en el caso de usuarios lo necesitan, tienen su propia base de datos también, verdad. Entonces entiendo yo que es otro.
para que realmente servicios o microservicios tienen que cumplir con esos requerimientos porque he visto sistemas donde es la misma base de datos, tienen diferentes bases de código, pero eso es como un monolítico un poco más quebrado.
realmente porque entonces si la base de datos se daña igual se caen todos los diferentes servicios aunque la aunque la código sea separado no verdad entonces no sé si lo estoy viendo o interpretando mal yo pero como yo entiendo tiene que también cumplir con eso no su propio código
su propia base de datos y luego ellos van a interactuar entre ellos por otros medios pues, pero no por medio de una sola base de datos para todos o no por medio de un code base para todos.
Juan (44:43)
Es correcto, son aplicaciones que pueden funcionar por sí solas, la idea de los microservicios es que si todo el sistema se cae pero una aplicación está funcionando, esa funcionalidad del sistema es la que debería seguir corriendo y los usuarios podrían ver eso.
El tema de la base de datos, en esencia si deberían tener su propia base de datos, pero también hay soluciones donde te permiten como pasos intermedios, donde podrías tener una sola base de datos y luego internamente irlo seccionando por los esquemas, por ejemplo en Postgres te permite tener diferentes esquemas.
Cada uno de estos esquemas tiene sus propias tablas y puedes tenerlas así. Luego podrías tener diferentes bases de datos y cada una de ellas tiene diferentes esquemas. Puedes irlo definiendo de diferente manera. Por eso mencionaba. La arquitectura te hace tomar este tipo de decisiones. Vamos a tener múltiples bases de datos o una base de datos con múltiples esquemas.
Todo esto forma parte de la arquitectura, pero es cierto, con los microservicios lo más normal es tener bases de datos independientes. Algo que estoy viendo hoy en día más que antes es que se está empezando a mayormente lo que es SQL Lite. Para estos microservicios donde la información es totalmente volátil,
o no volátil, pero tenemos mecanismos para reconstruir la información de la base de datos, lo que es SQLite es muy muy ventajoso. También se ha visto una mejoría en las diferentes librerías y cosas así. Y eso lo menciono porque nos permite tener múltiples bases de datos casi sin esfuerzo, porque SQLite es como un archivo más dentro de nuestro sistema.
También nos permite tener diferentes lenguajes de programación, es posible que si tenemos cinco microservicios, que cada uno de ellos tenga un lenguaje diferente, sería un sistema políglota. Sin embargo, y yo ya lo he mencionado en otros episodios, no lo recomiendo para nada, si acaso dos y ya tres lenguajes ya lo veo excesivo.
Creo que lo mejor es definir uno y que el equipo pueda aprender y crecer con ese mismo lenguaje. Pero la arquitectura te lo permite. Así de simple. Y bueno, lo que llames...
Douglas (47:17)
Pero
igual, lo tanto, entonces también me permite diferentes tipos de base de datos. Si alguien quiere un subservicio, usar MariaDB o MySQL. Si el otro quiere Postgres. Si el otro quiere Elasticsearch para guardar. O sea, también permite eso. Permite que uno quiera usar Nginx para Frontend, que el otro quiera usar Apache.
Juan (47:39)
es correcto, si la manera de verlo es que cada microservicio es una aplicación y ahí podemos tener total libertad lo que sucede es que muchas veces ya que trabajamos en equipo intentamos tener diferentes estándares intentamos que todo el mundo esté en la misma página
pero pues se puede hacer diferentes cosas en equipos tan grandes como Google si se permiten que un proyecto sale con un lenguaje tan raro porque pues tienen equipos muy grandes
Y bueno, la mayor ventaja o el mayor punto de venta de los microservicios creo que es la resiliencia, ¿no? Lo que mencionábamos de si una parte del sistema se cae, el otro puede funcionar. Por ejemplo, si se cae mi sistema de correos, pues es un golpe grande al sistema. Pero no debería evitar que yo siga aceptando pagos y que los usuarios puedan iniciar recesión y todo lo demás. Así que ese es uno de los grandes ventajas de los microservicios.
El microsepicio es un gran tema, es un tema complejo en sí mismo y es muy muy extenso.
Douglas (48:49)
Hay un tema, tenemos un episodio donde vos nos hablás de microservicios.
Juan (48:54)
Si mal no recuerdo, es así. Voy a tratar de dejar los enlaces en este video para que puedan visitar esos otros capítulos donde hemos tocado estos temas en mayor o menor medida. Así pueden profundizar un poco más en esto.
porque bueno, microservicios pareciera que es como la gran solución que tenemos ahora ya nuestro sistema es resiliente, tenemos libertad de elegir diferentes bases de datos pero aquí es donde vienen las desventajas que para algunos tal vez ya está siendo un poco obvia y es que requieren o tienen una mayor complejidad operativa necesitamos orquestar todas estas pequeñas aplicaciones entre sí
Y aquí es donde viene el equipo de SRE DevOps y nos brinda una mayor ayuda. No es que con las otras arquitecturas no no existe el departamento ni no nos ayude, pero aquí es es fundamental. Es casi de hecho una empresa sin equipo DevOps SRE. Y quiere lanzar microservicios. Yo yo estaría en contra de eso. De hecho.
porque hay muchas cosas que tienen que tomarse en cuenta desde la escalabilidad, desde...
lo que es el gateway, lo que es cómo se van a comunicar entre ellos, todo esto, ¿no? Es más complejo, requiere por su naturaleza, hoy en día al hablar de microservicios estamos hablando ya casi de contenedores, entonces se requiere de una cultura DevOps muy madura en la empresa y aquí me estoy refiriendo a la cultura, no al departamento de DevOps.
¿O te parece Douglas que podría una empresa? Bueno, de poder pueden, todo se puede en la vida, pero...
Douglas (50:46)
Sería suicidio en mi opinión. O sea, pueden intentarlo.
Juan (50:48)
Sí.
Douglas (50:50)
y terminaría muy mal, bien mal. Y aquí es de las cosas donde, tal vez solo porque se puede, porque alguien puede intentar cliquear, hacer click ops y levantar un clóset de Kubernetes y empezar a correr o no, pero cuando los recursos se desborden y tu aplicación esté matando los nodos porque no hay límites, cuando cueste hacer deployments o cuando el deployment tarde.
Juan (50:54)
Sí.
Douglas (51:17)
20, 30 minutos cuando es algo que pudiera tomar dos minutos, ahí es donde luego ya tienes la soga al cuello y ya querer corregir cosas que están en producción es complicado. Pero es esto es parte de lo mismo, que esto ha sido históricamente, yo siempre digo, lo que ocurre hoy con la inteligencia artificial ha ocurrido siempre en los diferentes aspectos.
Y es el hecho de que mucha gente por querer entrar a servicios o microservicios comenzaron con lo que tienen y arrancaban, verdad, no, sí, porque todo el mundo está haciendo microservicios. Fue lo mismo de por eso surgió el nombre de DevOps Engineer, porque todo el mundo tiene, entonces contratarle y cómo se llama, es DevOps Engineer, verdad, y lo mismo hoy con la IA,
Juan (51:45)
Ajá.
Douglas (52:02)
la gente dice, quiero que mi sitio web o mi aplicación tenga IA. ⁓
No sé en qué, no sé si me va a beneficiar, pero quiero que tenga Inteligencia Artificial. Entonces eso está pasando hoy en día y pasó con los servicios y microservicios. Y en efecto hubiera un equipo que tal vez o tenía o no tenía en un departamento de SRI o de sistemas maduro con conocimiento de cloud native, verdad, porque ya con lo que tiene que ver con servicios y microservicios yo pensaría que ya tenés que tener madurez.
en los conceptos de cloud native y ahí hubieron muchos problemas, y entonces sí, yo no recomendaría que entregan microservicios si no tienen un arquitecto de software que entienda lo que está haciendo, si no tienen un equipo mínimo, una persona, un sysadmin, un sre, un devops que también sepa lo que está haciendo.
Juan (53:00)
sí, sí, definitivamente. Otra desventaja bien grande relacionada al hecho de que es complejo y hay muchas piezas que se mueven, muchas partes desmovibles, es el hecho de que es bien difícil de buggear y testear.
Múltiples veces nos vamos a encontrar en una arquitectura de microservicios que sucede un error y tenemos que ir buscando ese error de entre un servicio a otro porque los servicios se comunican entre sí, ¿no? Con diferentes medios. Así que testear y debuggear se vuelve bien complejo. Con el tiempo uno aprende a cómo hacerlo. El mismo departamento de DevOps Accessories se encarga de darnos las herramientas a los developers para poder tener
el contexto de cada uno de los los request tener el contexto de los contenedores etcétera pero pues eso no quita que sí es un poco más complejo y y bueno por lo mismo que los son diferentes aplicaciones que están llamando entre sí hay una mayor latencia en la red porque pasamos de que todo sucede en una aplicación a que múltiples aplicaciones se están llamando una con otras una aplicación se llama con otra otra con otra y así
Así que eso incurre en que la red tiene que soportar este tráfico, ya sea un tráfico HTTP o gRPC o cualquiera de estas soluciones. ⁓ Hay que prestarle atención definitivamente. Definitivamente creo que los microservicios es una arquitectura donde el trabajo en equipo es fundamental y me refiero a DevOps y SRE y Developers.
porque de otra forma es bien difícil, de otra forma no se logra escalar o llegar a la finalidad de esta arquitectura. Si no, realmente lo que en vez de hacernos la vida más fácil va a complicar todo y va a ser un fracaso la implementación de esto. Bien, ya estamos llegando a la recta final del episodio Douglas. Vamos a hablar de la última arquitectura que quería mencionar.
y es la arquitectura basada en eventos. La arquitectura basada en eventos... ⁓
Douglas (55:19)
ahí perdón antes de que entre a ella es
con la que menos experiencia tengo con serverless tengo poca experiencia
Y la experiencia que tengo es porque los equipos de desarrollo que creyeron que todo lo podían, ahora tienen problemas serios y necesitan alguien con conocimiento de sistemas para que ayude, verdad. Y con esta arquitectura basada en eventos, ya trabajarla de manera directa no, sin embargo, pues he sido parte de planeaciones y cosas que las han implementado. Entonces te lo digo porque en toda esta conversación he estado aprendiendo.
Juan (55:40)
No,
Douglas (56:00)
bastante de vos y quiero que consideres que a partir de este punto en adelante me veas también como un alumno más a mí para yo tengo ideas y probablemente tenga alguna opinión que aportar pero mirame como un alumno más para aprender.
Juan (56:15)
No, excelente, excelente. bueno, un alumno que ya viene con más estudios previos, La arquitectura de eventos es como... Yo lo veo como la digievolución de los microservicios, porque se siguen utilizando microservicios. De hecho, es esencial que los microservicios existan para que puedan comunicarse a través de eventos. Entonces, ¿qué es? ¿Cuál es la gran diferencia?
con los microservicios digamos base vamos a decirlo así no existe el término pero los microservicios a nivel base se comunican entre sí normalmente utilizando peticiones HTTP podrías hacerlo también con peticiones mediante gRPC, gRPC es muy bueno porque es más ligero utilizas menos bytes es más rápido
tiene sus dificultades pero bueno, es otro tema. Sin embargo, con la arquitectura basada en eventos lo que se hace es que ahora en vez de... Vamos a hacer un caso hipotético. Un usuario realiza una compra. Esta compra llega al microservicio de pagos. A su vez, este microservicio de pagos necesita llamar la...
o notificar, enviar un correo o enviar algo, digamos que tenemos un servicio de correos que recibe peticiones así que el sistema de pagos hace la llamada HTTP al servicio de correos el servicio de correos realiza su transacción y le da una respuesta al servicio de pagos el servicio de pagos continúa
Con la arquitectura basada en eventos, lo que va a hacer el servicio de pagos es notificar, hubo un evento. Vamos a decir, purchase successful. Se completó la compra. Ese evento se envía al sistema. Ya vamos a hablar que medios utilizamos.
luego el servicio de correos va a recibir este evento y va a procesar este evento y va a enviar el correo. Ojo, aquí lo que sucede es que ambas aplicaciones, microservicios
no tienen idea el uno del otro. uno envía un evento al aire, el otro recibe un evento, pero ya no tienen que esperar que el uno termine o que el otro responda. Entonces, esa es una gran ventaja porque empieza a aliviar, número uno, el tráfico y número dos, la latencia de nuestro sistema. Empieza a ser más rápido porque no, no tenemos que esperar a cosas que, pues, no son críticas.
En el momento de yo realizar una compra, claro que voy a alegrarme de recibir un correo, de notificándome que todo está bien, pero no es crucial, porque lo que me interesa es saber que mi sistema en mi aplicación diga que la compra fue exitosa. Ya después voy a recibir el correo.
Douglas (59:20)
Es ahí entonces,
sí, es ahí entonces, Juan, y bueno, esto yo lo sabía, ¿no? Pero es ahí por donde inicialmente recuerdo yo que según, cuando ya estaban estas arquitecturas, que hasta que recibía el correo era que realmente la compra se había confirmado. Y luego cuando yo aprendí esto sobre esa arquitectura basada en eventos, me causó una gracia saber de que una vez que tengo el mensaje de que la compra fue hecha con éxito en la pantalla, de que ahí estaba confirmada realmente.
porque yo pasé un buen tiempo creyendo que hasta que me caía el correo era que estaba confirmada. Entonces me recuerdo sentirme como un niño cuando le dijeron que Santa Claus no existe.
Juan (1:00:04)
y bueno los que nos están escuchando creían eso ya. Es curioso porque con esta arquitectura empezas a identificar que partes son cruciales para un proceso en específico. Podría darte otro ejemplo, Cuando yo solicito la información de... cuando yo actualizo la información de un usuario, por ejemplo.
este usuario yo necesito que se actualice y está bien voy al servicio de usuarios pero al momento que se actualizó nuevamente lanza un evento un evento no es más que la información de una acción que sucedió que sucedió exitosamente entonces yo lanzo la el evento de que el usuario fue actualizado
y ahora otro sistema puede recibir esos cambios y hacer algo, tal vez mostrar en el correo, ya te muestra tu nombre actualizado pero de nuevo si no se actualizó en el momento indicado no pasa nada, empezás a notar que no tengo que notificar a todas las partes del sistema en ese preciso momento a mi me interesa que el sistema de usuarios se encargue de actualizar su información y luego el resto
de microservicios van a actualizarse. Aquí entonces empezamos a tener esta arquitectura que empieza a desacoplar los procesos mismos, ya no sólo las aplicaciones sino que los procesos. Esto lo que nos ayuda es que nos va a servir con estas aplicaciones, estos servicios, perdón, sistemas que requieren una reactividad extrema, necesitan que sean muy rápidas.
ya no tengo que esperar a que se envíe el correo para que me salga la mensaje en la pantalla, no, sale la pantalla exitosa y luego voy a recibir el correo también nos brinda una mayor extensibilidad porque algo muy interesante es que cuando envias un correo no, perdón, cuando envias un evento este evento puede ser recibido por múltiples servicios la acción ocurre en un servicio
y luego múltiples servicios pueden reaccionar a este cambio o a este evento. Eso nos da muchas ventajas porque ahora en vez de hacer, imagínate que tuvieses que notificar mediante HTTP request a todos los servicios, tendrías que hacer múltiples llamados, mayor tiempo de espera, mayor latencia en la red. En cambio ahora envías un evento y ya. Todos los demás servicios se van a actualizar o van a recibir el evento.
en algún momento porque eso es otro tema que ya lo vamos a mencionar.
Douglas (1:02:55)
Juan, pero entonces, verdad, así lo he entendido yo antes en lo que yo tal vez he investigado y participado y ahorita que vos lo estás aclarando, las cosas hacen todavía más clic. Esta arquitectura en base a eventos realmente viene a corregir estos gaps que los microservicios comenzaban a crear porque microservicios corrigieron un montón de problemas al hacer el decouple de las aplicaciones.
pero luego introdujeron problemas de espera, lo que estás diciendo, no. Si iba así a la compra, tenía que esperar, mandar al sistema de correo que hacía la compra.
Mandar al de correos y que el de correos quedara esperando el HTTP request a que responda y luego que esté acá. Luego me imagino que mandara a la parte de inventario, a la parte de ventas, mandarlo y esperar a que vuelva, ¿verdad? Y ahí lo enviaba, ahí lo recibía. Y entonces a veces la transacción aparecía como que había fallado.
la transacción aparecía como que había fallado porque alguno de esos servicios no hizo bien y a mi me parecía que era un error que no tenía la compra hecha, pero sin embargo ahora con el sistema de eventos se corrigen ese tipo de cosas o sea realmente es la evolución a los servicios buscando corregir esos espacios que quedaban en blanco.
Juan (1:04:24)
si definitivamente viene a simplificar el trabajo con los microservicios y sí a rellenar esas pequeñas partes que empezaban a complicarse mucho con lo que ya de por sí es complicado que son los microservicios
Y digo que simplifica el trabajo porque ahora, como mencionabas, de estar haciendo diferentes llamados, ahora ya no tengo que hacer ninguno. Y ahora sí, mi aplicación ya es mucho más independiente del resto. Ya ni siquiera tengo que saber sobre las demás. Ojo, no quiere decir que nunca vamos a hacer ningún llamado a HTTP. Claro que sí, sí pasa. Sí seguimos utilizándolo.
Pero ya no es una pieza fundamental para muchos procesos. Muchos procesos lo que vamos a hacer es levantar un evento y listo. Es como para dar un último ejemplo que se me viene a la mente, que de hecho es algo que hice hace un par de días. Imagina que estás haciendo una actualización en un registro de algo. De nuevo, el usuario por ejemplo. Y lo estás haciendo en una base de datos.
pero ese cambio tiene que sincronizarse con otra base de datos que también es del usuario, en este caso era una base de datos legacy por múltiples motivos había que sincronizarlos. Bien, en un sistema tradicional
en el mismo código tendría que ir yo a la primera base de datos, la actual y luego cuando eso funcionó continuar con la otra base de datos. En cambio con los eventos yo puedo terminar el proceso con mi base de datos porque esa es la base de datos de este microservicio. Termino el proceso, envío el evento que fue exitoso de que el usuario se actualizó
Y ahora en otra parte, en otra aplicación que si tiene que ver con esa otra base de datos, Legacy, recibe el evento y lo sincroniza. Entonces ya de esa manera pues estamos desacoplando procesos, sistemas, microservicios. Es muy muy bueno para la mantenibilidad del sistema, pero claro es complejo.
Y otra ventaja es que todo este tema nos da una mayor resiliencia a una sobrecarga porque pues ya no estamos saturando la red con múltiples llamados, lo que ya estábamos mencionando anteriormente. Lo que hacemos es que mandamos los mensajes a una cola. Entonces, ¿cómo funcionan estos eventos? Normalmente se maneja un llamado broker.
No sé cuál sería la traducción más apropiada en español, pero bueno, vamos a llamar broker porque así es como se le conoce normalmente. Un message broker. ⁓
Douglas (1:07:16)
Message broker, ¿no? Que sería como corredor
de colas, si hacés la traducción de como alguien broker en otras áreas es un corredor de seguros, podría ser. Que administra las colas, De mensajes, sí, de mensajes.
Juan (1:07:28)
corredor de sí de colas de mensajes tal vez
Sí, el mensaje es mejor. bueno, los dos más comunes, los que van a escuchar todo el mundo es Ravid MQ y Kafka. Cada uno tiene su nivel de complejidad, cada uno tiene sus reglas de cómo.
Douglas (1:07:36)
Sí.
Juan (1:07:51)
enviar los mensajes, cómo enrutarlos porque también pues tampoco es que se al inicio dije que se enviaban los mensajes al aire pero no es así cada mensaje tiene como a qué grupo va a ser enviado o de dónde proviene mejor dicho entonces tiene diferentes reglas cada uno de estos servicios tanto Kafka como RabbitMQ luego tenemos que también preocuparnos por las versiones de los eventos porque los eventos al inicio enviábamos una información
pero qué pasa si ahora yo necesito enviar más? Entonces ahora el mensaje cambia, qué pasa con los mensajes viejos que no tenían eso? tenemos que tener en cuenta este tipo de cosas. De nuevo es más complejo pero nos da una mayor flexibilidad dentro de todo el ecosistema de nuestro sistema.
Por lo mismo que es más complejo, tiene muchas dificultades y desventajas definitivamente. La primera es la complejidad mental. El hecho de trabajar con esto ya no solo es complejo al momento de diseñarlo, sino al momento de trabajar el día a día con esto, yo ahora tengo que saber que cuando envío un evento, esto se va a comunicar con múltiples servicios.
Si bien el microservicio no sabe sobre los demás, yo como developer si tengo que saber sobre ellos. es una carga mental porque no está a la vista directamente. Es algo que tenemos que saber. Y bueno, aquí donde entra en herramientas externas que nos permiten hacer diagramas para tener una idea de todo el mapa que existe de nuestra aplicación. Pero bueno, eso es otro tema.
También definitivamente es más complejo depurar las cosas que suceden y rastrear errores. Me ha pasado muchas veces que una aplicación que está escuchando a esto se le llaman consumidores, está escuchando eventos, empieza a fallar, empieza a fallar y no logra procesar un evento. Entonces no está claro o no está claro la simple vista, en qué momento se envió, quién envió esto, qué versión del sistema tenía.
cuando
se envió y eso hace que la depuración sea un poco compleja. formas de hacerlo, hay formas para suplirlas pero si mi experiencia les vale es, mi consejo les vale es que
todos estos pequeños problemitas se van corrigiendo con el tiempo, con la experiencia en un cierto momento nos vamos a dar cuenta que necesitamos enviar un ID de algo dentro del evento tal vez no estaba antes lo agregamos, luego agregamos otra cosa y vamos agregándole más metadata a los eventos y es más, es también una gran desventaja bueno esta no es una gran desventaja pero
Creo que de la situación, depende del sistema y es que esto da pie a la consistencia eventual, lo que mencionábamos hace un rato. ¿Qué pasa si yo actualizo un usuario? Yo actualizo tal vez los pagos. Perdón, hice un pago. Dentro de mi aplicación, tengo muchas aplicaciones que tienen eso. Yo puedo ir al registro de transacciones.
y a veces puede pasar que cuando voy al registro de transacciones yo no veo ese pago que acabo de hacer. Sin embargo el pago fue exitoso. Eso es porque son sistemas o aplicaciones o microservicios diferentes y probablemente el servicio que se encarga de mostrarte el registro de transacciones aún no ha procesado el evento que corresponde. ¿Esa es una desventaja? Bueno, va a depender de cada aplicación pero sí hay que tomarlo en cuenta.
si es algo que tenemos que saber al momento de decidir utilizar una arquitectura como esta porque cuando ya lo tenemos en cuenta, nuevo, la arquitectura nos dicta incluso el UI. El UI ahora va a tener que mostrar un mensaje o no mostrar nada o hacer retries o hacer... vamos a tener que hacer algo para compensar eso que puede llegar a pasar.
Así que definitivamente es una arquitectura que en lo personal me gusta mucho más cuando empezamos a agregarle más cosas, más cosas que bueno ni siquiera las voy a mencionar porque se va a extender mucho más el episodio y va a ser más complejo de explicar pero
realmente es bien complejo y yo solo lo recomendaría para estos sistemas que son muy grandes, que tienen muchos usuarios, que tienen muchas funcionalidades en el sistema como tal porque esto nos va a permitir empezar a desacoplar módulos, servicios, funcionalidades y procesos.
pero bueno, muchos puntos a favor y en contra definitivamente tener Kafka y RabbitMQ corriendo es crucial y aquí es donde, si con los microservicios si nunca he visto que utilicen los dos al mismo tiempo en teoría podrías pero lo veo necesario o no se, si alguien lo ha visto y lo ve útil pues que nos lo diga
Douglas (1:13:06)
Uno o el otro, ¿va? Uno o el otro normalmente.
Juan (1:13:24)
Si en los microservicios era crucial trabajar mano a codo con el departamento de SRE, de VOPs, aquí creo que es más que indispensable.
porque aquí es donde se vuelve más crítico el hecho de tener diferentes métricas para alarmas y notificaciones. También tenemos un episodio sobre eso. Dula nos habló mucho sobre alertar y todo esto. Porque al ser un sistema altamente desacoplado, realmente tenemos que tener los ojos en todos lados y es bien complejo. Así que sí necesitamos un departamento que tenga todas estas herramientas.
y
pueda configurar, setear los ambientes, setear los servidores y todas las cosas que conllevan que es el día día de Douglas. Estoy seguro Douglas que a pesar que como dijiste al inicio no has trabajado directamente con esta arquitectura, bueno en su momento sí trabajamos con una primera implementación que creo que nos quedamos a medio camino utilizando Kafka.
Pero aún así estoy seguro que en tu mente me imagino que pasaban muchas ideas de cómo hacer algunas cosas, cómo monitorear, cómo desplegar sistemas, qué sistemas o qué servicios requieren tener mayor prioridad, como mencioné, Rabbit en Qo Kafka, son piedra angular en esta arquitectura.
No sé qué te parece esta arquitectura, Douglas, ¿te parece que es sobrecomplicar las cosas? ¿Cómo lo ves?
Douglas (1:15:08)
No, no,
mira, realmente no. Y cada, cada...
Cada cosa, cada necesidad tiene su solución. Sobrecomplicar es un sistemita interno pequeño, querer hacerlo event driven, eso es sobrecomplicado. Pero un sistema grande, entonces normalmente implementemos la complejidad porque nos vamos a beneficiar de ello. Normalmente si nos analizamos los contras de algo surgen más cuando la aplicación no está aplicada donde debe de ser.
Si es más costos, porque desde el lado de infraestructura, el event driven, architecture, que se agrega es el que administra los mensajes, ya sea Kafka o RabbitMQ o que agarre su managed service del cloud. En infraestructura esa es como la pieza extra, si lo querés decir así. Existen obviamente...
Juan (1:15:45)
Ok.
a los que ya teníamos en microservicios.
Douglas (1:16:12)
Ajá,
a lo que ya tenés microservicios le agregás el Kafka o Ravenium Q o cualquier sistema de cola que vas a utilizar, ¿verdad? Pero fuera de ello, como te estás beneficiando de ello, entonces es más costo, es más mantenimiento, pero te estás beneficiando de ello, lo compensa, es más, lo necesitas porque te va a salir peor que tu sistema constantemente se trabe o de problemas o le esté dando mala experiencia a los clientes, perdás clientes por...
como ellas entonces realmente si es cierto que es más complicado si es cierto que es más costoso pero para tu equipo y tu aplicación no es un contra porque le estás sacando provecho entonces
sí existen contras reales, pero la mayoría de ellos sobresalen cuando no está aplicada la solución acorde. Entonces yo no creo que sea sobrecomplicar cosas, sin embargo, si la aplicación lo amerita, ¿verdad? Y es, mí me, a mí me, desde nuevo, como te digo, al final yo en lo personal no he llegado todavía al punto.
de tener que configurar para, ya sea RabbitMQ o Kafka, para un sistema de producción y agregar el estar monitoreando un message broker a mi sistema de monitoreo y de alerta, esas cosas, a esa parte no he llegado a ponerlo en práctica. Sin embargo, espero que en algún momento se pueda, hagamos alguna aplicación o algo que lo necesite para que yo pueda hacerlo.
Juan (1:17:43)
Sí,
sí, Ahí me gustaría dar solo dos comentarios. El primero, con lo que mencionabas, más que todo aclarando la audiencia. Estoy seguro que te conozco, sé que no es esa la intención. por si alguien escucha el hecho de cuando decís que no has llegado ahí.
Eso no significa que todas las empresas tienen que implementar esto. De hecho, el hecho de que no lo hayas hecho en tu trayectoria es muestra de que con microservicios o con un simple monolítico podés tener una aplicación muy grande. Douglas ya nos ha mencionado que trabaja para empresas que son muy grandes. La empresa en sí son grandes y no han necesitado utilizar Event-Revent-Design. para casos muy especiales.
casos muy concretos. Otra cosa que me gustaría mencionar, no sé si lo dije al inicio, algo donde creo que es donde empezamos a notar que sí nos va a beneficiar esto.
es cuando tenemos que estar agregando constantemente pequeñas nuevas funcionalidades a nuestro sistema porque se vuelve bien fácil agregar un nuevo consumidor que solamente recibe los eventos y podemos procesar esta información de otra manera. Lo que quiero decir es que un evento lo puede recibir múltiples aplicaciones y cada aplicación puede hacer algo diferente con ese mismo evento.
Así que a veces me ha pasado que necesitamos agregar algo nuevo, un reporte o un dashboard diferente en la aplicación. Entonces solamente tengo que empezar a reutilizar diferentes eventos y con eso yo puedo como armar la nueva información que quiero guardar. Y esa información se guarda en una tabla y pues todo eso.
si no es así, es una aplicación que no tiene que extenderse tanto, creo que tal vez no es el momento todavía o no lo necesita, de plano no lo va a necesitar. Bien, hay más arquitecturas como dije, pero bueno, por ahora creo que...
el episodio se ha extendido bastante con todas las diferentes explicaciones y eso que solo las mencionamos no nos adentramos a profundidad contra cada una de ellas de hecho ya lo mencioné esta vez si es la última tenemos un episodio sobre serverless significa que el tema de serverless pudimos hablar un episodio entero solamente sobre serverless y eso puede ser con cualquiera una de estas arquitecturas
Douglas (1:20:19)
Hay uno de microservicios también,
acordate.
Juan (1:20:21)
hay, tenés razón, hay uno de microservicios que lo hicimos hace tiempo, así que de nuevo, este es...
La idea era como mencionar, quería mencionar las diferentes arquitecturas que tenemos, cuáles son las ventajas que saltan a la vista, las desventajas más obvias y pues mencionar un poco en qué momentos se utilizan. Ya mencionábamos, monolítica es intuitiva, es como para iniciar o para aplicaciones no tan complejas y ya luego nos vamos al extremo opuesto que es event, aplicaciones basadas en eventos donde ya son sistemas bien bien complejos pero pues nos da muchas otras libertades.
Así que, bueno, creo que va a ser muy bien para cerrar el episodio de hoy. me gustaría que, no sé si tienes algunas palabras respecto a, ¿qué le recomendarías a las personas que quieren empezar a?
adentrarse en todo este tema de cómo arquitectar una aplicación realmente es algo que no solemos hacer desde el inicio es normal cuando venimos empezando no nos dan esa responsabilidad pero estoy seguro que a veces nos toca hacer aplicaciones aparte ya sea para un trabajo extra o para algo una aplicación que queremos hacer nosotros y tenemos que tomar ese tipo de decisiones ¿qué les podría recomendar?
Douglas (1:21:42)
Mira,
mi recomendación sería simple y es, traten de implementar la arquitectura correcta acorde a su aplicación, servicio, sistema y su proyección, su roadmap.
agreguen servicios, microservicios o basado en eventos si realmente no lo necesitan. No se vayan por una aplicación compleja en serverless, realmente no es para esos serverless. Si tienen una aplicación, un sistema entero complejo, no se vayan a serverless. Y busquen, busquen sacarle provecho.
a las palabras de Juan, ya con la experiencia de Juan, con lo que nos ha compartido, si no prestaron atención y alguien viene y se da el golpe, bueno ya la responsabilidad está en ello, verdad. Entonces, como consejo es simple, es ese y como cierre va bien agradecerte a vos Juan por este master class que nos has dado. Yo a nivel personal obviamente estas cosas de desarrollo empiezan a cobrar sentido para mí, verdad, y yo aprendí bastante y estoy seguro que las personas que pusieron atención,
llegado hasta este momento también recibieron ese valor más allá de que lo aprendieron y lo entendieron de nuevo intenten ponerlo en práctica
Juan (1:23:01)
Muchas gracias. Sí, definitivamente la idea es...
compartirles un poco de lo que hemos aprendido con el tiempo. Si algún tema no quedó muy claro, bueno, el vídeo va a quedar ahí en YouTube, lo pueden revisitar en cualquier momento o nos pueden escribir algo en los comentarios y con gusto vamos a tratar de despejar dudas porque definitivamente son temas que a veces no quedan tan claro a la primera, no pasa nada, es normal y vamos a tratar de darles una ayudadita cuando se pueda.
Sin más, la recomendación que les puedo hacer es... Intenten, ¿no? Intenten...
diseñar una aplicación, sistema y traten de descifrar cuál podría ser la arquitectura más ideal para ese caso en específico. En lo personal he tratado de hacer diferentes emprendimientos y solamente en uno decidí o llegué a la conclusión que era necesario tener microservicios y eventos solo en uno y ese es el que más rápido descarté porque era una aplicación muy compleja de todas las
tanto cosas externas como el desarrollo. que, creo que vale la pena intentarlo en cierto momento arquitectar algo como eso.
Bien, sin más que agregar dublas, ha sido un placer para mí estar en esta plática para este episodio. Muchas gracias por compartir esto conmigo y poder compartir con la audiencia. Espero que nos podamos encontrar en el próximo episodio. Y para los que llegaron hasta el final, por favor déjenlo en los comentarios para nosotros poder darles las gracias. Muchas gracias a todos. Nos vemos a la próxima.