Un programa o muchos: monolitos y servicios

Ya tienes un servidor, un contrato de API y cachés delante de él. Todo eso todavía cabe dentro de un solo programa: un proceso, iniciado una vez, que responde a cada petición. Eso es un monolito, y así empieza casi todo sistema. La pregunta interesante no es si un monolito está pasado de moda. Es qué le pasa a ese único programa cuando la empresa crece, y si de verdad ayuda partirlo en pedazos.

Un monolito es una sola unidad desplegable. El código que dibuja la página, el que cobra la tarjeta y el que envía el correo viven en el mismo programa, comparten la misma memoria y se publican juntos. Cuando una parte llama a otra, es una llamada a una función normal: microsegundos, y o devuelve un valor o lanza un error. Hay una sola base de datos, así que unir datos de varias funciones es una consulta, no un viaje de ida y vuelta por la red. Hay un solo archivo de registro que leer.

                     MONOLITH                  SERVICES
                   ----------------------    ----------------------
processes to run   one                       many
deploys            one for everything        one per service
where you debug    one stack trace           a trace across five logs
scaling            copy the whole thing      copy only the busy part
data               one database, easy joins  split, joins become calls
failure            one crash hurts all       one crash stays containedCada ventaja de la izquierda se vuelve un costo en la derecha; ninguna de las dos columnas es gratis.

Lo que te da un monolito es enorme y fácil de subestimar. Desplegar es una sola acción, así que un cambio en el código de pagos y un cambio en el texto de la página se publican juntos y se prueban juntos. Depurar es una sola traza: cuando una petición falla, la sigues por el mismo programa, en un solo archivo de registro, sin preguntarte qué versión de qué servicio estaba corriendo. Una transacción puede ser real: cobrar la tarjeta y marcar el pedido como pagado ocurren los dos, o ninguno. Y refactorizar sale barato: mover una función de un archivo a otro es un cambio de código, no un proyecto.

Aquí es donde aterrizan de verdad los costos. Escalar: ya no copias un solo programa, sino que decides qué partes copiar y cómo se encuentran entre ellas. Fallar: una llamada a una función devuelve un valor o lanza un error, pero una llamada por la red tiene un tercer desenlace: se queda colgada, o sale bien y la respuesta se pierde en el camino de vuelta. De pronto necesitas tiempos de espera, reintentos y la disciplina de que reintentar un pago no puede cobrar dos veces. Depurar: una sola acción del usuario ahora cruza cinco servicios, y la traza en la que confiabas es reemplazada por una búsqueda en cinco archivos de registro, que solo funciona si alguien hizo que todos los servicios escribieran un mismo id de petición. Consistencia: la base de datos está partida, así que la transacción que antes era gratis ahora hay que construirla a mano, y se llama saga.

El más profundo de estos costos es el que los principiantes nunca ven venir: la red no es gratis, y no es confiable. Dentro de un programa, llamar a una función es tan barato y tan seguro que dejas de pensarlo. Entre dos servicios, cada llamada puede tardar cien veces más, puede fallar por su cuenta, y puede ser lenta de una forma que se come un hilo y tumba a quien la llamó. Un código que era un simple bucle sobre cinco elementos se convierte en cinco viajes de ida y vuelta seguidos. La arquitectura a este nivel es sobre todo el estudio de qué llamadas puedes permitirte cruzar una frontera.