Bases de datos fuera de contenedores Docker
Contenido del curso
William Schnaider Torres Bermon
Royer Guerrero Pinilla
Royer Guerrero Pinilla
Luis Guillermo Galindo Sánchez
Steve Piñero
Amin Espinoza
Profesor
Ronald Sierra
Luis Sandoval
Angela Soler
William Schnaider Torres Bermon
Jhon Jairo Bautista Beltrán
Amin Espinoza
Profesor
Carlos Casilimas Olivar
Aarón Bernabé Cuarto Rojas Vera
Daniel Meza
Reglas clave (best practices)
Regla 1: “Database per Service”
Regla 2: Acceso indirecto
Regla 3: Polyglot persistence
Regla 4: Migraciones y versionado
Regla 5: Transacciones distribuidas
Regla 6: Caching aislado
Podrias expandir el conceptos de 2PC y Sagas por favor?
En un comentario me enseñaste mas de lo que este curso enseña
No es cierto del todo. realmente si puedes correr BD en contenedores solo que como son componentes de persistencia deben tener mapeado un volumen que mantenga la data fe ella BD aunque se destruya el contenedor.
Todos mis clientes los tengo corriendo con contenedores docker y bases de datos postgresql y mysql. Lo que me gusta es la flexibilidad a la hora de portar a otro servidor, simplemente apago los contenedores copio los volumenes al nuevo servidor y listo. y utilizo muchisimo docker-compose, pero claro en aplicaciones monoliticas como odoo del cual soy consultor. Entonces me hace un poco de ruido lo que dice el profesor es como que si todo lo estoy haciendo mal. O eso de tener la base de datos real donde mas se aplique es en microservicios.?
¡Tú muy bien!
en mi opinion creeria el trauma es que perdio los datos que debieron ser persistentes, pero no hace de manera automatica que "siempre" se deba descartar el uso de contenedores para alojar informacion, para trabajos de solo nube "escuchalo", si estas aprendiendo hay casos de uso donde esto no aplica, ejemplo puedo desplegar servicios en una empresa y datos en volumenes persistentes un servidor docker in house un glpi un zabbix un n8n,cluster de k8s in house igual puede manejar los datos en contenedores con volumenes persistentes no bloques 100% la opcion cuando estes diseñando.
Me gustaría comentar que con el tema de las base de datos para arquitectura de microservicios, conmumente he leido, escuchado que cada microservicio debe tener su propia base de datos, yo en lo personal, para mi es un depende, y porque, porque no todas las organizaciones/empresas tienen las facultadades de tener base de datos por microservicios, por ejemplo, cuanto dinero costaría tener un instancia de base de datos Oracle por servicio. creo que es un punto a considerar, he visto y escuchado tambien que organizaciones tienen su arquitectura de microservicios contra una misma base de datos, pero separados por esquema, no creería que una base de datos por microservicio deba ser un must, aunque sería lo adecuado o en la sana teoría recomendable pero en la realidad esto es muy diferente.
a mi ver opino igual. Tuve el mismo raciocionio. Estaria bueno si el profesor hubiera expuestos los cases de su experiencia, pq asi como que creer ciegamente en una regla que el dice es medio dificil.
Consigo imaginar que el se refiere a los servicios en cloud, los cuales ya ofrecem sus porprios DBaaS o tambien caso no quisieras usar los servicios especificos de cada provider uses una vm ou algo asi...
Principio fundamental: Propiedad de datos por servicio
En microservicios, cada servicio es dueño único de su modelo de datos y su persistencia.
Este principio está en la base del acoplamiento débil y despliegues independientes. ⚠️ Si compartes base de datos, rompes independencia y vuelves al monolito distribuido.
Cada microservicio debería tener su propio schema o instancia de acuerdo a su contexto?
Mmmmm no lo sé, depende del objetivo del servicio, si se trata de uno que actualice quizá podría no tenerlo, de nuevo, no lo sé, es un gran depende. Cada caso es único.
Los microservicios siempre deben conectarse a una base de datos real. Utilizar imágenes con MySQL, SQL, bases de datos relacionales o no relacionales directamente dentro de los microservicios generalmente lleva a problemas, ya que las bases de datos requieren un manejo adecuado del almacenamiento en disco. Es fundamental evitar crear bases de datos dentro de los microservicios, ya que esto puede generar complicaciones a largo plazo.
No es recomendable poner una base de datos en un contenedor porque las bases de datos requieren almacenamiento persistente y un manejo eficiente de datos. Cuando una base de datos está en un contenedor, los datos se almacenan en la imagen del contenedor, lo que puede hacer que esta crezca indefinidamente a medida que se acumulan datos. Esto afecta la escalabilidad y puede dificultar la recuperación de información en caso de fallos. Además, tener bases de datos separadas permite utilizar diferentes tecnologías de bases de datos para distintos microservicios, optimizando su rendimiento y gestión.
Interesante. Era una duda que tenía desde que vengo viendo temas de Docker por estudio
