‍

Actualmente en cualquier estrategia de modernización digital es fundamental considerar una arquitectura de microservicios como parte de cualquier ecosistema de TI. Sin embargo, si no se hace correctamente, una implementación de microservicios puede dar más dolores de cabeza que soluciones.

‍

En especial hay que tener en cuenta que implementar una arquitectura de microservicios es un modelo que no sólo impacta la forma en que diseñamos servicios y la forma en que se administran; impacta también la forma en que el negocio puede habilitar nuevas funcionalidades, en la forma en que se gestionan los proyectos, en la forma en que se habilita infraestructura, la forma en que se coordina un equipo de desarrollo o la forma en que se gobiernan los servicios.

‍

Hay que recordar que un microservicio NO es cualquier servicio que se puede desplegar en un contenedor. Un microservicio es un servicio que tiene la principal característica de ser altamente autónomo, es decir, funciona por sí mismo sin depender de otros participantes o dependiendo lo menos posible. Y muy relacionado con este punto, al ser autónomo resulta conveniente aislar los microservicios para que no sean afectados por otros participantes, de este modo un microservicio se ve beneficiado por la contenerización.

‍

Teniendo en cuenta lo anterior, a continuación se proponen una serie de preguntas que pretenden ser una guía elemental que ayude en el diseño de una arquitectura de microservicios desde las perspectivas de funcionalidad, implementación y mantenimiento:

• ¿Las entidades que participan en el ecosistema pueden aislarse para una operación en particular?

Cuando en la funcionalidad de negocio participan sistemas que no tienen la capacidad de ofrecer niveles de aislamiento y además atienden otros procesos que pueden comprometer la funcionalidad en cuestión, seguramente no se podrá abordar como microservicio.

Al enfrentarse a esta situación, hay que buscar posibilidades de aislamiento que permitan lograr los beneficios esperados de los microservicios. Por ejemplo, si se tiene una BD extensa con tablas de proveedores, clientes, pedidos, facturas, etc, y en el servicio en cuestión solamente se necesita la tabla de clientes entonces se puede generar un esquema independiente (con algún mecanismo de sincronización) que sólo tenga la tabla de clientes y sea de uso exclusivo del nuevo microservicio.

‍

• ¿Las entidades en el ecosistema son capaces de soportar altas cargas transaccionales?

Otra importante característica de los microservicios es que podemos escalarlos horizontalmente para soportar altas cargas transaccionales, sin embargo, cuando el microservicio tiene una dependencia de otro sistema que no puede ser aislado entonces es muy posible que no sea una buena idea escalar horizontalmente el servicio porque estarían llegando más peticiones de las que el sistema puede soportar.

Por esta razón siempre en el diseño de una arquitectura de microservicios hay que tener en cuenta la capacidad de aislamiento de los sistemas satélite y sus capacidades de procesamiento para definir una estrategia donde se establezcan límites de escalamiento para no desbordar a estos sistemas satélite.

‍

• ¿La funcionalidad en cuestión resuelve una única operación atómica?

Un microservicio está diseñado para atender una funcionalidad muy particular de negocio. Es decir, si la funcionalidad es compleja o muy amplia, seguramente no estamos hablando de un microservicio. En ese escenario se debería descomponer esa funcionalidad compleja en funcionalidades más simples y específicas que puedan ser consideradas como microservicios.

• ¿La funcionalidad esperada es en línea o BackOffice?

Una funcionalidad en línea es un candidato más natural a ser microservicio a diferencia de una funcionalidad "Back Office". Esto es porque una funcionalidad en línea busca tiempos de respuesta óptimos y predecibles. En una funcionalidad "Back Office" normalmente se tienen procesos complejos, múltiples integraciones y procesos asíncronos que buscan tiempos razonables pero no estrictos. Además en los escenarios de integración normalmente existen sistemas que no pueden ofrecer instancias aisladas.

• ¿Se tienen bien definidos los consumidores de los servicios?

Hay que tener muy claro que un microservicio se despliega en un contenedor con recursos limitados, por esta razón se diseña para satisfacer las necesidades de una consumidor en particular, de modo que si algún otro sistema quiere hacer consumo del mismo servicio puede comprometer los niveles de servicio para los cuales fue diseñado.

Es aquí cuando el gobierno de los microservicios se vuelve muy importante, porque conocer a los sistemas consumidores nos dará la pauta para escalar correctamente los microservicios.

‍

• ¿Se tienen bien definidos los niveles de consumo?

Relacionado al punto anterior, si se tienen bien definidos los consumidores y el nivel de consumo esperado (volumetría) se vuelve más probable que la funcionalidad esperada pueda ser tratada como microservicio.

Al igual que en el punto anterior, si no se conoce el nivel de consumo esperado normalmente se está hablando de una funcionalidad de uso general.

Además, cuando no se conoce bien el nivel de consumo esperado, normalmente se hace un afinamiento de los servicios para balancear la carga y para evitar el desbordamiento, es decir, que cuando se tenga una excesiva carga se tenga un mecanismo que permita continuar con el funcionamiento aunque sea degradado.

Para un microservicio esta no es la finalidad, como el microservicio vive en un ambiente aislado y autónomo, si se presenta una carga excesiva simplemente se levanta una nueva instancia que pueda mantener la funcionalidad con tiempos de respuesta predecibles.

• ¿Se cuenta con los elementos tecnológicos que permitan tener ambientes aislados y autónomos?

Con la posibilidad de tener contenedores entonces sin duda se tiene la capacidad de tener microservicios. Esto sin olvidar que un microservicio es el resultado del diseño particular de un servicio, es decir, no sólo por desplegarse en un contenedor es un microservicio.

Cuando no es posible tener contenedores aún así se pueden buscar alternativas para diseñar microservicios, por ejemplo, usando máquinas virtuales, nodos virtuales, instancias de JVM, instancias de un engine, etc.

Cuando no se tiene la iniciativa sería de adopción de microservicios ya sea por el aspecto humano o tecnológico quizá sea mejor optar por una arquitectura SOA tradicional identificando los claros candidatos a convertirse en microservicios en etapas posteriores.

‍

• ¿Se identifica un ciclo de vida dinámico del servicio?

Cuando se ha identificado la funcionalidad del servicio con una granularidad fina y además esta funcionalidad evoluciona rápidamente en comparación con otros servicios, entonces es buena idea aislar este servicio en su ambiente autónomo para no interferir en el desarrollo o mantenimiento de otros servicios con lo cual se convierte en un potencial microservicio.

• ¿Se cuenta con los elementos tecnológicos para automatizar tareas?

Teniendo en cuenta que las herramientas de automatización no son estrictamente indispensables, cuando se tiene una estrategia clara de adopción de microservicios es importante impulsar el uso de herramientas para CI/CD. Y esto toma mayor relevancia cuando el servicio tiene un ciclo de vida muy dinámico, por ejemplo, si tenemos un microservicio que valida y obtiene las promociones personalizadas para el usuario cuando entra a la tienda en línea, es un servicio crítico que suele ser actualizado constantemente por lo que construir, probar y desplegar automáticamente es indispensable.

‍