Cuando alguien le pide a su equipo que granule los servicios de su dominio en microservicios, ¿su equipo no tiene opiniones diferentes y la toma de decisiones se vuelve más difícil?

¿No se siente usted mismo confundido? ¿Debería ser un servicio único o deberíamos dividirlo en dos o más microservicios?

¿Cómo resolver este dilema?

Según yo, podemos considerar los siguientes controladores para decidir sobre esto

Alcance del servicio

El alcance del servicio es lo más común que solemos considerar al dividir un servicio en otros más pequeños.

Teniendo en cuenta el dominio de las redes sociales, aquí tenemos múltiples alcances como clientes, medios, notificaciones y muchos más.

Según el alcance, podemos crear diferentes servicios para todos estos.

¿Pero crees que eso es suficiente?

Tamaño del componente

¿No crees que el tamaño del componente también importa?

¿Se puede hacer un solo servicio para los clientes? ¿Sería eso suficiente?

¿Un solo servicio podrá gestionar los gustos, comentarios, preferencias, perfiles, etc. de los clientes?

¿No crees que este servicio está haciendo mucho?

Una solución a esto es dividirlo en múltiples servicios.

Pero, ¿podemos dividir cada componente grande en componentes más pequeños sin comprender su cohesión?

Cohesión

El grado y la manera en que se interrelacionan las operaciones de un servicio en particular.

El servicio de notificación tiene múltiples formas de enviar la notificación por correo electrónico, mensaje, servicio postal y notificación automática. ¿Podemos dividir esto también en múltiples servicios?

En mi opinión, NO.

¿Por qué?

Porque tienen una cohesión relativamente fuerte: todos estos se relacionan con la notificación al cliente. Nosotros, como desarrolladores, estamos muy tentados a dividir los servicios en componentes más pequeños sin considerar el propósito detrás de ellos.

Escalabilidad

La escalabilidad es otro factor importante a tener en cuenta al separar los servicios. Por ejemplo

Considere el servicio de medios que tiene dos componentes, imagen y video. Con la creciente demanda de videos de 2 minutos, su escala aumenta a una velocidad mayor.

Si no separamos, la funcionalidad de la imagen debe escalarse innecesariamente para satisfacer la demanda de video, lo que afecta el costo y muchos otros factores. Romper esto permitiría escalar ambos de forma independiente para satisfacer su demanda.

Volatilidad del código

La velocidad a la que cambia el código fuente

La volatilidad del código también es un factor importante a considerar. Consideremos el componente del servicio de notificación postal, que es una funcionalidad poco utilizada, su tasa de cambio es mínima. Ahora, cualquier cambio en otro servicio de uso frecuente nos obligará a probar también la funcionalidad postal y su riesgo de implementación también aumenta.

Aquí dividir los componentes en dos componentes será un movimiento inteligente. Esto, a su vez, reducirá el riesgo de prueba e implementación y no se interrumpirán otras funcionalidades.

Estos son algunos factores que pueden ayudarnos a granularizar los servicios y me encantaría compartir algunos más con usted. Lo compartiré pronto en mi próxima publicación.

Puedes seguir y suscribirte para mantenerte actualizado. :)

Arquitectura de software: las partes difíciles

por Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani