¿De verdad son necesarios los microservicios?

Veamos que está pasando con los microservicios. ¿Es necesario extender la arquitectura de microservicios hasta donde está llegando? ¿Deberíamos volver a arquitecturas monolíticas? Sobre estas y algunas preguntas más vamos a hablar en este video.

Si quieres tener un gran hosting para tu web con servicio en España 24/7 y con centro de datos en España aquí te dejo una gran recomendación, la empresa Loading, además, no olvides usar el código 10%ANTONIOPEREZ para conseguir un 10% de descuento al contratar con ellos!

Si queréis ampliar la información de este video he publicado otro en el que comento algunas alternativas de arquitectura de proyectos, así como algunos consejos para elegir la arquitectura:

Vídeo en el que hablo de crear apps con IA que menciono en el video:
¿Quieres programar apps con IA?

[josejaner]

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

[yas-code]

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

[marcelo]

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.
Hice de todo para optimizar mi forma de desarrollo.. desde crear mi ORM hasta mi propio framework con un lenguaje basado en XML. Siempre escuche el tipico consejo de reinventar la rueda es malo, pero hoy en dia mi productividad es mucho mas alta gracias a eso.

[sfernandez]

Muy interesante tu enfoque, gracias por el video.
El surgimiento de Docker y la tecnología de containers fue decisiva para el nacimiento de los microservicios; marcó un punto de inflexión, simplificando la división de aplicaciones en contenedores y facilitando los despliegues. Recuerdas cuando había que configurar una VM o aprovisionarla para desplegar nuevo la app, la DB, etc...
Los microservicios surgen como una forma de bajar el acoplamiento: cuando los desarrolladores toman cualquier decisión en un monolito logrando que el código sea una gigante bola inmantenible, los costos de cualquier cambio, o de un nuevo feature, empiezan a subir.
La clave de usar microservicios es que sean independientemente desplegables y reducir el acoplamiento todo lo posible. Microservicios bien usados permiten bajar el time-to-market ya que una nueva funcionalidad en un nuevo microservicio no se mete (en gral) en el resto del código de la app.
Muchas veces esto no se logra, se termina creando un monolito distribuido y las ineficiencias y costos se van a las nubes, como bien señalas.
Creo que es clave lograr un equilibrio en un punto medio. Considerar trabajar en múltiples repos Git y muy estricto versionado y gestión de depencias, que luego se pueden ensamblar en pocos servicios.
No es necesario implementar microservicios para hacer aplicaciones modulares.
Coincido en que los skills fullstack serán más valorados al igual que los devs que se esfuercen por encontrar soluciones eficientes.
Ej: hoy Vercel permite montar apps con SSR programando sólo Typescript en front+back, con backend services, integración y despliegue continuos directo desde Github, una maravilla.
También RoR como mencionas, es enormemente productivo.
HTMX también es muy interesante. En mi caso estoy experimentando este stack: Go, HTMX, TailwindCSS+DaisyUI, AlpineJS. Resultado: una imagen docker de 10 MB con una aplicación completa y tremendamente performante gracias a Go.

[darnack]

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.

[Iron_cryptus]

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.

[saulogarcia]

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

[carlosmollapaza]

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

[oscargalvez]

Yo no tengo experiencia en microservicios, pero en el proyecto de mi empresa (que por ahora llevo yo solo), tengo muy claro que cuando se haga alguna separación de algún módulo o bounded context, los beneficios tienen que superar a los inconvenientes. Además de que intentaré de que ese servicio que se cree sea lo suficientemente independiente como para que la interacción con el resto del proyecto sea mínima.

Yo creo que el problema es que cuando piensas en microservicios, tienes la sensación de que es una buenísima idea para cualquier situación. Lo ves perfecto porque dices "mira, proyectos pequeños independientes, todo más controlado". Pero luego, te paras a pensar en los problemas de verdad, como la comunicación entre ellos o la infraestructura que tienes que montar... y te das cuenta que es un problemón incluso para las cosas más simples.

