Monolito o Microservicios: Qué Necesita de Verdad una Pyme

Cada pocos años una arquitectura se pone de moda y se recomienda a empresas para las que nunca se diseñó. Los microservicios son el ejemplo reciente más claro. Resuelven problemas reales — de organizaciones que tienen esos problemas.

Si eres una empresa de menos de cincuenta personas, casi seguro que no los tienes, y este artículo va de por qué, y de dónde están las excepciones de verdad.

Qué significan las palabras

Un monolito es una aplicación. Un código, un despliegue, normalmente una base de datos. Cuando cambias algo, despliegas el conjunto. Así se ha construido siempre casi todo el software, y la palabra se ganó un desdén que no merece.

Los microservicios parten la aplicación en servicios pequeños e independientes, cada uno con su propio código, su despliegue y a menudo su propia base de datos. Se hablan entre ellos por la red.

Qué te dan los microservicios

Tres cosas, y conviene ser preciso porque las ventajas suelen enunciarse de forma demasiado vaga.

Despliegue independiente por equipos independientes. Si cuarenta ingenieros en seis equipos despliegan todos sobre una aplicación, hacen cola unos detrás de otros y un cambio malo bloquea a todos. Partir el sistema permite que cada equipo entregue sin coordinarse. Esta es la razón real por la que las organizaciones grandes adoptan microservicios, y es una ventaja organizativa antes que técnica.

Escalado independiente. Si una parte consume muchos más recursos que el resto — codificación de vídeo, un índice de búsqueda — puedes escalar solo esa parte en lugar de correr veinte copias de todo.

Aislamiento tecnológico. Un servicio puede escribirse en otro lenguaje, o usar otra base de datos, sin arrastrar al resto.

Qué cuestan

Los costes se enuncian menos, y son considerables.

Una llamada a función pasa a ser una llamada de red. En un monolito, una parte del código llamando a otra es instantánea y no puede fallar a medias. Por la red puede ir lenta, puede agotar el tiempo, puede tener éxito y perderse la respuesta. Todos esos casos pasan a ser tuyos, en todas partes.

Depurar se vuelve mucho más difícil. Un fallo que abarca cuatro servicios son cuatro conjuntos de registros, y necesitas trazado distribuido para seguir una petición por el sistema. Eso es infraestructura que ahora operas.

La consistencia de datos pasa a ser un problema de diseño. Una base de datos y una transacción te daban consistencia gratis. Repartido entre servicios, escribes lógica de compensación y convives con que las cosas estén mal un rato.

Las operaciones se multiplican. Quince servicios necesitan quince canalizaciones de despliegue, quince conjuntos de monitorización y alertas, quince caminos de actualización de dependencias. Eso es un trabajo, y si nadie lo tiene, no se hace.

La regla que aguanta: los microservicios cambian complejidad de desarrollo por complejidad de operación. Buen cambio si tienes un equipo de plataforma, malo si tienes tres desarrolladores.

Qué debería construir una pyme

Para casi cualquier empresa pequeña o mediana, la respuesta es un monolito bien estructurado. Una aplicación, desplegada como una sola cosa, pero organizada por dentro con fronteras claras entre las áreas del negocio.

Esa última parte es lo que lo hace funcionar. El fracaso que la gente recuerda como "el monolito" no suele ser el modelo de despliegue: es una aplicación sin estructura interna, donde todo mete la mano en todo. Eso es un problema de disciplina, y repartirlo por una red no lo arregla; solo hace el enredo más difícil de ver.

Construye las fronteras dentro de la aplicación primero. Si algún día de verdad hay que partirla, unas fronteras internas limpias son precisamente lo que lo hace posible.

Las excepciones de verdad

Hay casos en los que separar algo es correcto incluso en una empresa pequeña. Busca una parte que sea genuinamente distinta:

• Una carga con necesidades de recursos completamente distintas — procesamiento pesado de imagen o vídeo, un modelo de aprendizaje automático, un proceso largo. Ejecutarlo aparte evita que ahogue tu web.
• Una parte que deba escalar de forma independiente e impredecible — una API pública con picos, por ejemplo.
• Algo con requisitos de disponibilidad distintos — si los pagos tienen que seguir en pie mientras el resto tolera un despliegue.
• Un producto realmente separado que casualmente comparte el inicio de sesión.

Fíjate en la forma: son uno o dos servicios separados de un monolito por un motivo concreto. Eso es algo completamente distinto de empezar con quince servicios porque es lo moderno.

Consejo práctico

Empieza con un monolito. Siempre. Todavía no sabes dónde están las fronteras. Partir pronto es adivinar, y una frontera equivocada es mucho más cara de arreglar que una que falta.

Invierte en estructura interna desde el principio. Módulos claros, interfaces explícitas entre áreas, nada de meter la mano directamente en los datos de otro módulo. Al principio no cuesta casi nada y después es casi imposible de añadir.

Parte cuando algo concreto te obligue, no según un calendario. La señal es concreta: esta parte necesita otro escalado, o un equipo está de verdad bloqueado, o una carga desestabiliza todo lo demás.

Sé honesto sobre tu capacidad de operación. Si nadie en tu empresa está de guardia, no puedes operar un sistema distribuido con responsabilidad. No es una crítica, es una restricción, y diseñar dentro de ella es competencia, no renuncia.

El resumen

Los microservicios son una solución a problemas de escala organizativa que aparecen a un tamaño que la mayoría de las empresas nunca alcanza. Si tienes menos de cincuenta personas, un monolito bien estructurado te servirá mejor en casi todos los ejes: más barato de construir, más fácil de depurar, más rápido de cambiar y mucho menos que operar.

Construye las fronteras. Sáltate la red entre ellas hasta que algo concreto te obligue a ponerla.