El desafío de la escalabilidad: Monolitos vs. Microservicios (PRIME VIDEO VUELVE A MONOLITOS)

Hoy analizo las diferencias entre Monolitos y Microservicios, hablando de las ventajas y desventajas de cada uno. Tambien hablamos de la nota de PrimeVideo que dice que se pasó a monolitos y dejó de usar funciones (Lambda).
Hacete una cuenta en Bitwage con mi link y obtené todos los beneficios:
bit.ly/bitwage-peladonerd
Nota de Prime Video: www.primevideotech.com/video-...
--
Repo con todos los archivos que uso: github.com/pablokbs/peladonerd
Merchandising Pelado Nerd: merch.peladonerd.com
Micrófono: Rode VideoMicro + Zoom H1N
Cámara: Sony A7 Mark III
Lente: Sony 28-70mm 3.5
Laptop: Macbook Pro 16'' 2019
Puedes encontrar todos mis links en peladonerd.com

[@PeladoNerd]

Dejo tambien el análisis de @BettaTech al mismo artículo para que acompañen este video! kzbin.info/www/bejne/iIGofmWBrZpggKc

[@CarlosHernandez-hk8ye]

En el tiempo que llevo desarrollando (hace mucho) a los monolitos que he desarrollado simplemente se le han agregado microservicios y las aplicaciones siguen funcionando sin problemas. Siempre recomiendo un monolito para las partes que menos necesidad de cambios requerirían. La importancia de un buen análisis y diseño previo al desarrollo.

[@eldalai2]

Excelente reflexión! Hay un articulo de Martin Fowler (MonolithFirst) que explica que es mejor comenzar con un monolítico para que el equipo inicial conozca el negocio y sus complejidades. Es muy difícil saber cuales son los microservicios inicialmente sin conocer realmente que necesita el negocio. Además, para poder tener microservicios, por cada microservicio debería haber un equipo dueño. Tener 10 servicios con 5 personas, tampoco es saludable. PD: Comenzar una app web con Django (Python) o RoR (Ruby) es la mejor/barata manera de descrubrir lo que necesita tu negocio/startup y dar resultados. Don't worry, be crappy

[@reinaldo6318]

Como podria escalar en django una app en especifico que recibe mas demanda que las otras ? Convendria pasarla a un microservicio ?

[@octaviovallelopez3263]

Buenas!! demoraste un poco en citar que un monolito tambien puede ser modular. Usar multiples lenguajes en un monolito tambien es posible, justamente cuando uno hace shared libraries, esto lo puede llevar a adelante, con un contrato a nivel de interfaces y uso de builtin types, ej... python tiene muchas libs en C/C++ !, muy buen video, bien explicado.

[@omega-the-loner]

Muy buen video, pelado. Y muy de acuerdo en mucho de lo que has expuesto. En mi trabajo, pasé a dedicarme de puro development a tocar infra y deployments y si me preguntan si es mejor monolitos, microservicios, serverless o despliegues tradicionales, yo respondo: depende. En lo personal, me gusta que un diseño sea capaz de anticiparse a muchas situaciones que puedan afectar a la empresa y que lo que se haga, se haga en concordancia con la necesidad más que por lo que diga la teoría (sin dejarla de lado, claro).

[@juant72]

Es un recordatorio de que la gestión de costos en entornos de nube puede ser compleja, incluso para grandes empresas, y que es necesario realizar un análisis y optimización continuos para maximizar la eficiencia y reducir los gastos operativos.

[@sergiosandoval3821]

Antes de iniciar cualquier proyecto, me toma más tiempo pensar la arquitectura y tecnología que voy a utilizar, que ya resolver el modelo de negocio, pero para nada es tiempo perdido, ayuda en tener un buen inicio y no tener "Tantos" problemas con una base sólida, sea monolítica, o en mico-servicios.

[@andryjaviervichotchavez8470]

¡Excelente explicación! Felicitaciones.

[@pablogonzalezrobles4429]

Nota importante. Era para una funcionalidad en específico y no todo su backend. La moraleja es que hay que estudiar el caso de uso y decidir lo que más conviene cuando eso necesite escalar

[@lmora00]

Correcto. Una aplicación monolítica bien diseñada no debería afectarle cuando se realiza un cambio.

[@franhenrrobles9573]

