En una ocasión para un cliente integré un pasarela de pagos online en México en su plataforma que funcionaba de maravilla. Hasta que llegó un momento donde, por decision de negocio, se optó por cambiar de proveedor y tuve que migrar a otra pasarela y con ello las implementaciones a nivel de la plataforma. Gracias a que había definido un Adaptador y Fábrica, la migración no tuvo mayor complicación. La fábrica generaba las instancias según la interfaz que el adaptador arrojaba y el resto de las implementaciones funcionaban sin afectaciones por la migración. Genial tu video, Manuel. Saludos.
@oscarbarajas36103 жыл бұрын
Excelente contenido Manuel. Para este tema, deberías haber un video del cómo lidiar en las peticiones REST para un multi tenencia. Qué tengas un excelente día!
@elvargas13273 жыл бұрын
@Manuel Zapata
@JIDiaz Жыл бұрын
Lo que pasa es que todo parte de un modelo de negocio central. A raiz de eso tu dibujas tus modelos principales. Ejemplo si desarrollas un software multitenant para gestión académica, vas a requerir conocer cuales son tus procesos de negocio central, registrar notas, subir tareas, pagar en línea, etc. Al final del día esos procesos serán representados por endpoints. Pero los servicios hacen uso de implementaciones diferentes dependiendo el tenant. Es por eso que se nombran mucho algunos patrones estructurales o comportamiento para estas labores, porque de lo contrario terminarias haciendo un montón de validaciones para ejecutar reglas de negocio por cada inquilino.
@JIDiaz Жыл бұрын
El endpoint sigue siendo el mismo, pero dependiendo el tenant se comporta diferente. Fin
@cmarsiglia3 жыл бұрын
He diseñado una aplicación web Multi-tenant, única aplicación con múltiples bases de datos(DB) y los retos fueron los siguientes: 1- Crear la DB por cada tenant registrado en la aplicación. - En este punto tengo una clase que crea al tenant, y usuario de acceso a la DB para finalmente con los datos anteriores ejecuta migraciones del tenant. 2- Para acceder a la DB del tenant, al iniciar sesión se valida información de conexión para ver sus datos. 3- Se dice que actualizar la estructura de DB es complejo y es verdad, pero logre crear una clase que al hacer login se obtienen los datos de conexión hacia la DB del tenant, uso esa información para validar que migraciones están pendientes y ejecutarlas de ser necesario, esto ayuda a no generar updated de la DB de forma masiva sino por demanda cada vez que inicia sesión el tenant o los usuarios pertenecientes al tenant. ¡En cuanto al vídeo muy bien explicado!
@leogarcia5504 Жыл бұрын
Interesante!
@noeliafernanda10617 ай бұрын
Hola, buen video 👍🏽 Una consulta, tendrás un vídeo o sabrás de una web o vídeo sobre la elaboración de una base de datos multi tenant (para un Saas), es decir de un caso o negocio completo..??? 🤔🤔🤔
@develpersАй бұрын
Haz un project multitenant partiendo de esta teoria seia genial aprender de ti la forma en como nos brindas enseñansas
@jaajcade4 жыл бұрын
Justo en mi trabajo existe ese problema... El código es spaghetti ... Gracias por el contenido, estudiaré los patrones que mencionas para implementar en mi trabajo
@ManuelZapata4 жыл бұрын
Excelente Jaime! Cualquier duda, por aquí a la orden.
@daviscruz11014 жыл бұрын
Excelente, este canal debería tener muchos mas suscriptores 😜
@ManuelZapata4 жыл бұрын
De acuerdo contigo, David! Ahí vamos.
@nelsongomez85472 жыл бұрын
Hola Manuel excelente contenido, te felicito. Tienes algun video en donde demuestres como implementar lo expuesto en el video? Por ejemplo .net core y c# A la espera de tu valiosa respuesta.
@ksantacruz6 ай бұрын
Gracias por el video a mi me tocó implementar multitenant con .NET aplicamos IdentityServer y RBAC. Se creó un middleware para gestionar los contextos y con eso se conocía a BD apuntar
@diegotorres503 жыл бұрын
Muchas gracias Manuel, seria genial que hablaras un poco para complementar sobre las tecnologías que facilitan este tipo de implementacion, que d hecho existen evitando hacer de cero lo que nos compartes y se adecuan a distintos tipos de lenguajes, gracias de nuevo
@cristobalcifuentes8149 Жыл бұрын
tus videos siempre que busco algo son de mucha ayuda. muchas gracias
@ManuelZapata Жыл бұрын
Gracias por esas palabras!
@travko18334 жыл бұрын
excelente muy bien explicado. es justo como lo tengo configurado, agregar además que tuve que crear un sub tenant, es decir un sub cliente o sucursal (distinta region) porque comparten datos
@ManuelZapata4 жыл бұрын
🙌
@Peligroficial2Ай бұрын
Que crack muchas gracias.
@chacatico4 жыл бұрын
gracias por la info, excelente trabajo, siempre pensé que tenant significaba inquilino y por eso sería multi inquilino y no multitenencia pero es bueno aclarar que al español también se puede decir. explicas muy bien, sigue con el excelente trabajo, tienes un subscriptor +
3 жыл бұрын
De hecho si va por multi-inquilino, lo que pasa es que con la tropicalizacion del ingles, queda tenencia, pero para no generar controversia, ambas cosas llegan a ser lo mismo para efectos practicos
@MegaJeanpierrАй бұрын
Excelente video. Alguien sabe si sería útil el uso de Keycloack para el desarrollo en este tipo de infraestructura?
@-trycatch-4 жыл бұрын
Yo trabajo en un proyecto para un sistema multitenecia y este video me cae perfecto ya que no conocía todos los conceptos que mensionas, pienso que otro patrón útil puede ser el patrón builder para cuando queremos crear un objeto personalizado que puede tener muchas configuraciones.
@ManuelZapata4 жыл бұрын
Tienes mucha razón @Try Catch. El builder también puede ser muy útil.
@TechieGuy794 жыл бұрын
gracias Manuel, justo hoy leyendo documentacion en ingles de cosmos db me dejaba la duda sobre multitenant. A buen momento encontre tu video
@ManuelZapata4 жыл бұрын
🙌
@julianvargas2288 ай бұрын
El más claro 👏🏻👏🏻
@ManuelZapata7 ай бұрын
Gracias, Julián!
@DamCipolat2 жыл бұрын
Excelente video, gracias por compartirlo!
@ricardocorralesduque14854 жыл бұрын
Muchas gracias Manuel. Excelentes tus vídeos, son muy claros y explicas muy bien. Te pregunto algo, cómo se podría implementar una arquitectura multitenan con microservicios? Podrías hacer un vídeo explicando un poco esto? . Gracias.
@ManuelZapata4 жыл бұрын
Sería muy similar a como si la aplicación fuera monolítica. Saludos Ricardo!
@dev.martin61564 жыл бұрын
Excelente, gracias por compartir tus conocimientos, me ayuda mucho a tomar una decisión
@ManuelZapata4 жыл бұрын
De eso se trata. Genial Martin!
@diegoalejandroh61399 ай бұрын
gracias
@danielvera46614 жыл бұрын
Muy buen video manuel, he estado trabajando en un sistema asi pero un poco desorganizado y no entendia. tu video me ayudo a enteder y aplicar estrategias para mejorar ese sistema o programar uno nuevo aplicando los puntos que mensionaste
@ManuelZapata4 жыл бұрын
Que bacano eso que me comentas. Saludos Daniel!
@Algedibarrios4 жыл бұрын
Gracias Manuel! Super útil este video!! Claro y conciso además👍
@Algedibarrios4 жыл бұрын
Además describes un problema a los que nos enfrentamos con mucha frecuencia cuando queremos crear un producto que sirva a muchos clientes y hacer la menor cantidad de cambios posibles.
@Algedibarrios4 жыл бұрын
Y además muestras las posibles soluciones.
@ManuelZapata4 жыл бұрын
Gracias por la retroalimentación positiva, Algedi!
@Daviidscovers3 ай бұрын
Excelente video, quiza seria bueno expandir el multitenant por esquemas.
@leviatanMX4 жыл бұрын
Excelente video, tengo en mente un proyecto que voy a necesitar soportar multiples clientes
@ManuelZapata4 жыл бұрын
Genial!
@oscargarcia18512 жыл бұрын
Hola Manuel, muchas gracias por compartir este tipo de videos! Quería saber si me puedes compartir por favor más recursos, cursos o información para saber cómo comenzar a implementar esto en una aplicación. Muchas gracias!!
@giuliuploader2 жыл бұрын
Mí ejemplo más común es que tuve que desarrollar un sistema para varias sucursales de una empresa..donde tienen mínimo un usuario o PC por sucursal a veces mas
@OswaldMoreno4 жыл бұрын
Muy buen vide, bien claro sencillo de entender y directo al punto
@ManuelZapata4 жыл бұрын
Gracias por el feedback, Oswald!
@diana_nerd3 жыл бұрын
Se me ocurre que también se podría tener un sistema de BD híbrido en el que haya 1 DB para los datos de NUESTRO negocio (que es dar el servicio), y 1 DB por cliente para los datos de SU negocio. Así incluso podría cada cliente tener sus configuraciones y reglas de negocio en su DB.
@bryantbaldallaque8144 жыл бұрын
Excelente video... Tienes un video de. Como. Hacer el multi tenancy en core 3.1
@ManuelZapata4 жыл бұрын
Hola Bryant, no lo tengo. Pero con las explicaciones acerca de como modelar las tablas y la BD, debería ser un proceso sencillo.
@armandomartinez4434 жыл бұрын
Gracias excelente contenido, vengo por recomendacion de yesi days
@ManuelZapata4 жыл бұрын
Bienvenido Armando! Gracias por compartirme el dato de que Yesi te sugirió el contenido.
@adrianvega31483 жыл бұрын
Muy buen video, me gusta este tipo de contenido
@eduardojosegarcia2582 жыл бұрын
Gracias, muy instructivo
@shk.mexico8 ай бұрын
Tendras un curso de la 2 opcion?
@trex36123 жыл бұрын
Hola excelente video no lo había encontrado. Estoy desarrollando en PHP y Codeigniter. Este framework es MVC pero en el camino nos perdemos tienes un curso para desarrollo web app.
@Magistrado19143 жыл бұрын
Excelente vídeo Visto en 08/11/2020
@jesusalejandro29113 жыл бұрын
Hola Manuel, excelente aporte sobre todo los patrones de arquitectura y diseño. Tengo una consulta sobre implementacion para acceder a las base de datos por cliente (estoy con la opcion 2 Separada (Isolated)) internamente en mis token tengo un identificador unico por cliente el cual uso para consultar en una tabla tenant sus datos de conexion hacia su base de datos, Este seria los paso, 1) acceso a mi DB princical tabla tenant y obtengo los datos de conexion, 2) cierro esa instancia y creo una nueva para este cliente, 3) conculta a realizar. Estoy usando un ORM, mi pregunta es; lo estoy bien o hay una forma mejor de aplicar esto?
@emiliowildberger71512 жыл бұрын
Gracias, me ayudas muchísimo
@jklmg104 жыл бұрын
Hola Manuel, como aporte, para implementar "multitenencia" también hay que considerar temas de seguridad de los datos, personalmente me toco participar en un proyecto donde un requisito era ser "HIPPA compliant", por lo cual cada base de datos de cada cliente, tenia que estar totalmente separada y cumplir ciertos estandares adicionales. Saludos desde La Paz, Bolivia
@ManuelZapata4 жыл бұрын
Excelente aporte. Gracias!
@ing.nelsonsantamaria99133 жыл бұрын
Hola, excelente video, quisiera saber que tan buena o mala seria la multitenencia en un patrón de microservicios??
@emmanuels.r99574 жыл бұрын
Tocas temas muy buenos e interesantes. Yo siempre he tenido problemas con usuarios roles y permisos cómo modelar la bd y crear la lógica de la app si pudieras hacer un video sobre ello te estaría agradecido.
@ManuelZapata4 жыл бұрын
Te voy a dar una opinión un poquito controversial: yo no programaría el módulo de usuarios y roles. Yo usaría algo que ya está hecho. Tanto frameworks como herramientas como Auth0 hacen eso mil veces mejor de lo que nosotros podríamos. Ahora, si en realidad lo quieres hacer desde cero, te comparto este vídeo de mi colega @hdeleon.net: kzbin.info/www/bejne/jqPFnWmOnNKcY7M
@fernandopoveda54853 жыл бұрын
Debo crear un capa Domain y Application por cada cliente?
@JuanCarlosChoqueQuispe4 жыл бұрын
Muy buena la explicación, gracias!!
@ManuelZapata4 жыл бұрын
Con gusto Juan Carlos!
@JIDiaz Жыл бұрын
En mi experiencia metiendome con esta arquitectura dañando erp's, yo pienso que el problema no es desarrollarlo si no desplegarlo y escalarlo. Porque la plataforma a final del día escala como un monolito, y eso ya no es bueno para sistemas grandes que siempre deben estar disponibles. Por lo que quizás la mejor solución sea otra, tal vez combinandola con una arquitectura orientada a servicios. Además de que esta arquitectura puede resultar si el sistema es de 0, no en sistemas legados. Ahi lo único que te queda es microserviciar.
@marioolivera2843 Жыл бұрын
Hola manuel muchas gracias por tu explicación. Entiendo de que va todo, pero sigo sin saber que me convendria hacer en mi caso. Estoy desarrollando un sistema, el cual voy a vender a varios clientes, por un lado estoy con tecnologia Next JS, y como API PHP, que estoy pensando si usar php puro o laravel como api. El sistema va a ser un sistema administrativo, a nivel de recursos de procesamiento, generar archivos pdf creo seria una de las funcionalidades que demande un poco mas de procesamiento, pero despues no creo que consuma muchos recursos. La DB seria Mysql, ahora... No tengo idea que cantidad de clientes puedo llegar a captar. Si un sistema llega a tener 8000 clientes, sistema sencillo, querys dentro de todo sencillas, y solo generacion de archivos pdf por ejemplo, a que debo apuntar? Y como manejas el almacenamiento (archivos subidos por el cliente) total de informacion? Me da mucha duda el semejante peso que puede llegar a tener una db con todos los datos de los clientes.
@eriksonsamayoa25293 жыл бұрын
Ahora, como puedo aplicar la opción número 2 ?
@davidpccode4 жыл бұрын
Hola. La estrategia híbrida que propones es confusa, una BD por cliente pero a la vez con un tenanId? Si te entendí bien? si es así.. no tiene mucho sentido. De hecho la estrategia mas optima en mi concepto es el de esquemas, pues funciona con un aislamiento tan alto como tener BD separadas (también te libras de estar filtrando por un tenantId que es peligrosisimo) con el bajo costo y optimización de una columna tenantId en las tablas. El problema que dices de mantener las tablas actualizadas tanto para la estrategia de BD x tenat como Esquema x tenat es el mismo y se resuelve creando un un script muy bien hecho multi thread que sea capaz de ejecutar los cambios en todos los esquemas/bd tan rápido como sea posible, nosotros corremos scripts de actualización de varios cambios DDL en uno o dos minutos afectando 2000 esquemas cada una con 300 tablas aprox (600,000 tablas en total)
@ManuelZapata4 жыл бұрын
Hola David. Interesantisimo el caso que comentas y como han logrado escalar esos scripts de actualización. El esquema híbrido puede ser útil en esos puntos donde hay incertidumbre y no sabes cómo puedan crecer los datos de ciertos tenants. Pero ciertamente trae complejidad adicional. Gracias por tu aporte!
@douglasperez37013 жыл бұрын
Muy buen video, exitos
@flaviodias85424 жыл бұрын
Excelente video Manuel.
@ManuelZapata4 жыл бұрын
Gracias Flávio! 💪
@gonzasotocastro4 жыл бұрын
Hola Manuel , en realidad no tengo experiencia sobre este tema , tendrias links donde podria informarme mas. Gracias buen contenido
@ManuelZapata4 жыл бұрын
Con el vídeo ya tienes un buen contexto sobre el tema, Onasis. Profundizar en el tema depende del reto particular que tengas: bases de datos, escalabilidad, reglas de negocio, entre otros.
@dvdcampos173 жыл бұрын
Muy buen video. Recomiendas algún libro, sitio o curso para aprender a desarrollar multi-tenencia ? En mi caso estoy desarrollando una aplicación .Net Core 3 + Angular 8 y me interesa saber como pudo implementarlo.
@jose21francisco2 жыл бұрын
una pregunta estoy empezando con node tengo una pequeña api pero no entiendo como podria conectarme a diferentes base de datos dependiente de cliente como lo hago tendran un curso o alguien podria darme asesoria??
@josevicente6324 жыл бұрын
Excelente!!! ...gracias por el aporte
@ManuelZapata4 жыл бұрын
Con todo gusto!
@efrainespaderocanaviri27412 жыл бұрын
Te agradeceria mucho si pudieras recomendarme un libro que implemente o oriente sobre esta arquitectura.
@ManuelZapata2 жыл бұрын
A quien he visto compartir más información sobre multi-tenencia es Salesforce. Más allá de eso, no tengo un libro recomendado.
@LeonardoAngel30004 жыл бұрын
Gracias por el video, me suscribo si me ayudas a las dudas que tenga
@ManuelZapata4 жыл бұрын
Bienvenido a la comunidad!
@aguileraq3 жыл бұрын
Excelente video, tengo una duda sobre llevarlo a practica... por ejemplo, ¿que tipo de dato debería de ser un campo *tenant_id* ?
@yeanurdaneta7362 жыл бұрын
Hola. Nosotros en nuestros desarrollos multitenant usamos Guid para los caso de tenantid.
@cuentadeyoutuization4 жыл бұрын
Excelente contenido!
@ManuelZapata4 жыл бұрын
🙌
@paulvalencia92434 жыл бұрын
Gracias excelente video
@ManuelZapata4 жыл бұрын
Gracias Paul 🙌
@chackycrypto4 жыл бұрын
Manu! Excelente tu video, súper claro! Tengo una duda, esta es la arquitectura que por ejemplo utiliza Shopify? Para poder registrar clientes de manera “automática” ? Gracias !
@ManuelZapata4 жыл бұрын
Excelente pregunta, Damian! No conozco los detalles de cómo esté implementada esa parte de Shopify, pero seguro por ahí va la cosa.
@albertonavarroperez36862 жыл бұрын
Hola Manuel, excelentes videos, me han servido mucho, solo una pregunta, en la empresa donde trabajo hay varias plataformas, una desarrollada con laravel, la otra con c# devExpress, otra con angular y la ecommerce que está con Magento, mi pregunta sería, ¿Cual o cómo sería la mejor forma para hacer que entre todas las plataformas y servicios mencionados se usen un solo login, osea centralizar el login mismo usuario y contraseña para todas las plataformas ?
@JIDiaz Жыл бұрын
Valla hace un año yo tenía esa misma duda. Con una plataforma multitenant y varios aplicaciones separadas. Quizás a estas alturas sepas la respuesta, pero básicamente necesitas un single sign on, existe soluciones en la nube para eso, no recomiendo implementaciones propias, se puedén cometer varios errores y problemas de vulnerabilidad.
@JoseDlucca2 жыл бұрын
En el caso de una DB por cliente, si tenemos una tabla con información que debe estar disponible para todos los tenants (digamos, una tabla de países). Cuál sería la mejor manera de compartir ese recurso? Tener la tabla en todos los tenants y replicar la información?
@yeanurdaneta7362 жыл бұрын
Si es una tabla en común con datos que no cambien o que controles directamente tu como negocio, como países o estados por ejemplo es una sola tabla a la que van a consultar todos tus tenant pero sin permitirles borrar o editar. En el caso que los tenant puedan modificar la información entonces tienes que igualmente a tu tabla de países agregarle un tenantid y que cada cliente administre la información. Lo que podrías es cuando creas un tenant le inyectas a esa base de datos unos valores básicos y que luego el cliente los personalice
@JoseDlucca2 жыл бұрын
@@yeanurdaneta736 gracias por tu respuesta. Justamente pensaba en eso, que la tabla países debiese ser una sola tabla que los demás tenants consulten a ella. Pero eso me crea otra duda, que pasa con las claves foráneas? Si voy a insertar un registro en un tenant haciendo referencia al país, no tendría posibilidad de implementar una clave foránea. Existe una manera de mitigar este problema o es un sacrificio que hay que hacer al momento de trabajar con esta arquitectura?
@yeanurdaneta7362 жыл бұрын
La clave foránea iría contra la tabla de países. Lo único es que tendrías que quitarle que se borre en cascada para evitar eliminar datos sin querer. Pero en teoría no debería hablar problemas con eso. Seria cosa de probar y ver si se adapta a lo que realmente estás buscando hacer.
@gussware41774 жыл бұрын
Amigo por casualidad no haces vídeos en udemy o platzi o en alguna plataforma ??? de vdd pagaría lo que fuera por un taller avanzado sobres todo lo que acabas de mencionar en este vídeo.
@ManuelZapata4 жыл бұрын
Gracias Guss! Motivan tus palabras!
@TheSolopop3 жыл бұрын
Me encanta! En donde has aprendido todo esto que sabes?
@ManuelZapata3 жыл бұрын
🙌 En muchos lugares, Keiny. Estudiando y en la práctica. Saludos!
@AbrahamJLR4 жыл бұрын
Muy buen vídeo amigo, una pequeña consulta: sí presento una aplicación web donde mi lógica de negocio está siendo trabajada en una única API con una única Base de Datos, pero a su vez el API está trabajando con control de versiones en caso de que uno o más cliente requieran nuevas características, ¿entraría en el concepto de Multi-tenencia?
@ManuelZapata4 жыл бұрын
Esa es una excelente pregunta Adrian. La multi-tenencia normalmente está asociada a los datos. Ya a nivel de funcionalidad, puedes explorar patrones de diseño o patrones de arquitectura.
@jorgegomez26294 жыл бұрын
Excelente vídeo, muchas gracias! Respecto a la estrategia de repositorio de datos para aplicaciones multitenant, hay una sobre la que he estado investigando últimamente y es el data sharding; el cual permite escalabilidad (horizontal) y data isolation por tenant, según sea implementado. Saludos!
@ManuelZapata4 жыл бұрын
Gracias por tu aporte Jorge. El sharding es muy potente!
@oliverdjbrown4 жыл бұрын
Manuel, ¿existe algun tipo de documentación que se pueda consultar sobre patrones de diseño dependiendo del tipo aplicaciones que queremos crear?
@ManuelZapata4 жыл бұрын
Hola OAntu! No que yo sepa. Los patrones de diseño los usas para problemas puntuales en tu código, no para un sistema completo como tal. Por eso no estoy seguro que exista. Saludos!
@raul72544 жыл бұрын
Harías un video sobre escalar aplicaciones web y usuarios concurrentes
@ManuelZapata4 жыл бұрын
Pues mira que justo andaba pensando en hacer un live sobre el tema 🤔
@tecnologiawebinteligente45654 жыл бұрын
Hola Manuel .. tienes algún curso de tenancy..saludos
@ManuelZapata4 жыл бұрын
Hola! No, no tengo curso sobre el tema.
@juandavidreina96964 жыл бұрын
Buen video, muy educativo... pregunta, esos patrones de diseño don aplicables a cualquier lenguaje de programación? Por ejemplo, JS? De antemano, muchas gracias!
@ManuelZapata4 жыл бұрын
En cualquier lenguaje orientado a objetos los puedes implementar. Saludos!
@juandavidreina96964 жыл бұрын
@@ManuelZapata Muchas gracias!
@elbranching3 жыл бұрын
12:22 Manuel, esto NO es solo una pésima practica, es "Sacrilegio" estuve trabajando para una empresa en la que se hacia esto para diferentes clientes y el mantenimiento era un infierno. Nunca lo hagan!
@alexo25374 жыл бұрын
Hola pregunta, es posible darle un prefijo a los clientes por ejemplo 1-egahuxhuah; 2-jhshjhlas etc
@ManuelZapata4 жыл бұрын
Por supuesto. Tu tienes la libertad de identificar los clientes como consideres más apropiado.
@alexo25374 жыл бұрын
@@ManuelZapata Y como por donde podría configurar eso, es que soy re novato con esto del tenant y mientras creo al cliente por comando y en la Base de datos me lo crea con caracteres cifrados que no entiendo en que ira
@giuliuploader2 жыл бұрын
Nunca había escuchado la palabra multi tenencia..pero sería multiusuario o concurrencia..
@MarkTin20004 жыл бұрын
Esti tipo de aplicaciones es buena pero pienso que tiene mas contras que pros.
@ManuelZapata4 жыл бұрын
Cuáles son las desventajas más grandes que le ves, @Majestic Gold?
@MarkTin20004 жыл бұрын
@@ManuelZapata el rendimiento de la aplicación puede verse afectado cada que un usuario crece más que otro. Y respecto al costo me parece que solo en un principio puede verse como un ahorro sin embargo al paso del tiempo y al ir creciendo la BD los costos van a crecer más rápido.
@nelsonscript4 жыл бұрын
@@MarkTin2000 no es tan así si tienes lo combinas con una arquitectura de microservicios donde escale según la demanda de la aplicación y soportado por un buen proveedor en cloud.
@ahelord2 жыл бұрын
Tenant es inquilino no tenedor.
@ManuelZapata2 жыл бұрын
Inquilino suena mucho mejor. Gracias por la corrección.
@MarcosHernandez_VE3 жыл бұрын
Multi-tenencia??? 🤔 creo que ese nombre fue inventado por este canal jajajaja
@ManuelZapata3 жыл бұрын
jejeje ya quisiera yo atribuirme el nombre.
@MarcosHernandez_VE3 жыл бұрын
@@ManuelZapata jajajaja se que no, sólo lo dije en broma
@ComisarioLobo4 жыл бұрын
Tienes buen contenido, pero tienes que dejar de decir LISTO cada 10 segundos
@ManuelZapata4 жыл бұрын
Gracias por el comentario. Ya me lo habian hecho notar. Estoy trabajando en corregir la muletilla. No siempre es fácil.
@ComisarioLobo4 жыл бұрын
@@ManuelZapata perfecto Manuel, sigue adelante con el canal ya que hay muy poco contenido de arquitectura de software
@williand.5293 жыл бұрын
Excelente contenido, gracias por compartir tus conocimientos.