Microservices

Microservices significa dividir una aplicación en muchos servicios pequeños, cada uno dueño de una parte del negocio y cada uno desplegable por su cuenta. En lugar de un programa donde todo corre en el mismo proceso, obtienes una flota de servicios que se hablan entre sí por la red. La promesa es real: los equipos pueden entregar de forma independiente, puedes escalar solo las partes que lo necesitan, y un servicio puede fallar sin llevarse abajo todo el sistema.

El coste también es real, y suele subestimarse. En el momento en que tus llamadas a funciones se convierten en llamadas de red, tienes un sistema distribuido, y los sistemas distribuidos son difíciles. Heredas fallos de red, latencia, datos repartidos entre muchas bases de datos sin transacciones fáciles, versionado entre servicios y la carga operativa de ejecutar, monitorizar y depurar muchas piezas móviles en lugar de una. Un error que antes era una traza de pila ahora es una traza a través de cinco servicios y tres colas.

La postura honesta: la mayoría de las startups deberían empezar con un monolito. Una sola aplicación bien estructurada es más rápida de construir, mucho más fácil de depurar y perfectamente capaz de llevarte hasta ingresos reales. Te divides en microservices cuando tienes una razón concreta, un equipo lo bastante grande como para que una sola base de código sea un cuello de botella, o una carga que genuinamente necesita escalado independiente, no porque los microservices sean la respuesta de moda. Los microservices prematuros son la forma en que los equipos pequeños convierten un problema difícil en diez.

Polity corría sobre siete microservices, y esa fue la decisión correcta para su escala y su estructura de equipo. Ese es el punto: la arquitectura debe seguir al problema y al organigrama, no a una charla de conferencia. Elige los límites donde de verdad reducen el acoplamiento, y acepta que cada límite que dibujas es una llamada de red que ahora tienes que defender.