Otra ventaja de los microservicios y que para mi es crucial, es que se pueden crear matrices de ambientes muchos mas rapidos y mas "baratos" en el ciclo de vida del software. En la mayoria de los casos, las empresas solo tienen un array de ambiente para una unica version, maximo dos versiones cuando se trata de monolitos, ya que se vuelve muy complejo y costoso el aprovisionamiento y administracion de la infra. Monolito: VM Dev > VM Test > VM QA > VM PRE > VM Prod (latest) VM Dev > VM Test > VM QA > VM PRE > (ver2) Otro array y empieza a tornarse pesado. MS: Todos los que quieras divididos por namespaces. ns desa --ms ver1 --ms ver2 --ms ver3 --ms ver n ns testing --ms ver1 --ms ver2 --ms ver3 --ms ver n ns QA --ms ver1 --ms ver2 --ms ver3 --ms ver n Cluster produ. -- ns produ --ms produc1 -- ms produc2 y asi sucesivamente. saludos.

[@leonardomajado4011]

Muy buena la explicación, super clara 👍

[@miguelacardenashndez7819]

Pelado ante todo te admiro porque sacas tiempo de tu vida diaria para compartir conocimiento es admirable, respecto al video yo considero que para una empresa robusta siempre es mejor microservicios(alta disponibilidad, versatilidad ...) en el caso de Prime Video no pasaron a monolito, solo potenciaron un microservicio jajjaj( principios de IaC modulariza, pero nuncaaaa modularices demasiado) igual es difícil definir la mejor arquitectura al inicio de un proyecto, ya que este puede evolucionar de muchas formas, esto lo digo desde mi modesta opinión. Me gustaría que trataras algunos temas: - DevOps vs. Platform Engineering está muriendo DevOps? - Ventajas de la implementación de un IDP - Buenas prácticas a la hora de seleccionar un gitflow/git Worckflow Nota: Siempreeeeee sacas preciosas remeras en tus videos pasa el pique de donde las compras please

[@christianspq]

Explicación impresionante!!!

[@miguelvasquez9849]

muy buen análisis, gracias por la información.

[@Zephyrous.]

¡Grandísima explicación! Todo estuvo muy claro desde el inicio… y el cierre, aunque no soy de Argentina 😂😂😂

[@ignacio1531]

Muy buen contenido Pelado, gracias por los stickers de *IMPRESIONANTE* 😉

[@alvarogp2103]

Gracias por compartir tanta experiencia y conocimientos mi querido antónimo capilar. Ojalá nunca te Bayas...(aahh no pará) te deseo éxitos

[@NullSafeArchitect]

Brutal anàlisis de la notícia!

[@MartinDev77]

Hace mucho que no veía tus videos, lograste una muy buena fotografía en tus videos. Groso!!!

[@JoseElbioDarioVelazco]

Excelente video pelado!.

[@chalingui]

Grande Pelado, siempre data interesante

[@rlgino]

Venias re bien... Hasta el ultimo minuto jajaj igual te re banco pela 👨🏻‍🦲estaria bueno si podes hacer un video acerca de los roles que participan a la hora de tomar una decisión de que tecnologias se elijen o en que nube se despliega, gracias crack! 👏🏽

[@franhenrrobles9573]

Este caso en particular de amazon fue mas por un tema económico que tecnologico, tal es como dice El pelado, ambos son buenos, solo se debe saber cuando aplicar uno o el otro, o incluso pasar de uno al otro segun convenga. Abrazo pelado.

[@vargrrefr3666]

Genio, gracias x seguir compartiendo tu sabiduría. Al final es verdad que la experiencia es un peine que te da la vida cuando ya te quedaste pelado, atte otro pelado.

[@sebapinery]

Clarísimo Pela. No hay receta mágica, hay muchos factores a analizar a la hora de decidir la tecnologia de un proyecto. Gran idea me diste del monolito en bash 🤔😁😂

[@ivanleiva6144]

buena explicación, te mamaste al final Pelado

[@luispocodetodo]

Buen video macho!!

[@pablonavarro2523]

sos crack Pelado! Ojala algun dia me toque laburar en un equipo con vos loco! Abrazo

[@BurucuaGerardo]

Muy buen video y bien explicado, ahora entiendo por que no siempre la mejor solucion son los microservicios jeje. Gracias pelado!

[@alfonsoadalberto8472]