Tiene su mercado, por supuesto, pero es lo que tú dices, nos hemos pasado tres pueblos y ahora estamos sufriendo las consecuencias de no pararnos a ponerlo en una balanza a ver si compensa o no.

[luvhines]

Entiendo perfectamente el punto compañero, después de superar el código espagueti, llegamos a la infraestructura espagueti.

[LeotheProdu]

yo tengo muy pocos años de ser desarrollador, actualmente yo solito me hago una aplicación enorme, claro el costo de mi tiempo y vida ha sido enorme, pero si yo formara una empresa con otro como yo, creo que podriamos hacer aplicaciones, increíbles jaja... vieras que a estas alturas nunca pude conseguir trabajo, asi que me decidí a crear aplicaciones que solucionen ciertos problemas a negocios locales, y para este año, estimo poder vivir de esto totalmente

[alexismorison]

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

[alejandrokennedy]

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.

El mantenimiento del codigo ya pasa a ser parte de la practica del Clean Code y implementacion de test automatizados por sobre todo.

[FernandoAgurto]

Que bueno que haya gente que entiende las soluciones de software de esta manera, por lo general es bueno cuestionarse si en realidad es necesario tomando mejor ser prácticos

[bcippitelli]

Muchas gracias por el video. Soy desarrollador y he ido notando esa moda por microservicios que muchas veces no analiza bien el impacto. Dividir, seguro, pero no solo por moda, sino por necesidad. Un equilibrio creo yo.

[decimodanlive]

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:
1) El desarrollo móvil lleva años en decadencia
2) hoy tenemos alternativas que antes no teníamos (k8s, WASM, Docker, etc.)
3) Hay un frenesí por pasarse al lenguaje nuevo vs seguir trabajando en el lenguaje de turno
4) Realmente muy pocas personas trabajamos antes de usar microservicios y entendemos que le DUELEN a los monolitos
5) Poco a poco está arquitectura empieza a tocar al front end (micro-front, SSR, etc)
6) Muchos desarrollos son microservicios para adaptarse al proceso establecido (pipelines, plantillas, etc)
7) el tema de practicidad vs costos

Sin fin, me gustaría poder debatir algunos puntos contigo 😅

[CristianAndresMarin]

Rappi tenia más de 1800 Servicios hace 2 años, según la entrevista del Pelado Nerd al equipo de Rappi, ahora deberá tener más de 2000 🥲

[RoberAce]

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.

[lmarts]

En mi caso, trabajando en una empresa que factura muchos millones al año, estamos usando un monolito. Pero ha llegado un punto en el cual ya nos hemos planteado el paso a microservicios, porque tenemos muchos lanzamientos con miles de peticiones por segundo, en previsión de los cuales se hace necesario realizar escalados horizontales de infra (AWS) muy muy costosos (para que nos entendamos, replicar el monolito, y replicar la mega base de datos conectada, en múltiples instancias cada uno).

Con microservicios en soluciones serverless en la nube, p.ej funciones lambda, nos olvidaríamos de los escalados y son servicios mucho más baratos. Aparte, creo que usar EDD ayuda a desacoplar cada pequeña parte de la aplicación, evitando que si se rompe un microservicio, dejen de funcionar los otros.

En definitiva creo, al menos en nuestro caso, y en cualquiera con picos de alta demanda, que un monolito es la peor solución.

RoR, Laravel, sí, son perfectos, pero para aplicaciones web con poca fluctuación de tráfico.

Si alguien se ha visto o está en esta misma situación y tiene una solución monolitica y de bajo coste que me explique cómo lo hace 😅

Un saludo!

[ricardovillalta]

Volvera los inicios de PHP cuando se construia un trozo de interfaz como un componente en el servidor y se recibia con ajax para pintarlo?
simpre lo hice asi pero pense que lo hacia mal😅, bueno lo hacia asi porque no tenia compañeros programadores