Dejo tambien el análisis de @BettaTech al mismo artículo para que acompañen este video! kzread.info/dash/bejne/hIR5r5SEqJiTeqg.html

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.

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 ?

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.

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).

¡Excelente explicación! Felicitaciones.

Muy buena la explicación, super clara 👍

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

Explicación impresionante!!!

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

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

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

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.

Excelente video pelado!.

Grande Pelado, siempre data interesante

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

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

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.

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

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 🤔😁😂

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.

Buen video macho!!

Brutal anàlisis de la notícia!

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! 👏🏽

buena explicación, te mamaste al final Pelado

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

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

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.

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.

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

5 ай бұрын

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

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

exelente video, un saludo.

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

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.

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

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

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

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é.

Se puede aplicar clean architecture a un monolito?

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

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á

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!

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

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.

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

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

Impresionante hairless!! 🚀

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

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

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

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

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

Muy bueno el easter egg del final a lo Marvel

Grande pelade

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

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.

Capo!

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...

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

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

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

Pelado, dónde compras tus remeras?

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.

Grande Manute

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.

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!!

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.

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

17:39 al estilo Marvel 😅

@LuisYairMirandaGonzalez

Жыл бұрын

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

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.

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.

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.

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.

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

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

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

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 💪😎

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

Ec2 auto vs EKS. Cual seria mas barato

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.

Jajajaja me encanto tu chiste de bash

Estas muy futbolero estos dias Pelado jajajajajaj

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.

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.

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

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

¿ Llevas un Reloj SEIKO SKX001 ?

@PeladoNerd

Жыл бұрын

Seiko SRPD65

Excelente ese final pela jajaj 🔴⚪🔴

#solid

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

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...

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.

Creo que es independiente el tamaño de la empresa con el tamaño de una aplicación. Si la aplicación es masiva es más aplicable microservicios. Hay empresas muy grandes que tienen todo onpremise donde el escalado no es infinito.

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.

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 ?

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....

Yo creo que esto abre un debate para empezar a saber cuando un microservicio se convierte en un monolito. Porque como se menciona, aunque en Prime Video lo que hicieron fue agregar los microservicios en un solo servicio y lo montaron en una instancia EC2. ¿Por que no podria seguir siendo considerado un microservicio?

river y el pelado nerd lo mas grande de argentina

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

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