O conceito de muitos usuários de uma
mesma aplicação está presente desde os primórdios da programação, mas o
conceito como o conhecemos hoje só surgiu com o SaaS (Software as a Service). Este artigo é útil, pois com ele vamos aprender
as possíveis arquiteturas das aplicações Multi-Tenant utilizando o ASP.NET MVC.
Além disso, veremos como os múltiplos usuários vão interagir com a aplicação,
cada um dentro de seu espaço e com suas regras de negócios, sem invasões.
Quando estamos desenvolvendo aplicações, normalmente temos um público-alvo em mente, um usuário (ou uma série deles) que, teoricamente, irá utilizar essa aplicação.
Essa é uma premissa básica do desenvolvimento de software. Entretanto, quando criamos aplicações que serão utilizadas por múltiplos usuários, também precisamos lidar com as necessidades individuais de cada um deles.
Hoje em dia, não existe mais aquele negócio de que o usuário precisa se adaptar à solução criada: o contrário é muito mais comum – as empresas precisam adaptar suas soluções para criar experiências cada vez melhores para os usuários.
Na prática, isso significa que estaremos lidando com várias necessidades similares em uma mesma aplicação.
Mas vale a ressalva: é preciso um certo cuidado com essas “similaridades” – não vamos criar uma aplicação Multi-Tenant para um usuário do agronegócio e uma loja de sapatos – nesse caso, há muito mais diferenças do que similaridades entre as regras de negócios.
A lógica é relativamente simples de ser entendida, embora mais complexa de ser implementada: regras de negócios similares fazem valer a criação de uma aplicação Multi-Tenant, como, por exemplo, uma aplicação para agricultores e agropecuaristas, onde cada um deles possui necessidades específicas, como uma ideia similar por trás de tudo.
O objetivo deste artigo é que o leitor, ao final, tenha uma ideia básica de como aplicar alguns conceitos dessa arquitetura e possa lidar com as similaridades e as diferenças entre as necessidades de cada usuário de forma melhor.
Traremos as possíveis arquiteturas de dados para esse tipo de aplicação, indicando algumas possibilidades para o leitor, e faremos um exemplo baseado em uma delas: um schema básico da base de dados seguido de extensões específicas para dois tipos de usuários, uma das abordagens mais comuns para o desenvolvimento Multi-Tenant.
Software as a Service (SaaS) vs Multi-Tenant
O conceito de Software as a Service (SaaS) costuma andar lado a lado com as aplicações Multi-Tenant, como as conhecemos hoje.
Isso não significa que toda aplicação Multi-Tenant será um exemplo de SaaS, mas é o mais comum a ser feito. O que acontece é que as aplicações Multi-Tenant, pela forma como são estruturadas, permitem a adição de usuários (tenants) com certa facilidade, o que se encaixa na forma de utilização do SaaS.
Mas afinal, o o que é o Software as a Service? Como o nome sugere, trata-se de um “Software como Serviço” (em uma tradução literal). Em outras palavras, temos um produto de software que é desenvolvido e vendido como se fosse um serviço, de diversas formas.
Atualmente, vemos exemplos de SaaS sendo contratados mensalmente, diariamente, por utilização, ou ainda outras formas de utilização, dependendo do negócio a que o software se propõe.
Em uma definição mais completa, Software as a Service é um modelo de negócios para software. Um modelo de licenciamento e utilização de software que vem ganhando cada vez mais espaço, especialmente porque o mundo, globalizado como está, praticamente não suporta softwares de prateleiras, muito comuns no começo do século.
Os usuários entenderam os benefícios de gastar menos, inicialmente, e “contratar” um software, bem como as empresas entenderam que receber periodicamente dos usuários é mais interessante, a longo prazo, do que receber pelas vendas do software apenas uma vez.
A grande sacada do SaaS é que ele não está restrito ao que estava proposto pelo software, ou seja, não está limitado a uma solução genérica que se encaixa em vários tipos de problemas. A ideia é que nós, desenvolvedores, tenhamos a possibilidade de criar soluções específicas para cada usuário, partindo de uma base comum a vários deles.
E isso acaba sendo melhor para todos: desenvolvedores, que trabalham mais (e consequentemente recebem mais) e usuários, que recebem um produto adaptado à suas necessidades.
O conceito de Software as a Service sofreu muito com problemas na segurança dos dados, logo que foi lançado. Isso acabou atrasando um pouco sua “dominação” do mercado.
As empresas ficaram com medo de sair de um modelo mais seguro, uma vez que todo o software estava instalado localmente, para um modelo com alguns problemas de segurança onde, além disso, não era possível sabermos onde os dados estavam armazenados.
Esse evento acabou ocorrendo pela presença de software de baixa qualidade nesse quesito, somado à baixa segurança para o armazenamento de dados na internet.
Com o avanço da computação em nuvem, entretanto, vimos um avanço também nas tecnologias SaaS e Multi-Tenant. Temos, hoje, servidores extremamente robustos para esse tipo de projeto de software, o que faz com que as empresas poupem muito em infraestrutura, podendo comprar a utilização da infraestrutura presente no Microsoft Azure ou nas nuvens da Amazon ( BOX 1), por exemplo. Com isso, temos SaaS sendo desenvolvidos e distribuídos mais rapidamente para o usuário final.
O conceito de IaaS, ou Infraestrutura como Serviço, tem no Azure seu principal exemplo. Assim como o SaaS, o IaaS traz um conceito simples: estamos contratando o serviço de infraestrutura de uma empresa.
Esse conceito é extremamente útil, pois evita que empresas menores (ou mesmo as maiores) precisem gastar muito dinheiro em sua própria infraestrutura para guardar seus dados ou colocar suas soluções na internet.
As nuvens da Amazon são outro exemplo clássico desse tipo de serviço, e há muitos outros disponíveis. Esses serviços são extremamente completos e trazem, entre outras possibilidades, o armazenamento de dados, o processamento de tarefas e a hospedagem de websites ou outros softwares.