Jajajaja Es momento de desempolvar mis monolitos COBOL de 16,000 líneas cada uno. Son gigantescos pero tienen un poder de procesamiento bestial 😎

[@martinjavierllanos]

@PeladoNerd sos un genio y te quiero. Un micro servicio puede volver a ser monolito, pero de B no se vuelve mas.

[@gabrielwp]

Para mí, salvo ciertas excepciones, siempre será mejor la infraestructura monolítica... Siempre he opinado igual. Cuando salió el boom de microservicios, serverless, etc... Siempre estuve claro que era más de lo mismo, pero maquillado de otro modo. No digo que todo sea malo, pero realmente es reinventar la rueda... Ahora todo el mundo lo objeta, en algún momento llegué a cuestionar mi posición y abrirme, pero seguí pensando igual. Sin embargo, es como tú dices, todo depende del tamaño de la empresa y la complejidad de los procesos. Saludos

[@guidomaxier]

Te faltó el escudo de River, al final del vídeo. Muy bien vídeo muy claro, bien explicado, y didáctico.. Un abrazo.

[@joseluis3717]

exelente video, un saludo.

[@matiassiri5227]

Gran video!! Me caia muy bien el pelado...pero despues de escuchar el final, hablando de River.. me cae mucho mejor!! 😂 🤍♥️🤍

[@juanpablomezagazabon9238]

Buen vídeo amigo! Creo que el término apropiado para lo hicieron sería el de "microlito" pues... A rasgos generales representa un componente de toda la aplicación, pero tiene responsabilidades compartidas.

[@dzanotti]

Gracias por el video, lo distribui internamente en mi empresa porque todavia hay gente que no tiene claro las ventajas y desventajas de las dos arquitecturas. P.D: capaz paso desapercibido pero me rei mucho cuando hiciste el comentario de como pronunciaste el ingles jaja y lo digo porque yo soy muy malo jaja. Abrazo grande

[@oddikaro8236]

Muy buen vídeo. Yo añadiría que un Monolito es más fácil de debugear y arreglar porque sólo hay un código. También añadiría que una desventaja de los microservicios es la comunicación entre ellos, el despliegue es mucho más complicado, la ventaja de poder hacer cada servicio en la tecnología que quieras puede convertirse en una desventaja a la hora de mantener y buscar devs, y la mayor cantidad de dependencias en tu solución. Microservicios está bien para hacer aplicaciones consumidas por todo el mundo (la misma para todos vs una copia para cada cliente), principalmente por la posibilidad de escalar con el tráfico, la facilidad de optimizaciones geográficas y la facilidad de usar servicios cloud en vez de on premises. Yo trabajo en un monolito gigante modular y está muy bien hecho. No tendría ningún sentido hacerlo con microservicios, sería un disparo en el pié.

[@gilbertobarbosa5136]

Si a un monolito le agregas, corutinas , redis y db no relacionales, puede durar muuucho tiempo funcionando

[@jordixboy]

un monolito bien hecho sin eso puede durar igual, incluso puede tener buen codigo y escalar bien

[@gilbertobarbosa5136]

​@@jordixboy ah, si claro, bueno añado, que para cuando es previsible un trafico susperior al normal pero no tanto como para verse obligado a implementar MS, en ese caso se mantiene por mas tiempo un ponolito.

[@javicarrara]

Temas a tener en cuenta, la comunicación entre microservicios a gran escala no se hace via http, sino se usa el patrón Event-Driven Design, es decir, mediante eventos y colas. Faltan un montón de desventajas de los monolitos, a nivel seguridad, se compromete toda la app, a nivel de testing, es muy díficil hacer test unitarios, mas que nada a la hora de mockear, test de integración, etc, la app pierde la resiliencia y un fallo puede costar que falle toda la app. A nivel de ci/cd, los tiempos se elevan considerablemente, a nivel de arquitectura, se hace muy díficil hacer cambios, ya que afectaría toda la app. Saludos

[@Murzbul]

Justo venia a comentar eso. Me pareció interesante lo de http cuando en realidad las empresas que hacen eso es porque estan haciendo mal las cosas. Como bien decis del patron hablando directamente de alternativa de http existe gRPC que es lo ideal para la comunicacion de microservicios.

[@javicarrara]

