La gente que no entiende microservicios los implementa mal, en lugar de solucionar problemas crea nuevos, por eso muchos terminan odiandolo. No es para todos, si no los entiendes no los utilices.

Creo que tienes una idea vaga del problema de ms, es decir, ves el problema pero no sabes que lo causa. Ahora, antes de la mitad de tu vídeo no expusiste nada del problema del título de tu vídeo. Es una pérdida de tiempo, y bueno ya que perdí el tiempo aquí mi comentario, solo agrego, no se va a volver a monolítico hermano, creas monstruos insostenibles también. Solo te doy un único punto, cuando dices que se está llevando los ms al extremo, y ya!

no creo que el problema sea si es monolítico u orientado a servicios, creo que el tema es de como organizar una arquitectura de soluciones

Lo siento pero la filosofía de monolito ya no encaja a día de hoy, ya que toda App que desarrolles dentro de una organización se alimenta de servicios con los que tiene que integrar que están absolutamente desperdigados dentro y fuera de la organización. A día de hoy ya no se concibe ningún desarrollo sin la obligatoriedad de integrar, a no ser claro que sea para una pequeña PIME. Luego en cuanto al coste excesivo o el inflamiento de los distintos perfiles dentro de un equipo, eso ya es por todas las metodologías que todas las organizaciones aplican de obligado cumplimiento. Es muy difícil escapar de ese encorsetamiento a día de hoy, pero bueno, es lo que nos da de comer.

Muchas empresas comenzaron a utilizar microservicios por subirse al hype, sin entender que la idea de los microservicios es que distintas secciones del negocio puedan crecer y caerse sin afectar a otras, en su lugar solo separaron la lógica en distintos servicios, pero todos dependen entre todos, haciendo inútil la separación, gastando más en infra y complicando el mantenimiento

Realmente es siempre lo mismo. Hay que vender una nueva tecnología que hace lo mismo que la anterior para mantener vivo el mercado. Primero fue CORBA, luego SOAP, RMI, EJBs, REST, ahora los microservicios, ... Todas tecnologías que básicamente acaban haciendo lo mismo (arquitecturas distribuídas) pero cada diez años se convierten en obsoletas. Antes hacíamos un proyecto entre cuatro y ahora tenemos que ser cuarenta porque está que tener Devops, sistemas, desarrollo, arquitectura, ... Con los microservicios yo siempre digo lo mismo: el nombre es engañoso. Micro en este entorno no significa "diminuto". Es como los "Microcomputadores" de hace años, que ocupaban una habitación. Los microservicios tienen que ser amplio espectro, pero la gente insiste en crear microservicios para el mantenimiento de una tabla de la base de datos.

Totalmente de acuerdo,los microservicios son útiles más que todo para sistemas que sean de consumo masivo(estilo Netflix).

soy devops y me he encontrado con mucha sobreingenieria en muchos proyectos, muchas veces se toma libro de microservicios y se intenta aplicar todo y se terminan complicando demasiado.. saludos antonio que vuelvan los podscast de full stack

Lo malo de que todo mundo tenga acceso a un micrófono en redes sociales/internet es que cualquier hijo de vecino puede generar una opinión tan corta como su experiencia

Un microservicio tiene muchas ventajas, muchas de las cuales ya has mencionado. En el entorno que estoy desarrollando, la mayor ventaja respecto del monolito de cara al desarrollador es que puedes subir a producción una parte del sistema y no como antes que era necesario subir a producción el monolito entero. Esto en otro tipo de entornos puede no ser la gran cosa, pero en el nuestro es algo primordial, ya que provocaba que solamente pudieras modificar algo una vez al mes y el proceso desde que lo modificas hasta que sube a producción era insufrible y interminable. Como desventaja más importante para el propietario del producto, efectivamente son los costes de desarrollo, pero también hay que decir que, al menos en nuestro caso, el coste por unidad de procesamiento ha bajado mucho. De todas formas, los microservicios están pensados para aplicaciones altamente escalables, para sistemas de pequeño tamaño no tiene sentido usarlos.

Excelente video! coincido plenamente! Trabajo como programador desde 2004 y en los ultimos años solo programo mis propias apps. Vi tanto caos, en los equipos que integre, que decidi vivir unicamente de mis propias fuentes de ingresos. No solo el problema esta en el exceso de microservicios sino en el exceso de herramientas a usar y mil formas intrincadas de producir que lo unico que hacen es disminuir el tiempo productivo y la capacidad de dar respuestas eficientes.

¡Al fin alguien serio por Dios que dice las cosas como son! Pensé que era el único, jaja... Puro marketing de software. Hoy en día, las empresas usan lo que está de moda, ni se preguntan si realmente en su contexto aplica. Y sí, tal cual, me ha tocado ver aplicaciones que son un simple CRUD y un login con 4 y 5 microservicios xD...

Muy interesante tu enfoque, gracias por el video.

Hay varias cosillas que hay que señalar. Una arquitectura de microservicios tiene un propósito. La escalabilidad. Si en vuestros desarrollos no os encontráis con problemas de escalado o de aumento exponencial de los recursos que necesita un monolito para dar servicio a más y más usuarios entonces es que no se hicieron los deberes. La escalabilidad de un servicio de "tres o cuatro" pantallas, por ejemplo, porq es el servicio más demandado, es muucho más barato que escalar N funcionalidades que no demandan tantos recursos, pero al estar en monolito tienes que escalar el conjunto. Tarea que en cloud se vuelve imposible de asumir por ejemplo.

Buen video amigo, yo no tengo mucha experiencia, hace casi 3 años que comencé a trabajar.. pero estoy a cargo de un equipo y me tocó diseñar un servicio y la mejor decisión fue hacer un monolito modular, aislando lo mejor posible cada módulo.. y si en el futuro se necesita, se puede transformar fácilmente esos módulos en microservicios

Lindo video, realmente es importante conocer que soluciona la arquitectura de microservicios. Hay un principio que creo que todo proyecto nuevo debe aplicar que es el "Monolith First" y luego con las metricas que se obtengan ver que parte del sistema se pueden separar para tener una escalabilidad eficiente. Si aplicamos los principios SOLID facilita mucho extraer ese fragmento del sistema que requiera ser separado en microservicios.

Monolito con modulos es casi igual que microservicios. Lo mismo que usted comenta tambien Robert C. Martin lo ha comentado en su libro Clean architecture, osea una pantalla o un pequeño cambio e una tabla de base de datos, empieza a involicrar muchos micros servicios y mucha gente y se vuelve mas dependiente

Llevo 17 años programando, y lo que ocurre es que al plantear un proyecto la gente crea infraestructura como una empresa de éxito, es decir, crear infraestructura como si fuera a recibir millones de solicitudes por minuto, y a menudo ves que ni se acercan a sacar partido de lo planificado. En la vida real, los microservicios no dejan de ser dividir una app, pero una cosa es dividir algunas funcionalidades importantes y otra es que una app sean ciento y pico servicios que a veces son mini funcionalidades. Así le va a las empresas.

Me ha tocado dirigir equipos de alrededor de 100 desarrolladores y ser quien dicte las reglas de como DEBERÍAN SER los microservicios en algunas ocasiones… creo que tienes mucha razón pero la realidad es que me parece qué hay que sepáralo en sus bemoles:

Excelente reflexión. En mi día a día me consigo con este tema cuando estoy haciendo diseño de aplicaciones. Es importante no hacer sobre ingeniería y tratar de mantenerlo simple; no siempre es simple conseguir el equilibrio pero es parte del desafío. Gracias por el video.