Microservicios: MonolithFirst?

He estado investigando arquitecturas de microservicios tratando de obtener una visión general de alto nivel de todos los pros y los contras, cuándo y por qué, etc. Gran parte de la información que estoy leyendo / viendo proviene de ThoughtWorks (Martin Fowler, Neal Ford, et al. Alabama).

La mayor parte del trabajo de Martin Fowler sobre el tema tiene unos pocos años, cuando Microservicios (como un nombre familiar en programación, si no en la práctica general) todavía era joven, por lo que tomo gran parte con un grano de sal.

Una cosa en particular es esta:

Cuando escucho historias sobre equipos que utilizan una arquitectura de microservicios, noté un patrón común.

• Casi todas las historias exitosas de microservicios han comenzado con un monolito que se hizo demasiado grande y se rompió
• Casi todos los casos en los que escuché de un sistema que fue construido como un sistema de microservicio desde cero, terminó en serios problemas.

Este patrón ha llevado a muchos de mis colegas a argumentar que no debe comenzar un nuevo proyecto con microservicios, incluso si está seguro de que su aplicación será lo suficientemente grande como para que valga la pena. .

(ref: https://martinfowler.com/bliki/MonolithFirst.html - énfasis en el suyo)

Ahora, 3 años más tarde y con microservicios, un término más omnipresente, es generalmente aceptable que un nuevo sistema sea mejor servido al tener trozos de servicio más grandes (que un microservicio pero más pequeños que el monolito) para comenzar, y hacer ¿Son más granulares como parte de una medida evolutiva?

O, ¿existe una norma para comenzar un proyecto desde cero con una arquitectura de microservicio granular, en contraste con las declaraciones anteriores?

Parece un enfoque general sensato, pero curioso de los pensamientos de la comunidad.

Si su empresa ha estado haciendo microservicios durante un tiempo, es posible que algunas piezas ya estén construidas y simplemente necesite incorporarlas. Ejemplos probables pueden ser la autenticación como servicio o el almacenamiento de datos de blob. En ese caso, ya ha definido los límites y está reutilizando el código en una nueva aplicación. Eso es bueno.

Para el nuevo código donde no está seguro de dónde debe estar el límite, constrúyalo en un servicio. Si lo mantiene modular, puede separar microservicios de él según sea necesario. Particularmente a medida que encuentra piezas de su servicio que necesitan escalar de manera diferente al resto.

El beneficio de los microservicios es que puede agregar instancias para escalar el trabajo que se realiza bajo demanda. Si parte de su trabajo llega en ráfagas, podría tener sentido separarlo en su propio microservicio.

En general:

• Si ya tiene microservicios integrados, reutilícelos
• Si está construyendo algo nuevo, haga que la idea funcione primero
• Mientras construye, trate de mantener las cosas modulares para que algunos servicios se puedan dividir fácilmente
• A medida que construye, si parte de su servicio necesita poder escalar a demanda a una tasa diferente, sepárelo en su propio servicio

Con demasiada frecuencia, escuchamos pautas útiles de personas inteligentes con buena reputación como Martin Fowler, y luego lo convertimos en una doctrina dura de la que no se puede escapar de ninguna manera.

Tienes que tomar declaraciones como esa en el espíritu de cómo se entiende. Martin Fowler está tratando de salvar a las personas de la parálisis mediante análisis y les dice que construyan algo que funcione primero. Siempre puede separarlo más adelante, cuando sepa más sobre cómo funciona realmente su aplicación.

Los beneficios más inmediatos y valiosos de los microservicios se pueden lograr mediante una simple modularización de código. Puede aislar grupos de características en módulos utilizando cualquier sistema de módulos que tenga (maven, npm, nuget, lo que sea). Cada módulo puede cumplir un único propósito, sentar su propio repositorio, usar su propio esquema de base de datos, administrar su propia configuración, tener su propio registro de funciones y calendario de lanzamiento. Todavía se pueden desplegar juntos en un monolito. Esta es una cantidad de gastos generales muy manejable y ofrece algunos buenos beneficios. La mayor sobrecarga proviene de la separación de las implementaciones, que solo es realmente valiosa una vez que tiene la escala suficiente para necesitarla. Si su código ya es modular, será una migración más fácil cuando llegue el momento.

En mi opinión, puede ser beneficioso desarrollar primero un monolito (o mejor: desarrollar partes de su aplicación como monolito).

Hay casos en los que no está seguro sobre el dominio y los límites de su problema (por ejemplo, construyo un sitio de administración de barcos, ¿necesito un servicio de envío Y un servicio de flota, o es suficiente un servicio de envío?), Y en tales casos un El monolito puede ser más fácil de desarrollar.

Debe dejar de hacer esto si necesita incorporar diferentes tecnologías a la mezcla (por ejemplo, sus partes existentes están escritas en C #, pero su nuevo problema requiere aprendizaje automático, es mejor hacerlo con Python), tenga una buena comprensión de los dominios en su proyecto o su monolito intenta galvanizar, por ejemplo, todos simplemente construyen este monolito y aplastan la noción de servicios separados.

Estoy bastante seguro de que ha habido un par de preguntas sobre este artículo exacto de MF.

Mi opinión sobre esto es esta:

Un monolito con problemas de mantenimiento o escalabilidad se mejora al descomponerlo en microservicios. Tal proyecto casi siempre será 'exitoso', ya que incluso desglosar una pequeña sección puede generar ganancias medibles y puede trazar una línea debajo de él cuando esté contento.

Ya sea que su + una cola de mensajes monolito medio y un par de procesos de trabajo cuenta como 'Microservice Arquitectura' es un argumento a tener en el pub, pero que sin duda se llama que cuando se habla del proyecto.

Por otro lado, cualquier proyecto nuevo, independientemente de la arquitectura elegida, corre el riesgo de no cumplir con las expectativas, por lo que, naturalmente, esperaría una tasa de éxito más baja. Además, si ha comenzado con el objetivo de hacer toda la 'Arquitectura de microservicios de mejores prácticas' desde cero, entonces puede aventurarse en nuevas tecnologías y los trozos más difíciles de microservicios.

También tenemos que recordar que MF escribe desde una gran perspectiva OOP. Él es naturalmente escéptico de un enfoque distribuido más moderno.

En la actualidad, esperaría que cualquier solución de gran negocio incorpore un elemento de microservicios y solo un tonto recomendaría que haga una aplicación de monolito gigante a menos que esté distribuyendo una sola aplicación de estilo de escritorio.

En mi (vasta) experiencia, he sido testigo del fracaso de muchos más proyectos debido a problemas de personas que a problemas tecnológicos. Desafortunadamente, a las personas no les gusta fracasar y, por lo tanto, tienden a informar erróneamente los motivos del fracaso y culpan a la tecnología.

En mi dominio, finanzas, la mayoría de los proyectos nuevos siguen arquitecturas de microservicios en estos días, y parece ser una arquitectura ganadora desde una perspectiva de TCO (costo total de propiedad). Estos proyectos no parecen estar fallando tan a menudo, y cuando lo hacen, las razones dadas a menudo no mencionan la arquitectura de la aplicación como el problema.