Infelizmente, este termo não tem um bom equivalente em russo. A «Wikipedia» fornece «multi-inquilinos, aluguel múltiplo». Às vezes, isso é chamado de «propriedade múltipla». Esses termos podem causar alguma confusão, uma vez que o assunto não está essencialmente relacionado a aluguel ou propriedade. Trata-se de uma questão de arquitetura de software e da organização de sua operação. E esta última é igualmente importante.
Começamos a formar nossa compreensão sobre multitenancy ao mesmo tempo em que começamos a projetar uma abordagem para o modelo de trabalho em nuvem (serviço) do «1C:Enterprise». Isso foi há alguns anos. Desde então, nossa compreensão vem se expandindo continuamente. Estamos constantemente descobrindo novos e novos aspectos (prós, contras, dificuldades, peculiaridades, etc.) sobre esse assunto.
Às vezes, os desenvolvedores entendem multitenancy como uma questão bastante simples: «para que os dados de várias organizações sejam armazenados em um único banco de dados, é necessário adicionar uma coluna com o identificador da organização a todas as tabelas e aplicar um filtro sobre ela». Nós também, é claro, começamos nossa reflexão sobre o assunto a partir desse ponto. Mas rapidamente percebemos que esta é apenas uma pequena parte (que também não é simples). Na verdade, é «um verdadeiro país».
A ideia principal de multitenancy pode ser descrita da seguinte maneira. Um aplicativo comum é uma casa unifamiliar, planejada para o uso de uma única família, que utiliza sua infraestrutura (paredes, telhado, abastecimento de água, aquecimento, etc.). Já um aplicativo multitenancy é um prédio de apartamentos. Nele, cada família utiliza um conjunto semelhante de infraestrutura, mas essa infraestrutura é implementada para todo o prédio como um todo.
E a abordagem multitenancy – é boa ou ruim? Pode-se encontrar opiniões muito diversas sobre isso. Parece que não existe um «bom ou ruim» absoluto. É preciso comparar os prós e contras no contexto de tarefas específicas a serem resolvidas. Mas esse é um tema à parte...
Em termos mais simples, o objetivo do multitenancy é reduzir os custos de manutenção do aplicativo por meio da «compartilhamento» das despesas com infraestrutura. É um movimento semelhante à redução do custo do aplicativo por meio da utilização de uma solução padronizada (possivelmente, com configuração e personalização), e não da criação sob medida. Apenas em um caso, o desenvolvimento é compartilhado, enquanto no outro, a operação.
De fato, repetimos, aqui não há uma ligação direta com o modo de venda. A arquitetura de multitenancy pode ser aplicada também em infraestruturas de TI corporativas ou governamentais para automatizar um grande número de filiais ou empresas de um grupo.
Pode-se dizer que multitenancy não é apenas uma questão de organização do armazenamento de dados. É um modelo de operação de aplicativo como um todo (incluindo uma parte substancial dos aspectos de sua arquitetura, seu modelo de implantação e a organização da manutenção).
O aspecto mais desafiador e interessante do modelo de multitenancy, ao nosso ver, é que a essência do aplicativo se "dobra". Uma parte da funcionalidade lida com áreas de dados específicas (apartamentos) e "não se interessa" pelo que acontece com os residentes em outros apartamentos. Enquanto a outra parte vê o prédio como um todo e opera simultaneamente para todos os residentes. No entanto, esta última não consegue abstrair o fato de que ainda são apartamentos separados e é necessário garantir o nível adequado de granularidade e segurança.
No "1C:Enterprise", o modelo de multitenancy é implementado em nível de várias tecnologias. Esses são os mecanismos da plataforma "1C:Enterprise", mecanismos de” e “mecanismos (bibliotecas de subsistemas padrão).
Cada um desses itens contribui para a construção da infraestrutura geral de um prédio de apartamentos. Por que isso é implementado em várias tecnologias, e não em uma única, como na plataforma? Antes de tudo, porque parte dos mecanismos, em nossa opinião, merece ser modificada de acordo com a variante específica de implantação. Mas, de modo geral, essa não é uma questão simples, e constantemente nos deparamos com a escolha de em qual nível é melhor implementar determinado aspecto do multitenancy.
É óbvio que a parte básica dos mecanismos precisava ser implementada na plataforma. Por exemplo, a separação de dados em si. Isso é normalmente o ponto de partida da discussão sobre multitenancy. Mas, ao final, o modelo de multitenancy passou por uma parte significativa dos mecanismos da plataforma e exigiu ajustes, e em alguns casos, até uma reinterpretação.
No nível da plataforma, implementamos os mecanismos básicos. Eles permitem a criação de aplicativos que operam no modelo multitenancy. Mas para que os aplicativos "vivam e funcionem" nesse modelo, é necessário ter um sistema de gestão de seu "ciclo de vida". Isso é gerido pelas tecnologias 1cFresh e por uma camada unificada de lógica de negócios no nível do BSP. Assim como em um prédio de apartamentos, a infraestrutura fornece aos moradores tudo o que é necessário, as tecnologias 1cFresh também fornecem tudo o que é necessário para os aplicativos que operam no modelo de multitenancy. Para que os aplicativos possam interagir com essa infraestrutura (sem necessidade de modificações significativas), eles incluem os correspondentes "conectores" na forma de subsistemas do BSP.
Do ponto de vista dos mecanismos da plataforma, é fácil notar que, à medida que adquirimos experiência e avançamos com a opção de uso em nuvem do "1C:Enterprise", ampliamos os mecanismos envolvidos nesta arquitetura. Um exemplo disso é que, no modelo de multitenancy, a disposição dos papéis dos participantes na manutenção dos aplicativos muda significativamente. O papel (nível de responsabilidade) daqueles que são responsáveis pela exploração dos aplicativos se torna muito mais importante. Eles agora precisam ter ferramentas de controle mais robustas. Isso porque os usuários dos aplicativos (moradores) confiam, acima de tudo, no provedor com o qual estão trabalhando. Para isso, implementamos na versão 8.3 um novo . Este mecanismo permite que os administradores do provedor restrinjam a liberdade dos desenvolvedores de aplicativos ao nível de segurança necessário – essencialmente, isolar o funcionamento do aplicativo para cada morador dentro de certos limites de uma "caixa de areia" (sandbox).
A arquitetura para gerenciar aplicativos que operam em modo multitenancy (como é implementado nas tecnologias 1cFresh e BSP) também desperta um grande interesse. Aqui, em comparação com o modelo tradicional de implantação, os requisitos para a automação dos processos de gerenciamento aumentam significativamente. Existem dezenas desses processos: criação de novas áreas de dados ("apartamentos"), atualização de aplicativos, atualização de informações regulatórias, backup etc. E, claro, os requisitos para níveis de confiabilidade e disponibilidade também crescem. Por exemplo, para garantir uma interação confiável entre os aplicativos e os componentes do sistema de gerenciamento, implementamos uma tecnologia de sistema de chamadas assíncronas com entrega garantida.
Um ponto muito sutil é a forma de compartilhar dados e processos. À primeira vista, isso pode parecer simples (para alguns pode parecer). O maior desafio é encontrar o equilíbrio entre a centralização de dados e processos e a descentralização. De um lado, a centralização permite reduzir despesas (espaço em disco, recursos do processador, esforços dos administradores...). Por outro lado, limita a liberdade dos "moradores". Este é exatamente um dos aspectos da "duplicidade" do aplicativo, onde o desenvolvedor precisa pensar simultaneamente sobre o aplicativo em um sentido restrito (servindo um "apartamento") e em um sentido amplo (servindo a todos os "moradores").
Um exemplo dessa "dilema" pode ser encontrado nas informações regulatórias. É claro que é tentador torná-las comuns a todos os "moradores" do prédio. Isso permite armazená-las em uma única cópia e atualizá-las simultaneamente para todos. Mas há casos em que um morador precisa de alterações específicas. Estranhamente, isso ocorre na prática, mesmo para informações que são especificadas por reguladores (órgãos governamentais). Surge uma pergunta complexa: compartilhar ou não compartilhar? É tentador, é claro, criar informações comuns para todos e específicas para aqueles que desejam. E isso já leva a uma implementação bastante complicada. Mas estamos trabalhando nessa questão...
Um exemplo adicional é o projeto de implementação de processos regulares (executados de acordo com um cronograma, iniciados pelo sistema de gerenciamento, etc.). Por um lado, eles podem ser implementados para cada área de dados separadamente. Isso é mais simples e conveniente. Mas, por outro lado, essa granularidade fina cria uma grande carga sobre o sistema. Para reduzir a carga, é necessário implementar processos centralizados. No entanto, eles exigem um trabalho mais cuidadoso.
Certamente, surge uma questão bastante importante. Como os desenvolvedores de aplicativos podem garantir a operação em um modo de multitenancy? O que eles precisam fazer para isso? Claro, buscamos que o peso das questões tecnológicas e infraestruturais recaia o máximo possível sobre a tecnologia fornecida, para que o desenvolvedor do aplicativo se concentre apenas nas tarefas da lógica de negócios. Mas, assim como com outras questões arquitetônicas importantes, os desenvolvedores de aplicativos precisam ter uma noção sobre como funciona o modelo de multitenancy, e alguns esforços serão necessários no desenvolvimento de aplicativos. Por quê? Porque há aspectos que a tecnologia não pode garantir automaticamente sem considerar a semântica dos dados. Por exemplo, a definição das fronteiras de compartilhamento das informações. Mas nos esforçamos para que essas complexidades sejam mínimas. Já existem exemplos da implementação de tais aplicativos.
Um ponto importante no contexto da implementação de multitenancy no «1С:Предприятие» é que estamos criando um modelo híbrido, no qual um aplicativo pode funcionar tanto em modo de multitenancy quanto em modo normal. Essa é uma tarefa bastante complexa e um tema para discussão separada.
Fonte: habr.com
