Contenido del curso
Arquitectura Basada en Microservicios
Automatización y Preparación del Entorno
Comunicación Asíncrona entre Servicios
Despliegue
Observabilidad
Bases de datos fuera de contenedores Docker
Resumen
Meter una base de datos dentro de un contenedor parece la solución más rápida cuando estás armando una API en una arquitectura de microservicios, pero es justo el error que puede frenar tu proyecto durante meses. Aquí te explico por qué las bases de datos en contenedores no escalan y cómo separarlas correctamente para aprovechar al máximo tu arquitectura.
¿Por qué no debes meter una base de datos dentro de un microservicio?
La respuesta corta tiene que ver con el espacio en disco y con el principio de responsabilidad única.
Cuando empiezas con microservicios, lo más intuitivo es crear un contenedor de Docker que hospede tu base de datos junto con tu API. Funciona para practicar, claro. El problema aparece cuando lo llevas al mundo real: las bases de datos acumulan datos constantemente, y eso hace que la imagen del contenedor crezca sin control. Tu microservicio deja de ser ligero, deja de ser portátil y deja de escalar.
Da igual si usas MySQL, SQL Server, PostgreSQL o una base de datos no relacional. El resultado siempre va a terminar mal porque las bases de datos no están diseñadas para vivir dentro de una imagen efímera.
¿Puedo usar Docker con MySQL para una base de datos en producción? No. Está bien para entornos de desarrollo o pruebas locales, pero en producción tu microservicio debe conectarse a una base de datos real, externa al contenedor.
¿Qué patrón de diseño se rompe al combinar base de datos y microservicio?
Se rompe el principio de responsabilidad única. Un microservicio debe encargarse de su lógica de negocio y nada más. La base de datos tiene su propia responsabilidad: administrar, gestionar y devolver los datos que necesitas.
Cuando mezclas ambos en un mismo contenedor, estás cargando a un solo componente con dos trabajos distintos. Y cuando algo falla, no sabes si es la API o el almacenamiento.
¿Cómo se conecta correctamente un microservicio a su base de datos?
La base de datos siempre vive por separado. En el diagrama de arquitectura debes dibujarla como un componente independiente, conectado a los microservicios que la consumen, pero nunca embebida dentro de ellos.
Esto te da una ventaja enorme: puedes mezclar tecnologías según lo que cada servicio necesite.
- Algunos microservicios se conectan a una base de datos relacional como SQL.
- Otros pueden hablar con una base de datos no relacional como MongoDB o DynamoDB.
- Puedes tener lo mejor de ambos mundos en la misma arquitectura.
Esa flexibilidad es justo el superpoder de los microservicios. Si encierras tu base de datos en un contenedor, lo pierdes.
¿Puedo combinar bases de datos relacionales y no relacionales en una arquitectura de microservicios? Sí. Cada microservicio puede elegir el motor de base de datos que mejor resuelva su problema, siempre que la base viva fuera del contenedor del servicio.
¿Qué pasa cuando ignoras esta regla en producción?
Pasan cosas feas. La imagen crece, los despliegues se vuelven lentos, los datos se pierden cuando el contenedor se reinicia y escalar horizontalmente se vuelve imposible porque cada réplica tendría su propia copia desincronizada de los datos.
A mí me tomó meses entenderlo, y en el camino hubo varios descalabros en proyectos reales. Por eso esta lección llega como advertencia directa: no uses bases de datos dentro de contenedores que se vuelvan microservicios.
¿Cómo practicar esta separación para dominar microservicios más rápido?
El mejor ejercicio es tomar la arquitectura que ya estás construyendo y replicarla con variaciones.
- Repite el ejercicio usando una base de datos no relacional en lugar de SQL.
- Combina ambos mundos: unos microservicios con SQL, otros con NoSQL, comunicándose entre sí.
- Agrega más opciones de comunicación entre servicios para ver cómo se comportan bajo distintos escenarios.
Cada vez que repitas el ejercicio con una variante distinta, vas a acortar la curva de aprendizaje y vas a entender por qué la independencia de la base de datos no es un capricho, sino la base de que todo lo demás funcione.
¿Ya te topaste con este problema en algún proyecto? Cuéntame en los comentarios cómo lo resolviste.