¿Cuál es su opinión sobre el desarrollo de aplicaciones utilizando microservicios vs monolito?

¡Gracias por la solicitud!

Mi opinión es que son estilos arquitectónicos diferentes pero válidos. Depende de tus objetivos.

Si está desarrollando una aplicación muy simple para un objetivo muy bien restringido y definido, si no está destinado a vivir una vida muy larga (lo que significa que no se mantendrá por mucho tiempo o por equipos grandes) o si no está destinado a escalar a un gran proyecto, el monolito resolverá su problema sin problemas y no le dará demasiados problemas.

Optar por una arquitectura de microservicios significa facilitar la escalabilidad, el mantenimiento, el desacoplamiento y otras características en aplicaciones distribuidas bien estructuradas, pero tiene algunos costos. Aumenta la complejidad, la coordinación y la necesidad de orquestar muchas partes. Se necesitarán algunos componentes y tecnologías solo para permitir una arquitectura bien estructurada en microservicios. Buscarlo sin automatización e infraestructura como código, en mi opinión, es un suicidio.

Existe, por supuesto, la posibilidad de construir una aplicación de monolito muy bien estructurada que se pueda desacoplar en más de un monolito y, en algún momento, en microservicios. Puede hacerlo de acuerdo con las necesidades de escala (de complejidad e infraestructura). Al principio requerirá más trabajo y la necesidad de cierta complejidad adicional, pero puede valer la pena, ya que puede crear un arquetipo para futuras aplicaciones si no solo tira el código. Y la arquitectura se vuelve mucho más lista para la nube. Estoy usando este enfoque para mi proyecto actual. Cosas que pueden ayudar con eso: la aplicación Twelve-Factor, Home – Patrones de integración empresarial, Patrones de diseño y refactorización, Diseño impulsado por dominios, Un lenguaje de patrones para microservicios.

¡Atentamente!

El famoso científico informático Scott Shenker dijo una vez que hay dos fases para resolver cualquier problema: dominar la complejidad y extraer la simplicidad. Ambos requieren un conjunto de habilidades muy diferente. Él destaca esto al dar ejemplo del desarrollo de la red de Internet / computadora, cómo se dominó la complejidad anterior y se diseñaron varios protocolos complejos. Ahora, estamos en la fase de simplicidad de extracción y podemos sumergirnos en temas como la virtualización de redes, etc.

Creo que este enfoque es cierto para el desarrollo de cualquier sistema. Al hacer que las cosas funcionen, puede ser mejor crear un monolito y cuando hacer que las cosas sean más fáciles de trabajar puede ser aconsejable migrar a una arquitectura de microservicio. Sin hacer lo primero, uno podría tomar malas decisiones de diseño o optimizar en exceso.

Migramos desde un monolito de Java a servicios Micro basados ​​en Python en la compañía con la que trabajo. Nuestro arrepentimiento ha sido mínimo.

El mundo está cambiando todos los días, así que lo hacemos. Refaccionamos mucho todos los días y mejoramos la calidad del software, la responsabilidad del programa en función del contexto, la facilidad de mantenimiento para ser más fácil y la productividad mucho mejor.

El monolito se convierte en un punto único de falla y el mantenimiento será difícil día a día. Si usted es un proveedor de API y tiene una variedad de consumidores con diferentes puntos finales de API, es mejor tener una responsabilidad única para cada uno. Los microservicios te ayudarán en esto.

El consejo siempre es ir con Microservice y la adopción de Agile también sugerirá lo mismo.

Mi opinión se basa en un solo argumento:

“Cuando el bloqueo de la aplicación (y lo hará) es mejor tener impacto solo en los microservicios correlacionados que todo el monolítico, por ejemplo: (base de datos alta, consumo de grupo de subprocesos, memoria, CPU, lo que sea)”

Para mí es razón suficiente para no usar monolíticos.