@@Murzbul No lo veo como algo malo el uso de api rest, sino como algo que tiene varios problemas y no se adapta bien a patrones de diseño de software orientados a microservicios, como DDD, CQRS, etc. Donde el objetivo es separar responsabilidades en bounded contexts y se requiere comunicación asíncrona, por eso el uso de eventos de dominio.

[@Murzbul]

Claro yo si lo veo mal. Si usas api rest tenes que trabajar el doble para asegurar cierta calidad ademas que usando gRPC es mucho mas rapido y generas una mejora performance. DDD podes aplicarlo sin drama independientemente de esa decision todo depende de la abstraccion que se haya usado a la hora de implementar el sistema para que quede lo menos acoplado posible.

[@javicarrara]

@@Murzbul Estoy de acuerdo, ahora las empresas optan ir por esto cuando le ven el sentido, es más fácil ir por api rest que por gRPC, principalmente porque no todo el mundo conoce gRPC y hay una curva de aprendizaje. A nivel de infra, es más fácil desplegar un api gateway en aws y luego el microservicio en containers o serverless. En este rubro, nada está escrito en piedra, si tiene sentido y cumple con lo esperado genial.

[@oddikaro8236]

También faltan desventajas de microservicios: la comunicación, el despliegue, la aparente ventaja de hacer cada microservicio en una tecnología diferente puede convertirse en un problema tanto de mantener por el incremento de dependencias (y muchas open source) como a la hora de contratar personal, es más complicado de debugear...Finalmente, no todo el mundo usa ci/cd ni testing porque es inviable es soluciones grandes. Yo trabajo en un monoloto gigantesco y está muy bien hecho, una versión basada en microservicios sería un caos total. Como dice Nerd depende...

[@lucisdev]

Muy bueno el easter egg del final a lo Marvel

[@agustinnormand1404]

Impresionante hairless!! 🚀

[@melvinrmc2002]

17:39 al estilo Marvel 😅

[@LuisYairMirandaGonzalez]

Me saco un susto 😂😅 pensé que había terminado hace rato

El problema de los microservicios es abusar de ellos, cosa que ocurre demasiado frecuentemente. Eso ha disparado los costes de muchas empresas

[@jorge_pb8482]

Jajaj q buen video pero el final lo mejor sin duda xD

[@rafaelcampoverde]

Woow gracias por explicarnos tan claramente cuando usar una u otra tecnologia, lo maximo!!!!!

[@sebastianperez6124]

En este campo siempre se olvida que no existen balas de plata.

[@leonelibarra518]

Se puede aplicar clean architecture a un monolito?

[@ahnsylimbal6811]

Con un monolito bien estructurado de forma modular resuelve todas esas desventaja que tiene, estanto asi que hasta facilita el buen trabajo en equipo y se aprovecha el 100% de las potencia de los lenguajes interpretado, asi que Monolito forever 💪😎

[@eng3d]

You fui jefe de proyectos, programados y administrador de plataformas. Cuando se habla de microservicios, no se considera la administracion, no se considera el costo y no se considera la programacion. Por eso muchos proyectos de microservicios fallan. Para mi, lo mejor es escalar datos, no plataformas, lo cual sigue siendo complicado, pero eso es posible desde decadas tras.

[@BelgranoK]

Las deventajas mencionadas para monolítos tmabióne aplican a microservicios. En nuestra experiencia lo mejor es inciar con un monolíto y si surge agregar o separar en microservicios. Los lambdas no son tan baratos como parecen.

[@Iam_AndersonP]

La noticia es un poco clickbait (la de Prime video no este video), simplemente cambiaron de usar varios micro servicios hechos en lambda a uno solo y eso es completamente válido como dices Pelado. Muy buena info y muy buenos puntos de vista para los que se preguntren que es mejor

[@rossmelweb931]

Excelente contenido, xk estoy construyendo un proyecto de un freelo donde veo que la mejor opcion seria un monolito

[@mauromosconi554]

No dejó de ser micro servicios, desde mi punto de vista puede ser que hayan tenido un problema de diseño cuando pensanron esos micro servicios(los de conversion de audio y video), que deberian de haber sido un solo micro servicio. Esto no es un monolito, sigue siendo una arquitectura de micro servicios solamente que la parte de conversion de audio y video que eran 3 micro servicios lo pasaron a 1. Pero toda su arquitectura general sigue siendo micro servicios.

[@fernandoramones2647]

Casi me suscribo pero me encontré con un final tan gallina

