Excelente video, dejo una cita de Robert C. Martin (Tio Bob): "Los microservicios no son una arquitectura, son una estrategia de despliegue. El desacoplamiento y la división podran (y deberían) lograrse independientemente de si se impone el límite de servicio."
@@ManuelZapata Se puede. Antes de los micro servicios , hace ya años, todo lo que montaba era modular sin dependencias. El problema es que es difícil mantener esa disciplina en equipos grandes. Incluso con los micro servicios a veces se escapan cosas y hay miembros del equipo que se saltan esa separación. Yo he conseguido hacer una arquitectura modular en clipper y Delphi ( ya di pistas de mi edad 😂 )
quien tendria la razon? tu tio bob o martin fowler? segun Martin Fowler dijo lo siguiente: La Arquitectura de Microservicios es una "forma particular de diseñar aplicaciones de software como conjuntos de servicios desplegables de forma independiente". mas bien no seria un estilo arquitectonico?
Los microservicios no aparecieron como consecuencia de una mala arquitectura monolítica, ni del mal uso de patrones de diseño, los microservicios son la consecuencia de la necesidad de balancear las diferentes cargas de la aplicación y de garantizar hasta cierto punto la resiliencia del sistema. La parte positiva que muchos desarrolladores ven es que pueden trabajar orientados a contratos donde cada microservicio sería una caja negra para el que no lo mantenga. Uno de los principales problemas vienen desde el punto transaccional, cuando más de un microservicio toma parte en la misma transacción, garantizar la consistencia y atomicidad se vuelve complicado. Otro gran problema viene con la mantenibilidad del código, al ser un desarrollo orientado a un contrato no tenemos la ventaja del tipado fuerte del compilador, cualquier cambio inocente en un nombre de una variable a consumir puede llevar a que el sistema no funcione, o peor, que funcione de forma errónea. Otros elementos a tener en cuenta son: hay que cambiar el proceso de cómo se hacen las liberaciones, como se hace el monitoreo y traceo de errores, como preparar datos válidos para las diferentes tipos de pruebas. Para decidirse por la arquitectura de microservicios debemos tener razones sólidas porque implica una inversión en tiempo, hardware y conocimiento.
Muchas gracias por esta respuesta tan completa. Solo me queda una duda, ¿A que te refieres con la consideración del "cómo se hacen las liberaciones"? No se si te refieres a bajar instancias de los microservicios, o qué tipo de recurso liberar. Pese a eso, tu comentario me sirve bastante :)
Me parece una estrategia muy inteligente que la aplicación vaya marcando la evolución de la arquitectura. En los últimos años he hecho varias aplicaciones nuevas y no he necesitado los microservicios, no es resistencia al cambio simplemente las modas no me apantallan. Saludos!
CodeRoll, los microservicios no son una moda, es una forma de desarrollo para la evolucion del software desacoplada y facil de desplegar , yo llevo varios años desarrollandolos y dan una gran cantidad de facilidad a la hora del desarrollo y sobre todo del despliegue, permite esa independencia de modulos que de otra manera es mas complicada y encima si agregamos que los modulos de aplicaciones pueden tener diferentes evoluciones ...
Vale, igual me la bañe con eso de las modas. Aprovechando, tu que tienes experiencia en microservicios ¿Cuándo no los usarías? ¿esto de los monolitos modulares te hacen sentido o te vas directo al microservicio? Parto de la idea que no hay arquitecturas ni buenas ni malas, todo depende del contexto y en mi contexto no los he necesitado al parecer desarrollo monolitos muy buenos jejeje. Saludos!
@@Coderoll Como bien tu dices no hay ni buenas ni malas, y como has mencionado las arquitecturas hay que usarlas en su contexto correcto, no siempre he desarrollado ni desarrollo microservicios hay veces que es mas practico una arqutiectura monolita y no hay ningun problema, yo las monolitas las usaria en pequeñas aplicaciones y que no tengan mucha evolucion en el tiempo. Pero si realmenten es una aplicacion que tiene una evolucion continua es preferible usar los micros, por ejemplo una api de gestion, usaria un proyecto monolito para las maestras esas poco tiene de evolucion, pero en el negocio si usaria microservicios Un saludo
muy bueno.. a la larga se reinventan las cosas con nombres y detalles diferentes.. Esto de separar en capas y proyectos ya se hacía en 2003 cuando vino .net . Lo hacíamos con otras arquitecturas más acopladas como remoting web services etc no existía mucho sobre APIs REST y menos Microservicios pero a grosos modos es una arquitectura super usada desde hace 20 años
Totalmente de acuerdo. El problema de hoy día es que hay personas en puestos de decisión que realmente no entienden la programación. Como tú bien dices, se mueven por modas. Hace falta una revolución en el sector de la programación, donde los programadores no se limiten a tirar líneas de código si no que vean una aplicación como algo vivo, que crecerá y que no sabemos por donde lo hará. Esto debe hacer al programador tener un poquito más de formación sobre las tecnologías (si bien es cierto que no hay mejor ni peor, sino que dependerá de la finalidad del programa) También es importante que nuestro código esté modularizado, de modo que la lógica de negocio no sea un galimatías para un posible programador que ocupe nuestro puesto a futuro. En mi caso (y no digo que sea la mejor forma), uso .NET con EF y MVC 4 y conectada al dominio. Pero la aplicación es una especie de megaprograma modularizado, con secciones. Es decir, tengo una base monolítica que solo te lleva al login. Una vez te logueas ya tienes un menú lateral con todas las secciones o programas con su código standalone (Modelo de datos, con su controlador con sus vistas) y todo independiente de todas las demás secciones además como está conectada al dominio puedes gestionar fácilmente los permisos a las secciones mediante asignación de grupos en el controlador de dominio. Obviamente esto te hará usar métodos parecidos por no decir idénticos por lo que tiene un poco más de trabajo, pero es ROBUSTA, escalable y fácilmente entendible para otro programador. Éste programa nació como una idea en el 2017 y hoy día es una parte muy importante de la empresa. Sigue así Manuel Zapata, tienes la visión clara de un buen programador!
No cabe duda que la especialización cada vez es mayor y que soluciones sencillas y robustas de antes terminan siendo complejas por el tema de la especialización y de querer adoptar cada vez mas herramientas y productos. Esto que comentas lo haciamos desde hace más de 10 años con los Servidores de Aplicaciones, Maven (modules de Maven), Oracle, J2EE y Adobe Flex o jQuery
Muchas gracias amigo, saludos desde venezuela... Actualmente estoy incursionando en un framework de Typescript llamado NestJS y su diseno de arquitectura es completamente modular. Esto complementa con mi proceso de aprendizaje
Buen video manuel, para complementar, cuando se utiliza una base de datos por monolitos modular, ya estas aplicando un patron de los microservicios y por lo que veo lo que se esta aplicando aqui es el desacople por capacidades de negocio. un microservicio no necesariamiente debe ser 'micro', el tamaño del MS va ligado con la parte del negocio que quiere cubrir.
Muy buen tema, me recordó que Zend Framework 1.0 + ya se trabajaba la arquitectura modular y para Zend Framework (2 y 3) ahora llamado Laminas su punto fuerte poder separar en modulos la aplicación. Y como bien mencionas al interior del modulo se aplica la arquitectura que más convienga, en Laravel también se podría usar implementanto la separación por package que sirven para extender las funciones.
Concuerdo contigo, el problema la mayor parte de las veces es el diseño de las aplicaciones no tanto la arquitectura, inclusive si tienes un monolito bien hecho si alguna ves por escalabilidad requieres mudar tu aplicación a microservicios es muy fácil separarlos, cada ves trato de pensar mas en como resolver mis problemas en code modules que aunque parezca algo complejo al final favorece muchisimo es como si programaras paquetes y los subieras a packagist en cualquier momento los descargas con composer y los implementas en el proyecto que necesites con solo modificar algunos ficheros de configuración y lanzar migraciones. buen video gracias Manuel!
Excelente explicación, quiero contarte que sin saber estaba implementa esta arquitectura, pero solo lo hice por organización ahora con este video voy a independizar un poco más, sería bueno un ejemplo de comunicación de esta arquitectura 👍🏼
Me parece interesante y nosotros estamos pasando por un proceso conceptual de Modularización de un monolito, para luego ir a Microservicios. Creo que es el mejor path de migración para romper el monolito. Saludos
Muy interesante Manuel, se puede decir entonces que de esta forma, si se relaliza un simple cambio, hay que deployar todo el monolito modular no? como si de un monolito normal se tratara.
Excelente video, felicidades!!... desde mi vida laboral he venido comentando que no se debe escoger la arquitectura de una solución basado al modismo, eso es un gran error y con charlas o actividades con proveedores, se vuelve un punto de controversia. Esta es una buena opción que se debe analizar, otra opción válida. Agradecería mucho que nos compartas el código para conocer de fondo la propuesta. Gracias y saludos!!
De eso se trata. De conocer opciones y saber cuándo es conveniente usar una o otra. Ya con eso vamos ganando. En la descripción del vídeo está el enlace al repositorio.
Así es. No necesariamente las tendencias son cosas realmente nuevas. De hecho, hay personas que dicen los microservicios tampoco eran nada nuevo. Eran sencillamente una variante de SOA con nuevo nombre.
Como quedan las tablas que son comunes a todo los módulos tales como tabla de países, tablas de bitácoras de acceso al sistema quien posee el control de estas tablas en un sistema monolitico
Buena pregunta, aún no entiendo mucho, pero de acuerdo con el vídeo, esta info debería pertenecer a un microservicio o monolito y consultarse exclusivamente por una API.
Que buen video manuel, yo no sabia que microservicios eran mas de moda, muchas gracias por compartir el repositorio de Kamil. Muy informativo este video.
Siguiendo la línea de “Software is meant to be soft” de Martin Fowler, la implementación del software debería poder variar de estrategia. Si es costoso, entonces podríamos haber diseñado mal la arquitectura. Muy buen video! Gracias!
Que chévere hacia esto sin darme cuenta en Laravel , cada módulo expone un service provider e inyecta interfaces en lugar de objetos concretos y los iba creando por separando e instalando vía composer como una dependencia de Laravel
Hola, es relativo, me llama la atención una frase "...donde todo esta junto y todo es más fácil de desarrollar, siendo un monolito..." (Min.3:22) , para mi eso no es cierto, en nuestro caso usando Java Spring Cloud Microservices, se ha logrado una experiencia mejor al desarrollo monolítico, mejor control del tiempo, presupuesto y recursos. Es relativo ya que si hablamos de un sistema MVC construído por solo un equipo, compuesto por seis desarrolladores, aún cuando tengas una herramienta de integración como TFS u otra, si escalas ese proyecto a cuatro equipos ubicas tres de esos equipos en países distintos, contabilizando 50 desarrolladores al final, la complejidad es bastante mayor, lo monolítico me parece que se va mantener "simple" dependiendo de la escala, en su lugar la el diseño orientado a microservicio, permite generar un proyecto distribuído desde el inicio, con 1..n células y con una integración continua que se puede automatizar garantizando despliegues optimos. Por lo demás después de ver el video, me parece que es no plantea nada nuevo, es como forzar la arquitectura monolitica a trabajar similar a un diseño de micro servicio, por otro lado la organización que muestras en el proyecto de ejemplo es simplemente DDD, al final depende mucho en como lo ilustras, cómo lo prsentas y organizas en el proyecto, pero nuevo? Como concepto? No, no parece, mas bien un "Revamp" o "Upgrade" que en lo personal he visto muchas veces. De hecho el proyecto de ejemplo mostrado, en micro servicio probablemente se puede armar con tres microservicios y un "broker" (Kafka) y un Api Gateway que ni siquiera debe saber de estos microservicios ya que los puede localizar automáticamente, evitando mucha configuración y proceso de DI. Entre eso y DDD me quedo con DDD o un buen proyecto MVC armado dividido en varias API's y orquestadas por un administrador de procesos y todo ello sigue siendo más pesao que simplemente realizar un proyecto de mciroservicio en NODE JS o JAVA e incluso .NET. Saludos, buena iniciativa!
Ahí está el debate. Es una tendencia que se está discutiendo en la industria. Ya veremos si se adopta. Y eso es lo curioso. Las tendencias no necesariamente son ideas nuevas. A veces solo dan nombre a algo que no lo tenia, pero ya lo haciamos. Los mismos microservicios: hay gente que considera que no eran nada nuevo en su momento, y solo era una forma particular de hacer SOA. Lo de la escalabilidad es algo incierto, dependendiendo del proyecto. Hay proyectos que nunca crecen (por mas que el negocio quiera que crezcan). En esa incertidumbre es que creo que puede funcionar esa arquitectura. Por otro lado, creo que es bueno nunca olvidar el principio KISS y no hacer sobre ingeniería (especialmente si hay incertidumbre). Gracias por tu aporte, Juan.
gracias por el aporte! ..unos comentarios..es importante mencionar que para saltar a una arquitectura microservicios se requiere hacer una buena descomposición funcional, y creo que eso también aplicaría para los monolitos modulares, aplicando DDD por ejemplo.. mencionaste que se puede aplicar la arquitectura hexagonal para implementar un módulo monolítico, pero entendería que ya no sería una hexagonal como tal porque estarías integrando la capa de presentación a la arquitectura lógica, y eso es justamente lo que una arquitectura hexagonal no debe hacer. Otro tema importante es que en la práctica si todo el código fuente está en un solo proyecto y se maneja los módulos como una división puramente lógica (paquetes en java por ejemplo), se hace dificil controlar que un programador no acceda a la implementación de la api publica de otro módulo.. cosa que un microservicio se puede controlar fácilmente... saludos.
Gracias por tu aporte, Felipe. Hay formas de organizar el código que van a ayudar más al encapsulamiento que otros. La idea de que puedas implementar una arquitectura hexagonal (o cualquier otra) en un módulo es un poco para mostrar la independencia de los módulos.
Hola Manuel, muy interesante el video. Según lo que explicabas en el minuto 9:35 . Si un módulo necesita algo de una tabla que esta bajo el control de otro módulo , este no debería consultar directamente a la tabla. Si no , respetar y consultarlo por ese módulo . Así lo entendí y que me parece buena práctica, porque si se modifica algo en esa tabla , solo se modificaría un módulo. Pero en el ejemplo de Kamil, veo que crea tablas por Modulo (minuto 13:13) , con el mismo nombre, similares en su estructura (por no decir iguales). No se si entendí mal :/
Saludos, gracias y Bendiciones..... Estuve revisando el proyecto que mencionas aqui y veo que el lo mantiene actualizado!!!... algo me llamo la atencion, es que revise el proyecto y en ninguna parte del proyecto el realiza validaciones de que no le manden un correo como string en blanco, o algo asi, desde el API, luego a la aplicacion de un modulo, hasta el dominio de ese modulo, no existe ni una validacion de que los datos que se envian estan bien.... me pregunto si hizo eso por ahorrar tiempo o me estoy perdiendo de algo, talvez podrias revisar su repositorio y comparta tu opinion... de nuevo gracias y Bendiciones!!!
Excelente explicación, has visto Django? Esa es exactamente la forma en cómo se plantean los módulos, que allí se llaman aplicaciones ( en especial respecto de la base de datos)
Genial lo que me cuentas Cesar. He escuchado de Django, pero nunca lo he usado. Qué tan fácil será con Django separar luego esos módulos en servicios independientes?
No veo que sea una arquitectura nueva. Es una arquitectura DDD donde se separan verticalmente los bounded contexts. No deja de ser un monolito mejor organizado. No tienes en cuenta muchas de las ventajas aportadas por los microservicios como el despliegue y escalado independiente y el trabajo de distintos equipos especializados en distintas secciones y en distintos repositorios sin interferir, desarrollos de verdad independientes con frameworks y plataformas diversas adecuadas a las necesidades, etc. Eso si, estas ventajas sólo compensan en aplicaciones de cierta envergadura debido a la complejidad que añaden.
Como muchas tendencias, no necesariamente es algo nuevo. Solo algo que le pusieron un nombre distinto o que no tenía. El punto es: hacer microservicios por las razones correctas.
Estimado Manuel y comunidad. No entiendo el tema de los despliegues para este tipo de arquitectura, si tengo dos módulos, facturas y documentos. Requiero realizar un ajuste sobre documentos, como despliego sobre el modulo documentos sin afectar la disponibilidad del modulo facturas? si todo esta en un monolito aunque sea modular? Agradezco sus aportes.
Si necesito hacer un reporte con datos de modulos dependientes entre si, como sería el flujo de las peticiones?. Es decir, mi reporte inicia con datos del modulo A y por cada registro necesito su detalle que existe en el modulo B entonces como diseño el flujo de peticiones hacia el modulo B para no hacer algo así como un N+1 ?. Alguien sabe como se resuelve ese tema? ya que por lo que veo tendria que respetar el patrón de arquitectura y hacer solicitudes entre APIs
Cómo juega la escalabilidad en esta arquitectura? Si uno de esos módulos requiere escalar 3 nodos por temas de demanda en un día o una hora específica, todo el monolito tiene que escalar?
Son mas complicados de mantener los microservicios cuando son muchos, si claro...soluciona el tema de ceder una responsabilidad por cada microservicios lo que los convierte en una unidad mucho mas diluible y asimilable. Pero para entornos de integración muy grandes, pueden generar una plataforma un poco abrumadora.
En un monolito modular, podemos usar diferentes stacks y lenguajes para cada modulo o si esto es un requerimiento es mejor iniciar desde microservicios? Saludos
hay un tema que no queda del todo claro o tal ves este incorrecto, es la comunicación entre los módulos, si la comunicación se realiza utilizando las mismas Apis dentro de un mismo ensamblaje puede ocurre una redundancia cíclica, es decir: si el modulo "A" esta Diseñado en capas o sus derivados como clean arquitecture y su capa de aplicación o negocio apunta a un capa de API la cual, es la única entrada de ejecución del mismo sistema lo mas probable es que ocurra una redundancia cíclica en cada componente. otra opción seria que cada modulo tuviera su ensamblaje de APIS, ósea, capa modulo con su proyecto de APIS , pero, ya no seria un monolito por que tendría varias entradas de ejecución y para cada proyecto un despliegue... entonces lo mejor a mi juicio y teniendo en cuenta el repositorio que sugeriste es utilizar un "InMemoryEventBus" con una cuarta capa para la integración de eventos utilizando un patrón pub-sub. una librería que encontré para facilitar esto es JKANG. sin embargo, seria mejor aclarar tu video por que no creo que sea posible la comunicación de la manera como la explicas en el video. gracias y feliz día.
Excelente! Otra alternativa al respecto: Porto SAP (github.com/Mahmoudz/Porto). También va en la misma línea: modularizar correctamente y en base a dominios una aplicación monolítica.
Muy buen video. Tengo una consulta. Si tengo un módulo de facturación de una tienda de abarrotes y otro módulo para administrar los artículos la descripción del artículo que va en la factura la debería obtener desde el módulo de artículos, que método recomendarías?
Excelente! Tengo una duda. En este proyecto de ejemplo la comunicacion entre modulos lo hace bajo eventos (usa MediatR). Y es practicamente 4 microservicios pero sin implementar la capa de Aplicacion con técnicas de comunicacion entre procesos. Por tanto la unica ventaja vs Microservicios es en cuanto a infraestructura IPC. No me queda claro cual es la ventaja real vs 4 microservicos para este ejemplo. Gracias, Saludos
Me gustó tu vídeo, excelente. En mi opinión en esta opción de arquitectura estamos sacando lo peor de los 2 mundos, monolitos y las dificultades y retos de microservicios sin poder sacarle el máximo de provecho aunque habría que revisar los requerimientos. En lo personal solo lo usaría para algo súper puntual y teniendo una muy buena razón.
Se puede crear una aplicación completa que muestre solo el módulo del usuario respectivo solamente y crear un súper usuario administración que tenga acceso a toda la aplicación. completa
Excelente explicación. ¿Es recomendable utilizar integridad referencial entre módulos? Puesto que si separamos los módulos por bases de datos perdemos la integridad referencial (en el caso de utilizar modelos relacionales).
Hay muchos nuevos programadores que solo creen que hacer microservicios es hacer 1-1 con cada objeto de la bd y nunca hn hecho un proyecto o formado parte de un proyecto grande y no saben darle escalabilidad .
Muy interesante! Cuales crees que son los drawbacks o posibles desventajas de utilizar esta arquitectura? .. sera que si los desarrolladores no son disciplinados se puede volver un problema?
Ese es el eterno reto con el monolito. Que como todo está ahí, si no tiene la disciplina, unos buenos code reviews y buenos modificadores de acceso en el código, es posible que se terminen tomando atajos. El otro posible problema que veo es que exista acoplamiento a nivel de los datos, y luego sea más difícil separar las bases de datos.
Qué pasa si un módulo se cae y quien consume la API obtiene un 503 ? No es mejor que los módulos se comuniquen a través de un Bus de mensajería como se hace en una arquitectura de microservicios? De tal forma que si un módulo, microservicio o consumidor se cae los mensajes permanecen el Bus hasta que esté nuevamente disponible.
Buenas noches, buen video. Una pregunta esos módulos es lo mismo que se conoce en clean arquitecture como bounded context o son diferentes conceptos. Gracias
Excelente video !! Muy bien explicado el tema, aunque me surge una pregunta: ¿Que alcance tiene la variedad de capas de código? ¿Es posible programar capas a nivel de Linux Bash Scripting? Gracias de antemano ...
Hola Gerardo. Me imagino que al final tendrás una capa donde llamarás scripts de Linux Bash si lo necesitas. El nivel (alto o bajo) se lo das tu y el lenguaje de programación que estés usando.
Me estás hablando de una aplicación fragmentada por módulos , eso se ve me empresas grandes , donde cada dependencia maneja su aplicativo para trabajar. Cómo por ejemplo los almacenistas tienen la aplicación de inventario . Los de ventas tienen otra aplicación los de , módulo de estadísticas.
Hola! me topé con tu canal y me encanta, tengo una pregunta, que sucede en el caso de las transacciones que involucren mas de un modulo? se aplica patrones de microservicios?
En una arquitectura monolítica modular es bueno tener un canal de comunicación entre módulos para abstraer lo más posible. Una forma de hacerlo es con el patrón CQRS (que menciona Manuel al final del video) que define un service bus y eventos. Es parecido a queues.
Hola Manuel, Excelente video. Te quería preguntar si en este tema de monolitos modulares podríamos meter a tecnologías de java como OSGI implementando frameworks como apache karaf
Con OSGI no estoy familiarizado Mario, entonces no podría darte una opinión. Lo que dice Axel Fontaine (un arquitecto promotor de estos monolitos) es que tu podrías eventualmente usar colas para comunicar los módulos.
Microservicios es una manera en que puedes organizar tu backend. Un webservice sencillamente es como un API que puedes consultar para que te retorne algo o ejecute un proces. Saludos.
Před 3 lety
El API también se podría llegar a modular? Cómo se llegaría a comunicar un módulo con otro módulo, es decir, a partir de qué capa?
Te refieres a un API REST? Realmente la arquitectura no entra en mayores detalles en el punto en el cual se hace la comunicación con otro módulo. Esto dependerá de la organización interna de cada móulo.
Před 3 lety
@@ManuelZapata entonces podría ser comunicación entre endpoints por medio de http o por medio de las librerías internas, no?
La arquitectura de microservicios no se ideo para organizar mejor un proyecto. Se pensó para aprovechar las virtudes de varios lenguajes de programación. Por ejemplo, tengo un sistema en .net y quiero trabajar con IA, puedo hago un microservicio en python.
Lo ideal es definir qué modulo es el "dueño" de la tabla. Si al final te das cuenta que hay dos módulos que la necesitan muchísimo, posiblemente esos módulos deban unirse en uno solo.
Excelente video, dejo una cita de Robert C. Martin (Tio Bob): "Los microservicios no son una arquitectura, son una estrategia de despliegue. El desacoplamiento y la división podran (y deberían) lograrse independientemente de si se impone el límite de servicio."
Excelente cita, Christian! Si lograramos desarrollar con ese nivel de desacoplamiento, pasar a microservicios debería ser sencillo.
@@ManuelZapata Se puede. Antes de los micro servicios , hace ya años, todo lo que montaba era modular sin dependencias. El problema es que es difícil mantener esa disciplina en equipos grandes. Incluso con los micro servicios a veces se escapan cosas y hay miembros del equipo que se saltan esa separación. Yo he conseguido hacer una arquitectura modular en clipper y Delphi ( ya di pistas de mi edad 😂 )
Conclusion son fragmentaciones de una aplicación completa.
quien tendria la razon? tu tio bob o martin fowler? segun Martin Fowler dijo lo siguiente: La Arquitectura de Microservicios es una "forma particular de diseñar aplicaciones de software como conjuntos de servicios desplegables de forma independiente". mas bien no seria un estilo arquitectonico?
Los microservicios no aparecieron como consecuencia de una mala arquitectura monolítica, ni del mal uso de patrones de diseño, los microservicios son la consecuencia de la necesidad de balancear las diferentes cargas de la aplicación y de garantizar hasta cierto punto la resiliencia del sistema. La parte positiva que muchos desarrolladores ven es que pueden trabajar orientados a contratos donde cada microservicio sería una caja negra para el que no lo mantenga. Uno de los principales problemas vienen desde el punto transaccional, cuando más de un microservicio toma parte en la misma transacción, garantizar la consistencia y atomicidad se vuelve complicado. Otro gran problema viene con la mantenibilidad del código, al ser un desarrollo orientado a un contrato no tenemos la ventaja del tipado fuerte del compilador, cualquier cambio inocente en un nombre de una variable a consumir puede llevar a que el sistema no funcione, o peor, que funcione de forma errónea. Otros elementos a tener en cuenta son: hay que cambiar el proceso de cómo se hacen las liberaciones, como se hace el monitoreo y traceo de errores, como preparar datos válidos para las diferentes tipos de pruebas. Para decidirse por la arquitectura de microservicios debemos tener razones sólidas porque implica una inversión en tiempo, hardware y conocimiento.
Lo has descrito muy bien, Denys. Gracias!!
Muchas gracias por esta respuesta tan completa. Solo me queda una duda, ¿A que te refieres con la consideración del "cómo se hacen las liberaciones"? No se si te refieres a bajar instancias de los microservicios, o qué tipo de recurso liberar. Pese a eso, tu comentario me sirve bastante :)
Excelente video Manuel, leí por encima pero ahora con tu video me queda todo muy claro, gracias por compartir
Gracias Yesi por pasarte por acá y por compartir el video!
Me parece una estrategia muy inteligente que la aplicación vaya marcando la evolución de la arquitectura. En los últimos años he hecho varias aplicaciones nuevas y no he necesitado los microservicios, no es resistencia al cambio simplemente las modas no me apantallan. Saludos!
Muy sabio ese enfoque @CodeRoll. Seguramente cuando llegue la necesidad, aplicarás microservicios.
Uy considerar que los microservicios son moda es una afirmación muy atrevida.
CodeRoll, los microservicios no son una moda, es una forma de desarrollo para la evolucion del software desacoplada y facil de desplegar , yo llevo varios años desarrollandolos y dan una gran cantidad de facilidad a la hora del desarrollo y sobre todo del despliegue, permite esa independencia de modulos que de otra manera es mas complicada y encima si agregamos que los modulos de aplicaciones pueden tener diferentes evoluciones ...
Vale, igual me la bañe con eso de las modas. Aprovechando, tu que tienes experiencia en microservicios ¿Cuándo no los usarías? ¿esto de los monolitos modulares te hacen sentido o te vas directo al microservicio? Parto de la idea que no hay arquitecturas ni buenas ni malas, todo depende del contexto y en mi contexto no los he necesitado al parecer desarrollo monolitos muy buenos jejeje. Saludos!
@@Coderoll Como bien tu dices no hay ni buenas ni malas, y como has mencionado las arquitecturas hay que usarlas en su contexto correcto, no siempre he desarrollado ni desarrollo microservicios hay veces que es mas practico una arqutiectura monolita y no hay ningun problema, yo las monolitas las usaria en pequeñas aplicaciones y que no tengan mucha evolucion en el tiempo. Pero si realmenten es una aplicacion que tiene una evolucion continua es preferible usar los micros, por ejemplo una api de gestion, usaria un proyecto monolito para las maestras esas poco tiene de evolucion, pero en el negocio si usaria microservicios
Un saludo
muy bueno.. a la larga se reinventan las cosas con nombres y detalles diferentes.. Esto de separar en capas y proyectos ya se hacía en 2003 cuando vino .net . Lo hacíamos con otras arquitecturas más acopladas como remoting web services etc no existía mucho sobre APIs REST y menos Microservicios pero a grosos modos es una arquitectura super usada desde hace 20 años
Un companero de trabajo me envio este video, fue lo mejor del dia. Gracias Manuel excelente video!
Excelente contenido el que brinda Manuel, llevemos este canal a otro nivel!!!!
Al siguiente nivel! 📈
Totalmente de acuerdo. El problema de hoy día es que hay personas en puestos de decisión que realmente no entienden la programación. Como tú bien dices, se mueven por modas. Hace falta una revolución en el sector de la programación, donde los programadores no se limiten a tirar líneas de código si no que vean una aplicación como algo vivo, que crecerá y que no sabemos por donde lo hará.
Esto debe hacer al programador tener un poquito más de formación sobre las tecnologías (si bien es cierto que no hay mejor ni peor, sino que dependerá de la finalidad del programa)
También es importante que nuestro código esté modularizado, de modo que la lógica de negocio no sea un galimatías para un posible programador que ocupe nuestro puesto a futuro.
En mi caso (y no digo que sea la mejor forma), uso .NET con EF y MVC 4 y conectada al dominio. Pero la aplicación es una especie de megaprograma modularizado, con secciones. Es decir, tengo una base monolítica que solo te lleva al login. Una vez te logueas ya tienes un menú lateral con todas las secciones o programas con su código standalone (Modelo de datos, con su controlador con sus vistas) y todo independiente de todas las demás secciones además como está conectada al dominio puedes gestionar fácilmente los permisos a las secciones mediante asignación de grupos en el controlador de dominio. Obviamente esto te hará usar métodos parecidos por no decir idénticos por lo que tiene un poco más de trabajo, pero es ROBUSTA, escalable y fácilmente entendible para otro programador. Éste programa nació como una idea en el 2017 y hoy día es una parte muy importante de la empresa.
Sigue así Manuel Zapata, tienes la visión clara de un buen programador!
Me gusto mucho el video, efectivamente pienso en monolitos y creo que para usar microservicios debe haber una experiencia- necesidad puntual y enorme.
Excelente video, explica super bien gracias por compartir sus conocimientos.
Con todo gusto, Lilián!
No cabe duda que la especialización cada vez es mayor y que soluciones sencillas y robustas de antes terminan siendo complejas por el tema de la especialización y de querer adoptar cada vez mas herramientas y productos. Esto que comentas lo haciamos desde hace más de 10 años con los Servidores de Aplicaciones, Maven (modules de Maven), Oracle, J2EE y Adobe Flex o jQuery
Gracias por el aporte Abner. Así pasa con muchos conceptos en la industria. A veces cambian de nombre o le dan nombre a algo que no lo tenia.
Excelente explicación.
Muchas gracias amigo, saludos desde venezuela... Actualmente estoy incursionando en un framework de Typescript llamado NestJS y su diseno de arquitectura es completamente modular. Esto complementa con mi proceso de aprendizaje
Genial Thaeron. Saludos desde Colombia!
Buen video manuel, para complementar, cuando se utiliza una base de datos por monolitos modular, ya estas aplicando un patron de los microservicios y por lo que veo lo que se esta aplicando aqui es el desacople por capacidades de negocio. un microservicio no necesariamiente debe ser 'micro', el tamaño del MS va ligado con la parte del negocio que quiere cubrir.
Muy buen tema, me recordó que Zend Framework 1.0 + ya se trabajaba la arquitectura modular y para Zend Framework (2 y 3) ahora llamado Laminas su punto fuerte poder separar en modulos la aplicación. Y como bien mencionas al interior del modulo se aplica la arquitectura que más convienga, en Laravel también se podría usar implementanto la separación por package que sirven para extender las funciones.
Concuerdo contigo, el problema la mayor parte de las veces es el diseño de las aplicaciones no tanto la arquitectura, inclusive si tienes un monolito bien hecho si alguna ves por escalabilidad requieres mudar tu aplicación a microservicios es muy fácil separarlos, cada ves trato de pensar mas en como resolver mis problemas en code modules que aunque parezca algo complejo al final favorece muchisimo es como si programaras paquetes y los subieras a packagist en cualquier momento los descargas con composer y los implementas en el proyecto que necesites con solo modificar algunos ficheros de configuración y lanzar migraciones. buen video gracias Manuel!
Esto es buenísimo!!!
Excelente explicación, quiero contarte que sin saber estaba implementa esta arquitectura, pero solo lo hice por organización ahora con este video voy a independizar un poco más, sería bueno un ejemplo de comunicación de esta arquitectura 👍🏼
Me acabo de dar cuenta que estuve desarrollando monolitos modulares sin darme cuenta 😂. Buen vídeo 👏🤘.
Que explicación tan excelente, muchas gracias
Muy interesante Manuel muchas gracias por explicarlo tan claramente.
Excelente video gracias por compartir tus conocimientos Manuel.
Me parece interesante y nosotros estamos pasando por un proceso conceptual de Modularización de un monolito, para luego ir a Microservicios. Creo que es el mejor path de migración para romper el monolito. Saludos
Es un buen path. Saludos Javier!
Muy interesante Manuel, se puede decir entonces que de esta forma, si se relaliza un simple cambio, hay que deployar todo el monolito modular no? como si de un monolito normal se tratara.
Excelente video, felicidades!!... desde mi vida laboral he venido comentando que no se debe escoger la arquitectura de una solución basado al modismo, eso es un gran error y con charlas o actividades con proveedores, se vuelve un punto de controversia.
Esta es una buena opción que se debe analizar, otra opción válida.
Agradecería mucho que nos compartas el código para conocer de fondo la propuesta. Gracias y saludos!!
De eso se trata. De conocer opciones y saber cuándo es conveniente usar una o otra. Ya con eso vamos ganando.
En la descripción del vídeo está el enlace al repositorio.
Muy interesante tema, amigo Manuel, comenzando a escuchartee... 👋🏻
Gracias Oscar por pasarte por aquí!
Buen video, microservicios otro legacy hell para los proximos años, a ver como queda ahora estos monolitos modulares, mas de lo mismo renombrado
Así es. No necesariamente las tendencias son cosas realmente nuevas. De hecho, hay personas que dicen los microservicios tampoco eran nada nuevo. Eran sencillamente una variante de SOA con nuevo nombre.
Excelente video Manuel, todo me queda muy claro en estos conceptos que no los tenia tan claros, Gracias!
Con todo gusto!
Excelente material, muchas gracias !!!
Como quedan las tablas que son comunes a todo los módulos tales como tabla de países, tablas de bitácoras de acceso al sistema quien posee el control de estas tablas en un sistema monolitico
Buena pregunta, aún no entiendo mucho, pero de acuerdo con el vídeo, esta info debería pertenecer a un microservicio o monolito y consultarse exclusivamente por una API.
Al escuchar esto describe lo que es angular.
Me hizo recordar bastante a lo que se hace con nx monorepo. Buen video!
Gracias Nathan!
Que buen video manuel, yo no sabia que microservicios eran mas de moda, muchas gracias por compartir el repositorio de Kamil. Muy informativo este video.
Ha sido con todo gusto Armando!
Siguiendo la línea de “Software is meant to be soft” de Martin Fowler, la implementación del software debería poder variar de estrategia. Si es costoso, entonces podríamos haber diseñado mal la arquitectura.
Muy buen video! Gracias!
Gracias por tu aporte, Javier!
Excelente, me encantan los temas de arquitectura de software. Tienes un nuevo suscriptor :)
Bienvenido César!
Que chévere hacia esto sin darme cuenta en Laravel , cada módulo expone un service provider e inyecta interfaces en lugar de objetos concretos y los iba creando por separando e instalando vía composer como una dependencia de Laravel
Excelente! No estoy familiarizado con Laravel.
Hola, es relativo, me llama la atención una frase "...donde todo esta junto y todo es más fácil de desarrollar, siendo un monolito..." (Min.3:22) , para mi eso no es cierto, en nuestro caso usando Java Spring Cloud Microservices, se ha logrado una experiencia mejor al desarrollo monolítico, mejor control del tiempo, presupuesto y recursos. Es relativo ya que si hablamos de un sistema MVC construído por solo un equipo, compuesto por seis desarrolladores, aún cuando tengas una herramienta de integración como TFS u otra, si escalas ese proyecto a cuatro equipos ubicas tres de esos equipos en países distintos, contabilizando 50 desarrolladores al final, la complejidad es bastante mayor, lo monolítico me parece que se va mantener "simple" dependiendo de la escala, en su lugar la el diseño orientado a microservicio, permite generar un proyecto distribuído desde el inicio, con 1..n células y con una integración continua que se puede automatizar garantizando despliegues optimos.
Por lo demás después de ver el video, me parece que es no plantea nada nuevo, es como forzar la arquitectura monolitica a trabajar similar a un diseño de micro servicio, por otro lado la organización que muestras en el proyecto de ejemplo es simplemente DDD, al final depende mucho en como lo ilustras, cómo lo prsentas y organizas en el proyecto, pero nuevo? Como concepto? No, no parece, mas bien un "Revamp" o "Upgrade" que en lo personal he visto muchas veces. De hecho el proyecto de ejemplo mostrado, en micro servicio probablemente se puede armar con tres microservicios y un "broker" (Kafka) y un Api Gateway que ni siquiera debe saber de estos microservicios ya que los puede localizar automáticamente, evitando mucha configuración y proceso de DI. Entre eso y DDD me quedo con DDD o un buen proyecto MVC armado dividido en varias API's y orquestadas por un administrador de procesos y todo ello sigue siendo más pesao que simplemente realizar un proyecto de mciroservicio en NODE JS o JAVA e incluso .NET.
Saludos, buena iniciativa!
Ahí está el debate. Es una tendencia que se está discutiendo en la industria. Ya veremos si se adopta. Y eso es lo curioso. Las tendencias no necesariamente son ideas nuevas. A veces solo dan nombre a algo que no lo tenia, pero ya lo haciamos. Los mismos microservicios: hay gente que considera que no eran nada nuevo en su momento, y solo era una forma particular de hacer SOA.
Lo de la escalabilidad es algo incierto, dependendiendo del proyecto. Hay proyectos que nunca crecen (por mas que el negocio quiera que crezcan). En esa incertidumbre es que creo que puede funcionar esa arquitectura.
Por otro lado, creo que es bueno nunca olvidar el principio KISS y no hacer sobre ingeniería (especialmente si hay incertidumbre). Gracias por tu aporte, Juan.
Se me hace bastante familiar esta arquitectura, sobretodo porque programo en elixir y ahí se usan este tipo de arquitecturas.
Buenísimo! La idea no es tan "novedosa". Es solo que ya se le dio un nombre y se le está haciendo más difusión.
Excelente video!. y ahora en 2022 Modular monolith ya está en "Early majority", significa que ha tenido más adopción?
Excelente video. Gracias por compartir !
Mil gracias por esas palabras Edward!
gracias por el aporte! ..unos comentarios..es importante mencionar que para saltar a una arquitectura microservicios se requiere hacer una buena descomposición funcional, y creo que eso también aplicaría para los monolitos modulares, aplicando DDD por ejemplo.. mencionaste que se puede aplicar la arquitectura hexagonal para implementar un módulo monolítico, pero entendería que ya no sería una hexagonal como tal porque estarías integrando la capa de presentación a la arquitectura lógica, y eso es justamente lo que una arquitectura hexagonal no debe hacer. Otro tema importante es que en la práctica si todo el código fuente está en un solo proyecto y se maneja los módulos como una división puramente lógica (paquetes en java por ejemplo), se hace dificil controlar que un programador no acceda a la implementación de la api publica de otro módulo.. cosa que un microservicio se puede controlar fácilmente... saludos.
Gracias por tu aporte, Felipe. Hay formas de organizar el código que van a ayudar más al encapsulamiento que otros.
La idea de que puedas implementar una arquitectura hexagonal (o cualquier otra) en un módulo es un poco para mostrar la independencia de los módulos.
Hola Manuel, muy interesante el video.
Según lo que explicabas en el minuto 9:35 .
Si un módulo necesita algo de una tabla que esta bajo el control de otro módulo , este no debería consultar directamente a la tabla. Si no , respetar y consultarlo por ese módulo .
Así lo entendí y que me parece buena práctica, porque si se modifica algo en esa tabla , solo se modificaría un módulo.
Pero en el ejemplo de Kamil, veo que crea tablas por Modulo (minuto 13:13) , con el mismo nombre, similares en su estructura (por no decir iguales).
No se si entendí mal :/
Excelente vídeo
Visto en 08/11/2020
🙌
Me gustó, nuevo sub
Bienvenido por estos lados.
Saludos, gracias y Bendiciones..... Estuve revisando el proyecto que mencionas aqui y veo que el lo mantiene actualizado!!!...
algo me llamo la atencion, es que revise el proyecto y en ninguna parte del proyecto el realiza validaciones de que no le manden un correo como string en blanco, o algo asi, desde el
API, luego a la aplicacion de un modulo, hasta el dominio de ese modulo, no existe ni una validacion de que los datos que se envian estan bien.... me pregunto si hizo eso por ahorrar tiempo o me estoy perdiendo de algo, talvez podrias revisar su repositorio y comparta tu opinion... de nuevo gracias y Bendiciones!!!
Excelente explicación, has visto Django? Esa es exactamente la forma en cómo se plantean los módulos, que allí se llaman aplicaciones ( en especial respecto de la base de datos)
Genial lo que me cuentas Cesar. He escuchado de Django, pero nunca lo he usado. Qué tan fácil será con Django separar luego esos módulos en servicios independientes?
@@ManuelZapata Es bastante facil, doy fe de eso
Buen video Manuel, ilustrativo material, gracias.
Con todo gusto Mauricio!
No veo que sea una arquitectura nueva. Es una arquitectura DDD donde se separan verticalmente los bounded contexts. No deja de ser un monolito mejor organizado. No tienes en cuenta muchas de las ventajas aportadas por los microservicios como el despliegue y escalado independiente y el trabajo de distintos equipos especializados en distintas secciones y en distintos repositorios sin interferir, desarrollos de verdad independientes con frameworks y plataformas diversas adecuadas a las necesidades, etc. Eso si, estas ventajas sólo compensan en aplicaciones de cierta envergadura debido a la complejidad que añaden.
Como muchas tendencias, no necesariamente es algo nuevo. Solo algo que le pusieron un nombre distinto o que no tenía. El punto es: hacer microservicios por las razones correctas.
Estimado Manuel y comunidad. No entiendo el tema de los despliegues para este tipo de arquitectura, si tengo dos módulos, facturas y documentos. Requiero realizar un ajuste sobre documentos, como despliego sobre el modulo documentos sin afectar la disponibilidad del modulo facturas? si todo esta en un monolito aunque sea modular? Agradezco sus aportes.
Excelente.
Gracias!
Si necesito hacer un reporte con datos de modulos dependientes entre si, como sería el flujo de las peticiones?. Es decir, mi reporte inicia con datos del modulo A y por cada registro necesito su detalle que existe en el modulo B entonces como diseño el flujo de peticiones hacia el modulo B para no hacer algo así como un N+1 ?. Alguien sabe como se resuelve ese tema? ya que por lo que veo tendria que respetar el patrón de arquitectura y hacer solicitudes entre APIs
Buen vídeo
Gracias!
exclente muchas gracias!
Con gusto, Diana!
Lo bueno de esto es que así se puede crear una aplicación rápido si , se reparte el trabajo por módulos a cada programador.
Cómo juega la escalabilidad en esta arquitectura? Si uno de esos módulos requiere escalar 3 nodos por temas de demanda en un día o una hora específica, todo el monolito tiene que escalar?
Así es. Todo el monolito tiene que escalar. Esa es y seguirá siendo una desventaja de cualquier monolito.
Son mas complicados de mantener los microservicios cuando son muchos, si claro...soluciona el tema de ceder una responsabilidad por cada microservicios lo que los convierte en una unidad mucho mas diluible y asimilable. Pero para entornos de integración muy grandes, pueden generar una plataforma un poco abrumadora.
En un monolito modular, podemos usar diferentes stacks y lenguajes para cada modulo o si esto es un requerimiento es mejor iniciar desde microservicios? Saludos
hay un tema que no queda del todo claro o tal ves este incorrecto, es la comunicación entre los módulos, si la comunicación se realiza utilizando las mismas Apis dentro de un mismo ensamblaje puede ocurre una redundancia cíclica, es decir: si el modulo "A" esta Diseñado en capas o sus derivados como clean arquitecture y su capa de aplicación o negocio apunta a un capa de API la cual, es la única entrada de ejecución del mismo sistema lo mas probable es que ocurra una redundancia cíclica en cada componente. otra opción seria que cada modulo tuviera su ensamblaje de APIS, ósea, capa modulo con su proyecto de APIS , pero, ya no seria un monolito por que tendría varias entradas de ejecución y para cada proyecto un despliegue... entonces lo mejor a mi juicio y teniendo en cuenta el repositorio que sugeriste es utilizar un "InMemoryEventBus" con una cuarta capa para la integración de eventos utilizando un patrón pub-sub. una librería que encontré para facilitar esto es JKANG. sin embargo, seria mejor aclarar tu video por que no creo que sea posible la comunicación de la manera como la explicas en el video. gracias y feliz día.
Genial... 👍
Muy interesante el video 😁😁😁
Gracias Giancarlo!
Me supo a algo que sabemos de perogrullo o no? Como q hacer submodulos es lo minimo q deberiamos hacer en cualquier situacion. o me equivoco?
Muy buen video Manuel, saludos desde Chile.
Saludos Alvaro. Gracias!
Excelente...Yo buscaba el nombre de lo que hacemos en mi empresa y es este....
Genial! 🙌
Alguna técnica para tener múltiples soluciones para no tener una única solución para decenas de proyectos?
¿Manuel se podría decir entonces que esta es una arquitectura por servicios?
Gracias por los videos!
💪
Excelente! Otra alternativa al respecto: Porto SAP (github.com/Mahmoudz/Porto). También va en la misma línea: modularizar correctamente y en base a dominios una aplicación monolítica.
Si están trabajando en JS / TS pueden revisar un framework llamado NESTJS y facilita este diseño modular, además tienen un curso oficial muy bueno.
Buenísimo el dato. Gracias por compartilo, Cristian!
Genial tu contenido.
Gracias Ivan!
Muy buen video. Tengo una consulta. Si tengo un módulo de facturación de una tienda de abarrotes y otro módulo para administrar los artículos la descripción del artículo que va en la factura la debería obtener desde el módulo de artículos, que método recomendarías?
Excelente!
Tengo una duda. En este proyecto de ejemplo la comunicacion entre modulos lo hace bajo eventos (usa MediatR). Y es practicamente 4 microservicios pero sin implementar la capa de Aplicacion con técnicas de comunicacion entre procesos. Por tanto la unica ventaja vs Microservicios es en cuanto a infraestructura IPC. No me queda claro cual es la ventaja real vs 4 microservicos para este ejemplo.
Gracias,
Saludos
Muy buen video, pero me queda una duda pendiente y es ¿Cuándo sé que debo pasar a Microservicios?
Esto es como Liferay creo?
hola Manuel, muchas gracias por el video. en donde puedo ver un tutorial o libro que sea practico para .net core sobre el monolito modular en capas
Quizá esta serie de artículos te puede ser útil. www.kamilgrzybek.com/design/modular-monolith-primer/
Me gustó tu vídeo, excelente. En mi opinión en esta opción de arquitectura estamos sacando lo peor de los 2 mundos, monolitos y las dificultades y retos de microservicios sin poder sacarle el máximo de provecho aunque habría que revisar los requerimientos. En lo personal solo lo usaría para algo súper puntual y teniendo una muy buena razón.
Se puede crear una aplicación completa que muestre solo el módulo del usuario respectivo solamente y crear un súper usuario administración que tenga acceso a toda la aplicación. completa
Gracias Manuel, era algo que te había pedido hace un tiempo. Cuando estés en Cali tengo que invitarte un par de cervezas :D
Si, recuerdo muy bien cuando me sugeriste el tema. Lo puse en mi backlog y finalmente vio la luz. Ojalá se dé el espacio para esas polas! 🍻
Excelente explicación. ¿Es recomendable utilizar integridad referencial entre módulos? Puesto que si separamos los módulos por bases de datos perdemos la integridad referencial (en el caso de utilizar modelos relacionales).
Yo creo que sí. Yo mantendría siempre la integridad referencial, hasta que la separación no me lo permita.
Interesante opción para cuando existe esa incertidumbre de escalabilidad
Exactamente. Puede ser que al final nunca se escale, y así no se desperdicia el esfuerzo de desarrollar microservicios.
@@ManuelZapata Que suele ser en ocasiones agotador
Hay muchos nuevos programadores que solo creen que hacer microservicios es hacer 1-1 con cada objeto de la bd y nunca hn hecho un proyecto o formado parte de un proyecto grande y no saben darle escalabilidad
.
Excelente Presentacion Manuel, gracias, pero lo que he visto son como microservicios pero con gran cantidad de funcionalidad..
Sigue siendo un monolito, pero con una mayor facilidad para que algún día, si es necesario, se vuelva microservicios.
Buen video, podrías hablar de osgi vs microservicios, gracias
Gracias por la sugerencia, Jhonny. Lo anoté como idea para futuros videos.
Se parece al concepto de apps de Django. Puede ser?
Muy interesante! Cuales crees que son los drawbacks o posibles desventajas de utilizar esta arquitectura? .. sera que si los desarrolladores no son disciplinados se puede volver un problema?
Ese es el eterno reto con el monolito. Que como todo está ahí, si no tiene la disciplina, unos buenos code reviews y buenos modificadores de acceso en el código, es posible que se terminen tomando atajos.
El otro posible problema que veo es que exista acoplamiento a nivel de los datos, y luego sea más difícil separar las bases de datos.
Qué pasa si un módulo se cae y quien consume la API obtiene un 503 ? No es mejor que los módulos se comuniquen a través de un Bus de mensajería como se hace en una arquitectura de microservicios? De tal forma que si un módulo, microservicio o consumidor se cae los mensajes permanecen el Bus hasta que esté nuevamente disponible.
El problema es que sigue siendo un monolito. Si se cae el monolito, se caen todos los módulos.
Buenas noches, buen video. Una pregunta esos módulos es lo mismo que se conoce en clean arquitecture como bounded context o son diferentes conceptos. Gracias
Si pensamos en que la separación de los módulos se hace por funcionalidad, tiene mucha relación con los bounded context.
Excelente video !!
Muy bien explicado el tema, aunque me surge una pregunta: ¿Que alcance tiene la variedad de capas de código? ¿Es posible programar capas a nivel de Linux Bash Scripting? Gracias de antemano ...
Hola Gerardo. Me imagino que al final tendrás una capa donde llamarás scripts de Linux Bash si lo necesitas. El nivel (alto o bajo) se lo das tu y el lenguaje de programación que estés usando.
A qué se refieren a la capa de presentación?
Gracias
Capa de presentación es contra la que interactua un usuario. Ejemplo: una página, un formulario en una aplicación de escritorio.
@@ManuelZapata gracias Manu!
Me estás hablando de una aplicación fragmentada por módulos , eso se ve me empresas grandes , donde cada dependencia maneja su aplicativo para trabajar. Cómo por ejemplo los almacenistas tienen la aplicación de inventario . Los de ventas tienen otra aplicación los de , módulo de estadísticas.
Suscrito!!!
Bienvenido!
Hola! me topé con tu canal y me encanta, tengo una pregunta, que sucede en el caso de las transacciones que involucren mas de un modulo? se aplica patrones de microservicios?
En una arquitectura monolítica modular es bueno tener un canal de comunicación entre módulos para abstraer lo más posible. Una forma de hacerlo es con el patrón CQRS (que menciona Manuel al final del video) que define un service bus y eventos. Es parecido a queues.
Hola Manuel, Excelente video. Te quería preguntar si en este tema de monolitos modulares podríamos meter a tecnologías de java como OSGI implementando frameworks como apache karaf
Con OSGI no estoy familiarizado Mario, entonces no podría darte una opinión.
Lo que dice Axel Fontaine (un arquitecto promotor de estos monolitos) es que tu podrías eventualmente usar colas para comunicar los módulos.
Cuáles son los problemas que los microservicios no resolvieron?
Organizar bien un monolito, por ejemplo. Que un equipo de desarrollo no sepa hacer bien un monolito, no te lo va a arreglar un microservio.
Qué diferencia hay entre los webservices y los microservicios??? O son lo mismo???
Microservicios es una manera en que puedes organizar tu backend. Un webservice sencillamente es como un API que puedes consultar para que te retorne algo o ejecute un proces. Saludos.
El API también se podría llegar a modular? Cómo se llegaría a comunicar un módulo con otro módulo, es decir, a partir de qué capa?
Te refieres a un API REST?
Realmente la arquitectura no entra en mayores detalles en el punto en el cual se hace la comunicación con otro módulo. Esto dependerá de la organización interna de cada móulo.
@@ManuelZapata entonces podría ser comunicación entre endpoints por medio de http o por medio de las librerías internas, no?
Excelente vídeo Manuel, cuando un vídeo sobre DDD 😁?
Yo sé. Ese es uno de los pendientes en el canal.
La arquitectura de microservicios no se ideo para organizar mejor un proyecto. Se pensó para aprovechar las virtudes de varios lenguajes de programación. Por ejemplo, tengo un sistema en .net y quiero trabajar con IA, puedo hago un microservicio en python.
Esa una de las ventajas de usar microservicios. El punto es: usar los microservicios por las razones correctas.
Hola Manuel, hay posibilidad de comprar tu curso de arquitectura desde Argentina? saludos
Hola Miguel. Gracias por el interés. Claro que sí. Lo puedes comprar por Paypal.
Qué relación tiene este enfoque con DDD?
Podrías usar DDD en varias partes del monolito. El repositorio que puse en la descripción tiene buenos ejemplos de esto.
muy bueno el video, pero microservicios for life :)
🙌
Como deberia organizar la base de datos, si una o varias tablas son compartidas por varios modulos ?
Lo ideal es definir qué modulo es el "dueño" de la tabla. Si al final te das cuenta que hay dos módulos que la necesitan muchísimo, posiblemente esos módulos deban unirse en uno solo.