Bueno, cuando la complejidad no es trivial, es mejor dividir la solución en componentes, ¿verdad?
Ahora, hay diferentes niveles de ” complejidad ” relevante: complejidad funcional pura, complejidad de escala (principalmente rendimiento, pero también espacio, a veces) que requieren distribución.
Tenga en cuenta que la complejidad funcional no necesariamente significa flujos complicados; También incluyo múltiples flujos simples (por ejemplo, procesamiento y distribución de resumen de correo electrónico, además de otros flujos que pasan por el sistema, tareas de limpieza y muchos otros).
- ¿Qué es la tecnología en la nube?
- ¿Qué define un servicio en la nube?
- ¿Qué es la selección de instancia?
- ¿Debo crear una aplicación móvil en tiempo real con Firebase, con mi propio servidor o con ambos?
- ¿Cuáles serían los principales pasos y análisis necesarios para migrar aplicaciones de un sistema heredado (Mainframe) a la nube?
Entonces, las preguntas son:
- Cómo lo desglosamos en componentes distribuibles. Eso significa, qué infraestructura se utiliza como tiempo de ejecución del componente, cómo se comunican, etc.
- Qué componentes estarían allí y, en consecuencia, qué tan grande sería cada componente.
Entonces, creo que puede deducir que hay muchas soluciones que no se beneficiarán de MS-s, porque son demasiado triviales (a menos que use una infraestructura muy ligera para MS-s que no complique nada, como me gusta usar) y hay muchos que se benefician enormemente de él:
- El software como servicio y sus hermanos (PaS, etc.) seguramente son candidatos
- Todas las aplicaciones empresariales no triviales
- Servidores de juegos
- Aplicaciones que realizan muchos flujos, programados y / o en paralelo.
- Y muchos muchos mas.