[@theblackven]

"interesante" 😮😮😮😮😮 gracias pelado por el dato y la explicación

[@raulsandoval262]

Buen vídeo pelado... mmmm pues he trabajado con ambos, usando el monolitos con el servicio de Fargate y Microservicios en eks y te digo que me quedo con los microservice, así también los de amazon estan ofrecen instancia SPOT a %90 de descuento, en si son una mierda, se rompen en los microservice cuando quieren escalar, lógico todo esto desplegado con Don Pulumi o Go. Bueno también la latencia influye mucho de la región donde estas desplegando y a donde se consumirá

[@sergioortegadev]

ja ja ja 🤣🤣🤣🤣 Pelado bardero! me hacés reír muchísimo!!! Bardeando a Boca te van a matar ja ja ja ja ja, sos un genio hermano, abrazo enorme

[@shaquespiare]

No hay que sorprenderse si en sus inicios se opto por una arquitectura, sin los previos estudios. No hay mejor ni peor, sino la herramienta adecuada para cada ocasión. Los microservicios no son la panacea a todo mal, lo que ocurrió en aws es una clara demostración. Buen video!!

[@eriknyk2k]

estoy de acuerdo en el 50% de lo que mencionas, pero igual va a depender de algunos otros aspectos como por ejemplo la arquitectura de tu monolito, si esta bien diseñado, usara Clean Architecture con principios SOLID y desde esa perspectiva tu plataforma no necesariamente se volvera con el tiempo obsoleto, pues la logica de negocio (Dominio) estara bien abstraido y no dependera de ninguna tecnologia en especifico, se implementa tecnologia en de los adapters que esta capas mas arriba (Infraestructura) y no tocan la logica de negocio, en ese sentido si el dia de mañana sale una nueva tecnologia solo hay que hacer una nueva version del adapter que implemente esa nueva, y no toca codigo del core, bueno el que haya leido Clean Architecture de Uncle Bob me entendera. Saludos.

[@juanmajacquet]

Muchos sistemas fueron migrados de usar Lambda a usar Fargate, por un tema de cantidad de requests hay ciertos escenarios donde es mas conveniente

[@CosasCotidianas]

Grande pelade

[@nicolasesteban699]

Capo!

[@GualbertoEsparza9]

Jajajajaja River mejor que Boca eso fue lo más genial del video de ejecutar las fork bom

[@jacmkno5019]

La custión es que hay problemas que son intrínsicamente acoplados por definición de su dominio y los profesionales de OOP suelen priorizar el desacoplamiento de las soluciones de software por encima de la comprensión de los problemas desde el punto de vista del dominio. Esto empieza a generar los costos tópicos en los que incurre quien mantiene una mentira en cualquier industria, se gastan la plata y su tiempo tratando de ocultar la realidad....

[@AleloKey]

Grande Manute

[@ignaciosepulveda4775]

Dale me gusta para mas escenas post creditos jajaja grande pelade!

[@orlandojimenez1]

no creo que la escalabilidad de un monolito sea una desventaja, esto depende mucho del diseño/arquitectura del monolito. para el procesamiento de videos que se usa de ejemplo, buenas practicas de computación distribuida pueden hacer que escale de manera sencilla.

[@stivenf8]

Pelado, dónde compras tus remeras?

[@aquirozdev]

Estuve en una empresa en la que (no sé exactamente las razones) empezaron desde cero con los microservicios, y como es típico, muchos de estos MS crecieron sin tener una arquitectura común, sin documentación y todos usaban la misma BD en Mongo, era un lío solucionar un bug porque tenías que tirarte medio día buscando en kubesphere el log en donde se produjo el error. Al final decidieron empezar una nueva versión partiendo de un monolito porque el código se volvió inmantenible.

[@DD-le1nf]

Saludos Crack. Excelente contenido. Disculpa una pregunta, Si tengo 2 Vps en digital Ocean, 2 en EC2 en AWS y en Linode otros, de que forma puedo monitorear estos de una forma centralizada, uso de CPU, RAM almacenamiento, entre otras y muchas mas alertas ? Gracias 🙌🙌

[@ejant]

prometheus + node exporter + grafana

[@carlosmollapaza9267]

Un monolito con DDD, separado por Bounded Context y se hace como yn solo servicio queda bien escala bie bien, los cambios son faciles por Bounded context

