Para escribir esta publicación decidí revisar mis anotaciones, experiencias, leer algunas referencias e incluso volver a leer algún libro que me permitiera confirmar –o reforzar– mis puntos de vista al respecto. La finalidad es compartir algo distinto y que además sea fácil de entender. Espero cumplir con ese objetivo 🙂

¿Qué no es un microservicio?

1. Un servicio pequeño: Esta confusión se genera al creer que el tamaño tiene que ver con el número de líneas de código del programa a exponer como microservicio. No hay que confundir tamaño con nivel de [granularidad]

2. Un API: Las [Application Program Interfaces] son una puerta para consumir o comunicarnos con un microservicio expuesto. Existe una dependencia muy marcada entre ambos elementos, pero un [API] no necesariamente involucrará el uso de microservicios.

3. La evolución de SOA: A veces se habla de migrar arquitecturas a “algo nuevo”, cuando en realidad lo que se debe buscar es la convivencia de las mismas. Si no les ha ocurrido, encontrarán situaciones en las que será más barato (y efectivo) implementar un servicio en vez de un microservicio.

¿Cómo describiría un microservicio?

1. Una necesidad específica de negocio: Una componentización adecuada sugiere que las funcionalidades se agrupen por [afinidad de objetivos en el negocio]. Posterior a esto, debemos dar un paso adicional y subdividir dicho componente en funcionalidades particulares que podrían generar valor al negocio. Un ejemplo aquí sería, aislar la funcionalidad de obtención de ranking financiero de un usuario, del resto de funcionalidades –o cálculos o servicios– financieros.

2. Independiente: No se debería involucrar a otro microservicio para cumplir el objetivo del microservicio diseñado inicialmente. De acuerdo al ejemplo anterior, la obtención del ranking financiero tendría que ser resuelta de manera efectiva sin apoyo de otros elementos.

3. Autónomo: Un microservicio debe utilizar sus propios recursos, esto implica fuentes de información e incluso el espacio donde será instalado fisicamente. Esto algunas veces no se cumple a nivel de datos y ya hace un tiempo se habla de [servicios stateless]

En términos sencillos, un microservicio es un programa que responde a una sola necesidad de negocio y que además puede instalarse y ejecutarse sin depender de la existencia de otros microservicios.

¿Qué tengo que hacer si quiero construir un microservicio?

Lo que normalmente hacemos es [buscar en la web]. Allí encontraremos muchas plantillas que, en algunos casos, brindan erroneamente el concepto de microservicio. Esto principalmente porque reflejan servicios que exponen (y soportan) más de una funcionalidad.

Creo que un diseño adecuado se puede conseguir si respetamos los principios propuestos por [Sam Newman], autor de [Building Microservices], el cual por cierto es un excelente libro. Aquí un gráfico que la propuesta y claro, un enlace a [un video] donde se explican cada uno de los principios.

¿Cómo construyo un microservicio?

Hay que tener en cuenta que lo ideal es respetar principios de diseño (en mi caso me pareció que Sam Newman lo explicaba de manera más sencilla). Ahora, si estan aprendiendo o experimentando, podrían seguir las consideraciones que definí mientras iba aprendiendo (las cuales respetan de alguna forma la propuesta del buen Sam)

1. Requisitos de negocio: Creo que independiente a la estrategia de arquitectura, lo primero que debemos respetar es la funcionalidad a cubrir. Si esta no está cubriendo las expectativas del negocio (lo cual en algunas situaciones se relaciona con el core del negocio), no tiene sentido continuar con el diseño.

2. Exposición: Otro elemento importante es responder ¿cómo vamos a exponer el microservicio? Aquí entrará a tallar la API que complementará el diseño que estamos realizando.

3. Requisitos técnicos: Si se tienen cubiertos las dos primeros consideraciones, se puede continuar con el diseño de otras necesidades, como por ejemplo ¿cómo vamos a probar el microservicio? ¿cómo vamos a desplegarlo? ¿cómo vamos a manejar los errores? Aquí es donde entra la sección de herramientas complementarias.

Un diseño que estoy construyendo es el siguiente:

Como mencioné en una [publicación anterior], hace poco empecé un proyecto open source en el cual comparto plantillas y ejemplos de microservicios. Todo el [código fuente] que verán en dicho repositorio responde a las consideraciones de diseño que comento en esta publicación.

Hay que recordar que este diseño responde a un microservicio como unidad de trabajo. Esta acotación es importante pues queda pendiente conversar sobre la interacción con otros elementos del ecosistema. Aquí es donde se entiende que se necesitará estudiar conceptos de [orquestación y coreografía]

¿Cuáles son los próximos pasos?

No debemos olvidar que los microservicios son una técnica más dentro de las posibilidades para atender las necesidades del negocio. Esto significa de que no necesariamente serán la primera –ni la única– respuesta a los problemas a cubrir.

Habiendo dicho esto, sugiero que descarguen el [código de ejemplo] (en este momento está disponible en JavaScript, TypeScript y c#), revisar el contenido, contribuir en GitHub o bueno, darme feedback al respecto.

Quedo atento, un abrazo.

Fuente cabecera: [what are microservices?]