Al desarrollar un sistema por mí mismo, ¿debo usar microservicios?

Estoy comenzando un nuevo proyecto en el trabajo, y probablemente sea casi el único desarrollador del proyecto, aunque uno o dos desarrolladores más necesitarán integrar aplicaciones existentes o scripts simples en el proyecto principal. El proyecto debe manejar la ingesta / procesamiento de datos a granel y de transmisión a pequeña escala, y la ejecución de código a pedido y controlado por eventos. Algunas partes del marco estarán fuertemente vinculadas a la CPU, y algunas partes podrían estar fuertemente vinculadas a E / S; la mayoría de los datos deben vivir en una sola máquina, pero podemos crear un clúster y conectar máquinas virtuales para aumentar la potencia de cómputo disponible. Probablemente habrá una o más aplicaciones web pequeñas que dependan de los servicios proporcionados por este marco central. El lenguaje principal será Python para casi todo.

Mi pregunta es si debería o no adoptar un enfoque de microservicios para un esfuerzo como este o seguir con una aplicación monolítica, dado que haré la mayor parte del desarrollo por mí mismo. Mi opinión es que los microservicios (usando Nameko) proporcionan una separación natural entre los elementos del marco que tienen diferentes modelos de ejecución (canalizaciones de datos, lanzamiento de eventos, bajo demanda, aplicaciones web, etc.) y una forma clara de distribuir la carga de trabajo y comunicación a través de múltiples procesos. Mi preocupación es que probablemente terminaría con un clúster de Kubernetes para administrar (estoy familiarizado con Docker, pero todavía bastante nuevo en Kubernetes), se requieren múltiples servicios (rabbitmq, redis, etc.) solo para facilitar la ejecución del sistema, y potencialmente una gran cantidad de pequeños trozos de código para implementar realmente todas las capacidades necesarias que '

Para un proyecto con poco más que un único desarrollador, ¿los microservicios aún simplifican el desarrollo y el mantenimiento de un sistema complicado como este? ¿Hay métodos / sistemas / marcos que debería considerar usar en su lugar, o para reducir la sobrecarga involucrada en el diseño del sistema de esta manera?

Los microservicios generalmente no son deseables porque convierten su software en un sistema distribuido, y los sistemas distribuidos hacen que todo sea mucho más difícil. Pero una arquitectura orientada a servicios tiene algunos beneficios importantes:

• diferentes equipos pueden ser desarrollados e implementados independientemente por diferentes equipos
• diferentes servicios pueden escalarse independientemente

Como será el único desarrollador, no necesita la flexibilidad para desarrollar los servicios de forma independiente.

Pero observa que algunas partes pueden estar vinculadas a la CPU. Por lo tanto, podría ser deseable escalarlos independientemente del resto de la aplicación. Si ese es el caso, eso no significa que tenga que convertir todo el proyecto en una arquitectura de microservicios. Solo necesita mover esa parte de uso intensivo de la CPU a su propio servicio, y puede mantener el resto en un monolito conveniente. En qué líneas se debe dividir el sistema es difícil de determinar, pero en general la idea DDD de "contextos limitados" es una buena guía.

Tenga en cuenta que los monolitos no son malos. Los monolitos no equivalen a un gran proyecto desordenado e imposible de mantener. Donde podría dividir el sistema en diferentes microservicios, también puede dividir el sistema en diferentes componentes dentro de un monolito. La separación entre estos componentes es más visible y se aplica con mayor claridad en una arquitectura orientada a servicios. Esto también significa que para un sistema bien diseñado, debería ser bastante fácil convertir un componente en un servicio en algún momento posterior. Por lo tanto, no tiene que decidir en este momento, puede pasar a microservicios si un monolito ha demostrado ser inadecuado.

Considere también el concepto de Martin Fowler de Microservice Premium (2015): los microservicios introducen una complejidad sustancial propia, además de la complejidad base de su sistema. Debe pagar esta "prima" en términos de productividad reducida. Esto significa que para proyectos simples, los microservicios lo hacen menos productivo. Esto cambia para proyectos más complejos: mientras que una solución monolítica puede ser cada vez más difícil de trabajar, una arquitectura de microservicio se escala mucho mejor y requiere un esfuerzo constante constante. Debe saber si el esfuerzo inicial adicional de los microservicios vale la pena dado su sistema de software. Como está haciendo esta pregunta, la respuesta es probablemente "no". Fowler continúa:

Por lo tanto, mi directriz principal sería ni siquiera considerar microservicios a menos que tenga un sistema que sea demasiado complejo para administrar como un monolito. La mayoría de los sistemas de software deben construirse como una sola aplicación monolítica. Preste atención a la buena modularidad dentro de ese monolito, pero no intente separarlo en servicios separados.