[@jose6433]

Yo utilizando la nube de Google me sorprende que utilicen servicios como lambda (aka cloud functions) conociendo la cantidad de datos que se manejan, siempre ha sido mucho más costoso el uso de esos servicios por sobre el de servidores y de hecho muy pocas veces los promuevo. Y lo otro, es que aún siendo de las mismas empresas se cobran entre ellos, a pesar de la cantidad de servidores y datos que manejan

[@maxxcan]

yo siempre pensé que Amazon (tienda, videos, etc) era la misma empresa que AWS, de hecho yo conocí Amazon por AWS así que me ha extrañado mucho que les cobren.

[@jeffbezzos]

le está pasando cada vez a más empresas y es normal, el modelo cloud es carísimo y solo beneficia a Google, Amazon y Microsoft. Además, el éxito de un sistema basado en microservicios depende de que los analistas y diseñadores de API sean muy buenos, para que luego los desarrolladores no pierdan tiempo en ir corrigiendo incidencias continuamente. Lo he sufrido en todos los proyectos en los que he usado microservicios. Da igual que uses agile, al usar microservicios multiplicas las interacciones entre equipos y pierdes mas tiempo desplegando y revisando PRs que sacando adelante lógica de negocio. Y reza porque la empresa no base la QA solo en cobertura de tests...

[@Mike-bc1xl]

Pelado tengo una duda sobre algo que comentaste en el vídeo… Dijiste que Amazon prefirió salir con lambdas porque era lo más rápido, ya que escribes menos código. Es curioso porque se comenta muchas veces que salir con un monolito a nivel de complejidad es mucho más sencillo y rápido para salir al mercado. No crees que estaba más asociado a que Amazon eran los pioneros del serverless? Y por ello se tiraron con esto al mercado? Ya luego recogieron la cuerda porque en particular el servicio de streaming les valía más con hacer un monolito para el procesado. Saludos y gracias por el vídeo!

[@carloscepeda8402]

Buen video colega, como tu dices, los microservicios no son la panacea ante cualquier desarrollo, existen otros estilos arquitectonicos que nos puede permitir ahorrar costos. Siempre hay que buscar ser costo eficientes. Saludos men.

[@inteligenciafutura]

yo tengo un proyecto pequeño que si consigue fama la idea es escalar muy rapido y aun no me decido por microservicios o el tradicional monolito

[@luisolave5991]

como aplico micro-servicios en una aplicacion grande que esta en un cpanel?

[@elgoleminculto]

es que esas lambdas ahi escuecen bastante ... un Deployment con una buena política de escalado y un cluster autoscaler detrás, unido a microservicios con contenedores pequeños, hace todos los efectos de ser serverless escalando incluso desde 0, y sin la parte mala del serverless :D parece más un tema de la infraestructura usada casi que de la arquitectura de la aplicación

[@erickjhormanromero6905]

Si si hay que pensar en todas las opciones pero si el mono me ha dado problema para deployar. 😉😉😉

[@mariocortes2670]

Grande Pelado. Ultimamente después de que salió la noticia de amazon, he visto varios post en Linkedin donde muchas personas quieren dar a entender que los microservicios son malos y una moda. Pero realmente cada solución tiene sus ventajas y desventajas tal cual lo has explicado.

[@js53649]

Ec2 auto vs EKS. Cual seria mas barato

[@ebetanzosm]

Esta gente lo que hicieron fue simplemente desfragmentar un poco su sistema. Se dieron cuenta que una fragmentación (en este caso) excesiva era contraproducente. Y ahí es donde veo la clave para entender todo este asunto de microservicios vs. monolitos. La verdad es es que la idea detrás de los micro servicios es básicamente el "micro" (los sistemas distribuídos existen desde hace mucho tiempo antes de que se introdujera el término) y esto es algo que se ha demostrado una y otra vez que perjudica más de lo que aporta. Prime Video lo que hizo fur juntar en la misma unidad de despliegue aquellos procesos que no hace sentido tenerlos separados. Como reza el refrán "en el justo medio está la virtud".

[@user-lm4gv2di8l]

Jajajaja me encanto tu chiste de bash

[@jordixboy]

El problema de la interdependencia y complejidad del codigo lo puedes solucionar con una arquitectura tipo DDD/Hexagonal

[@fmiranda]

