GEEKEANDO

Microservices:

patrones de diseño para separar lo que antes funcionaba junto

Written by Lucio de Simone
Geek Software Engineer
noviembre 3, 2025
2:08 pm

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 el de 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.” “El diseño correcto minimiza la cantidad de personas necesarias para construir y mantener el sistema.”

Frases inferidas de Clean Architecture, Robert C. Martin

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

Antes de hablar de microservicios, hay que volver a lo básico.

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.”

Y dentro de ese marco, los microservicios aparecen como una especialización del patrón cliente-servidor: pequeños servicios autónomos que se comunican entre sí para cumplir procesos de negocio más complejos.

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.

Características que suelen repetirse:

– 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:

– Base de datos por servicio (cada uno maneja su consistencia interna)
– Eventos (Kafka, SAGAs) para orquestar procesos
– Service discovery y circuit breaking para no caerse en cascada
– API gateway como entrada controlada
– Logging y métricas centralizadas para no quedar ciego

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: 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

Acá es donde la teoría choca con la práctica.

Algunos problemas frecuentes:

– 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”

Casos reales de marcha atrás:

– Uber (fusionó microservicios por latencia y complejidad)
– Segment (centralizó para bajar costos y ganar productividad)
– Amazon Prime Video (reescribió un sistema distribuido en un proceso único más barato y rápido)

Alternativa: el monolito modular

Antes de correr hacia microservicios, hay una opción intermedia: el monolito modular.

– Una sola app, organizada en módulos claros
– Módulos aislados, pero con base de datos compartida
– 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.

Antes de adoptarlos conviene preguntarse:

– ¿El negocio realmente necesita esta complejidad?
– ¿El equipo tiene la experiencia y la infraestructura para sostenerlo?
– ¿No sería más simple un monolito modular bien diseñado?

La respuesta rara vez es “usar microservicios porque sí”. La arquitectura debería ser siempre un medio para un fin: servir al negocio de la forma más eficiente posible.

Agradecimientos

Quiero agradecer a G2K por brindarme este espacio para compartir ideas y experiencias en equipo.

También a Mehmet Ozkaya por su artículo “Microservices Killer: Modular Monolithic Architecture” que me dio una mirada muy clara sobre cómo reducir la complejidad en sistemas distribuidos y bajar los costos de infraestructura. Lean su articulo para entender mas sobre migraciones y el funcionamiento tecnico de microservicios.