Arquitectura de microservicios: ¿cuándo usarla?

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 estás iniciando. 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 independientes. 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 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 — cada uno orientado al negocio.

Hemos separado un monolito en varios servicios independientes con su propia 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 tenga un equipo de desarrollo responsable. Uno de los ejercicios más comunes es usar la Ley de Conway: crear pequeños equipos con la suficiente autonomía para poder dar valor al negocio de principio a fin.

¿Cuándo plantear este patrón?

Primero te preguntaría:

• ¿Cuál es tu tráfico?
• ¿Qué tan nueva es tu app?
• ¿Cuál es la dimensión de tu equipo de desarrollo?

Esta arquitectura la usan empresas con un flujo absurdamente grande (Netflix, Uber, Spotify) en respuesta a la necesidad de escalar. Si tu aplicación es pequeña y el tráfico no lo amerita, ¿por qué hacerlo?

Ejemplo práctico

Supongamos que tienes un e-commerce y lanzas una campaña que lo rompe en ventas. Tu servicio de pagos empieza a saturarse, degradando la instancia y la base de datos, afectando a los demás servicios. Entonces planteas separar este servicio, su infraestructura y su base de datos, dando la posibilidad de escalarlo según las peticiones.

Perfecto — ya separaste el servicio y la base de datos. Pero aquí entran las complejidades: el servicio de usuarios puede necesitar información del servicio de pagos. Lo más común es realizar una comunicación síncrona vía HTTP, pero si el servicio de pagos degrada, el tiempo de respuesta puede ser muy alto o incluso dar timeout, creando un efecto dominó.

Has distribuido tus servicios pero, al necesitar comunicarse, si alguno degrada su performance afectará a los demás de forma directa.

Arquitectura orientada a eventos

Aquí es donde entra la arquitectura orientada a eventos y la magia del asincronismo. Te permitirá desacoplar totalmente tus microservicios: publicarás eventos y tendrás servicios suscritos a estos eventos que podrán obtener los datos que requieren.

Aquí es donde entran brokers de mensajería como Apache Kafka o RabbitMQ.

Pero no todo es color de rosa: tendrás desafíos que resolver — mensajes duplicados, orden en las colas, toda la complejidad de orquestar correctamente una arquitectura de microservicios. Créeme 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 SOA

Si detallas la arquitectura orientada a eventos pensarás en SOA, ya que el broker te recuerda al BUS de mensajes (ESB — Enterprise Service Bus). Y sí: microservicios es una forma de implementar SOA en entornos ágiles. Pensar que es algo muy nuevo no lo consideraría, pero microservicios evoluciona y escala mucho con tecnologías en la nube.

Un último dato muy importante: la Observabilidad. Una buena arquitectura de microservicios debe tener una buena monitorización. Tienes muchas opciones:

• AWS, Azure, Google Cloud
• ElasticSearch, Prometheus, Grafana, Kibana

Estas te permitirán saber qué está sucediendo con cada microservicio en tiempo real.

Mi recomendación final

Usa 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 los más complejos.