Gracias por compartir, aunque me parece muy discutible que hay que elegir microservicios para hacer una aplicacion robusta. Es mucho mas facil hacer un monolito robusto que una aplicacion con micreservicios robusta por las razones que se mencionan en el video: Los microservicios son aplicaciones distribuidas, más difíciles de implementar, más difíciles de testear, deployar y monitorear. Hay muchas partes en movimiento en una arquitectura de microservicios que agrega mucha complejidad y por lo tanto puntos de falla. Por otro lado, hacer un monolito que corra en varias instancias con un monitor que levante las instancias que se caen es bastante simple y robusto.

[@garamburito]

la industria del software se mueve por modas, por suerte los programadores nos beneficiamos de ello, me imagino a los proyectos legacy que se reescribieron como microservicios, reescribiéndose de nuevo para volver a implementarlos como monolitos :)

[@jdiegosf]

No creo que sean modas, en este caso en su día les encajaba mejor usar Lambdas y con el aumento de clientes y de tráfico es mejor este enfoque. No son modas, simplemente los parámetros han cambiado.

[@mayikx]

Las modas no existen aquí, son paradigmas evolutivos. Es que se hace mejor fit a nuestro problema.

[@danielfernandezdev]

Yo creo que el software va cambiando en su ciclo de vida. Hoy en día entiendo como práctica común hacer esto de darle más o menos responsabilidad a los módulos, microservicios o lo que se esté usando según como va evolucionando una aplicación. Lo importante es conocer los diferentes modelos de arquitectura de software, sus ventajas y desventajas; y decidir qué utilizar no solo dependiendo del momento en el que creamos algo nuevo, sino cuando eso evoluciona. Algo similar sucede entre las metodologías prescriptivas, como por ejemplo, cascada. No es ni buena ni mala respecto a otras, ejemplo scrum, sino depende del momento y la situación.

[@joelh766]

Modas hahah ni que fuera musica. Esto es evolution, hacer cosas maa Rapides y eficientes.

[@jdiegosf]

@@joelh766 no es evolución, la arquitectura de monolito es más antigua que los microservicios.

[@galactico4916]

Y si se parte estratégicamente un unico monolítico en varios monolíticos?

[@Tho7odos]

Ventajas del Monolito: - Facil de sacar a produccion, - Easy to go live - Facil de enviar a la parte donde el publico la encuentra online - no es complicado enviarla al servidor donde estara corriendo para que se use........

[@sauljeronimorodriguez4261]

mmm , el que sea un monolito NO SIGNIFICA QUE "todo este junto con pegado" es decir, hay un concepto por ahi que se llama Bajo Acoplamiento y bajo un diseño arquitectonico de tu aplicativo en N capas bien definido, creánme, que NO ES TAN DIFICIL como este buen hombre menciona (al inicio) hacer cambios o quesque alguién tenga miedo de meter mano por que le vas a pegar a todo en todas partes. A veces, es el detalle de que estas nuevas generaciones ni siquiera conocen CORBA, RMI, EJBs, etc ¿acaso creen que todo lo DISTRIBUIDO y ESCALABLE nació con lo CLOUD y los Microservicios ?

[@elvisedmar6629]

Estas muy futbolero estos dias Pelado jajajajajaj

[@alexarraga5360]

Excelente ese final pela jajaj 🔴⚪🔴

[@miguelsirna]

#solid

[@sebastianviana4010]

river y el pelado nerd lo mas grande de argentina

[@augustogomezsaa476]

Soy mendocino trabajo en el it hace 5 años veo tus videos hace mucho y enterarme que sos de river ahora me hace ver lo grande que sos.

[@hba6018]

He visto monolitos desarrollados en varios lenguajes y aplicando conceptos de microservicios usando modulos, la unica ventaja que veo es el tema de infraestructura, levantar microservicios en demanda de un balanceador de carga o algo por el estilo.

[@miguelalzate4850]

Podría decirse entonces que Amazon Prime simplemente unió varios microservicios en uno solo y que en realidad no es un monolito?

[@diegof.6538]

Toda la descripción que hace del código (agregar funcionalidades o duplicación) es alrevés. Un monolito facilita agregar funcionalidades, es más difícil en los microservices. Y usar microservices no implica duplicación de código

[@djthdinsessions]

El video genial, pero mis oidos sangran cada vez que escucho "deployar" 🤣🤣