Gracias al GSAS tuve la oportunidad de asistir al taller “Architecture, the hard parts” impartido por Mark Richards. Para los que no lo conozcan, Mark es un arquitecto de software especializado en Service-Oriented Architectures. Fue uno de los mejores talleres a los que he tenido el placer de asistir en arquitectura de software. 

En este taller Mark nos muestra las diferencias entre los diferentes tipos de arquitectura monolito y distribuida. Nos proporciona amplios ejemplos basados en casos reales de cuándo implementar cada una de ellas y las posibles soluciones a los tradeoff.

No existe la arquitectura perfecta para un proyecto, dependiendo de las necesidades de tu negocio se adaptará mejor una u otra. Hoy me gustaría hablar sobre la arquitectura basada en servicios.

Service-based Architecture

Una Arquitectura Basada en Servicios es una arquitectura que se define como pragmática y distribuida, un punto intermedio entre una Arquitectura Monolito y una Arquitectura de Microservicios. 

En comparación con las arquitecturas totalmente distribuidas consta de varios puntos diferenciadores en los que cabe destacar la granularidad de los servicios y el scope de la base de datos.

A diferencia de los microservicios los componentes son más flexibles y menos atómicos. Esto permite realizar operaciones de negocio más complejas y mejorar los problemas de orquestación y transacción al agrupar varios módulos.

La base de datos es un recurso compartido, lo que mejora la performance porque reducimos las llamadas a otros servicios para acceder a los datos.

En contrapartida, refactorizar una base de datos entera puede que no sea posible. Los cambios en una tabla son un poco más difíciles al crearse un acoplamiento al esquema de datos.

Además, los servicios no serán tan atómicos convirtiéndolos en algo más difíciles de desarrollar y testear. Lanzar una nueva versión requiere más planificación.

Sin embargo, si la comparamos con una arquitectura monolito obtendremos ventajas significativas como es el desacoplamiento entre módulos, un mejor control sobre el desarrollo, estabilidad y escalabilidad. Permitiendo así ganar el time to market.

En definitiva, obtendremos una arquitectura robusta, fácil de entender, bien organizada con componentes que se pueden recomponer, adaptar y escalar de manera independiente.

Adoptando Arquitectura Service-based

Para adoptar la arquitectura basada en servicios no basta con dividir la aplicación en pequeños componentes. Una arquitectura modularizada en partes muy grandes puede generar problemas de orquestación e interdependencia entre servicios, sin embargo una muy granulada en componentes pequeños puede generar problemas transaccionales. 

Hay muchas maneras para migrar la arquitectura, pero una manera básica sería de la siguiente forma: 

– Cambiar la estructura de paquetes de capas técnicas en capas de dominio de nuestro monolito. Para este caso podemos hacer uso de los patrones de DDD como puede ser Aggregate o Bounded context. De esta forma no solo dividimos la estructura sino que reducimos el coste del cambio.

– Identificar los contextos de nuestra aplicación

– Agrupar los paquetes de dominio en componentes mediante:

• • Business functionality groupings: Como su nombre indica, sería agrupar componentes por funcionalidades de la aplicación. 
  • Transactional boundaries: Una forma de identificar los transactional boundaries es si cada vez en una request tenemos que actualizar dos componentes: el ítem y el inventario (account y customer), quizás deberíamos unir esos componentes. 
  • Deployment goals: En ciertas circunstancias nos encontramos que un componente cambia constantemente y el resto de la aplicación no. Esto es un indicativo que deberíamos extraer ese componente como una unidad deployable.
  • Scalability needs: A veces necesitamos mejorar la performance de un componente o un caso de uso específico.  

  Iterando estos pasos, lo que implica desacoplar todo lo que podamos y tener en cuenta que a mayor distribución y granularidad aumenta la complejidad, podemos conseguir la arquitectura adecuada.

  Y como Mark Richards dijo: “Embrace modularity, but be cautious of granularity.”

  Echa un vistazo a los testimonios del Workshop de arquitectura de software: