Vamos a ver una serie de posts en los que se desarrollará una arquitectura de microservicios aplicada a desarrollos para los productos de Atlassian Cloud. En concreto se hará uso del framework Atlassian Connect Spring Boot, pero se puede utilizar cualquier otro de Atlassian Connect.

Introducción

En este primer post se explicará la arquitectura que se desea plantear (centrándonos en los microservicios a desarrollar), para poco a poco, en sucesivos posts, ir introduciendo los diferentes componentes hasta llegar a tener una arquitectura completa.

Antes de nada, si no estáis relacionados con los conceptos de una arquitectura orientada a microservicios, tenéis un post muy bueno sobre ellos escrito por nuestro compañero Daniel Sánchez (Arquitectura de microservicios - Parte 1: Introducción)

¿Por qué utilizar los frameworks para construir add-ons Atlassian Connect?

La respuesta es simple e inmediata, simplifican y agilizan el desarrollo del código, nos proporcionan mucha auto configuración, permitiendo centrarnos en nuestro desarrollo de negocio; y en muchas ocasiones, elimininando muchos quebraderos de cabeza. Además, ante cualquier problema podemos obtener soporte de Atlassian.

Personalmente prefiero Atlassian Connect Spring Boot, pero podría utilizarse cualquier otro, o combinaciones de ellos.
Atlassian Connect Spring Boot nos aporta:

• Parte del descriptor del add-on (atlassian-connect.json) con soporte de configuración.
• Manejo automático de los eventos de instalación y desinstalación del ciclo de vida.
• Verificación del JWT (JSON Web Token) de las solicitudes entrantes.
• JWT para solicitudes salientes.
• Persistencia mediante Spring Data
• Conversión de parámetros de contexto a atributos del modelo Spring MVC.

Podeís ver un ejemplo de desarrollo con Atlassian Connect Spring Boot en el post de nuestro compañero Fernando LLaca (Desarrollo Spring Boot)

¿Qué microservicios necesitamos?

El primer punto a tener en cuenta es conocer en cuantos microservicios vamos a dividir la funcionalidad de nuestro negocio. Esto nos ayudará a realizar mejores estimaciones tanto de tiempo como de costes.

La funcionalidad de un microservicio debe ser pequeña e independiente del resto de microservicvios. Dicho de otra manera, deben cumplir el Principio SOLID

Supongamos un caso muy simple como el siguiente:

Un concesionario quiere modelar el proceso de venta de sus vehículos, y para esto han decidido usar JIRA Cloud donde tendrán tickets de tipo "Venta". El workflow para estos tickets puede ser algo parecido a esto:

En el momento de crear el ticket de venta, se necesita la información del vendedor que la realiza, y del cliente que hace la compra (datos personales, bancarios...) para poder continuar con el proceso de compra. Dicha información se encuentra en sistemas externos y se tienen que recuperar de forma automática.

Además, una vez que el pago se haya realizado, es necesario comunicar a un sistema de facturación externo, la realización del mismo.

Para este caso, una posible propuesta de microservicios de negocio podría ser la siguiente:

• Un microservicio para notificar la realización del pago.
• Otros dos para recuperar la información del vendedor y el cliente, respectivamente.
• Y un cuarto encargado de establecer las conexiones con los sistemas externos, que será usado por los demás microservicios.

¿Cómo realizamos nuestros microservicios para JIRA Cloud?

Incluir nueva funcionalidad en los productos Atlassian lleva consigo instalación de add-ons. Para nuestro ejemplo, una solución podría ser a través de post-funciones, que se ejecutan cuando un ticket pasa de un estado a otro. De forma que utilizaríamos los microservicios de consulta de empleado y cliente en la transición "Create"; y el microservicio de notificación de pago al aplicar la transición "Pagado".

Llegados a este punto, tenemos nuestra funcionalidad dividida en "microservicios" y la forma en la que los vamos a desarrollar para su uso en JIRA Cloud. Fijaos en la palabra "microservicios", porque si nos quedamos aquí, solo tendremos tres add-ons que añaden tres postfunciones a nuestro JIRA Cloud, y tendríamos que instalar los tres para hacer uso de su funcionalidad, y esto no es lo que queremos. Nosotros estamos buscando la instalación de un solo add-on y que se pueda utilizar la funcionalidad aportada por los tres.

Por este motivo, y atendiendo a la conservación del Principio SOLID, es por lo que necesitamos un quinto microservicio. Éste será el encargado de manejar el Ciclo de Vida del add-on, y el único que se instale en JIRA Cloud. Por tanto, debe ser el encargado de declarar los servicios ofrecidos en su descriptor del add-on atlassian-connect.json

Por lo que nuestra arquitectura de microservicios (por el momento muy simple) nos quedaría así:

Requeriremos de un proxy inverso para exponer los servicios que JIRA Cloud deberá consumir, por ejemplo un nginx.

En siguientes posts de esta serie iremos ampliado nuestra arquitectura e insertando mas componentes (Config Server, Registry/Discovery Service...)

Para estar al día de esta serie, ¡síguenos en Twitter!