MONOLITOS VS MICROSERVICIOS en 10 MINUTOS

Exploramos los aspectos prácticos del desarrollo de software al implementar arquitecturas monolíticas y de microservicios, examinando cómo estas decisiones afectan la escalabilidad, la flexibilidad y el mantenimiento a largo plazo, entre otros...

Este video esta basado en una investigacion presentada en JAIIO 53 2024

Link a la investigacion:

Bibliografia
1. Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice. 3rd edn. Addison-Wesley Professional, United States of America (2012).
2. K. Gos and W. Zabierowski, "The Comparison of Microservice and Monolithic Architecture," 2020 IEEE XVIth International Conference on the Perspective Technologies and Methods in MEMS Design (MEMSTECH), Lviv, Ukraine, 2020, pp. 150-153
3. Ford, N., Richards, M., Sadalage, P., Dehghani, Z.: Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures. O'Reilly Media, United States of America (2021)
4. Newman, S.: Monolith to Microservices. O’Reilly Media, Inc., United States of America (2020).
5. Richardson, C.: Microservices Patterns: With examples in Java. Manning Publications, United States of America (2018).
6. M. Mosleh, K. Dalili and B. Heydari, "Distributed or Monolithic? A Computational Architecture Decision Framework," in IEEE Systems Journal, vol. 12, no. 1, pp. 125-136, 2018
7. Taibi, D., Lenarduzzi, V., Pahl, C., & Janes, A. (2017, May). Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages. In Proceedings of the XP2017 Scientific Workshops (pp. 1-5).
8. Martha, V. S., & Lenglart, M. Webservices engineering. Webservices: Theory and Practice, (2019)., pp. 173-196.
9. P. Jamshidi, C. Pahl, N. C. Mendonça, J. Lewis and S. Tilkov, "Microservices: The Journey So Far and Challenges Ahead," in IEEE Software, vol. 35, no. 3, pp. 24-35, 2018.
10. J. Jung, "Randy Shoup on Evolving Architecture and Organization at eBay," in IEEE Software, vol. 40, no. 1, pp. 98-100, 2023
12. Blinowski, G., Ojdowska, A., & Przybyłek, A. (2022). Monolithic vs. microservice architecture: A performance and scalability evaluation. IEEE Access, 10, 20357-20374.

TAGS
Arquitecturas monolíticas, arquitecturas de microservicios, desarrollo de software, implementación práctica, escalabilidad, mantenimiento a largo plazo, análisis comparativo, casos de estudio, empresas líderes, Walmart, Amazon, eBay, Prime Video, simplicidad, complejidad, modularidad, flexibilidad, agilidad, innovación, eficiencia, experiencia del usuario, integración, comunicación, desacoplamiento, cohesión, actualización, despliegue, gestión de recursos, equipos de desarrollo, planificación, diseño de interfaces, escalado horizontal, escalado vertical, adaptabilidad, independencia, autonomía, coordinación, ciclo de vida, monitoreo, modularidad, errores, recuperación, implementación continua, mejoras, introducción de características, crecimiento empresarial, demandas del mercado, experiencia del cliente, costos operativos, desarrollo incremental, rapidez, calidad del software, optimización, eficacia, tecnología, estrategias empresariales, lecciones aprendidas, mejores prácticas, tendencias tecnológicas, evolución del desarrollo de software, decisiones informadas, análisis de casos, sistemas de software, programación, APIs, protocolos de comunicación, herramientas de desarrollo, eficacia operativa, rendimiento del sistema, flexibilidad organizativa, requisitos del negocio, eficacia del equipo, gestión de proyectos, colaboración, ciclo de lanzamiento, integración continua, pruebas, innovación tecnológica, soluciones empresariales, adaptación al cambio, optimización de recursos, desarrollo ágil, eficiencia operativa, satisfacción del cliente, liderazgo tecnológico, buenas prácticas, sistemas distribuidos, optimización del tiempo, administración de la complejidad, toma de decisiones, análisis de riesgos, mejora continua.

[aldopestoy]

Antes que nada, muy bueno el video, el resumen de la "visión" actual que se tiene de estas plataformas es muy acertado. Pero según mi humilde opinión, creo q la visión es la que está desenfocada (no la tuya sino en general):
1) Primero y principal, como decis en el 8:40'' "depende de las necesidades de específicas de cada proyecto". Eso deja afuera cualquier duda. Ahora si los ingenieros del proyecto no son capaces de discernir el mejor camino, no depende de las opciones sino de los ingenieros.
2) La mayoría de las veces, se tiene una "visión" contrapuestas de estas arquitecturas y no es así. Podes tener un mayorista de artículos de limpieza con un sistema monolítico y dos o tres servicios para recibir ordenes de pedido, como una cooperativa de energía eléctrica con un sistema de servicios, replicaciones, etc., pero su core ser monolítico debido a su verticalidad y centralidad (por ejemplo).
3) Estoy de acuerdo con que las empresas grandes es muy probable que tengan una arquitectura basada en servicios, pero cual sistema? porque sabes bien que una empresa grande no tiene un solo sistema, tiene sistemas por aquí, por allá, programitas, programas, algunos en camino de actualización, implementaciones fallidas.. etc.. Por otro lado una empresa grande puede tener en su staff programadores de cada lenguaje y plataforma que sale y está de moda, sin mencionar toda la plantilla de personal que requiere un proyecto en arq. de servicios (de solo pensar me duele el bolsillo). Por otro lado una empresa grande, se puede dar el lujo de tener 3 meses a un analista aprendiendo el negocio de la empresa. De todos modos, ¿todo vale y se justifica en pos de la arquitectura del sistema? (espero que como gerente de sistemas tengas un buen powerpoint para la reunión de noviembre).
4) También es cierto que una empresa chica le conviene una monolítica, pero no por la arquitectura.. te imaginaras que al gerente de un corralón de 2 sucursales no le importa la "arquitectura del sistema", sino porque no quiere tener después una subempresa de software metida en su nómina de empleados.
En resumen, según mi humilde punto de vista y después de trabajar mas de 30 años en la industria del software.. lo mas importante es conocer a tu cliente (que necesita ahora y dentro de 7 años), dibujar mucho antes tocar el teclado (y mucho mas), y pensar en lo mejor para tu cliente no para mi "comodidad" coyuntural.
Se me fue al carajo el comentario, pero me agarraste con ganas de escribir porque terminé de ver el ultimo cap de Shögun.