Luis Hernandez 26/1/2021

Un patrón de arquitectura de software muy potente, pero NO debe ser tu primera opción y más aún si tu aplicación es pequeña o estas iniciando ya que tendrás nuevos problemas que resolver y si tu equipo es pequeño mantenerlo será más costoso que un monolito.

¿Qué son los microservicios?

Consiste en distribuir pequeños componentes de nuestro sistema en pequeños servicios, para realizar este tipo de arquitectura primero se tiene que hacer un análisis de los procesos que existen en el negocio para posteriormente abstraer partes primordiales de un proceso como servicios que brindan funcionalidad no solo al proceso en cuestión, sino también a otros. En este análisis hay que reconocer servicios de entidad, de negocio y de utilidad primordialmente, cada uno de estos orientado a negocio. 

Como vemos en la imagen anterior, hemos separado un monolito en varios servicios independientes con su base de datos, donde cada pequeño servicio puede ser desarrollado en lenguajes diferentes y con tipos de bases de datos diferentes (SQL o NoSQL), aquí es importante que cada microservicio sea un frente de negocio y a su vez un equipo de desarrollo responsable de ese microservicio, uno de los ejercicios más comunes es usar la ley de Conway que para resumir es crear pequeños equipos con la suficiente autonomía para poder dar valor al negocio de principio a fin, en otro post hablaremos más de este concepto y como la ley de Conway debería implementarse a la hora de formar estructuras organizativas.

Veamos un ejemplo de la ley de Conway en una arquitectura de microservicios que de hecho si la miras detenidamente me dirás ¡Luis esto es agilidad ejemplificada! Y si, lo es...

¿Cuando plantear este patrón de arquitectura?

Yo primero te preguntaria ¿Cual es tu tráfico?, ¿Qué tan nueva es tu app?, ¿Cuál es la dimensión de tu equipo de desarrollo? esto te lo pregunto porque esta arquitectura trae nuevos problemas a resolver, como la comunicación entre servicios, probar un flujo E2E, la carga cognitiva y debes tener en cuenta que esta arquitectura la usan empresas con un flujo absurdamente grande (Netflix, Uber, Spotify) en respuesta a la necesidad de escalar debido al alto flujo de peticiones, si tu aplicación es pequeña y el tráfico no amerita microservicios ¿por qué hacerlo? ahora me preguntaras ¿Luis entonces cuando? vamos a verlo con varios ejemplos: 

Suponemos que tienes un ecommerce y lanzas una campaña que la rompe en ventas y por ende tu servicio de pagos se empieza a saturar degradando así la instancia y la base de datos, por lo cual los demás servicios se verán afectados de igual forma, entonces planteas separar este servicio, su infraestructura y su base de datos, dando así la posibilidad de escalar y replicarlo según las peticiones.

Aquí me dirás ¡perfecto! ya he separado el servicio y la base de datos, por lo cual el servicio de pagos por más que esté saturado no va a afectar a los demás servicios, pero aquí es donde entran complejidades y es que el servicio de usuarios o cualquier otro puede necesitar información del servicio de pagos y lo más común es que realices una comunicacion sincrona via http (o cualquier otro protocolo) pero el problema continúa porque al degradarse el servicio de pagos cuando lo invoque otro servicio para obtener información puede tener tiempos de respuestas muy altos o incluso un time out, creando así un efecto dominó en el cual has distribuido tus servicios pero debido a que necesitan comunicarse, si alguno degrada su performance afectará a los demás de forma directa.

Aquí es donde entra el patrón de arquitectura orientada a eventos y la magia del asincronismo el cual te permitirá desacoplar totalmente tus microservicios, ya que podrás publicar eventos y tendrás servicios suscritos a estos eventos que podrán obtener los datos que requieren tus microservicios, aquí es donde entran brokers de mensajería como Apache Kafka o RabbitMQ, pero no todo es color de rosa ya que tendrás desafíos que resolver, mensajes duplicados, orden en las colas y toda la complejidad de orquestar de forma correcta una arquitectura de microservicios pero creeme que toda esta complejidad la tendrás al inicio, luego que todo esté implementado, mantener y evolucionar los microservicios será bastante sencillo y cada equipo tendrá la autonomía necesaria.

.

Microservicios como una forma específica de realizar SOA

Si detallamos la imagen anterior pensaras en SOA ya que el broker te recuerda al BUS de mensajes que por lo general se usa ESB (enterprise service bus) y me dirás ¡Luis pero esto parece SOA! y si, microservicios es una forma de implementar SOA en entornos ágiles, así que pensar que es algo muy nuevo no lo consideraría, pero sí debemos tener en cuenta que microservicios evoluciona y escala mucho con tecnologías en la nube, un último dato y muy importante, ¡la Observabilidad!, una buena arquitectura de microservicios debe tener una buena monitorización y tienes muchas opciones en la nube (AWS, Azure, GoogleCloud) que no son tan complejas como se ven, documentate sobre ElasticSearch (Prometheus, Grafana , Kibana) que te permitirán saber qué está sucediendo con cada microservicio en tiempo real lo cual permitirá madurar a tu arquitectura, mi recomendación final es que uses esta arquitectura solo cuando tu negocio escale lo suficiente para sacarle partido y tengas equipos de desarrollo para poder asumirlo, en mi opinión es el patrón de arquitectura más potente pero también uno de lo más complejos.