Contenido

Entre los grandes bandazos tecnológicos que ha habido en nuestro negocio, pocos han sido tan extendidos y tan mal implementados como la arquitectura de microservicios.  

Perfectamente explicada en el libro de Sam Newman “Building Microservices” (lectura obligatoria para cualquiera que esté desarrollando microservicios o piense hablar del tema), esta se ha alzado como una alternativa poco comprendida que va más allá de la mera división de un monolito en pedazos más pequeños, y digo poco comprendida porque he oído como la etiquetan como una alternativa superior o como una evolución de la arquitectura monolítica (aquí es donde te das cuenta de que tu interlocutor no sabe de qué habla). Los microservicios no son intrínsecamente mejores que un monolito, simplemente son una alternativa válida en función del contexto y las necesidades concretas del sistema.  

La verdadera clave del éxito, como suele suceder en el desarrollo de software, no está en la forma sino en el fondo: test automatizados, código limpio y buenas prácticas que trascienden cualquier patrón arquitectónico. 

La propuesta de los microservicios nació como respuesta a la creciente complejidad de las aplicaciones, a la necesidad de escalar partes específicas de la funcionalidad y a la búsqueda de mayor autonomía entre equipos. En una arquitectura monolítica, el código suele crecer como una gran bola de nieve en la que cada cambio, por mínimo que sea, requiere llevar a cabo un despliegue completo de la aplicación. La promesa de los microservicios es la modularidad: dividir el sistema en servicios independientes, pequeños, con un propósito bien definido, que pueden ser desplegados y gestionados de manera autónoma. Esto posibilita el escalado “granular” (ampliar solo la parte que lo necesita) y hace que el despliegue de nuevas versiones sea más ágil, sin arrastrar consigo el peso de todo el conjunto. 

Nunca hay que confundir la herramienta con la solución a todos los males. Una arquitectura no arregla por sí sola los problemas de diseño y mantenimiento; su éxito depende de cómo se implemente y gestione. Un microservicio mal diseñado es más problemático que un monolito igualmente descuidado. Y es que, al adoptar esta arquitectura distribuida, aparecen nuevos desafíos: la comunicación entre servicios se hace más compleja, se empiezan a generar problemas de excesiva comunicación entre microservicios si la funcionalidad no está separada de manera correcta, se acaban acoplando funcionalidades que hacen que para actualizar un microservicio haya actualizar los demás, ligando los despliegues y perdiendo así parte de los beneficios de la nueva arquitectura, entre otros. 

Sam Newman enfatiza la importancia de la cultura del equipo y de los procesos a la hora de adoptar esta arquitectura. De poco sirve tener microservicios “perfectamente” separados si tu equipo no es capaz de mantener una mentalidad de mejora continua, pruebas automatizadas rigurosas y un estándar de limpieza de código. De hecho, la verdadera virtud de cualquier enfoque arquitectónico radica en la capacidad de los desarrolladores para mantener un ciclo constante de feedback, refactorización y calidad. En otras palabras, microservicios o monolito, lo que hace que la máquina avance es la disciplina en la construcción de software, la robustez de los tests automatizados y el compromiso con un código legible y sostenible. 

Desde esa perspectiva, los microservicios no son ni héroes ni villanos: son una opción técnica más. Pueden encajar de maravilla en organizaciones con equipos independientes, que trabajan en dominios bien delimitados y que necesitan libertad tecnológica para elegir las herramientas más adecuadas a cada problema. Sin embargo, para equipos más pequeños, con un  alcance funcional menos complejo o con requerimientos de tiempo menos exigentes, un monolito bien construido, testeado y limpio puede ser igual de eficiente, más fácil de mantener y menos propenso a complicaciones innecesarias. 

En definitiva, la arquitectura de microservicios se presenta como una alternativa a explorar, no un dogma a seguir ciegamente. Con el foco siempre puesto en las buenas prácticas, los tests automatizados, la calidad del código y en saber lo que estamos haciendo y por qué lo estamos haciendo, podremos aprovechar las virtudes de esta alternativa cuando realmente aporte valor a nuestros proyectos.  

¿Te interesan más temas como este? Aquí te dejamos una lista de entradas que pueden interesarte: