Microservices: patrones de diseño para separar lo que antes funcionaba junto
Los microservicios pueden ser útiles en ciertos contextos y un dolor de cabeza en otros. Qué son, qué patrones los sostienen y cuándo conviene un monolito modular.
Por Lucio de Simone · Geek Software Engineer · Publicada originalmente en Medium
La arquitectura de microservicios está en boca de todos. Muchas empresas la adoptan pensando que es la solución mágica para escalar, organizar equipos y moverse más rápido. Pero la realidad es menos romántica: puede ser útil en ciertos contextos, y un dolor de cabeza en otros. En esta charla de G2K mostramos qué son los microservicios, qué ventajas tienen y en qué situaciones pueden salir más caros de lo que valen.
El propósito detrás del diseño
El propósito de la arquitectura de software no es crear una estructura que sea fácil de desarrollar. Es crear una estructura que sea fácil de mantener y cambiar con un esfuerzo humano razonable, a lo largo del tiempo.
En resumen: el software se diseña para servir al negocio, no para alimentar la moda tecnológica de turno ni el ego del arquitecto.
Introducción: sistemas distribuidos y cliente-servidor
Un servidor es simplemente una pieza de hardware que corre un servicio. Un servicio es un proceso que espera ser llamado para cumplir una tarea. Un cliente es quien hace la petición, mediante un protocolo, al servidor. Con estos conceptos simples entendemos qué es un sistema distribuido: el conjunto de computadoras o servidores interconectados que trabajan juntos como un solo sistema para lograr un objetivo común. Dentro de ese marco, los microservicios aparecen como una especialización del patrón cliente-servidor.
Qué son los microservicios
Un microservicio es un servicio pequeño, autónomo, con una sola responsabilidad. Habla con otros a través de interfaces claras y se despliega por separado.
- Cada servicio va por su cuenta (despliegue independiente)
- Autonomía tecnológica (cada equipo puede usar stack distinto)
- Escalabilidad distribuida
- Un equipo dueño de cada servicio (y también de sus problemas)
Patrones y convenciones que ayudan
No alcanza con “tener microservicios”. Hay que sostenerlos con prácticas:
Migrando desde un monolito
La historia típica: un monolito gigante, indeployable, con equipos chocando. El camino común es el Strangler Fig Pattern: sacar funcionalidades de a poco, testear, redirigir tráfico, y repetir. El problema es que mantener microservicios exige automatización, infraestructura madura y gente que sepa lo que está haciendo. Si no, se transforma en caos distribuido.
Costos y complicaciones
- Velocidad: en sistemas simples, la sobrecarga mata cualquier beneficio
- Versionado: mantener APIs vivas y compatibles es un dolor de largo plazo
- Costos ocultos: containers, pipelines, métricas, coordinación… todo suma
- La moda: muchas veces se adoptan porque “queda bien decir que usamos microservicios”
Alternativa: el monolito modular
Antes de correr hacia microservicios, hay una opción intermedia: una sola app organizada en módulos claros, con módulos aislados pero base de datos compartida, que escala equipos sin tener que hacer DevOps ninja. Muchas veces es suficiente y evita complejidad y costos asociados.
Conclusión
Los microservicios no son ni buenos ni malos en sí mismos: son una herramienta. En el escenario correcto, permiten escalar equipos, ganar flexibilidad tecnológica y desplegar de manera independiente. Pero en contextos más chicos o con sistemas menos complejos, suelen sumar más fricción, costos y burocracia que valor real.
La arquitectura debería ser siempre un medio para un fin: servir al negocio de la forma más eficiente posible.
