Valeu por compartilhar, muito claro e objetivo, vamos começar a implementar alguns SAAS aqui na empresa e este vídeo já me deu um belo norte, agradeço.
Parabéns pela aula. Estou desenvolvendo um Marketplace em PHP, com o fim de suportar um e-commerce multi-lojas, então penso que seja exatamente o modelo de Saas Multi Tenancy com isolamento lógico conforme seus esclarecimentos. Se fosse recomendar um banco de dados pro meu caso qual escolheria, entre o PostgreSQL e o MySql? Desde sou muito grato por compartilhar seu conhecimento Luiz!
Conceitualmente explicado algo que por natureza é complexo, de uma forma muito simples, pude notar que você menciona muito sobre isolamento lógico e físico, achei que o isolamento lógico poderia ser um pouco mais explorado no sentido de que ele não necessariamente será feito por um id na tabela, mas também bases de dados separadas como bem mencionastes assim como por meio de schemas dentro de uma mesma base de dados (este um pouco mais específico pois depende muito do banco que você está usando). Um outro ponto que daria pra dar uma aprofundada é na influencia que as regras de negócio do teu produto tem sobre o tipo de arquitetura de tenancy a ser abordado e como trabalhar a escalabilidade em cases mais específicos que tendem a fugir do padrão conceitual. Acho que esses dois pontos renderiam bons conteúdos complementares. No momento que faço esse comentário não tenho conhecimento se você tem algo neste sentido publicado aqui no TH-cam.
Se fizer bases de dados separadas não é mais isolamento lógico, se tornou físico. Trabalho melhor estes conceitos, e na prática em alguns de meus cursos, o vídeo é apenas uma introdução mesmo. Obrigado pela contribuição.
Descendo o nível, no postgres por exemplo, é possível fazer isolamento via schemas, e via multi databases. Porém ainda é a mesma string de conexão. Ou seja, a mesma instância do postgres no servidor.
Poderíamos dizer então que todo sistema na verdade é multi-tenancy e que um sistema multi usuário padrão seja na verdade um tipo especifico de multi-tenancy com, somente, um tenancy? Acredito que no SaaS que estou desenvolvendo acabei utilizando esse modelo logico por pura...logica rsrs sem nem conhecer essa solução/padrão arquitetural. Só não entendi do porque ter que passar na requisição um ID especificando o tenancy, isso não acaba sendo embutido no atributo "sub" do jwt na maioria das aplicações monolitos "modernas" (back/front separado)? Ou não entendi nada? Além disso, qual a probabilidade ( ao menos de um jwt forjado ) de um usuario visualizar recursos que não sejam deles ( usando esse approach do tenancy via sub jwt ) se qualquer ação dele será filtrada a partir do ID tenancy dele? Tem outros problemas de segurança que não estou enxergando? Obrigado pelo conteudo, bem explicado por sinal
Não, sistemas são single tenant por padrão (o seu sistema operacional que está usando agora é um exemplo, não tem nada de multi-tenant nele), a menos que esteja falando SOMENTE de SaaS, aí sim, eles são construídos para serem multi-tenant na maioria dos casos. Sistemas multi-tenant são desenvolvidos especificamente para tal, eles não são o padrão. Sobre chamar um sistema multi-usuário de "multi-tenancy de um tenancy só"...não faz sentido pois se não há a capacidade de adicionar tenants nele, então ele simplesmente não é multi-tenant. Ponto. Sobre informar o tenant via JWT ou outro tipo de token ou cookie, é uma possibilidade sim. A solução informada na URL é comum quando você tem usuários que vão acessar diretamente seu tenant (como no caso das soluções da Atlassian) ou ainda quando a separação é física (senão me engano as soluções enterprise da SAP e Microsoft são assim). Muitas vezes o tenant estar visível no subdomínio é um requisito desejável de usabilidade, outra vezes ajuda na performance. Sobre brechas de segurança, tem várias possibilidades, a depender de como implementar a sua arquiteturas, suas validações, etc. Pegue todas as brechas possíveis em uma aplicação web comum e eleve ao número de tenants, esse é o conjunto de possibilidades de dar problema, haha. Um dos casos mais famosos que eu me lembro foi esse da Salesforce há alguns anos: invenioit.com/continuity/salesforce-outage/
@@lucastavares7767 Parcela em 6x sem juros ou até 12x com juros. Se você só sabe o básico, recomendo fazer a playlist de Node.js que tem aqui no canal, vai te ajudar a dar mais um up, e no curso tem um nivelamento logo no início também que vai ajudar. Link da playlist: th-cam.com/video/bmhFFFAxve0/w-d-xo.html
Oi Luiz boa noite. Cara valeu pela explicação. Mas só uma pequena luz, por favor. Um sistema de contra-cheque online por exemplo, é um multiusuários ou um multitenancy? Brigado desde já!
Se todos os contra-cheques são de funcionários da mesma empresa, então o sistema tem apenas um tenant, a empresa em si e vários usuários, os funcionários. Agora se o sistema atende várias empresas diferentes, cada uma administrando seus funcionários de maneira isolada, então é multi-tenant.
Eu sem saber dessa técnica "inventei" uma "gambiarra" no nome das tabelas. Tenho uma tabela de clients onde ficam todas as informações dos clientes, no caso o seu catálogo. E nas tabelas eu colocava o id no nome da tabela, dessa forma: 1234_users 1234_messages 1234_history E assim por diante, já viu ser feito dessa forma? Não sei, colocar tudo na mesma tabela me faz parecer que vai ficar lento pra executar as queries o tempo todo. Não acha? Me parece mais arriscado tbm fazer modificações na numa tabela onde estão não só as informações do cliente atual como de todos os clientes, como vc falou
O catálogo é um conceito não necessariamente uma tabela, eu colocaria essa informação na tabela mas manteria cópia do catálogo em cache, em um Redis por exemplo, o acesso seria estupidamente rápido. Mesmo que faça em banco, com a consulta sendo via chave primária ou índice, o tempo sempre será O(1) por ser um index scan, então não precisa se preocupar, os próprios bancos SQL têm mecanismos de cache para acelerar consultas repetidas.
Muito bom! Acho que é a dúvida clássica de todo empreendedor quando vai começar um SaaS...rs
Sim, haha
Excelente! De tudo o que ja ví sobre Tenant, essa foi a explicação mais clara e objetiva.
Fico feliz que tenha gostado. :D
Incrível 👍
Fico feliz que tenha gostado.
Entendi agora ❤
Fico feliz em saber Ricardo!
Valeu por compartilhar, muito claro e objetivo, vamos começar a implementar alguns SAAS aqui na empresa e este vídeo já me deu um belo norte, agradeço.
Fico feliz em ter ajudado. Caso queira algo mais prático, meu curso de Web FullStack JS e a Expansão Hydra do Beholder podem ajudar.
Conteúdo excelente
Valeu Uelder!
Passei um tempo pensando em como ter bancos isolados (um banco por cliente) até que cheguei nesse conceito do “catálogo”. Ótima explicação. Obrigado.
Fico feliz por ter ajudado.
Pouco conteúdo em português sobre, aguardando o curso do beholder + vip abrir !
Anota aí: 09/02. Primeiro e melhor dia para se inscrever no Beholder em 2023!
Muito bom ! Gostei bastante, obrigado !
Fico feliz que tenha gostado!
Excelente conteúdo Luiz, fez uma ótima e clara explicação.
Valeu pelo feedback André!
Parabéns pela aula. Estou desenvolvendo um Marketplace em PHP, com o fim de suportar um e-commerce multi-lojas, então penso que seja exatamente o modelo de Saas Multi Tenancy com isolamento lógico conforme seus esclarecimentos. Se fosse recomendar um banco de dados pro meu caso qual escolheria, entre o PostgreSQL e o MySql? Desde sou muito grato por compartilhar seu conhecimento Luiz!
Eu faria com MySQL por estar mais acostumado, mas qualquer uma das duas opções vai lhe atender bem. Fico feliz que tenha gostado do vídeo.
Top top top
bom dia luis,, eu to comecando uma aplicacao web e eu gostaria de usar abordagem saas, eu gostaria de ter acesso ao curso ?
O curso está disponível para novas inscrições neste link: www.luiztools.com.br/curso-fullstack
Conceitualmente explicado algo que por natureza é complexo, de uma forma muito simples, pude notar que você menciona muito sobre isolamento lógico e físico, achei que o isolamento lógico poderia ser um pouco mais explorado no sentido de que ele não necessariamente será feito por um id na tabela, mas também bases de dados separadas como bem mencionastes assim como por meio de schemas dentro de uma mesma base de dados (este um pouco mais específico pois depende muito do banco que você está usando).
Um outro ponto que daria pra dar uma aprofundada é na influencia que as regras de negócio do teu produto tem sobre o tipo de arquitetura de tenancy a ser abordado e como trabalhar a escalabilidade em cases mais específicos que tendem a fugir do padrão conceitual.
Acho que esses dois pontos renderiam bons conteúdos complementares.
No momento que faço esse comentário não tenho conhecimento se você tem algo neste sentido publicado aqui no TH-cam.
Se fizer bases de dados separadas não é mais isolamento lógico, se tornou físico. Trabalho melhor estes conceitos, e na prática em alguns de meus cursos, o vídeo é apenas uma introdução mesmo. Obrigado pela contribuição.
Descendo o nível, no postgres por exemplo, é possível fazer isolamento via schemas, e via multi databases. Porém ainda é a mesma string de conexão. Ou seja, a mesma instância do postgres no servidor.
Luiz, conhece o PostgreSQL Row Level Security pra implementar multitenancy?
Infelizmente não tenho muita experiência com PostgreSQL a ponto de conhecer esta funcionalidade.
Poderíamos dizer então que todo sistema na verdade é multi-tenancy e que um sistema multi usuário padrão seja na verdade um tipo especifico de multi-tenancy com, somente, um tenancy?
Acredito que no SaaS que estou desenvolvendo acabei utilizando esse modelo logico por pura...logica rsrs sem nem conhecer essa solução/padrão arquitetural.
Só não entendi do porque ter que passar na requisição um ID especificando o tenancy, isso não acaba sendo embutido no atributo "sub" do jwt na maioria das aplicações monolitos "modernas" (back/front separado)? Ou não entendi nada?
Além disso, qual a probabilidade ( ao menos de um jwt forjado ) de um usuario visualizar recursos que não sejam deles ( usando esse approach do tenancy via sub jwt ) se qualquer ação dele será filtrada a partir do ID tenancy dele? Tem outros problemas de segurança que não estou enxergando?
Obrigado pelo conteudo, bem explicado por sinal
Não, sistemas são single tenant por padrão (o seu sistema operacional que está usando agora é um exemplo, não tem nada de multi-tenant nele), a menos que esteja falando SOMENTE de SaaS, aí sim, eles são construídos para serem multi-tenant na maioria dos casos. Sistemas multi-tenant são desenvolvidos especificamente para tal, eles não são o padrão. Sobre chamar um sistema multi-usuário de "multi-tenancy de um tenancy só"...não faz sentido pois se não há a capacidade de adicionar tenants nele, então ele simplesmente não é multi-tenant. Ponto.
Sobre informar o tenant via JWT ou outro tipo de token ou cookie, é uma possibilidade sim. A solução informada na URL é comum quando você tem usuários que vão acessar diretamente seu tenant (como no caso das soluções da Atlassian) ou ainda quando a separação é física (senão me engano as soluções enterprise da SAP e Microsoft são assim). Muitas vezes o tenant estar visível no subdomínio é um requisito desejável de usabilidade, outra vezes ajuda na performance.
Sobre brechas de segurança, tem várias possibilidades, a depender de como implementar a sua arquiteturas, suas validações, etc. Pegue todas as brechas possíveis em uma aplicação web comum e eleve ao número de tenants, esse é o conjunto de possibilidades de dar problema, haha. Um dos casos mais famosos que eu me lembro foi esse da Salesforce há alguns anos: invenioit.com/continuity/salesforce-outage/
@@LuizTools Muito obrigado pela resposta exaustiva Luiz, realmente esclareceu bastante minhas ideias.
Prof, daria certo criar um sistema multitenant utilizando a arquitetura limpa?
Sim, não são arquiteturas excludentes. Multitenancy encaixa bem com qualquer outro padrão estrutural como Clean Arch, Hexagonal, MVC, etc.
@@LuizToolsShowww, muito obrigado pela resposta, estou estudando comprar o seu curso de Fullstack Web para mim aprender como criar meu primeiro SaaS.
@@lucastavares7767 O curso é dedicado a esse assunto, do zero em SaaS até produção, acho que vai gostar.
@@LuizTools showww, vou comprar sim, parcela no cartão de crédito? É indicado para quem sabe o básico de javascript?
@@lucastavares7767 Parcela em 6x sem juros ou até 12x com juros. Se você só sabe o básico, recomendo fazer a playlist de Node.js que tem aqui no canal, vai te ajudar a dar mais um up, e no curso tem um nivelamento logo no início também que vai ajudar. Link da playlist: th-cam.com/video/bmhFFFAxve0/w-d-xo.html
Oi Luiz boa noite. Cara valeu pela explicação. Mas só uma pequena luz, por favor. Um sistema de contra-cheque online por exemplo, é um multiusuários ou um multitenancy? Brigado desde já!
Se todos os contra-cheques são de funcionários da mesma empresa, então o sistema tem apenas um tenant, a empresa em si e vários usuários, os funcionários. Agora se o sistema atende várias empresas diferentes, cada uma administrando seus funcionários de maneira isolada, então é multi-tenant.
@@LuizTools Valeu pelo esclarecimento. Obrigado!
Eu sem saber dessa técnica "inventei" uma "gambiarra" no nome das tabelas.
Tenho uma tabela de clients onde ficam todas as informações dos clientes, no caso o seu catálogo.
E nas tabelas eu colocava o id no nome da tabela, dessa forma:
1234_users
1234_messages
1234_history
E assim por diante, já viu ser feito dessa forma?
Não sei, colocar tudo na mesma tabela me faz parecer que vai ficar lento pra executar as queries o tempo todo. Não acha?
Me parece mais arriscado tbm fazer modificações na numa tabela onde estão não só as informações do cliente atual como de todos os clientes, como vc falou
O catálogo é um conceito não necessariamente uma tabela, eu colocaria essa informação na tabela mas manteria cópia do catálogo em cache, em um Redis por exemplo, o acesso seria estupidamente rápido.
Mesmo que faça em banco, com a consulta sendo via chave primária ou índice, o tempo sempre será O(1) por ser um index scan, então não precisa se preocupar, os próprios bancos SQL têm mecanismos de cache para acelerar consultas repetidas.