Josino Rodrigues Neto

Transcrição

1 Desenvolvimento de aplicações multi-tenancy: um estudo de mapeamento sistemático Por Josino Rodrigues Neto Dissertação de Mestrado Universidade Federal de Pernambuco RECIFE, Junho/2012

2 Universidade Federal de Pernambuco Centro de Informática Pós-graduação em Ciência da Computação Josino Rodrigues Neto Desenvolvimento de aplicações multi-tenancy: um estudo de mapeamento sistemático Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Orientador: Silvio Romero de Lemos Meira Co-Orientador: Vinicius Cardoso Garcia RECIFE, Junho/2012

3 Eu dedico essa dissertação primeiramente à minha família, aos meus amigos e aos meus professores que me deram todo o suporte necessário para chegar até aqui. Em especial agradeço a Deus por ter colocado todas essas pessoas no meu caminho.

4 Agradecimentos Agradeço a Deus, por ter me dado uma família linda. À minha esposa, Késia(in memorian) por ter me incentivado a continuar mesmo quando eu pensava que nada iria dar certo. À minha filha Sara, que aprendeu a usar o skype sozinha pra conseguir conversar comigo enquanto trabalhava na minha dissertação. À minha mãe, Dona Susana que me apoiou no momento mais difícil da minha vida e que sempre esteve ao meu lado. Aos meus amigos Carlos Portela, Brunno Wagner e Andreza Leite pela madrugadas em claro estudando e fazendo trabalhos das disciplinas(as SCRUMadrugadas). Isso deu resultado, tivemos conceito A em todas as disciplinas amigos. Minha amiga Andreza Leite também foi muito útil nas revisões da minha dissertação, deu contribuições de precisão cirúrgia ao meu trabalho. Ao meu amigo Wilton, que embora tenha pago algumas cadeiras comigo eu só conheci de verdade quando descobri que ele dividia apartamento com meu melhor amigo piauiense residente em Recife, Julio Damasceno. Julio Damasceno diga-se de passagem, um nerd++ com o qual eu tive a oportunidade de trabalhar por muitos anos e aprender tudo que sei sobre Linux. A todos os outros amigos que conheci no mestrado e com os quais eu aprendi diversas coisas diferentes: Kadna, Thalita, Danielle, Fish, Elaine, Emanuel e Viviane(Vivi). Agradeço também por todos os meus amigos da Rise: Marinho, Rafael, Leonardo, Alexandro, Luiz e em especial Eduardo Cruz por terem me proporcionado bons momentos de aprendizado na incubadora do Porto Digital, ajudando na implementação prática da minha dissertação. Gostaria de agradecer aos meus amigos da FJB(Força Jovem Brasil), aos que são piauienses(jezlia Resende, Ângela Núbia, Eulálio Pereira e Amanda Patricia) e aos que são pernambucanos(aqui não vou citar nomes porque são muitos). Todo essas pessoas foram um suporte pra mim nas horas vagas. Era com eles que eu realizava as atividades filantrópicas que me fizeram crescer como ser humano. Dentre esses gostaria de agradecer especialmente à Dra Jezlia Resende por ter revisado alguns trechos da minha dissertação e ajudado corrigir alguns detalhes do português. Por fim, mas não mais importante queria agradecer aos meus mestres e orientadores Silvio Meira, Vinícius Garcia e Paulo Anselmo por terem me ajudado a organizar minhas idéias em uma dissertação e transforma-las em ciência de verdade. Muito Obrigado a todos. iv

5 Eu vou marcar a minha geração Vou conquistar a minha posição Se eu acreditar no sonho Vou realizar Chegou a minha vez Não vou ter medo de tentar Eu sei, quem sabe faz a hora É hora de lutar. SONOROS (Força Jovem Brasil)

6 Resumo De forma crescente, Software como serviço (SaaS) está se tornando uma forma dominante de entrega de software aos usuários. Da perspectiva dos provedores de serviço, os benefícios de SaaS mostram-se através da economia de escala, pela oferta de software a um grande número de consumidores através de uma instância compartilhada de software. Uma forma de implementar SaaS é através da adoção de multi-tenancy, uma abordagem para a implementação de SaaS que divide a instância de uma aplicação em várias aplicações virtuais chamadas tenants. Para prover software desse tipo é necessário levar em consideração vários aspectos como segurança, alocação de recursos, customização, escalabilidade, armazenamento de dados, reuso, etc. Esse trabalho visa, apartir de um mapeamento sistemático, identificar o estado da arte de multi-tenancy, propostas de implementação e principais lacunas existentes nessa área através da análise dos principais trabalhos publicados sobre o assunto. Ao final desse trabalho é apresentado aplicação desses conceitos na indústria. vi

7 Abstract Increasingly, Software as a Service (SaaS) is becoming a dominant form of software delivery to users. From perspective of service providers, the benefits of SaaS are shown through economies of scale, by offering software to a large number of consumers through a shared instance of software. One way to implement SaaS is through multi-tenancy, an approach to the implementation of SaaS that divides the instance of an application in various virtual applications called tenants. To offer this type of software is necessary to take into account various aspects such as security, resource allocation, customization, scalability, data storage, reuse, etc. This paper aims to start a systematic mapping to identify the state of the art of multi-tenancy, implementation proposals and major gaps in this area through the analysis of the main papers on the subject. At the end of this study is presented applying these concepts in the industry. vii

8 Sumário Lista de Figuras Lista de Tabelas Lista de Siglas xi xiii xiv 1 Introdução Motivação Objetivos Objetivos Gerais Objetivos Específicos Metodologia Contribuições científicas Estrutura da dissertação Fundamentação Teórica Cloud Computing SaaS - Software como Serviço Multi-tenancy Considerações Finais Metodologia de Seleção de Trabalhos Acerca de Multi-tenancy Diretivas de pesquisa Pesquisa exploratória Definição de Questões de Pesquisa Seleção dos dados Condução da pesquisa Triagem dos Trabalhos Classificação Esquema de Classificação Classificação dos trabalhos relevantes Principais Descobertas Alocação de Recursos Banco de Dados Customização viii

9 3.4.4 Escalabilidade Migração Monitoramento Performance Segurança SOA Mapeamento das evidências Q1 - Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy? Q2 - Quais as propostas existentes para implementação da arquitetura multi-tenancy? Frameworks Ferramentas Métodos ou Técnicas Modelos Propostas de Arquitetura Q3 - Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicação multi-tenancy Q4 - Quando a adoção da arquitetura multi-tenancy é viável? Discussão Ameaças a validade Considerações Finais Aplicação na Indústria Problema Metodologia Definição de Arquitetura Identificação dos objetivos da Arquitetura Visão geral da aplicação Pontos Críticos e Soluções Proposta de solução de arquitetura Autenticação Configuração Banco de dados (Database) Tecnologias Prototipagem ix

10 4.4 Migração do Sistema Considerações Finais Conclusão e Trabalhos Futuros Contribuições Trabalhos Futuros Referências Bibliográficas 96 Appendices 111 A Estudos Primários 112 x

11 Lista de Figuras 1.1 Cauda Longa(Adaptada de: (Chong and Carraro, 2006)) Empresas de software globais vêem seu pecentual de venda de produtos diminuirem de 70 por cento em 1990 para menos de 50 por cento em 2003(Adaptada de: (Cusumano, 2008)) Empresas de software corporativo baseado em web tem adotado uma varidade de modelos de negócio. Pagamento de assinatura mensal é o modelo de pagamento mais popular (Adaptada de: (Cusumano, 2008)) Hype Cycle para Cloud Computing((Smith, 2011)) Resumo da Metodologia(Elaboração própria) Modelos de serviço de Cloud Computing Amazon S3 s Growth(Huang, 2011a) Níveis de Maturidade SaaS(Chong and Carraro, 2006) Processo de Mapeamento Sistemático - Adaptado de (Petersen et al., 2008) Percentual de estudos retornados de acordo com a estratégia de busca Percentual de estudos retornados pelas buscas automáticas Quantidade de artigos por questão Quantidade de artigos por contexto Quantidade de artigos por contribuição Quantidade de artigos agrupados por Contexto e Ano Quantidade de artigos agrupados por Contexto e Contribuição Quantidade de artigos agrupados por Contexto e Tipo de Pesquisa Quantidade de artigos agrupados por Questão e Tipo de Pesquisa Quantidade de artigos por ano Técnicas de mapeamento de esquema(fonte: (Aulbach et al., 2008)) Metamodelo para SPL(Fonte: (Cavalcanti et al., 2011)) Metodologia utilizada para desenvolvimento de aplicação na indústria(fonte: Elaboração própria) Diagrama de Caso de Uso da Aplicação Alexandria(Fonte: Elaboração própria) Arquitetura de Referência adotada(fonte: (Bezemer et al., 2010)) Arquitetura do Grails Framework(Fonte: (Judd et al., 2008)) Arquitetura da Aplicação xi

12 4.7 Exemplo de classe escrita em linguagem Groovy que utiliza o plugin Multi-Tenancy Core Tela de autenticação gerada pelo Spring Security Plugin Tela com Formulário para criação de classes dinâmicas xii

13 Lista de Tabelas 2.1 Definições de Cloud Computing(Vaquero et al., 2008) Questionamentos e termos Strings Search Resultado da aplicação dos critérios de exclusão Faceta Contexto Faceta Tipos de pesquisa (Fonte: (Wieringa et al., 2005)) Faceta Contribuição (Fonte: (Wieringa et al., 2005)) Artigos associados por Questão de pesquisa Artigos agrupados por contexto Artigos agrupados por contribuição Artigos agrupados por Tipo de Pesquisa Métodos e técnicas para implementar multi-tenancy Estilos arquiteturais escolhidos e suas influências em nossa arquitetura Atributos de qualidade desejáveis na arquitetura Resultado da aplicação dos critérios de exclusão(fonte: Elaboração própria) 89 A.1 Estudos Primários A.2 Estudos Primários(Continuação) A.3 Estudos Primários(Continuação) A.4 Estudos Primários(Continuação) A.5 Estudos Primários(Continuação) xiii

14 Lista de Siglas API Application Programming Interface ARPANET Advanced Research Projects Agency Network CRM Customer Relationship Management CRUD Service Component Architecture EC2 Elastic Compute Cloud GUI Graphic User Interface IaaS Infrastructure as a Service ITHA Isolated Tenancy Hosted Applications MTEA Multi-tenant Enabled Application NIST National Institute of Standards and Technology P2P Peer-to-Peer PaaS Platform as a Service PDA Personal Data Assistent QoS Quality of Service RBAC Role-Based Access Control RIA Rich Internet Application S3 Simple Storage Service SaaS Software as a Service SCA Service Component Architecture SGBD Sistema de Gerenciamento de Banco de Dados SLA Service Level Agreement SOA Service Oriented Architecture xiv

15 SPIN Service Performance Isolation Infrastructure SPL Software Product Lines TI Tecnologia da Informação UML Unified Modeling Language WSDL Web Service Definition Language XML Extensible Markup Language xv

16 1 Introdução Os consumidores mudaram com a evolução dos meios de comunicação, transporte e distribuição de produtos e serviços. À medida que os custos de distribuição baixam, diversos produtos que não tinham condições de serem ofertados por ter baixa procura e volume de vendas passam a ter seu lugar no mercado. Nesse contexto, surgiu o conceito de Cauda Longa (Anderson, 2006). A Cauda Longa é um fenômeno observado em empresas de internet que conseguem faturar com produtos de nicho de mercado tanto quanto, ou até mais que os tradicionais produtos da "moda". Isso se tornou viável com o advento da internet, já que a inexistência de limitação do espaço físico, para exibição de produtos, faz com que os produtos que atendem a uma pequena fatia do mercado sejam exibidos aos clientes da mesma forma que os produtos focados na grande massa de clientes. A grande descoberta veio da análise da quantidade de produtos vendidos. Um estudo feito com a Amazon (Amazon, 2011) mostrou que, por ter uma "prateleira"maior de livros à venda, o faturamento dos livros menos populares (fora dos 100 mil principais títulos) representava em torno de um quarto da receita. Analisando o cenário temos a impressão de que são produtos que não vale a pena vender (Anderson, 2006). Isso é verdade para uma loja física tradicional puramente por uma questão de espaço físico, o que não acontece em uma loja virtual. Foi no varejo da internet que descobriu-se o poder da Cauda Longa e da prateleira de tamanho infinito. Segundo Chong et al. (Chong and Carraro, 2006), fornecedores de soluções complexas de software de linha de negócios se defrontam com uma curva de mercado semelhante, como é mostrado na Figura 1.1. Em contraste com os pacotes mais simples de software pronto, o software de linha de negócios tende a ser personalizado para atender as necessidades de clientes individuais, potencialmente incluindo instalação no local e visitas de serviço por parte das equipes de manutenção do fornecedor, muitas vezes exigindo 1

17 1.1. MOTIVAÇÃO hardware de servidor dedicado e uma equipe de suporte para gerenciá-lo. O custo de fornecer esse tipo de atenção dedicada influencia no preço mínimo desse produto. Esse software, portanto, tende a ser vendido para empresas maiores que podem pagar por esse nível de atenção. Figura 1.1 Cauda Longa(Adaptada de: (Chong and Carraro, 2006)) Para cada grande empresa que compra uma solução de linha de negócios existem dezenas de empresas menores e de tamanho médio que poderiam beneficiar-se dessa solução, mas não possuem os recursos para adquiri-la. Assim, no modelo SaaS (Choudhary, 2007) de fornecimento de software, precisa-se desenvolver soluções e infraestruturas de baixo custo, com alto aproveitamento de recursos durante o uso do aplicativo por um grande número de usuários, para assim atingir um público ainda não suportado, devido os custos proibitivos de entrada(sousa et al., 2010). 1.1 Motivação Na Cauda Longa, um número muito grande de usuários que poderá adotar a solução de software que permite a cada cliente pagar um valor muito baixo pelo uso do software, e ainda assim, o provedor de serviço poderá ter um lucro considerável ao final do mês. No mercado de software pode-se citar duas abordagens para venda de software, uma seria vender uma solução para um pequeno grupo de clientes que estão dispostos a pagar um alto valor por esse produto ou serviço. Outra é vender(ou prover um serviço) a um valor muito baixo, desde que se possa atender a um número grande de clientes. Esse cenário é demonstrado na Figura 1.1. Quanto mais um provedor de serviços consegue 2

18 1.1. MOTIVAÇÃO baixar o custo de um produto para os clientes, um número maior de clientes poderá ser alcançado. Um ponto importante no modelo de SaaS é o apoio para vários clientes, fazendo possível que compartilhem a mesma aplicação e infraestrutura, reduzindo os custos operacionais. Isso significa que cada cliente pode interagir com o aplicativo como se ele fosse o único usuário da aplicação. Em especial, um cliente não pode acessar ou visualizar os dados de outro, embora compartilhem a mesma estrutura física (Sousa et al., 2010) e paga por esse serviço de acordo com o uso. Nos últimos anos, temos sofrido uma grande mudança no mercado de software onde empresas têm mudado seu foco do desenvolvimento de produtos para o desenvolvimento de serviços(cusumano, 2008). Um estudo realizado com 500 empresas de desenvolvimento de software, onde analisou-se o percentual de vendas de produtos e serviços dessas empresas, mostrou o crescimento do percentual de vendas de serviços em relação à produtos. O resultado desse estudo é apresentado na Figura 1.2. Figura 1.2 Empresas de software globais vêem seu pecentual de venda de produtos diminuirem de 70 por cento em 1990 para menos de 50 por cento em 2003(Adaptada de: (Cusumano, 2008)) O mesmo estudo citado anteriormente, baseado em informações obtidas apartir 108 empresas de desenvolvimento de software corporativo, identificou que a cobrança de taxa mensal é a forma de cobrança mais utilizada nessas empresas, superando em mais de 2 vezes a forma de cobrança através de pagamento de Taxa Inicial de Licença de Software, que é considerada a forma de cobrança tradicional(figura 1.3)(Cusumano, 2008). Segundo estudos do Instituto Gartner(Gartner, 2011), em julho de 2011, a previsão de receita mundial de SaaS era de U$ 12,1 bilhões em 2011, um aumento de 20,7% em relação à receita de 2010 quando a receita atingiu U$ 10 bilhões. A previsão, de acordo com a pesquisa é que SaaS apresente um crescimento saudável até 2015, quando a receita 3

19 1.1. MOTIVAÇÃO Figura 1.3 Empresas de software corporativo baseado em web tem adotado uma varidade de modelos de negócio. Pagamento de assinatura mensal é o modelo de pagamento mais popular (Adaptada de: (Cusumano, 2008)) mundial atingiria U$ 21,3 bilhões. No mercado de SaaS, aplicações de CRM(Customer Relationship Management) arrematam a maior fatia, com faturamento de U$ 3,2 bilhões em 2010 e podendo chegar ao final de 2011 com U$ 3,8 bilhões. Gartner espera que SaaS represente quase 32% da receita do mercado total de software CRM em Embora seja grande o volume de recursos aplicados nessa área, a publicidade massiva em torno de Cloud Computing e SaaS deixa o cenário nebuloso para os desenvolvedores(milojicic, 2008). O número crescente de tecnologias, somado à expeculações sobre seu uso, pode dificultar a tomada de decisão por parte de desenvolvedores e gerentes de projeto. O Gartner lança anualmente o "Gartner s Hype Cycle", que caracteriza como o exagero sobre uma tecnologia desenvolve-se "de um entusiasmo através de um período de desilusão a um eventual entendimento da relevância da tecnologia e seu papel em um mercado ou domínio"(smith, 2011). Segundo Smith et al.(smith, 2011), multi-tenancy(tsai et al., 2010c), uma das formas de se implementar aplicações SaaS está no segundo estágio do "hype cycle"definido pelo Gartner, como mostra a Figura 1.4. O "hype cycle"é dividido em cinco fases que são descritas a seguir: Technology Trigger - È a primeira fase do hype cycle, quando a nova tecnologia gera grande interesse da mídia e da sociedade. Peak of Inflated Expectations - Nesta fase é apresentado um entusiasmo exagerado, cercado de expectativas não realistas. Ocorrem aplicações de sucesso da 4

20 1.1. MOTIVAÇÃO Figura 1.4 Hype Cycle para Cloud Computing((Smith, 2011)) tecnologia e decepções. É a fase atual de Cloud Computing, segundo o relatório do Instituto Gartner(Smith, 2011). Trough of Disillusionment - O interesse na tecnologia começa a diminuir devido a experimentos e implementações falharem na entrega. Ela ocorre devido a nova tecnologia não conseguir atender toda a expectativa criada. Slope of Enlightenment - Nessa fase, mais casos de como as empresas podem se beneficiar da tecnologia começam a se cristalizar e a tecnologia começa a ser mais amplamente compreendida. Produtos começam a surgir de fornecedores de tecnologia, mas empresas conservadoras continuam cautelosas. Plateau of Productivity - Uma adoção da tecnologia com maior maturidade começa a acontecer. Os critétios de viabilidade da tecnologia são melhor definidos. A aplicabilidade da tecnologia no mercado em geral e sua relevância podem ser claramente vistos. De acordo com o gráfico da Figura 1.4, um entusiasmo exagerado, cercado de expectativas não realistas permeia a área de multi-tenancy. Diante disso, identificou-se a necessidade de elaborar uma sintetização do conhecimento gerado sobre multi-tenancy, bem como o levantamento de evidências que possam auxiliar desenvolvedores a tomar 5

21 1.2. OBJETIVOS decisões durante o desenvolvimento de uma aplicação SaaS multi-tenancy. A realização de uma sintetização que siga o rigor da metodologia científica, aumenta a credibilidade deste trabalho e elimina interferências causadas por entusiasmos proporcionados pela mídia. Tornando esse trabalho um artefato importante durante a tomada de decisões em um projeto real. 1.2 Objetivos Esta seção lista o objetivo geral e os objetivos específicos desta dissertação Objetivos Gerais Mapear a área de multi-tenancy identificando pontos que possam auxiliar desenvolvedores e engenheiros de software durante o criação de aplicações web que adotem multi-tenancy como estilo arquitetural para a implementação de SaaS Objetivos Específicos O objetivo geral pode ser decomposto nos seguintes objetivos específicos: Apresentar uma visão geral da arquitetura multi-tenancy, explicando os principais conceitos úteis para entendimento deste trabalho; Definir o status de maturidade atual de multi-tenancy; Identificar as evidências sobre os fatores que influenciam na adoção e desenvolvimento de SaaS multi-tenancy; Analisar e classificar de maneira sistemática os estudos primários e os artefatos encontrados que podem auxiliar no desenvolvimento de uma aplicação multitenancy Por fim, combinar os resultados evidenciados no estudo secundário com uma aplicação prática dos conceitos de multi-tenancy na indústria. 1.3 Metodologia Para alcançar os objetivos esperados, as atividades foram divididas em 3 fases: 6

22 1.3. METODOLOGIA Fase 1 - Apartir dos objetivos da pesquisa, foi realizado uma revisão bibliográfica inicial para a familiarização com os termos e principais conceitos relacionados ao tema multi-tenancy. Essa fase foi baseada na leitura de artigos, publicações em sites e revistas relacionados ao tema. Como resultado dessa fase obtivemos os principais conceitos e termos relacionados a multi-tenancy que servirão de entrada para a próxima fase. Fase 2 - Conhecidos os conceitos e termos, é possível planejar e executar um mapeamento sistemático que servirá para entender o contexto no qual o tema pesquisado está inserido. Nessa fase são executadas atividades como definição de questões de pesquisa, escolha de engines de busca, leitura e categorização dos trabalhos relevantes, etc. O objetivo principal dessa fase é entender o estado da arte de multi-tenancy e SaaS, bem como conhecer o que já existe no mercado e quais os possíveis problemas em aberto. Fase 3 - baseado no resultado do mapeamento sistemático realizado na fase anterior, é definida uma abordagem de implementação, que é adotada durante o desenvolvimento de um projeto na indústria. A Figura 1.5 descreve de forma resumida a metodologia utilizada nessa dissertação. Figura 1.5 Resumo da Metodologia(Elaboração própria) 7

23 1.4. CONTRIBUIÇÕES CIENTÍFICAS 1.4 Contribuições científicas Com este trabalho, espera-se fornecer as seguintes contribuições científicas: Fornecer um mapeamento da área de multi-tenancy Consolidar de forma sistemática o conhecimento sobre multi-tenancy, bem como o conhecimento sobre ferramentas e técnicas que auxiliem no desenvolvimento dessas aplicações Fornecer um catálogo de frameworks e propostas para a implementação da arquitetura multi-tenancy 1.5 Estrutura da dissertação O restante deste trabalho está organizado em 5 capítulos, conforme a divisão que se segue. O Capítulo 2 introduz os conceitos básicos necessários ao entendimento do trabalho. Em seguida, o Capítulo 3 apresenta a metodologia que foi utilizada para conduzir esta dissertação. O Capítulo 4 apresenta os resultados encontrados após a execução do estudo de mapeamento. No Capítulo 5 é apresentado um estudo de caso para validar o conceito de multi-tenancy. Por fim, o Capítulo 6 apresenta as conclusões da dissertação, ressaltando as contribuições, as limitações e os trabalhos futuros a serem realizados. 8

24 2 Fundamentação Teórica Em 1969, Leonard Keinrock, um dos cientistas chefe da ARPANET, precursora da internet, disse: "A partir de agora, redes de computadores estão ainda na sua infância, mas a medida que crescem e tornam-se sofisticadas, nós iremos provavelmente ver a disseminação do computador utilitário que, como telefones e energia elétrica, irão servir casas e escritórios por todo país"(kleinrock, 2003). Essa visão de computação utilitária baseada no modelo de fornecimento de serviços antecipa a transformação massiva de toda a indústria de computação nos últimos anos, em que os serviços de computação estarão prontamente disponíveis sob demanda, como os outros serviços utilitários disponíveis atualmente. Similarmente, os usuários(consumidores) precisam pagar os provedores somente quando eles acessam os serviços de computação. Além disso, consumidores não precisam mais realizar altos investimentos ou enfrentar a dificuldade de construir e manter complexas infra-estruturas de TI. Os profissionais de desenvolvimento de software estão enfrentando inúmeros novos desafios para criar software para milhões de consumidores usarem como serviço ao invés de executarem em seus computadores pessoais. E ao longo dos anos, o surgimento de avanços tecnológicos como processadores multicore e ambientes de computação em rede como Cluster Computing(Yeo et al., 2006), Grid Computing(Jacob, 2005), computação P2P(Vu et al., 2010) e o mais recente Cloud Computing(Mell and Grance, 2009), tornam esse objetivo cada vez mais factível. Os serviços de computação citados anteriormente precisam ser altamente confiáveis, escaláveis e dinâmicos para suportar acesso ubíquo e fornecer a possibilidade de composição de outros serviços(dustdar and Schreiner, 2005). Além disso, consumidores devem ter a capacidade de determinar o nível de serviço requerido através de parâmetros de QoS(Quality of Service) e SLA(Service Level Agreement)(Berberova and Bontchev, 2009). 9

25 2.1. CLOUD COMPUTING Cloud Computing foi o último desses paradigmas a emergir e promete entregar serviços confiáveis através da nova geração de datacenters que são construídos utilizando tecnologias de virtualização de processamento e armazenamento. Consumidores estarão habilitados a acessar aplicações e dados da "cloud"em qualquer lugar do mundo e sob demanda, como é o caso do Gmail 1, Google Docs 2, Office Web Apps 3, Dropbox 4, dentre outros. Em outras palavras, a cloud parace ser um ponto de acesso único para todas as necessidades de computação dos consumidores. 2.1 Cloud Computing Atualmente não existe uma definição oficial do que seja Cloud Computing. O objetivo nessa seção é reunir várias definições de Cloud Computing disponíveis e chegar a uma definição que seja um denominador comum. A Tabela 2.1 mostra as definições de Cloud Computing propostas por muitos especialistas na área (Vaquero et al., 2008). Segundo Markus Klems(Geelan, 2009), escalabilidade imediata e uso otimizado dos recursos são os principais elementos de uma cloud. Isso é provido pelo aumento no monitoramento e automação do gerenciamento de recursos, em um ambiente dinâmico. Outros autores discordam que esse é um requisito para uma infraestrutura ser considerada cloud(haaff, 2009). Além disso, Cloud Computing tem sido definido por alguns autores como hardware e software virtualizados, somados a aplicação de tecnologias de monitoramento e provisionamento(geelan, 2009). Ainda existem alguns outros especialistas que não enfatizam capacidades da cloud, mas acreditam que cloud computing é uma "buzz word"abrangendo uma grande variedade de aspectos como deployment, balanceamento de carga, provisionamento e terceirização de processamento e armazenamento de dados. Levando em consideração as características apresentadas na Tabela 2.1, Luiz M. Vaquero e outros autores (Vaquero et al., 2008) tentaram chegar a uma definição de Cloud Computing. Obviamente o conceito de cloud ainda está em mudança e essas definições mostram como o conceito de cloud é concebido por alguns especialistas. Cloud é um grande pool de recursos virtualizados(hardware, plataformas de desenvolvimento e serviços) facilmente utilizáveis e acessíveis. Esses recursos podem ser dinâmicamente reconfigurados para se ajustar a carga variável(escala), permitindo também a otimiza

26 2.1. CLOUD COMPUTING Autor Definição M. Klems... é possível escalar sua infraestrutura sob demanda em minutos ou em segundos, ao invés de dias ou semanas, evitando desse modo sub-utilização e sobrecarga dos seus recursos in-house. P. Gaw Uso da internet para permitir pessoas acessarem serviços tecnologicamente disponíveis. Esses serviços precisam ser massivamente escaláveis. R. Buyya Uma Cloud é um tipo de sistema paralelo e distribuído que consiste de uma coleção de computadores virtualizados e interconectados que são dinâmicamente provisionados e apresentados como um ou mais recursos computacionais unificados, baseados em SLA estabelecida através de negociação entre o provedor de serviço e o consumidor. R. Cohen Cloud Computing é uma das várias buzz words existentes que tentam abranger uma variedade de aspectos como deployment, balanceamento de carga, provisionamento, modelo de negócios e arquitetura. Esse é o próximo passo em software. A explicação mais simples de Cloud Computing é descrevê-la como Software centrado na internet. J. Kaplan Uma ampla gama de serviços baseados na web que objetivam permitir ao usuário obter uma variedade de funcionalidades que são pagas por uso e que anteriormente requeria uma grande quantidade de investimentos em hardware/software e contratação de bons profissionais. Cloud Computing é a realização de idéias antigas de computação utilitária sem a complexidade técnica ou preocupação com deployments complicados. D. Gourlay D. Edwards... o próximo termo para campanhas publicitárias... criado fora do modelo de software que a virtualização habilitou.... é o que é possível quando você alcança a infra-estrutura(de aplicação e física) para o tamanho da web de uma forma sob-demanda. B. de Haff Existem somente três tipos de serviço que são baseados em cloud: SaaS, PaaS e Plataformas de Cloud Computing. O autor não garante que escalar massivamente seja um requisito para caber em qualquer categoria. B. Kepes Simplificando, Cloud Computing é uma mudança de paradigma de infraestrutura que habilita a ascenção de software como serviço... É uma gama de serviços baseados em web que tem como objetivo permitir a usuários obter uma ampla variedade de funcionalidades baseada no modelo de pagamento por uso e que anteriormente requeria uma grande quantidade de investimentos e contratação de profissionais especialistas. K. Sheynkman Cloud foca em fazer a capacidade de processamento e armazenamento da camada de hardware consumível sob demanda. Esse é um primeiro passo importante, mas para as companhias aproveitarem o poder da cloud, infra-estruturas completas de aplicações precisam ser facilmente configuradas, distribuídas, dinâmicamente escaladas e gerenciadas nesses ambientes de hardware virtualizado. K. Hartig Na realidade é o acesso a recursos e serviços necessários para executar funcionalidades com necessidade de mudança dinâmica. É a virtualização de recursos auto-mantidos e auto-gerenciáveis. J. Pritzker Clouds são um vasto pool de recursos com alocação sob demanda... virtualizados... e cobrados por utilização. T. Doerkzen T. Von Eicken Cloud Computing é... uma versão de grid computing amigável para o usuário. terceirizado, sob-demanda, pago por uso, em qualquer lugar da internet, etc. 11

27 2.1. CLOUD COMPUTING Autor Definição M. Sheedan a pirâmide de cloud computing ajuda a diferenciar as várias ofertas de cloud... no topo: SaaS, no meio: PaaS, na base: IaaS. A. Ricadela Projetos de Cloud Computing são mais poderosos e tolerantes a falhas que sistemas de grid desenvolvidos nos últimos anos. I. Wladawsky Berger A principal coisa que queremos virtualizar e ocultar do usuário é a complexidade... todos aqueles softwares que serão virtualizados ou ocultos de nós e o tratamento de sistemas e/ou profissionais que estão em qualquer outro lugar, fora da Cloud. B. Martin Cloud computing inclui qualquer serviço baseado em assinatura ou pago por uso que, em tempo real e rodando na internet, extende as capacidades de ti existentes. R. Bragg O conceito principal de cloud é a aplicação web... a cloud mais desenvolvida e confiável. Muitos acham barato migrar agora para uma cloud na web ao invés de investir em seus proprios servidores... isso é um desktop por pessoa sem um computador. G. Gruman and E. Knorr P. McFedries Cloud é toda sobre: SaaS... computação utilitária, PaaS... integração na internet... plataformas comerciais. Cloud Computing, onde residem não somente nossos dados mas também alguns de nossos softwares. Nós acessamos qualquer coisa não somente através de nossos PCs, mas também de outros dispositivos, como smartphones, PDAs,... O megacomputador é habilitado pela virtualização e software como serviço... Essa é a utilização do poder de computação pela massiva utilização de data centers Tabela 2.1 Definições de Cloud Computing(Vaquero et al., 2008) ção na utilização de recursos. Esse pool de recursos é normalmente explorado pelo modelo pay-by-use(pague por uso), no qual garantias são oferecidas pelo provedor de infraestrutura por meio de SLA(Service Level Agreement). Olhando para o mínimo denominador comum nas definições, os autores não chegaram a uma definição de uma funcionalidade única proposta em todas as definições. O conjunto de funcionalidades que mais se aproxima da definição mínima poderia ser escalabilidade, modelo de pagamento por uso e virtualização. Nesse trabalho usaremos a definição proposta pelo National Institute of Standards and Technology(NIST), que define Cloud Computing como um modelo que permite, de forma conveniente, o acesso a um pool de recursos computacionais compartilhados(rede, servidores, armazenamento, aplicações e serviços) que podem ser rapidamente provisionados e liberados com o mínimo de esforço de gerenciamento ou interação do provedor de serviço. Ainda segundo o National Institute of Standards and Technology (NIST), Cloud Computing é composta por cinco características essenciais(mell and Grance, 2009): Alocação de recursos sob demanda: O usuário pode adquirir unilateralmente 12

28 2.1. CLOUD COMPUTING recursos computacionais, como tempo de processamento no servidor ou armazenamento, através da rede na medida em que necessite e sem precisar de interação humana com os provedores de cada serviço. Amplo acesso a rede: recursos estão disponíveis através da rede e podem ser acessados por meio de mecanismos que funcionem em plataformas heterogêneas (por exemplo, telefones celulares, laptops e PDA). Pooling de recursos: os recursos do provedor de computação são agrupados para atender vários consumidores através de um modelo multi-tenancy, com diferentes recursos físicos e virtuais atribuídos dinamicamente e novamente de acordo com a demanda do consumidor. Há um senso de independência local em que o cliente geralmente não tem nenhum controle ou conhecimento sobre a localização exata dos recursos disponibilizados, mas pode ser capaz de especificar o local em um nível maior de abstração (por exemplo, país, estado ou data center). Exemplos de recursos incluem o armazenamento, processamento, memória, largura de banda de rede e máquinas virtuais. Elasticidade rápida: recursos podem ser adquiridos de forma rápida e elástica, em alguns casos automaticamente, caso haja a necessidade de escalar com o aumento da demanda, e podem também ser liberados, na retração dessa demanda. Para os usuários, os recursos disponíveis para uso parecem ser ilimitados e podem ser adquiridos em qualquer quantidade e a qualquer momento. Serviço medido: sistemas em nuvem automaticamente controlam e otimizam a utilização dos recursos, alavancando a capacidade de medição em algum nível de abstração adequado para o tipo de serviço (por exemplo, armazenamento, processamento, largura de banda, e contas de usuários ativos). Uso de recursos pode ser monitorado, controlado e relatado a existência de transparência para o fornecedor e o consumidor do serviço utilizado. Ainda segundo o NIST(Mell and Grance, 2009), Cloud Computing é dividido em três modelos de serviço(figura 2.1): Software como Serviço (SaaS): A capacidade fornecida ao consumidor é a de usar as aplicações do fornecedor em uma infraestrutura da nuvem. As aplicações são acessíveis de vários dispositivos cliente através de uma interface thin client, como por exemplo um browser web. O consumidor não administra ou controla a 13

29 2.1. CLOUD COMPUTING infraestrutura básica, incluindo rede, servidores, sistemas operacionais, armazenamento, ou mesmo capacidades individuais da aplicação. Mesmo assim ainda é possível definir algumas configurações específicas para o usuário na aplicação. Plataforma como Serviço (PaaS): A capacidade fornecida ao consumidor é a de realizar deploy de uma aplicação em uma infraestrutura pré-definida ou adquirir aplicações criadas usando linguagens de programação e as ferramentas suportadas pelo provedor de PaaS. O consumidor não administra ou controla a infraestrutura básica como rede, servidores, sistemas operacionais, ou armazenamento, mas tem controle sobre os aplicativos utilizados e eventualmente hospedagem de aplicativos e configurações de ambiente. Infraestrutura como Serviço (IaaS) : A capacidade prevista para o consumidor é a de processamento, armazenamento, redes e outros recursos computacionais fundamentais para que o consumidor seja capaz de implantar e executar programas arbitrários, que podem incluir sistemas operacionais e aplicativos. O consumidor não administra ou controla a infraestrutura de nuvem subjacente, mas tem controle sobre os sistemas operacionais, armazenamento, aplicativos implantados, e, eventualmente, o controle limitado de componentes de rede (por exemplo, firewall). Figura 2.1 Modelos de serviço de Cloud Computing Nesse trabalho teremos como foco principal os tópicos relacionados a SaaS, embora sejam mencionados alguns conceitos associados à PaaS e IaaS. O motivo disso é que multi-tenancy é um conceito existente dentro do contexto de Software como serviço. 14

30 2.2. SAAS - SOFTWARE COMO SERVIÇO 2.2 SaaS - Software como Serviço Nos últimos anos muitas empresas tem saído do modelo de entrega de software empacotado para o modelo de fornecimento de software na web(huang, 2011b). Essas aplicações entregues através da web vão desde s a calendários, sistemas colaborativos, publicações online, processadores de texto simples, aplicações para negócios e aplicações para uso pessoal. Salesforce.com(Lehnen, 2011), por exemplo, criou um aplicativo para CRM(Customer Relationship Management) e o configurou não como um software empacotado, mas como software rodando sobre servidores acessível através do browser. Quando fez isso, criou a propria plataforma in-house para entregar o software como serviço para seus consumidores. Logo em seguida Salesforce.com criou o AppExchange, uma plataforma de integração aberta para outras empresas de software construirem produtos utilizando algumas funcionalidades do CRM do salesforce. Pouco tempo depois Salesforce extendeu o conceito de plataforma aberta como force.com, um ambiente de desenvolvimento e deployment usando a infraestrutura de SaaS do Salesforce. Posteriormente, algumas outras empresas ingressaram nesse mercado, a Amazon com o Elastic Compute Cloud (EC2)(Amazon, 2011) e Google com o Google AppEngine 5, abrindo suas infraestruturas de cloud para hospedarem aplicações de terceiros, além de produzirem serviços online. Amazon vem se tornando bastante atraente porque possui uma rica infraestrutura para suportar operações de varejo online e tem oferecido vários serviços para usuários de cloud como: data storage, processamento, fila de mensagens, billing e etc. O artigo "Amazon S3 s Amazing Growth"(Huang, 2011a) menciona o crescimento vertiginoso no uso do serviço S3 da Amazon(Amazon, 2011) nos últimos anos, é possível ver o gráfico de crescimento desse serviço na figura 2.2. Cloud Computing e SaaS também parecem ser eficientes tanto para usuários quanto para fornecedores de software. Vários consumidores podem usar a mesma instalação do software e consequentemente isso melhora as taxas de utilização de hardware e rede. Por exemplo, Amazon 6 e Google 7 tem enormes datacenters que eles não utilizam completamente o tempo todo. Eles podem executar seus próprios produtos e enquanto hospedam aplicações de outras empresas. Hosts como Amazon, Google e Salesforce geralmente garantem a qualidade de serviço para todos os seus consumidores de cloud

31 2.2. SAAS - SOFTWARE COMO SERVIÇO Figura 2.2 Amazon S3 s Growth(Huang, 2011a) através de SLAs (Service Level Agreeements) detalhadas. Segundo Harris et al.(harris and Ahmed, 2011) existem três tipos diferentes de aplicações SaaS: Multi-instance: essas aplicações executam em ambientes onde o servidor web é compartilhado. Nessa abordagem uma cópia da aplicação é inicialmente configurada para cada cliente, e então cada cópia é implantada como um contexto no mesmo servidor web. Single-instance: as aplicações provêem serviços para um único cliente e executam em um servidor exclusivo. Nesse caso cada servidor web possui uma única instância da aplicação. Essa pode considerada a abordagem com maior desperdício de recursos, dado que um servidor pode executar com apenas 10% de sua capacidade. Multi-tenancy: provê uma única aplicação compartilhada por vários clientes. Nessa abordagem várias aplicações "virtuais"são criadas na mesma instância. Implementar o conceito de SaaS nem sempre é tão simples como parece. Chong (Chong and Carraro, 2006) propõe 4 níveis de maturidade para aplicações que utilizam o modelo de SaaS: Nível 1 - Ad-Hoc/Personalizado: O primeiro nível de maturidade é semelhante ao modelo de entrega de software do provedor de serviços de aplicativos (ASP - Application Service Provider) tradicional, que data da década de Nesse nível, cada cliente tem a sua própria versão personalizada do aplicativo hospedado e 16

32 2.2. SAAS - SOFTWARE COMO SERVIÇO Figura 2.3 Níveis de Maturidade SaaS(Chong and Carraro, 2006) executa a sua própria instância do aplicativo nos servidores do provedor. Pensando em arquitetura, software nesse nível de maturidade é muito semelhante aos softwares corporativos vendidos tradicionalmente, em que diferentes usuários de uma organização conectam a uma instância única em execução no servidor, mas essa instância é totalmente independente de quaisquer outras instâncias ou processos que o host esteja executando para os seus outros clientes. Nível 2 - Configurável: No segundo nível de maturidade, o fornecedor hospeda uma instância separada do aplicativo para cada inquilino. Enquanto no primeiro nível cada instância é personalizada individualmente para o inquilino, neste nível todas as instâncias utilizam a mesma implementação de código e o fornecedor atende as necessidades dos clientes fornecendo opções de configuração detalhadas que permitem ao cliente alterar a aparência e o comportamento do aplicativo para os seus usuários. Apesar de serem idênticas a nível do código, cada instância permanece totalmente isolada de todas as demais. Nível 3 - Configurável e eficiente para vários tenants: No terceiro nível de maturidade, o fornecedor executa uma única instância que serve a todos os clientes. Metadados configuráveis são usados para fornecer uma experiência de usuário e um conjunto de recursos exclusivos para cada instância. Políticas de autorização e de segurança garantem que os dados de cada cliente sejam mantidos separados dos dados de outros clientes e que, da perspectiva do usuário final, não exista qualquer 17

33 2.3. MULTI-TENANCY indicação de que a instância do aplicativo esteja sendo compartilhada entre vários tenants. Nível 4 - Escalonável, configurável e eficiente para vários tenants: No quarto e último nível de maturidade, o fornecedor hospeda vários clientes em um ambiente com balanceamento de carga. Os dados de cada cliente são mantidos separados e com metadados configuráveis fornecendo uma experiência do usuário e um conjunto de recursos exclusivos para cada cliente. Um sistema de SaaS é escalonável para um número de clientes arbitrariamente grande, uma vez que a quantidade de servidores e instâncias no lado do fornecedor pode ser aumentada ou diminuída conforme necessário para corresponder à demanda sem a necessidade de remodelar a arquitetura aplicativo, além disso as alterações ou correções podem ser transmitidas para milhares de tenants tão facilmente quanto para um único tenant. Normalmente se esperaria que o quarto nível fosse a meta definitiva para qualquer aplicativo de SaaS, mas não é sempre assim. É necessário verificar as necessidades operacionais, arquiteturais e de negócio relacionadas à aplicação. Uma abordagem singletenant faz sentido financeiramente? O seu aplicativo pode ser feito para executar em uma única instância lógica? Você pode garantir os seus contratos de nível de serviço (SLAs) sem isolamento das aplicações? Essas são questões que devem ser respondidas quando se pretende adotar o modelo SaaS. O objeto de estudo principal desse trabalho serão aplicações SaaS do tipo multitenancy. 2.3 Multi-tenancy Multi-tenancy é uma abordagem organizacional para aplicações SaaS. Bezemer e Zaidman (Bezemer and Zaidman, 2010) definem multi-tenancy como aplicações que permitem a otimização no uso dos recursos de hardware, através do compartilhamento de instâncias da aplicação e da instância do banco de dados, enquanto permite configurar a aplicação para atender às necessidades do cliente como se estivesse executando em um ambiente dedicado. Tenant é uma entidade organizacional que aluga uma aplicação multi-tenancy. Normalmente, um tenant agrupa um número de usuários que são os stakeholders da organização. A definição anterior foca no que nós consideramos aspectos em aplicações multitenancy: 18

34 2.4. CONSIDERAÇÕES FINAIS Possibilidade de compartilhamento de recursos de hardware, permitindo a redução de custos (Wang et al., 2008a). Alto grau de configurabilidade, permitindo que cada consumidor customize sua própria interface e seu workflow na aplicação (Nitu, 2009; Jansen et al., 2010). Uma abordagem arquitetural na qual os tenants fazem uso de uma única aplicação e banco de dados (Kwok et al., 2008a). É possível que algumas pessoas confundam multi-tenancy com o conceito de multiusuário. Multi-tenancy não é multi-usuário. Em uma aplicação multi-usuário nós assumimos que os usuários estão usando a mesma aplicação com opções de acesso limitadas e que essa instância da aplicação é utilizada por apenas um único cliente. Nesse caso podemos ter vários usuários com o perfil "gerente", com o perfil "vendedor", ou com qualquer perfil de usuário necessário para o funcionamento da aplicação. Em uma aplicação multi-tenancy nós assumimos cada instância tenants tem um algo grau de configuração, dependendo da definição dessas configurações, dois tenants pode possuir aparência e workflows diferentes. Um argumento adicional para essa distinção é que o SLA para cada tenant pode ser diferente (Lin et al., 2009a). Outra abordagem que contrasta com multi-tenancy é a abordagem multi-instance. Com o aumento da popularidade das tecnologias de virtualização e de Cloud Computing, multi-instance é a forma fácil de criar aplicações parecidas com multi-tenancy. É necessário apenas criar uma imagem de maquina virtual com a aplicação pré-configurada e, logo em seguida criar instâncias apartir dessa imagem. A abordagem multi-instance é uma melhor abordagem quando o número de clientes for pequeno (Guo et al., 2007). Uma abordagem mais profunda sobre o tema multi-tenancy será apresentado no Capítulo 3, onde será realizado um mapeamento da área. 2.4 Considerações Finais Este capítulo apresentou os conceitos básicos usados na dissertação. Inicialmente, noções sobre Cloud Computing, SaaS, PaaS e IaaS. O conceito de multi-tenancy foi introduzido, explicitando visões e características que serão importantes para o entendimento dos capítulos posteriores. Por fim, foram apresentadas alguns requisitos de aplicações que adotam o modelo de SaaS e multi-tenancy. Embora o que foi apresentado até aqui seja de grande relevância, é preciso bem mais do que isso para adotar uma tecnologia na indústria. É necessário entender as vantagens e 19

35 2.4. CONSIDERAÇÕES FINAIS desvantages, o estado da arte na academia, bem como o nível de maturidade existente na aplicação dessa tecnologia. Para responder essas questões o capítulo seguinte apresenta um mapeamento sistemático sobre o campo de multi-tenancy com o objetivo de sintetizar os conhecimentos existentes na área. 20

36 3 Metodologia de Seleção de Trabalhos Acerca de Multi-tenancy Esse trabalho originou-se de uma necessidade real de se implementar um aplicativo para uma empresa startup (Ries, 2011) que seguisse o modelo de SaaS e que pudesse ser hospedado em algum ambiente de Cloud como Amazon AWS ou Google AppEngine. A publicidade excessiva da mídia em torno de SaaS e multi-tenancy propiciam o surgimento de especulações e informações imprecisas sobre esse campo (Milojicic, 2008). Além disso a ausência de trabalhos que sintetizem o conhecimento gerado de forma a eliminar informações imprecisas ou baseadas exclusivamente em opinião pessoal torna ainda mais difícil definir o status atual da área, como foi possível observar no gráfico da Figura 1.4. Para realizar uma boa pesquisa e gerar conhecimento útil e consistente era necessário utilizar alguma metodologia na realização da pesquisa. Metodologia científica é necessária, entre outras razões, para tornar os resultados da pesquisa mais confiáveis e possíveis de serem reproduzidos, de forma independente, por outros pesquisadores. Partindo do princípio de que deveríamos utilizar alguma metodologia para realizar nossas pesquisa escolheu-se a técnica de Mapeamento Sistemático (Petersen et al., 2008). Um Mapeamento Sistemático provê a estruturação de uma área de pesquisa, no tocante a relatórios de pesquisa e resultados que vem sendo publicados. Muitas vezes esses resultados são resumidos de forma visual através de tabelas e gráficos. A aplicação dessa técnica provê uma melhor visão panorâmica da área pesquisada (Kitchenham and Charters, 2007). A escolha de sua utilização nesse trabalho ocorreu principalmente por utilizar um processo e protocolo de execução bem definidos, o que permite que essa atividade possa ser repetida por outros pesquisadores em momentos futuros. Mapeamento Sistemático é uma metodologia que é frequentemente utilizada em pesquisas médicas, mas que vem gradualmente ganhando força na comunidade de engenharia 21

37 de software. De acordo com Budgen (Budgen et al., 2008), dentre os principais motivos para se executar uma mapeamento sistemático podemos citar: ajuda na realização de uma avaliação imparcial do maior número de estudos possível, identificando lacunas existentes atualmente na área de pesquisa e contribuição para a comunidade científica com uma síntese confiável dos dados; provê um procedimento sistemático para identificar a natureza e a extensão de dados do estudo que são úteis para responder às questões de pesquisa; auxilia no mapeamento da pesquisa que foi realizada; ajuda a planejar uma nova pesquisa,evitando duplicação desnecessária de esforço e erros. ajuda a identificar lacunas e grupos de estudos primários, para identificar tópicos e áreas para realizar revisões sistemáticas mais completas. Para conduzir o mapeamento sistemático realizado nesse trabalho serão seguidos os passos descritos na Figura 3.1. Cada etapa do processo é brevemente descrita a seguir: 1. Pesquisa exploratória: nessa etapa foram realizados pesquisas em máquinas de busca e bibliotecas digitais disponíveis na web, com o objetivo de entender melhor a área a ser pesquisada. 2. Definição de questões de pesquisa: passado a fase de entendimento do problema, são definidas questões de pesquisa, que irão guiar o mapeamento sistemático. 3. Condução da pesquisa: nessa fase são selecionadas as bibliotecas digitais onde as questões de pesquisa serão executadas e outros locais onde serão pesquisados trabalhos sobre o tema. 4. Triagem de papers: é comum que as pesquisas retornem alguns trabalho com pouca relevância para responder às questões de pesquisa, nesse caso é realizado uma triagem dos trabalhos encontrados durantes as pesquisas, de forma a eliminar os trabalhos irrelevantes. 5. Busca de termos chave usando abstracts: nessa etapa é desenvolvido o esquema de classificação dos trabalhos encontrados. Primeiro é realizado a leitura dos abstracts e palavras chave em busca de conceitos que reflitam a contribuição do 22

38 trabalho. Ao final dessa leitura um conjunto de palavras chave de diferentes trabalhos são combinadas para desenvolver um entendimento de alto nível sobre a natureza e a contribuição do trabalho. Isso auxilia na definição de um conjunto de categorias que ajudam no entendimento da população de estudos encontrados. 6. Extração de dados e processo de mapeamento: após a definição do esquema de classificação, os trabalhos são agrupados e as informações necessárias para responder às questões de pesquisa são extraídas. Figura 3.1 Processo de Mapeamento Sistemático - Adaptado de (Petersen et al., 2008) Os detalhes de como o mapeamento sistemático foi conduzido serão descritos no decorrer desse capítulo que está estruturado da seguinte forma: a seção 3.1 descreve as questões que esse mapeamento pretende responder e a seção 3.2 descreve como foram realizadas as buscas e a seleção dos trabalhos relevantes associados às questões definidas na seção 3.1. Após a exclusão dos trabalhos irrelevantes e da leitura de todos os trabalhos relevantes, os mesmos foram agrupados de acordo com as categorias definidas na seção 3.3. Os resultados desse mapeamento sistemático são apresentados nas seções 3.4, 3.5 e 3.6. A seção 3.7 apresenta possíveis ameaças à validade desse trabalho e por fim a seção 3.8 apresenta as considerações finais do capítulo. 23

39 3.1. DIRETIVAS DE PESQUISA 3.1 Diretivas de pesquisa Pesquisa exploratória Para realizar o mapeamento, a primeira atividade foi realizar uma pesquisa exploratória onde foram realizadas buscas no Google e Bing sobre com as seguintes palavras chave: multi-tenant multi-tenancy SaaS Software as a service Apartir dessas buscas foram encontrados alguns artigos e matérias na web sobre o assunto. Boa parte desse material tratava-se de artigos baseados em opiniões pessoais ou pequenos tutoriais. Essa atividade serviu para que fosse criada uma massa crítica de conhecimento que ajudou a compreender melhor o problema e a formalizar um conjunto de questionamentos relacionados à multi-tenancy: Quais as vantagens e desvantagens da adoção da arquitetura multi-tenancy? Devido à inexperiencia com a adoção dessa abordagem era necessário saber quais o benefícios e perdas que se teria adotando a arquitetura multi-tenancy. Quando a adoção de multi-tenancy é viável? É necessário identificar os cenários onde a adoção da arquitetura multi-tenancy é viável. Existe alguma forma de extender as funcionalidades de um tenant específico? Dado que cada cliente pode ter uma necessidade específica é preciso saber como implementar as funcionalidades específicas de um cliente(tenant), já que teremos apenas uma única instância da aplicação que será utilizada por todos os clientes. Como gerenciar a variabilidade entre os tenants? Se o aplicação suportar regras de negócio específicas para cada tenant, é relevante saber como gerenciar isso. Como verificar se um tenant está consumindo mais recursos do que o esperado? Como otimizar o uso de recursos é uma das principais propostas de multitenancy, é importante saber a quantidade de recursos consumidos por cada tenant. Isso pode ajudar a identificar tenants que tenham uma maior demanda por recursos 24

40 3.1. DIRETIVAS DE PESQUISA computacionais e alocar uma infraestrutura adequada para os mesmos, evitando que os outros tenants sejam comprometidos. Como tratar solicitações de forma assíncrona? A fim de otimizar o uso de recursos, permitir que requisições sejam realizadas de forma assíncrona pode ajudar na melhor utilização de recursos. Existem muitas funcionalidades que podem ser solicitadas e executadas posteriormente quando a demanda de recursos no servidor for menor. Como isolar os tenants, de forma que um tenant não tenha acesso a dados de outro indevidamente? Prover a segurança dos dados na arquitetura multi-tenancy é um fator crítico, tendo em vista que todos os tentants compartilham a mesma aplicação e possivelmente o mesmo banco de dados. Caso um tenant esteja consumindo muitos recursos, como migrar esse tenant para outra máquina ou VM (Virtual Machine)? Caso um tenant exija mais recursos do que o esperado, ele pode sobrecarregar o servidor e prejudicar o funcionamento de outros tenants que compartilham a mesma aplicação. Quais as propostas existentes para se implementar a arquitetura multi-tenancy? Saber quais as propostas, frameworks e bibliotecas existentes que auxiliem na implementação da arquitetura multi-tenancy é de grande importância para prover produtividade no desenvolvimento e evitar trabalho desnecessário Definição de Questões de Pesquisa Para conduzir as pesquisas realizadas nesse trabalho,era necessário definir o escopo do estudo, para isso 4 questões foram derivadas apartir das questões já citadas na Seção 3.1.1: 1. Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy? 2. Quais as propostas existentes para implementação da arquitetura multi-tenancy? 3. Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicação multi-tenancy? 4. Quando a adoção da arquitetura multi-tenancy é viável? 25

41 3.1. DIRETIVAS DE PESQUISA A estratégia usada para definir os termos de busca, segue uma abordagem baseada em (Kitchenham et al., 2007), uma vez que esse trabalho sistematizou e definiu passos para derivar termos de pesquisa a partir de perguntas, pontos de vista de experts e artigos relevantes. Os passos para definição dos termos são descritos a seguir: Apartir das questões de pesquisa definidas anteriormente, os principais termos são definidos; Identificação de sinônimos a partir de artigos conhecidos e trabalhos relevantes na área de pesquisa; Tradução dos termos para o inglês por ser a língua utilizada nas bases de dados eletrônicas de pesquisa e nas principais conferências e eventos dos tópicos de investigação; Uso do operador OR para indicar que dois termos são alternativos; Uso do operador AND para indicar que dois termos devem estar juntos no resultado. Após a execução dos passos definidos acima foram encontrados termos para cada pergunta do nosso mapeamento sistemático como é possível observar na Tabela A.5. ID QUESTÃO TERMOS Q1 Q2 Q3 Q4 Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy? Quais as propostas existentes para implementação da arquitetura multi-tenancy? Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicação multi-tenancy? Quando a adoção da arquitetura multi-tenancy é viável? Tabela 3.1 Questionamentos e termos multi-tenancy, advantages, disadvantages, approach, barrier, adoption, viability approach, methods, techniques, proposal, framework "multi-tenancy" "product lines", variability, variation, "multi-tenancy" adoption, viability, approach, "multi-tenancy" A combinação desses termos deu origem a uma consulta genérica descrita a seguir: (multi-tenancy OR multi-tenant) AND ("Cloud computing"or iaas OR paas OR saas OR advantages OR disadvantages OR approach OR barrier OR adoption OR viability OR approach OR methods OR techniques OR proposal OR framework OR tenant OR "product lines"or variability OR variation OR adoption OR viability OR challenges OR problems OR benefits OR loss) 26

42 3.2. SELEÇÃO DOS DADOS 3.2 Seleção dos dados Condução da pesquisa Segundo Kitchenham (Kitchenham and Charters, 2007), as pesquisas iniciais dos estudos podem ser realizadas em bibliotecas digitais, mas isso não é suficiente para uma revisão sistemática, outras fontes também podem ser pesquisadas. Pesquisadores da área também podem ser consultados para a indicação de fontes de material mais adequado. Os critérios para a seleção das fontes foram: (1) disponibilidade de consultar os artigos na web; (2) presença de mecanismos de busca usando palavras-chave; e, (3) importância e relevância das fontes. Um processo de ampla pesquisa foi realizado à procura de artigos publicados combinando pesquisa automática e manual para aumentar a cobertura. A busca automática foi realizada em cinco fontes de pesquisa: IEEEXplore Digital Library (httt://ieeexplore.ieee.org/) ACM Digital Library ( Elsevier ScienceDirect ( EI Compendex ( Elsevier Scopus ( A Tabela 3.2 mostra a string de busca executada em cada biblioteca digital. As consultas foram executadas em setembro de 2011, portanto nem todos os trabalhos publicados em 2011 foram considerados nesse trabalho. A pesquisa manual foi realizada, buscando trabalhos nas 5 conferências onde mais se encontrou trabalhos na busca automática: ICEBE - International Conference on e-business Engineering CLOUD - International Conference on Cloud Computing SIGMOD - Special Interest Group on Management Of Data ICACT - International Conference on Advanced Communications Technology ICDE - International Conference on Data Engineering 27

43 3.2. SELEÇÃO DOS DADOS Fonte Query Resultados IEEE (("Document Title":"multi-tenant") OR ("Document Title":"multi-tenancy") OR (Abstract:"multitenant") 93 OR (Abstract:"multi-tenancy")) AND ("Document Title":advantages OR "Document Ti- tle":disadvantages OR "Document Title":approach OR "Document Title":barrier OR "Document Title":adoption OR "Document Title":viability OR "Document Title":approach OR "Document Title":methods OR "Document Title":techniques OR "Document Title":proposal OR "Document Title":framewORk OR "Document Title":tenant OR "Document Title":"product lines"or "Document Title":variability OR "Document Title":variation OR "Document Title":adoption OR "Document Title":viability OR "Document Title":challenges OR "Document Title":problems OR "Document Title":benefits OR "Document Title":loss OR "Document Title":Iaas OR "Document Title":Paas OR "Document Title":Saas OR "Document Title":"Cloud computing"or Abstract:advantages OR Abstract:disadvantages OR Abstract:approach OR Abstract:barrier OR Abstract:adoption OR Abstract:viability OR Abstract:approach OR Abstract:methods OR Abstract:techniques OR Abstract:proposal OR Abstract:framewORk OR Abstract:tenant OR Abstract:"product lines"or Abstract:variability OR Abstract:variation OR Abstract:adoption OR Abstract:viability OR Abstract:challenges OR Abstract:problems OR Abstract:benefits OR Abstract:loss OR Abstract:Iaas OR Abstract:Paas OR Abstract:Saas OR Abstract:"Cloud computing") ACM ((((Title:"multi-tenant") or (Title:"multi-tenancy") or (Abstract:"multi-tenant") or 88 (Abstract:"multi-tenancy")) and (Title:advantages or Title:disadvantages or Title:approach or Title:barrier or Title:adoption or Title:viability or Title:approach or Title:methods or Title:techniques or Title:proposal or Title:framework or Title:tenant or Title:"product lines"or Title:variability or Title:variation or Title:adoption or Title:viability or Title:challenges or Title:problems or Title:benefits or Title:loss or Title:Iaas or Title:Paas or Title:Saas or Title:"Cloud computing"or Abstract:advantages or Abstract:disadvantages or Abstract:approach or Abstract:barrier or Abstract:adoption or Abstract:viability or Abstract:approach or Abstract:methods or Abstract:techniques or Abstract:proposal or Abstract:framework or Abstract:tenant or Abstract:"product lines"or Abstract:variability or Abstract:variation or Abstract:adoption or Abstract:viability or Abstract:challenges or Abstract:problems or Abstract:benefits or Abstract:loss or Abstract:Iaas or Abstract:Paas or Abstract:Saas or Abstract:"Cloud computing"))) and (PublishedAs:journal OR PublishedAs:proceeding OR PublishedAs:magazine) Scopus (TITLE-ABS-KEY(multi-tenancy OR multi-tenant) AND TITLE-ABS-KEY("Cloud computing"or 148 iaas OR paas OR saas OR advantages OR disadvantages OR approach OR barrier OR adoption OR viability OR approach OR methods OR techniques OR proposal OR framework OR tenant OR "product lines"or variability OR variation OR adoption OR viability OR challenges OR problems OR benefits OR loss)) AND SUBJAREA(comp) ScienceDirect (TITLE-ABS-KEY(multi-tenancy OR multi-tenant) AND TITLE-ABS-KEY("Cloud computing"or 144 iaas OR paas OR saas OR advantages OR disadvantages OR approach OR barrier OR adoption OR viability OR approach OR methods OR techniques OR proposal OR framework OR tenant OR "product lines"or variability OR variation OR adoption OR viability OR challenges OR problems OR benefits OR loss))[all Sources(Computer Science)] Engineering Village (multi-tenancy wn TI OR multi-tenant wn TI OR multi-tenancy wn AB OR multi-tenant wn AB ) AND ("Cloud computing"wn TI OR iaas wn TI OR paas wn TI OR saas wn TI OR advantages wn TI OR disadvantages wn TI OR approach wn TI OR barrier wn TI OR adoption wn TI OR viability wn TI OR approach wn TI OR methods wn TI OR techniques wn TI OR proposal wn TI OR framework wn TI OR tenant wn TI OR "product lines"wn TI OR variability wn TI OR variation wn TI OR adoption wn TI OR viability wn TI OR challenges wn TI OR problems wn TI OR benefits wn TI OR loss OR "Cloud computing"wn AB OR iaas wn AB OR paas wn AB OR saas wn AB OR advantages wn AB OR disadvantages wn AB OR approach wn AB OR barrier wn AB OR adoption wn AB OR viability wn AB OR approach wn AB OR methods wn AB OR techniques wn AB OR proposal wn AB OR framework wn AB OR tenant wn AB OR "product lines"wn AB OR variability wn AB OR variation wn AB OR adoption wn AB OR viability wn AB OR challenges wn AB OR problems wn AB OR benefits wn AB OR loss) 152 Tabela 3.2 Strings Search 28

44 3.2. SELEÇÃO DOS DADOS Além das buscas realizadas nessas conferências, foram realizados também buscas de whitepapers de empresas privadas abordando o assunto, como é o caso de Salesforce.com, Amazon e Google que frequentemente publicam documentos sobre o assunto em questão. O Gráfico na Figura 3.2 mostra o percentual de estudos retornados de acordo com cada estratégia de busca, onde 98% (625/637) dos estudos foram retornados por meio de busca automática e 2% (12/637) por meio de busca manual. Figura 3.2 Percentual de estudos retornados de acordo com a estratégia de busca A partir da string e fontes definidas, as buscas automáticas retornaram um total de 625 estudos, no qual, 23% (144/625) no ScienceDirect, 15% (93/625) dos estudos foram identificados no IEEExplore, 24% (152/625) no El compendex, 24% (148/625) no Scopus e 14% (88/625) na ACM. O gráfico da Figura 3.3 mostra o percentual de estudos retornados por cada engenho de busca. Figura 3.3 Percentual de estudos retornados pelas buscas automáticas Identificados os potenciais estudos, eles precisam ser analisados para que sua relevância seja confirmada e trabalhos com pouca relevância sejam descartados. 29

45 3.2. SELEÇÃO DOS DADOS Triagem dos Trabalhos Segundo Travassos (Travassos and Biolchini, 2007) critérios de inclusão e exclusão devem ser baseados nas questões de pesquisas. Os mesmos servem para excluir estudos que não são relevantes para responder às questões da pesquisa. Durante uma leitura prévia dos abstracts dos artigos foi possível identificar alguns artigos que foram retornados na busca que não estavam relacionados ao contexto dessa pesquisa. Isso ocorreu pelo fato das palavras tenancy e tenant também serem utilizadas na área de engenharia civil. Outro ponto importante é identificar e remover resultados duplicados, já que muitos artigos foram retornados em mais de uma fonte de pesquisa. Foram encontrados também alguns trabalhos aos quais o acesso era restrito. Diante desse cenário, com o objetivo de eliminar os trabalhos irrelevantes, foram definidos os seguintes critérios de exclusão: 1. Papers duplicados 2. Trabalhos não relacionados à arquitetura multi-tanancy 3. Poster, Panel e Workshop paper 4. Papers que não estejam escritos em inglês 5. Papers que não acessíveis na web. Após a aplicação dos critérios de exclusão foram eliminados os trabalhos irrelevantes como mostra a Tabela 3.3. Ao final da aplicação dos critérios de exclusão restaram 71 artigos que foram considerados relevantes para esses trabalho. Esses 71 papers podem ser vistos na Tabela A.1, no Apendice A. Cada paper é referenciado nesse mapeamento através do código descrito nessa tabela. A próxima seção apresenta o processo de análise e classificação desses trabalhos. CRITÉRIO TRABALHOS EXCLUÍDOS Trabalhos duplicados 297 Trabalhos não relacionados à arquitetura multi-tanancy 233 Poster, Panel e Workshop paper 14 Papers que não estejam escritos em inglês 3 Papers que não acessíveis na web. 7 Tabela 3.3 Resultado da aplicação dos critérios de exclusão 30

46 3.3. CLASSIFICAÇÃO 3.3 Classificação Nessa seção será descrito o esquema de classificação e os resultados do agrupamento dos trabalhos de acordos com o esquema de classificação definido. O resultado desse agrupamento é apresentado através de tabelas e gráficos no decorrer dessa seção Esquema de Classificação A idéia de categorização dos estudos foi baseado no processo definido por (Petersen et al., 2008). O resumo, título e palavras-chave de cada estudo são revisados em busca de termos e conceitos que reflitam a contribuição do trabalho. Durante essa atividade é identificado também o contexto de cada pesquisa. Nesse processo palavras-chave de diferentes artigos são combinadas para desenvolver um entendimento de alto nível sobre a natureza e a contribuição da pesquisa. Isso auxiliou na definição de um conjunto de categorias que ajudaram representativamente no entendimento de nossa população de artigos. Em nosso estudo três categorizações foram criadas. A primeira delas verifica a área de interesse de multi-tenancy no qual o estudo é focado, por exemplo: banco de dados, alocação de recursos, customização, performance, segurança, escalabilidade, migração de sistemas, SOA e monitoramento. Essas categorias foram baseadas em nos trabalhos (Godse and Mulik, 2009) e (Höfer and Karagiannis, 2011), cada uma delas é descrita na Tabela 3.4. A segunda faceta (Tabela 3.6) agrupa os trabalhos de acordo com suas principais contribuições: framework, método/técnica, modelo, ferramenta e proposta de arquitetura. Essas duas primeiras facetas foram criadas apartir da identificação dos termos mais importantes existentes no título, resumo, introdução e conclusão dos estudos encontrados. No entanto, nesse trabalho também foi utilizado uma faceta que reflete a abordagem de pesquisa usada em cada artigo, independente do foco ou área associado ao artigo. Para isso foi considerado a classificação utilizada por (Wieringa et al., 2005). Essa classificação é descrita na Tabela Classificação dos trabalhos relevantes Essa atividade consiste em agrupar os trabalhos relevantes de acordo com as questões de pesquisa e facetas definidas anteriormente. Durante essa atividade foi possível encontrar alguns trabalhos que poderiam auxiliar na resposta de mais de uma questão de pesquisa. É possível perceber também que tem-se poucos trabalhos relacionados à resposta da 31

47 3.3. CLASSIFICAÇÃO CATEGORIA Alocação de recursos Banco de dados Customização Escalabilidade Migração Monitoramento Performance Segurança SOA Virtualização DESCRIÇÃO Essa categoria agrupa trabalhos que estudam ou propõem soluções para alocação eficiente de recursos(processamento, armazenamento, largura de banda) em uma arquitetura multi-tenancy. Métodos, técnicas e ferramentas que auxiliem na implementação de uma aplicação multi-tenancy para de banco de dados. Nessa categoria também inclui trabalhos que realizam comparativos e experimentos relacionados a técnicas de implementação de requisitos multi-tenancy para de banco de dados. Em muitos casos um tenant pode precisar de customizações específicas para poder atender às necessidades de um cliente. Nesse caso é necessário a aplicação de técnicas para implementar e gerenciar a variabilidade entre os tenants de uma aplicação multitenancy. Essa categoria agrupa trabalhos que estudam ou propõem ferramentas, técnicas ou métodos para resolver o problema de variabilidade de tenants. O principal objetivo de uma aplicação SaaS é atender a muitos clientes a um baixo custo. Nesse caso, permitir que a aplicação consiga atender a um número cada vez maior de clientes é de fundamental importância. Essa categoria agrupa trabalhos que abordem o problema de escalabilidade. Em muitos casos uma empresa pode possuir uma aplicação convencional e deseja transformá-la em uma aplicação multi-tenancy. Essa categoria agrupa trabalhos que estudem ou proponham uma solução para esse problema. Uma questão de grande importância para o sucesso de uma aplicação multi-tenancy é o atendimento à SLA definida para cada cliente. Os trabalhos associados a esse grupo apresentam estudos e propostas para monitoramento dos tenants da aplicação quanto à consumo de recursos ou qualidade de serviço. Esses trabalhos abordam metodologias e técnicas que otimizem a performance de uma aplicação. Tendo em vista que vários tenants podem compartilhar a mesma aplicação e o mesmo banco de dados, é vital para uma aplicação multi-tenancy isolar cada tenant de forma a não permitir acesso a dados não autorizados. Esses trabalhos abordam como SOA pode ser utilizada na implementação de uma aplicação multi-tenancy. Esses trabalhos abordam como virtualização pode ser utilizada para auxiliar o desenvolvimento de aplicações multi-tenancy. Tabela 3.4 Faceta Contexto questão 4, como é possível observar na Figura 3.4. Isso pode ser um indicativo que essa área poderia ser melhor explorada. Tão importante quanto saber qual questão o trabalho responde é saber a qual contexto ele está relacionado. Baseado nesse princípio foram criadas as categorias descritas na Tabela 3.4. Na Tabela 3.8 os trabalhos são agrupados por contexto. O objetivo com isso é identificar em qual subárea de multi-tenancy o trabalho está focado. Por exemplo, quais trabalhos estudam a relação entre multi-tenancy e banco de dados, ou multi-tenancy e segurança, etc. A Figura 3.5 apresenta a quantidade de artigos em cada uma dessas categorias. É possível notar que Banco de dados, Customização e Performance são as principais áreas de interesse dos pesquisadores no tocante a multi-tenancy. Identificado o foco de cada trabalho, é necessário saber as contribuições de cada 32

48 3.3. CLASSIFICAÇÃO CATEGORIA Validation Research Evaluation Research Solution Proposal Philosophical Paper Opinion Paper Experience Paper DESCRIÇÃO As técnicas investigadas são novas e não foram implementadas ainda na prática. As técnicas usadas são,por exemplo, experimentos realizados em laboratório. Técnicas são implementadas na prática e uma avaliação da técnicas é conduzida. É mostrado como a técnica é implementada na prática (solução de implementação) e quais são as consequências da implementação em termos de benefícios e perdas (avaliação da implementação). Isso também inclui identificar problemas na indústria. A solução para o problema é proposto, a solução pode ser nova ou uma extensão significativa de uma técnica existente. Os potenciais benefícios e a aplicabilidade da solução é mostrada por pequenos exemplos ou uma boa linha de argumentação Esses artigos esboçam uma nova forma de visualizar coisas existentes pela estruturação do campo de pesquisa em termos de taxonomia ou framework conceitual. Esses artigos expressam uma opinião pessoal de alguém sobre alguma técnica ou se ela é boa ou ruim, ou como as coisas deveriam ser feitas. Eles não dependem de trabalhos relacionados ou metodologias de pesquisa. Artigos de experiência explicam o que e como algo vem sendo feito na prática. Deve ser uma experiência pessoal do autor. Tabela 3.5 Faceta Tipos de pesquisa (Fonte: (Wieringa et al., 2005)) Figura 3.4 Quantidade de artigos por questão trabalho. Isso pode ajudar a saber em qual nível de maturidade as pesquisas relacionadas a multi-tenancy encontram-se. Dado que um dos objetivos desse trabalho é gerar insumos para possíveis implementações futuras, é importante saber se já existem frameworks, ferramentas, métodos, modelos, arquiteturas, etc, que possam ser utilizadas durante uma possível implementação. A Tabela 3.9 apresenta os trabalhos agrupados por contribuição. Em alguns casos é possível que um trabalho apresente mais de uma contribuição e nesse caso irá aparecer em mais de uma categoria. De acordo com a Figura 3.6 é visivelmente perceptível que a grande maioria dos trabalhos apresentam propostas de arquitetura e métodos ou técnicas para resolver algum problema associado a multi-tenancy. Pode-se observar também que a área é carente de trabalhos que apresentem experimentos e estudos de caso sobre o assunto. Outra forma de mapear os trabalhos é através do tipo de pesquisa realizado no trabalho, essa categorização foi descrita na Tabela 3.5 e o resultado de sua aplicação é apresentado na Tabela

49 3.3. CLASSIFICAÇÃO CATEGORIA Framework Método ou técnica Modelo Ferramenta Proposta de Arquitetura DESCRIÇÃO Essa categoria agrupa trabalho que apresentam frameworks que auxiliam no desenvolvimento de aplicações multi-tenancy. Consideramos framework como um construto fundamental que define pressupostos, conceitos, valores e práticas, e que inclui orientações para a execução propriamente dita (Tomhave, 2005). Trabalhos que apresentam métodos e técnicas que tem o objetivo de resolver algum problema específico durante a implementação de aplicações multi-tenancy Agrupa trabalhos que definem construções conceituais que auxiliam no desenvolvimento de aplicações multi-tenancy. Consideramos modelo como um resumo, uma construção conceitual que representa processos, variáveis e relacionamentos, sem prover orientações específicas ou práticas para implementação (Tomhave, 2005). Essa categoria agrupa ferramentas implementadas para atender à algum requisito de multi-tenancy ou para auxiliar durante o desenvolvimento de uma aplicação. Agrupamento de propostas de arquitetura para implementação de aplicações multitenancy ou propostas de arquitetura de plataformas de suporte à multi-tenancy. Tabela 3.6 Faceta Contribuição (Fonte: (Wieringa et al., 2005)) Questão Q1 Q2 Q3 Q4 Artigos Relacionados EP09, EP11, EP12, EP13, EP15, EP32, EP44, EP45, EP54, EP55, EP57, EP66 EP03, EP04, EP05, EP06, EP07, EP08, EP09, EP1, EP11, EP13, EP15, EP16, EP17, EP18, EP19, EP20, EP21, EP22, EP23, EP24, EP26, EP27, EP28, EP29, EP30, EP31, EP32, EP33, EP35, EP38, EP39, EP40, EP41, EP42, EP43, EP44, EP46, EP47, EP48, EP49, EP50, EP51, EP52, EP53, EP56, EP57, EP58, EP59, EP60, EP61, EP62, EP63, EP64, EP65, EP66, EP67, EP68, EP69, EP70, EP71 E0P8, EP02, EP05, EP06, EP07, EP10, EP14, EP16, EP25, EP29, EP30, EP34, EP36, EP37, EP47, EP57 EP05, EP08, EP11, EP26, EP45 Tabela 3.7 Artigos associados por Questão de pesquisa Para um melhor entendimento da área pesquisada e do seu grau de maturidade, foi realizado o cruzamento de algumas categorizações. O objetivo dessa atividade é identificar por exemplo, quantos trabalhos tratam de métodos ou frameworks para resolver problemas de performance de uma aplicação multi-tenancy, ou quais trabalhos apresentam soluções para monitoramento de aplicações multi-tenancy, dentre outros. As Figuras 3.7, 3.8, 3.9 e 3.10 apresentam o resultado desse mapeamento. Observando a Figura 3.7 é possível perceber que a maioria dos trabalhos encontrados foram publicados nos anos de 2010 e 2011, e dentre esses o os principais temas de pesquisa foram customização, performance, segurança, alocação de recursos e banco de dados. Pode-se observar também que em todos os anos temos publicações realcionadas a bancos de dados, customização e performance, isso é um indicativo de que tais áreas possuem aparentemente maior relevância para o desenvolvimento de aplicações multitenancy. Essa figura pode ser muito útil para que pesquisadores possam identificar áreas pouco exploradas no campo de desenvolvimento de aplicações multi-tenancy, de forma a 34

50 3.3. CLASSIFICAÇÃO Figura 3.5 Quantidade de artigos por contexto Contexto Alocação de Recursos Banco de Dados Customização Escalabilidade Migração Monitoramento Performance Segurança SOA Virtualização Artigos Relacionados EP13, EP26, EP32, EP39, EP51, EP55, EP66, EP70 EP03, EP05, EP08, EP09, EP20, EP24, EP28, EP45, EP49, EP57, EP60, EP61, EP63, EP64, EP67, EP69 EP01, EP02, EP05, EP07, EP10, EP14, EP16, EP24, EP25, EP30, EP34, EP36, EP37, EP39, EP42, EP44, EP47, EP55, EP63, EP70 EP31, EP39, EP62, EP70 EP21, EP41, EP71 EP17, EP43 EP01, EP06, EP09, EP15, EP19, EP23, EP38, EP40, EP51, EP52, EP56, EP62 EP01, EP05, EP18, EP22, EP23, EP24, EP35, EP44, EP45, EP54, EP58, EP68 EP11, EP29, EP33, EP46, EP48, EP50 EP04,EP53,EP65 Tabela 3.8 Artigos agrupados por contexto servir como ponto de partida para seus trabalhos de pesquisa. A Figura 3.8 foi criada com o objetivo de auxiliar em decisões a serem tomadas durante o processo de desenvolvimento de software. Durante esse processo é muito comum dúvidas sobre qual técnica será utilizada para implementar o mecanismo de customização da aplicação, qual mecanismo de armazenamento de dados será utilizado, como poder-se-á garantir uma performance aceitável para a aplicação. Observando o gráfico foi possível verificar que a maioria dos trabalhos apresentava algum método/técnica ou alguma proposta de arquitetura para multi-tenancy e a área mais carente de trabalhos é escalabilidade. A maioria dos métodos e técnicas apresentados tratam de assuntos como banco de dados, customização, performance e segurança. Já as arquiteturas e geral focam mais em banco de dados e customização. Ainda assim, foram encontrados trabalhos que apresentam arquiteturas que tratam de assuntos como alocação de recursos, escalabilidade, 35

51 3.3. CLASSIFICAÇÃO Figura 3.6 Quantidade de artigos por contribuição Contribuição Proposta de Arquitetura Ferramenta Framework Método/Técnica Modelo Artigos Relacionados EP09, EP17, EP31, EP33, EP39, EP40, EP44, EP45, EP46, EP48, EP56, EP58, EP63, EP70 EP15, EP42, EP61, EP69 EP01, EP05, EP10, EP26, EP27, EP32, EP38, EP47, EP50, EP53 EP02, EP03, EP04, EP06, EP07, EP08, EP11, EP13, EP16, EP18, EP19, EP20, EP21, EP22, EP23, EP25, EP28, EP29, EP35, EP36, EP41, EP43, EP52, EP64, EP65, EP66, EP69, EP71 EP30, EP49, EP51, EP60, EP62, EP68 Tabela 3.9 Artigos agrupados por contribuição Figura 3.7 Quantidade de artigos agrupados por Contexto e Ano 36

52 3.3. CLASSIFICAÇÃO Tipo de pesquisa Validation Research Evaluation Research Solution Proposal Philosophical Paper Opinion Paper Experience Paper Artigos Relacionados EP28, EP31, EP42, EP50, EP57, EP61, EP62, EP66, EP67, EP69 EP05, EP11, EP37 EP01, EP02, EP04, EP07, EP08, EP13, EP14, EP15, EP16, EP17, EP18, EP19, EP20, EP21, EP22, EP23, EP25, EP26, EP27, EP29, EP30, EP32, EP33, EP35, EP36, EP38, EP39, EP40, EP41, EP43, EP46, EP47, EP48, EP49, EP51, EP52, EP53, EP56, EP58, EP60, EP64, EP65, EP68, EP70, EP71 EP10, EP59 EP03,EP12 EP06, EP09, EP24, EP34, EP44, EP45, EP54, EP55, EP63 Tabela 3.10 Artigos agrupados por Tipo de Pesquisa Figura 3.8 Quantidade de artigos agrupados por Contexto e Contribuição performance, segurança e arquiteturas que se beneficiam de integração de serviços com forte influência de SOA. Para identificar as lacunas existentes na área de pesquisa foi criada a Figura 3.9, com o objetivo de identificar quais tipos de pesquisa foram desenvolvidos em cada contexto relacionado a multi-tenancy. Observou-se que a maioria dos trabalhos apresenta propostas de solução e que tem-se poucos trabalhos objetivando realizar experimentos e validações dessas propostas na indústria. É possível observar a grande evolução das pesquisas na área de customização. Em geral, os autores desses trabalhos são pesquisadores da área de SPL(Software Product Lines) que vislumbraram em multi-tenancy uma oportunidade de aplicar seus conhecimentos de customização. A Figura 3.10 apresenta um mapeamento dos tipos de pesquisa por questão de pesquisa, esse cruzamento de informações ajudou a organizar os dados de forma a identificar para cada questão de pesquisa quais os tipos de trabalhos que mais foram 37

53 3.3. CLASSIFICAÇÃO Figura 3.9 Quantidade de artigos agrupados por Contexto e Tipo de Pesquisa realizados. Percebeu-se que a questão de pesquisa 2 (Quais as propostas existentes para implementação da arquitetura multi-tenancy?) possui a maior quantidade de trabalhos associados, mas que a maioria são propostas de solução que ainda não foram validadas na indústria. Isso indica a necessidade de integração dos pesquisadores dessas áreas com o mercado de forma a validar as propostas apresentadas e evoluir o campo de pesquisa, que vem crescendo a cada ano como mostra a Figura??. Essa Figura apresenta todos os estudos utilizados em nosso mapeamento agrupados por ano de publicação. O Ano de 2011 encontra-se com poucos trabalho pelo fato das buscas terem sido realizadas na metade do mesmo ano, quando nem todos os eventos realizados no ano em questão haviam publicado seus trabalhos nas bibliotecas digitais utilizadas. Embora os gráficos apresentados até aqui tenham sido de grande relevância para esse trabalho, durante a leitura dos trabalhos encontrados foi encontrado algumas informações importantes que podem ajudar os leitores a entender melhor cada contexto relacionado a multi-tenancy. A seção a seguir apresenta as principais descobertas realizadas durante essa leitura. 38

54 3.3. CLASSIFICAÇÃO Figura 3.10 Quantidade de artigos agrupados por Questão e Tipo de Pesquisa Figura 3.11 Quantidade de artigos por ano 39

55 3.4. PRINCIPAIS DESCOBERTAS 3.4 Principais Descobertas Alocação de Recursos Para que se possa desfrutar dos benefícios que uma aplicação multi-tenancy traz, um conjunto de desafios devem ser solucionados (Kwok and Mohindra, 2008): 1. calcular os recursos computacionais necessários para o funcionamento de cada novo tenant, e ao mesmo tempo atender às restrições de todos os tenants em instância da aplicação compartilhada. 2. Identificar fatores limitantes ou gargalos nos recursos computacionais requeridos para as várias instâncias, cada uma com vários tenants contendo diferentes restrições que devem ser atendidas. 3. Durante a distribuição dos tenants é necessário indicar a melhor localização para que nenhuma restrição de SLA seja violada. 4. A distribuição dos tenants e instâncias em um ambiente de computação distribuído deve ser automatizada. 5. A economia alcançada entre as diferentes formas de distribuições de tenants e instâncias deve ser comparada e otimizada, de forma que seja encontrada a melhor distribuição possível. O cálculo do número máximo de usuários e tenants em uma instância compartilhada em um servidor, sem que haja violação de restrições definidas no contrato de SLA de cada tenant é um desafio não trivial. Em (Kwok and Mohindra, 2008) os autores propõem uma abordagem para o cálculo de recursos requeridos para o bom funcionamento de vários tenants em uma instância de aplicação compartilhada. Nesse trabalho também é descrito um método para otimizar a distribuição de tenants e instâncias de uma aplicação em um conjunto de servidores sem violar qualquer requisito de SLA dos tenants. Por fim os autores apresentam uma ferramenta que tem o objetivo de auxiliar o deployment de aplicações multi-tenancy usando o número mínimo de servidores, fornecendo portanto o máximo de economia em um ambiente de computação distribuído. Em (Fehling et al., 2010), os autores também realizam um estudo sobre as oportunidades de otimização do uso de recursos, mas nesse caso o cenário considerado é um ambiente de computação heterogêneo onde os recursos utilizados são oriundos de 40

56 3.4. PRINCIPAIS DESCOBERTAS clouds públicas e privadas. Nesse trabalhos os autores utilizam um algoritmo Smarter Simulated Annealing para auxiliar na busca de uma distribuição otimizada dos recursos computacionais. Outra questão associada à alocação de recursos é a priorização das requisições recebidas por uma instância de uma aplicação multi-tenancy. Em um cenário multi-tenancy é comum que cada tenant necessite priorizar as requisições de seus consumidores de tal maneira que um consumidor com prioridade alta poderá ser atendido mais rapidamente que outro, e que a instância da aplicação também priorize os tenants, de forma que as requisições de um tenant tenha maior prioridade de atendimento que outros. Diante desse cenário, os autores de (Tsai et al., 2010b) propõem um modelo para priorizar requisições de vários tenants enquanto preserva as prioridades locais das requisições de um tenant específico. Os autores propõem um algoritmo chamado Crystalline Mapping que mapeia prioridades internas de um tenant específico para prioridades globais Banco de Dados Uma das preocupações quando pretende-se implementar uma aplicação multi-tenancy é planejar como os dados da aplicação serão armazenados. Atualmente, boa parte das aplicações existentes no mercado utilizam bancos de dados relacionais. Existem várias estratégias para implementar um esquema de banco de dados relacional de forma que ele permita o armazenamento de dados de vários tenants. (Aulbach et al., 2008) apresenta várias dessas técnicas, que são mostradas na Figura 3.12 e brevemente descritas a seguir: Basic Layout - a técnica mais básica para implementar multi-tenancy é adicionar uma coluna TENANTID em cada tabela para armazenar um valor que identifica a qual tenant um registro pertence. Essa abordagem provê uma boa consolidação mas não provê uma boa extensibilidade, já que não possui nenhum mecanismo para customização de armazenamento de dados para um tenant específico. Private Table - é a forma mais básica para suportar extensibilidade, dado que cada tenant possui sua próprias tabelas privadas. Nessa abordagem, é necessário uma camada de transformação de queries para ajustar o nome das tabelas nas queries e substituir pelo nome da tabela privada. Extension Table - essa técnica é a combinação das duas técnicas anteriores, as tabelas de extensão bem como as tabelas base devem possuir uma coluna para armazenar os dados de identificação do tenant. Outra coluna também precisa ser 41

57 3.4. PRINCIPAIS DESCOBERTAS adicionada para armazenar a tabela lógica para que os dados possam ser reconstruídos. Essa abordagem é utilizada para mapear esquemas orientados a objeto com herança no modelos relacional atualmente. Universal Table - estruturas genéricas permitem a criação de um número arbitrário de tabelas com formas arbitrárias. Universal Table é uma estrutura genérica com uma coluna Tenant, uma coluna Table e um grande número de colunas de dados genéricas. A coluna de dados tem um tipo flexível, como VARCHAR, no qual outro tipo pode ser convertido. Pivot Table - nessa técnica as entidades de domínio são representadas por tabelas lógicas, cujas informações são montadas dinâmicamente. Uma Pivot Table possui as seguintes colunas: Tenant(identifica o tenant), Table(identifica a tabela à qual o dado está associado), Row(identificar a linha à qual o dado está associado) Col(identifica o campo que a linha representa) e uma coluna para armazenar o dado em si, que pode ser armazenada em um tipo flexível como VARCHAR. Essa abordagem proporciona uma alta flexibilidade mas possui muitas colunas de metadados que podem impactar negativamente na performance da aplicação, durante a manipulação dos dados. Chunk Table - essa técnica é uma extensão da técnica anterior e trabalha com o conceito de Chunk Table. Uma Chunk Table é semelhante a uma Pivot Table exceto pelo fato de possuir um conjunto de colunas de dados de vários tipos, e a coluna Col é substituida pela coluna Chunk. Em comparação com a técnica Pivot Table, essa técnica armazena uma quantidade menor de metadados, o que diminui o tempo de reconstrução da tabela lógica. Chunk Folding - as tabelas lógicas são verticalmente particionadas em chunks, os quais permitem junção quando necessário. Essas são as técnicas básicas para a implementação de modelos de dados para aplicações multi-tenancy, outras abordagens foram criadas apartir delas como é o caso de (Foping et al., 2009; Xue et al., 2011; Weiliang et al., 2010). Em (Aulbach et al., 2009) é realizado um estudo experimental para comparar cinco técnicas de implementação de aplicações multi-tenancy a nível de banco de dados. Os autores concluíram que ainda não existe um Sistema de Gerenciamento de Banco de Dados(SGBD) ideal para esse tipo de aplicação e que um SGBD para SaaS deveria ser baseado na técnica Private Table. 42

58 3.4. PRINCIPAIS DESCOBERTAS Figura 3.12 Técnicas de mapeamento de esquema(fonte: (Aulbach et al., 2008)) 43

59 3.4. PRINCIPAIS DESCOBERTAS Schiller (Schiller et al., 2011) apresenta em seu trabalho as primeiras funcionalidades para que um SGBD relacional possa suportar múltiplos tenants nativamente. Em sua proposta tenants são introduzidos como objetos de primeira classe e é proposto o conceito de "contexto"para isolar um tenant de outro. Além disso, o conceito de herança permite compartilhar o esquema da aplicação entre os tenants, ao mesmo tempo em que permite que o esquema seja extendido com estruturas de dados adicionais. Ao final do trabalho o autor realiza uma avaliação da implementação de sua proposta através de experimentos Customização Um ponto importante em uma aplicação multi-tenancy é a customização. Em aplicações web customizáveis o código torna-se mais complexo, problemas de performance impactam todos os tenants da aplicação e planejar segurança e robustez tornam-se pontos importantes. Segundo (Jansen et al., 2010), existem três áreas de pesquisa que são diretamente relacionadas a Técnicas de Realização de Customização(Customization Realization Techniques - CRT) em aplicações multi-tenancy: variabilidade em linhas de produtos de software, personalização do usuário final em aplicações web e arquiteturas multi-tenancy. Pesquisadores que pretendem atacar esse problema devem direcionar seus estudos nessas três áreas. Outro ponto importante é que os tenants de uma aplicação multi-tenancy não somente tem diferentes requisitos com respeito a propriedades funcionais, mas também podem exigir diferentes propriedades de qualidade de serviço como privacidade e performance. Alguns tenants exigem que a aplicação possua alta disponibilidade e estão dispostos a pagar um alto preço pelo uso desse serviço. Outros tenants não estão interessados em alta disponibilidade mas preocupam-se mais com um baixo preço. Em casos como esse é necessário que exista na aplicação algum mecanismo para ajustar a aplicação às reais necessidades do usuário, no tocante aos casos citados anteriormente Escalabilidade Para alcançar economia de escala, esse é um dos problemas mais críticos para serem resolvidos em um cenário real. Dado um número fixo de servidores, é necessário otimizar a distribuição dos tenants de forma a maximizar o número total de tenants possíveis sem violar seus requisitos de SLA e ainda estar preparado para o crescimento do volume de dados e de requisições. Em (Yuanyuan et al., 2009), os autores apresentam uma arquitetura focada na escala- 44

60 3.4. PRINCIPAIS DESCOBERTAS bilidade de dados. Eles propõem uma entidade com base em grupos de particionamento horizontal, através da análise das relações entre as entidades de uma aplicação multitenancy. Nessa abordagem, entidades de negócio altamente coesas formam um grupo de entidades e o particionamento ocorre com base nesse grupo. Dessa forma cada operação acessa um único grupo de instâncias, podendo obter os dados necessários através do acesso a um único banco de dados e evitando a necessidade de transações distribuídas. (Koziolek, 2010) e (Koziolek, 2011) apresentam um estilo arquitetural focado em escalabilidade de dados e ilustra como os conceitos apresentados nesses trabalhos podem ajudar a fazer as Plataformas como Serviço(PaaS) atuais como Force.com,Windows Azure, e Google App Engine escaláveis e customizáveis. Já em (Zhang et al., 2010b), os autores focam no problema de localização de tenants, propõem um algoritmo heurístico chamado Tenant Dispatch Heuristic(TDH) e realizam um conjunto de simulações e comparações onde é avaliado como o uso desse algoritmo impacta na escalabilidade e economia de recursos Migração Migrar aplicações web legadas que trabalham com um único tenant(isolated Tenancy Hosted Applications - ITHA) para multi-tenancy(multi-tenancy Enabled Application - MTEA) é não é uma tarefa trivial, devido a quantidade de ferramentas e técnicas de migração apropriadas. De acordo com (Zhang et al., 2010a) os métodos existentes para migração são muito abstratos ou muito específicos quando tentamos aplicá-los como guias para migrar uma aplicação que trabalha com um tenant isolado para uma aplicação multi-tenancy. Nesse mesmo trabalho os autores propõem um método sistemático que provê diretrizes para migrar aplicações ITHA para MTEA, levando em conta custo, risco e efetividade do método de migração. Dado a característica de demanda sazonal existente em vários tipos de aplicação, uma funcionalidade essencial para um ambiente multi-tenancy é a funcionalidade que permite a migração de tenants entre hosts, uma técnica chamada live migration(clark et al., 2005; Liu et al., 2009). Em (Elmore et al., 2011) os autores apresentam Zephyr, uma técnica para live migration que tem o objetivo de minimizar a interrupção de serviço do tenant migrado. Através da introdução de uma sincronização dupla que permite a ambos os nós, o nó origem dos dados e o nó destino, executarem simultaneamente transações para o tenant. A migração inicia-se com a transferência dos metadados do tenant para o nó destino, que pode realizar novas transações enquanto o nó origem completa as transações que foram 45

61 3.4. PRINCIPAIS DESCOBERTAS iniciadas quando a migração se iniciou. De acordo com os autores, live migration é uma importante característica para habilitar elasticidade em bancos de dados multi-tenancy para plataformas de cloud Monitoramento Para obter uma visão geral do funcionamento de seus serviços, provedores de serviço precisam de informações sobre todas as camada de seus sistema, incluindo a aplicação, máquinas virtuais e uso de rede. Por razões de simplicidade, todas essas informações devem idealmente ser entregues através de uma única interface de monitoramento. Em (Hasselmeyer and d Heureuse, 2010) os autores apresentam alguns requisitos básicos de uma infraestrutura de monitoramento para ambientes multi-tenancy: Multi-tenancy: a infraestrutura de monitoramento precisa naturalmente ser capaz de lidar com informações de monitoramento provinientes de diferentes clientes (tenants). Escalabilidade: uma solução de monitoramento precisa ser escalável em vários aspectos. Ela precisa escalar para um grande número de agentes de monitoramento, de notificação de eventos, de tenants, de recursos(virtuais e físicos, servidores, elementos de rede e aplicações), e de tipos de informação de monitoramento. Dinamismo: sistemas de monitoramento multi-tenancy precisam suportar o dinamismo que é inerente a um ambiente multi-tenancy. Esse dinamismo decorre da rápida e frequente adição e remoção de tenants no datacenter. Além disso, a alocação de recursos para os tenants também está em constante mudança e o conjunto de recursos que está sendo monitorado também pode mudar. Simplicidade: o sistema de monitoramento deveria ser simples em dois aspectos: primeiro, a interface para monitoramento do sistema precisa ser fácil de entender e usar. Segundo, o sistema precisar ser fácil de instalar e manter, tanto para quem gerencia o datacenter quanto para os consumidores. Uma API simples é desejável, uma vez que facilita o trabalho de desenvolvedores que criam soluções de controle e monitoramento. Abrangência: esse requisito aborda a necessidade de uma infraestrutura única de monitoramento que deve ser utilizável para todos os tipos de informação de monitoramento, não importa o que está relacionado ao recurso ou qual o significado 46

62 3.4. PRINCIPAIS DESCOBERTAS que ele transmite. Essa abrangência aplica-se a multiplos aspectos: tipos de dados, fontes de notificação e tenants. Já em (Cheng et al., 2009) os autores propõem um mecanismo de controle que monitora a qualidade de serviço por tenant, detecta situações anormais e dinamicamente ajusta o uso de recursos baseado nos parametros de SLA definidos para o tenant. Nesse trabalho os autores apresenta sua proposta e realizam um estudo experimental para avaliar os resultados Performance Esse assunto está diretamente ligado à monitoramento de aplicações multi-tenancy, isso porque aplicações são monitoradas para que se possa verificar se a mesma está executando em um nível de performance compatível com a SLA definida para o cliente. Desde 2008 temos um bom número de trabalhos que estudam esse problema, dentre eles estão propostas de arquitetura, frameworks, métodos, técnicas, ferramentas e experimentos, que utilizam as mais variadas abordagens. O primeiro trabalho encontrado relacionado à performance foi (Wang et al., 2008a), onde os autores apresentam os principais padrões de implementação de aplicações multi-tenancy que tratam dos aspectos de isolamento e segurança, e avaliam a performance desse padrões através de uma série de experimentos e simulações. Para permitir que um provedor de serviço ofereça diferentes níveis de performance baseado no nível de SLA definido para um tenant específico, (Lin et al., 2009b) propõe uma solução que utiliza um regulador de performance baseado no controle de feedback. O regulador possui uma estrutura hierárquica, na qual um controlador de alto nível gerencia a taxa de admissão de requisições para prevenir sobrecarga e um controlador de baixo nível que gerencia os recursos alocados pelas requisições admitidas para alcançar um nível específico de diferenciação de serviço entre os tenants que compartilham os mesmos recursos. Um protótipo dessa abordagem é implementado utilizando Tomcat e MySQL e ao final são realzados alguns experimentos para validar a proposta. Outro ponto importante é o isolamento de performance para prevenir protenciais anomalias de comportamento de um tenant, que possam afetar a performance de outros tenants que compartilham os mesmos recursos. Em (Li et al., 2008) os autores propõem o SPIN(Service Performance Isolation Infrastructure) que visa permitir um abrangente compartilhamento de recursos em ambientes multi-tenancy. Uma vez que alguns tenants agressivos podem interferir na performance de outros tenants, SPIN fornece um relatório 47

63 3.4. PRINCIPAIS DESCOBERTAS de anomalias, identifica os tenants agressivos, e fornece um mecanismo de moderação para eliminar o impacto negativo em outros tenants. Durante sua pesquisa os autores implementaram um protótipo do SPIN e realizaram alguns experimentos para demonstrar sua eficiência. Um desafio interessante na área de gerenciamento de performance é entender e predizer performance de sistemas. Durante a realização desse mapeamento foram encontradas duas abordagens relacionadas a esse assunto. (Schaffner et al., 2011) apresenta um estudo sobre a automação de tarefas operacionais em clusters multi-tenancy de bancos de dados em memória orientados a coluna. Foi desenvolvido um modelo para predizer se a alocação de um tenant em um servidor no cluster levaria a uma violação no tempo de resposta esperado. Já em (Ahmad and Bowman, 2011) é realizado um estudo experimental para entender e predizer a performance de sistemas, nesse trabalho os autores sugerem uma abordagem de máquina de aprendizado que usa dados monitorados para entender a performance do sistema. (Guo et al., 2007) apresenta um framework que possui um componente específico para isolamento de performance. Segundo os autores os objetivos principais do isolamento de performance incluem dois aspectos. Primeiro, evitar que o comportamento(potencialmente ruim) de um tenant afete o comportamento de outro tenant de maneira imprevista. Segundo, evitar a injustiça entre tenants em termos de performance de uso. Para alcançar esse objetivo os autores sugerem um padrão de isolamento de performance híbrido, baseado em várias técnicas apresentadas em seu trabalho Segurança Confiança é um dos maiores desafios que influenciam a ampla aceitação de SaaS. Na ausência de confiança em SaaS, segurança e privacidade de dados figuram entre os principais e mais importantes assuntos relacionados a arquitetura multi-tenancy. Foram encontrados durante nossa pesquisa alguns trabalhos publicados nos últimos 2 anos que estão relacionados a esse assunto. Um assunto bastante relevante é a avaliação de credibilidade de tenants, que indica quais tenants tem um comportamento que possa prejudicar o funcionamento dos demais. Zhiqiang(Nie, 2010) apresenta um algoritmo de avaliação de credibilidade de tenants baseado na experiência. Essa abordagem visa realizar a detecção e gerenciamento de tenants maliciosos a um baixo custo. De acordo com o histórico de acesso dos tenants, ele pode calcular a credibilidade de tenants, atribuir privilégios de acesso e determinar estratégias de detecção e monitoramento. 48

64 3.4. PRINCIPAIS DESCOBERTAS De acordo com (Li et al., 2010) separação de responsabilidade de segurança entre provedores SaaS e consumidores precisa ser suportada em um ambiente de cloud. Arquitetura multi-tenancy baseada em modelo de controle de acesso (MTACM - multi-tenancy based access control model) foi projetada para inserir o princípio de separação de responsabilidade de segurança em cloud; essa arquitetura define dois níveis de granularidade no mecanismo de controle de acesso. O primeiro nível está relacionado ao provedor de serviço, que compartilha sua infraestrutura entre vários clientes. O segundo nível é o nível da aplicação onde uma mesma aplicação hospeda informações de vários tenants. Em (Zhang et al., 2009; Calero et al., 2010; Tsai and Shao, 2011) são apresentadas três abordagens diferentes para implementação de mecanismos de segurança e controle de acesso para aplicações multi-tenancy. Em (Zhang et al., 2009) é proposta uma abordagem de controle de acesso baseado em restrições de privacidade customizáveis. Essa abordagem combina criptografia de dados e separação de informação e define três tipos de restrições de privacidade baseado na funcionalidade de customização em aplicações SaaS. (Calero et al., 2010) descreve um sistema de autorização para um serviço de middleware em uma PaaS, que suporta controle de acesso baseado em hierarquia de funções, hierarquia de objetos baseada em caminho e federações. Os autores apresentam também uma arquitetura de sistema de autorização para implementação do modelo. De acordo com Wei-Tek(Tsai and Shao, 2011) as abordagens atuais para controle de accesso em cloud não escalam bem para requisitos multi-tenancy porque eles são baseados principalmente em identificadores(ids) de usuário individual em diferentes níveis de granularidade. No entanto, o número de usuários pode ser enorme e causar um overread significante no gerenciamento de segurança. RBAC (Role-Based Access Control) torna-se atrativo nesse caso pelo fato do número de papéis de usuário em uma aplicação ser significativamento menor, e usuários podem ser classificados de acordo com seus papéis. Wei-Tek propõe um RBAC usando uma ontologia de papéis para arquitetura multi-tenancy em clouds SOA De acordo com o cenário apresentado até aqui, é possível perceber que seria muito difícil e caro criar uma aplicação multi-tenancy que fosse tão configurável a ponto de permitir que todos os requisitos do usuário pudessem ser atendidos através de configurações. Mesmo nesse cenário é possível permitir que os próprios usuários implementem parte de suas soluções e as integrem à plataforma multi-tenancy utilizada. Para solucionar esse problema, alguns autores propuseram abordagens para implementar arquitetura 49

65 3.5. MAPEAMENTO DAS EVIDÊNCIAS multi-tenancy com SOA. Afkham Azeez(Azeez et al., 2010) apresenta uma arquitetura para implementar multitenancy no nível de SOA, que habilita usuários a executar seus serviços e outros artefatos SOA em um framework multi-tenancy SOA, bem como prover um ambiente para construir aplicações multi-tenancy. Em seu trabalho os autores discutem arquitetura, decisões de projeto, e problemas encontrados, juntamente com potenciais soluções. Diferentes aspectos de arquitetura de sistemas no que se refere a multi-tenancy para SOA também são considerados como: deployment de serviços, envio de mensagens, segurança, execução de serviços e finalmente acesso a dados. Junjie Jing(Jing and Zhang, 2010) apresenta uma arquitetura aberta para construir soluções SaaS. Um benefício dessa abordagem é a diminuição do acoplamento, o que traz maior flexibilidade para aplicações SaaS. Por um lado novos serviços podem facilmente se juntar aos existentes, por outro lado pode-se também reprogramar um serviço para gerar um novo serviço de acordo com as necessidades do negócio. Dessa forma aplicações multi-tenancy baseadas em SOA podem ser consideradas alteráveis e extensíveis para suportar resposta rápida e agilidade operacional. 3.5 Mapeamento das evidências Nessa seção, são apresentados os resultados para cada questão de pesquisa. Na Seção são apresentadas a evidências relacionada à vantagens e desvantagens da adoção da arquitetura multi-tenancy. Na Seção são apresentadas as evidências relacionadas à propostas existentes que podem auxiliar a adoção e implementação de multi-tenancy, bem como frameworks, APIs e ferramentas relacionadas a esse tema. Na Seção são descritos evidências que apresentam formas de gerenciar variabilidade entre tenants de uma aplicação multi-tenancy, nessa seção são apresentadas abordagens e propostas de solução para esse problema. Por último a seção apresenta evidências que podem auxiliar durante a tomada de decisão de adotar ou não a arquitetura multi-tenancy Q1 - Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy? Essa questão busca identificar em meio aos trabalhos encontrados, evidências que apontem vantagens e desvantagens da adoção da arquitetura multi-tenancy. Durante esse trabalho foram identificados 12 trabalhos que citam alguma vantagem ou desvantagem da adoção 50

66 3.5. MAPEAMENTO DAS EVIDÊNCIAS de multi-tenancy. Apartir da leitura dos mesmos identificamos as seguintes vantagens: O provedor de serviço pode usar a mesma versão da aplicação(com o único código base) para prover serviços para várias organizações(tsai et al., 2010b) Consumidores obtém acesso à capacidade de processamento elástico que pode ser aumentada ou diminuida de acordo com a demanda se a necessidade de realizar manutenção em servidores(tsai et al., 2010b) Dois benefícios de uma abordagem baseada em uma plataforma multi-tenancy são colaboração e integração. Pelo fato de todas as aplicações executarem em um único espaço, torna-se mais fácil permitir a um usuário de qualquer aplicação acesso à uma coleção de dados. Essa capacidade simplifica o esforço necessário para integrar aplicações relacionadas e os dados que elas gerenciam(weissman and Bobrowski, 2009) Atualização do software de uma só vez para todos os tenants(mietzner et al., 2009a) Economia nos custos com infra-estrutura de hardware(shwartz et al., 2009)(Kwok and Mohindra, 2008)(Aulbach et al., 2009) Economia nos custos de gerenciamento de infra-estrutura(shwartz et al., 2009)(Kwok and Mohindra, 2008)(Aulbach et al., 2009) Os tenants podem obter acesso imediato às últimas melhorias e inovações sem gastar seu próprio orcamento de TI(Kwok and Mohindra, 2008) Aumento da margem de lucro para o provedor de serviço através da redução dos custos de entrega e diminuição dos custos de assinatura do serviço para os clientes(li et al., 2008) Possibilidade de reusar regras de negócio com o mínimo de adaptação(bezemer et al., 2010) Organização dos usuários em vários níveis de acordo com suas necessidades e melhor gerenciamento de recursos(jasti et al., 2010) O usuário pode customizar sob-demanda os serviços providos pelo fornecedor do software(zheng et al., 2010) 51

67 3.5. MAPEAMENTO DAS EVIDÊNCIAS Redução dos custos de venda e manutenção do software por porte do provedor do software(zheng et al., 2010) As desvantagens da adoção de multi-tenancy foram pouco mencionadas nos trabalhos encontrados. Em geral os trabalhos mencionavam mais vantagens do que desvantagens. A seguir são listados alguns pontos considerados vantagens e desvantagens por alguns autores: É difícil calcular os recursos requeridos por cada novo tenant e ao mesmo tempo garantir que as restrições de todos os outros tenants da mesma instância sejam atendidas(kwok and Mohindra, 2008) Fatores limitantes e gargalos nos recursos computacionais exigidos pelas várias instâncias devem ser identificados(kwok and Mohindra, 2008), e isso não é trivial nesse tipo de ambiente Dificuldade de comparar e otimizar a redução de custos das diferentes formas de distribuição dos tenants entre os servidores, pelo fato de existirem várias variáveis envolvidas(kwok and Mohindra, 2008) Preocupação das empresas com o custo inicial de reestruturas suas aplicações legadas para multi-tenancy(bezemer and Zaidman, 2010) Preocupação dos mantenedores de software com a possibilidade de multi-tenancy introduzir problemas adicionais de manutenção decorrentes do fato desses novos sistemas serem altamente customizáveis(bezemer and Zaidman, 2010) Q2 - Quais as propostas existentes para implementação da arquitetura multi-tenancy? Essa questão visa identificar trabalhos que possam auxiliar na possível implementação de uma aplicação multi-tenancy. Frameworks, ferramentas, modelos, propostas de arquitetura, métodos ou técnicas que possam auxiliar no desenvolvimento de aplicações multi-tenancy são identificados e catalogados. Um ponto importante nessa parte do trabalho é identificar o grau de maturidade das aplicações multi-tenancy com relação à implementação. 52

68 3.5. MAPEAMENTO DAS EVIDÊNCIAS Frameworks Os autores de (Guo et al., 2007) focam seu trabalho principalmente no padrão multitenancy nativo. Eles exploram os principais requisitos e dasafios de multi-tenancy nativo e apresentam um framework baseado em SOA para suportar o projeto, desenvolvimento e gerenciamento de aplicações multi-tenancy de forma transparente. Através de da entrega de vários serviços que provêem funcionalidades multi-tenancy à aplicação desenvolvida, os desenvolvedores podem focar na camada de lógica de negócios sem se preocupar com a implementação dos requisitos inerentes a multi-tenancy. Os 5 principais componentes de serviço desse framework que habilitam multi-tenancy em uma aplicação são: isolamento de segurança: baseado nos mecanismos de segurança tradicionais (autenticação, autorização, auditoria, etc), é preciso também considerar os riscos de segurança pontenciais introduzidos por outros tenants que compartilham a mesma instância da aplicação e recursos. isolamento de performance: administradores do sistema estão interessados em evitar que o comportamento de um tenant afete a performance de outros tenants. Além disso, os tenants esperam receber os níveis de serviço definidos no contrato. isolamento de disponibilidade: quando muitos tenants compartilham a mesma instância da aplicação, é crítico para o provedor de serviço detectar qualquer falha e evitar a propagação dessa falha o mais breve possível. isolamento de administração: a interface administrativa deveria ser isolada para cada tenant individual para que eles possam visualizar e mudar os dados no nível operacional e de negócio que são relevantes para suas organizações. customização on-the-fly: é necessário customizar a aplicação para ajustar as necessidades e situações particulares do tenant. Para negócio pequenos e médios que utilizam esse framework a customização será realizada de forma intuitiva e pelo próprio cliente, sem a necessidade de uma equipe de desenvolvimento. (Kwok et al., 2008b) e (Rimal and El-Refaey, 2010) apresentam propostas de frameworks e apresentam o resultado de sua aplicação em um contexto específico. (Kwok et al., 2008b) apresenta o desenvolvimento de uma aplicação para gerenciamento de contratos eletrônicos e a implementação dos requisitos multi-tenancy através de um framework proposto pelos autores. Em sua abordagem os autores tratam de pontos importantes como customização, segurança e armazenamento de dados. (Rimal and El-Refaey, 53

69 3.5. MAPEAMENTO DAS EVIDÊNCIAS 2010) descreve um framework para orquestração de ambiente de cloud multi-tenancy que apresenta duas abordagens para o gerenciamento de workflows científicos: workflows baseados em semântica onde os autores apresentam uma abordagem utilizando ontologias e workflows baseados em políticas, que podem ser definidas como recursos requeridos ou controle de segurança. Um ponto importante no contexto de multi-tenancy é a alocação de recursos e localização dos tenants no datacenter. (Fehling et al., 2010) e (Tang et al., 2010) tratam desse assunto. (Fehling et al., 2010) analisa os desafios inerentes ao cenário de multi-tenancy e identifica várias oportunidades de otimização decorrentes da necessidade de distribuir eficientemente tenants que possuem funcionalidades iguais, mas qualidade de serviço diferentes. Esse trabalho também define um framework para desenvolvimento de estratégias de distribuição de tenants que permite a modelagem de recursos, suas dependências de implantação e usuários com demandas específicas de forma a permitir o melhor uso dos recursos. (Tang et al., 2010) discute como o acesso a dados entre os tenants afeta a carga de trabalho do datacenter e como otimizar a utilização de recursos no processo de alocação dos tenants. Nesse mesmo trabalho os autores propõem um framework para capturar dados dos tenants que auxiliem na identificação de fatores determinantes na localização dos tenants, um algoritmo para alocação de tenants e um método para estimação de recursos. (Pervez et al., 2010a) apresenta o framework D-Val que realiza a validação de requisições e auxilia os provedores de SaaS a fornecer software com qualidade de serviço em conformidade com a SLA definida para o cliente. D-Val funciona como um filtro que identifica requisições inválidas e impede que elas sejam processadas pelo servidor. Em (Tsai et al., 2010a) e (Wang et al., 2010) os autores propõem frameworks que focam em customização. (Tsai et al., 2010a) apresenta um framework para customização, que suporta e gerencia variabilidade de SaaS e requisitos específicos dos tenants. Os autores utilizam ontologias para derivar a customização e informações de implantação dos tenants. Além disso esse framework possui uma engine de recomendações inteligente que auxilia a criação de novos tenants usando informações de tenants já implantados. (Wang et al., 2010) apresenta um framework para gerenciamento de processos de negócio em aplicações multi-tenancy que utiliza o paradigma orientado a aspectos para implementar as customizações. (Chen et al., 2011) define RaaS(Routing as a Service), um framework para prover uma plataforma de controle de rota para múltiplos tenants para executar controle de rota independentemente com pouco envolvimento do administrador do sistema. 54

70 3.5. MAPEAMENTO DAS EVIDÊNCIAS Ferramentas (Li et al., 2008),(Hui et al., 2009) e (Xiong et al., 2011) apresentam ferramentas para auxiliar o desenvolvimento de aplicações multi-tenancy. (Li et al., 2008) apresenta o SPIN(Service Performance Isolation Infrastructure), que permite compartilhamento de recursos em sistemas de hospedagem. Dado que podem existir tenants que interferem de forma agressiva no comportamento de outros tenants, SPIN fornece relatórios para identificar os tenants agressivos e fornece um mecanismo de moderação auto-adaptativo para eliminar seus impactos negativos nos outros tenants. Em (Hui et al., 2009) os autores propõem um SGBD chamado M-Store, que provê serviços de armazenamento e indexação para aplicações multi-tenancy. Para melhorar a escalabilidade dos sistemas, M-Store trabalha com 2 técnicas chamadas BIT(Bitmap Interpreted Tuple) e MSI(Multi-Separated Index). BIT é uma otimização onde o SGBD não armazena valores nulos de atributos não usados em tabelas compartilhadas, já o MSI provê flexibilidade, uma vez que os indices no SGBD são criados para cada tenant ao invés da criação de um indice para todos os tenants. (Xiong et al., 2011) propõe o SmartSLA que apresenta uma forma de gerenciar recursos em sistemas de bancos de dados compartilhados em ambiente de cloud. O SmartSLA consiste de dois componentes principais: o módulos de modelagem de sistema e o módulo de decisão de alocação de recursos. O módulo de modelagem de sistema usa técnicas de máquinas de aprendizado para descobrir a margem de lucro potencial para cada cliente sob diferentes formas de alocação de recursos. Baseado no modelo de aprendizado, o módulo de alocação de recursos ajusta dinamicamente a alocação de recursos para alcançar a otimização dos lucros. Métodos ou Técnicas No total foram encontrados 27 métodos ou técnicas que abordam os mais variados contextos relacionados a aplicações multi-tenancy. Esses trabalhos são brevemente descritos na tabela Modelos É de fundamental importância modelos que auxiliem desenvolvedores e engenheiros de software durante a construção de aplicações. No caso de multi-tenancy isso é ainda mais crucial pelo fato da mesma ser uma abordagem nova. Os modelos encontrados durante essa pesquisa surgiram nos último 2 anos, específicamente nos anos de 2010 e 55

71 3.5. MAPEAMENTO DAS EVIDÊNCIAS Contexto Alocação de Recursos Alocação de Recursos Banco de dados Banco de dados Banco de dados Banco de dados Banco de dados Banco de dados Customização Customização Migração Migração Migração Monitoramento Performance Performance Performance Performance/ Segurança Segurança Descrição do método ou técnica (Kwok and Mohindra, 2008) descreve métodos para localização ótima de tenants e instancias baseado em um modelo de localização de tenants proposto pelos autores, sem violar qualquer requisitos de SLA dos tenants existentes nos servidores do datacenter. (Tsai et al., 2010b) propõe um método para priorizar requisições de serviços para aplicações multi-tenancy preservando as prioridades locais das requisições de cada tenant. Os autores propõem o um algoritmos chamado Crystalline Mapping(CM) que mapeia prioridades locais de cada tenant individualmente e para prioridades globais. (Jacobs and Aulbach, 2007) esse trabalho descreve três abordagens para implementar bancos de dados multi-tenancy e às compara através de experimentos. As tres abordagens comparadas são: shared machine, shared process e shared table. (Aulbach et al., 2008) descreve uma técnica para mapeamento de esquemas de banco de dados para multi-tenancy chamada Chunk Folding. Nessa técnica tabelas lógicas são verticalmente particionadas em chunks que são distribuídas em diferentes tabelas físicas e é realizado a junção desses dados quando necessário. (Grund et al., 2008) os autores analisam operações típica em bancos de dados multi-tenancy e mostram como essas operações se relacionam. No decorrer o trabalho os autores definem diferentes padrões de acesso baseado na abordagem de tabelas compatilhadas(shared table approach) e propõem uma nova projeto de compartilhamento de tabelas multitenancy. (Weiliang et al., 2010) os autores propõem uma abordagem chamada multiple sparse tables que seria uma adaptação da técnica sparse tables tradicional para o contexto de multi-tenancy. (Schiller et al., 2011) essa abordagem implementa isolamento entre tenants, extensão de esquemas tenants e funcionalidade de gerenciamento de dados centrada nos tenants em um SGBD relacional. Os autores também apresenta o conceito de herança de esquema, que permite o compartilhamento do esquema base de uma aplicação através dos tenants ao mesmo tempo que permite a extensão do esquema por tenant. (Xiong et al., 2011) esse trabalho já citado na seção 3.5.2, além de apresentar a ferramenta SmartSLA apresenta os métodos e técnicas implementados pela ferramenta. (Mietzner et al., 2008) descreve um formato para compor pacotes de aplicações SaaS configuráveis para aplicações desenvolvidas utilizando arquitetura orientada a serviço. Os autores descrevem como arquitetura de componentes de serviço (SCA - Service Component Architecture) pode ser extendida com descritores de variabilidade e padrões multitenancy para empacotar e implantar aplicações multi-tenancy configuráveis. (Jegadeesan and Balasubramaniam, 2009) os autores apresentam uma abordagem para implementar variabilidade de tenants utilizando programação orientada a aspectos. (Cai et al., 2010) nesse trabalho é descrito uma abordagem transparente para fazer uma aplicação web existente suportar multi-tenancy e executar em uma cloud pública. Os autores também implementam um sistema multi-tenancy real que separa os interesses dos desenvolvedores da aplicação, operados de SaaS, administrador do tenant e usuário do tenant. (Zhang et al., 2010a) um método sistemático é proposto para migrar aplicações single-tenant para multi-tenancy focando em aspectos como modelo de dados, controle de acesso e gerenciamento de tenants, levando em consideração as necessidades de negócio e assuntos técnicos. (Elmore et al., 2011) é proposto o Zephyr, uma técnica para migrar tenants com o mínimo de interrupção de serviço. (Hasselmeyer and d Heureuse, 2010) os autores apresentam uma abordagem para monitoramento de vários recursos coo rede, servidores e aplicações em um ambiente multi-tenancy, levando em consideração que normalmente essas aplicações executam em algum ambiente virtualizado. (Wang et al., 2008b) nesse trabalho os autores identificam os potenciais gargalos de performance, apresentam as abordagens de otimização correspondentes e melhores práticas para implementação em ambientes multi-tenancy. (Lin et al., 2009b) nesse trabalho é apresentado uma abordagem de regulação de performance baseada em feedback. O regulador de performance possui uma estrutura hieráquica, com a qual um controlador de alto nível gerencia as taxas de admissão de requisições para evitar sobrecarga e um controlador de baixo nível gerencia a alocação de recursos para as requisições aceitas. (Ahmad and Bowman, 2011) os autores realizam um estudo experimental é realizado para entender os fatores que influenciam na performance de sistemas multi-tenancy e sugerem uma abordagem utilizando máquinas de aprendizado para predizer a performance das aplicações. (Brassil, 2010) os autores apresentam uma abordagem utilizando hardware para isolar tenants. (Zhang et al., 2009) esse trabalho demonstra o modelo de armazenamento de dados compartilhado, definie três tipo de restrições de privacidade, e então propõe uma abordagem baseada em restrições de privacidade customizáveis. Segurança (Li et al., 2010) os autores apresentam uma abordagem para serparação de segurança em cloud onde são definidos 2 níveis de granularidade para controle de acesso. O primeiro nível refere-se à segurança entre tenants e o segundo nível trata do mecanismo de controle de acesso da própria aplicação. Segurança SOA SOA Virtualização Virtualização (Nie, 2010) apresenta um algoritimo de avaliação de credibilidade entre os tenants baseado em experiência. De acordo com o histórico de acesso, o algoritimo calcula a credibilidade de um tenant, permitindo a detecção e monitoramento de tenants maliciosos com um baixo custo. (Mietzner et al., 2009a) os autores introduzem e avaliam um conjunto de padrões que podem ser usados para projetar, desenvolver e implantar aplicações SaaS orientadas a serviço. Além disso os autores descrevem como os requisitos multi-tenancy podem ser alcançados. (Ding et al., 2010) os autores apresentam um mecanismo de compensação flexível que suporta customização e implanta dinâmicamente processos de compensação. (Tsai et al., 2007) os autores exploram o uso de virtualização para habilitar funcionalidades multi-tenancy em sistemas com o mínimo de alterações possível. (Siddhisena et al., 2011) apresenta uma abordagem que utiliza uma abordagem de virtualização para construção de uma plataforma virtualizada para aplicações multi-tenancy, com foco no aumento de segurança e escalabilidade. Tabela 3.11 Métodos e técnicas para implementar multi-tenancy 56

72 3.5. MAPEAMENTO DAS EVIDÊNCIAS Essa seção apresenta alguns trabalhos relacionados a modelos que visam auxiliar o desenvolvimento de aplicações multi-tenancy. (Kong et al., 2010) propõe um modelo de customização multi-nível para aplicações SaaS que suporta compartilhamento de customizações através de diferentes tenants. Nesse trabalho os autores apresentam o projeto de uma arquitetura de armazenamento de dados que implementa esse modelo e apresenta uma comparação experimental dessa nova estratégia de customização. Em (Schaffner et al., 2011), como já mencionado na seção os autores estudam a automação operacional de tarefas em bancos de dados orientados a coluna e definem um modelo para predição de violações no tempo de resposta esperado. Para a alocação de recursos no datacenter, os autores apresentam um algoritmo que move os tenants entre os servidores do datacenter para garantir o tempo de resposta esperado. Outro modelo focado em performance e alocação de recursos é apresentado em (Zhang et al., 2010b). Focando-se no problema OTPP(On-line Tenant Placement Problem), nesse trabalho os autores propõem um modelo para estimar consumo de recursos em aplicações multi-tenancy. Foram encontrados também modelos que propõem alguma melhoria no armazenamento de dados em aplicações multi-tenancy. (Xue et al., 2011) apresenta um modelo de indexação para armazenamentos de dados que utilizam a abordagem Multiple Sparse Tables. Um trabalho que também aborda esse assunto é (Ahmad and Bowman, 2011) e já foi citado na seção Já em (Aulbach et al., 2011) os autores apresentam três funcionalidades que um SGBD multi-tenancy deveria prover: extensibilidade, compartilhamento de dados e evolução. Os autores apresentam o FLEXSCHEME, um modelo integrado para bancos de dados multi-tenancy que atende, segundo os autores, às três funcionalidades citadas anteriormente. (Tsai and Shao, 2011) propõe um modelo de controle de acesso que utiliza ontologias. Esse modelo já foi mencionado na seção Propostas de Arquitetura Um ponto importante durante o desenvolvimento de software em qualquer segmento é conhecer implementações semelhantes já realizadas por outros desenvolvedores. Partindo desse princípio essa seção apresenta propostas de arquitetura de software que auxiliem no desenvolvimento aplicações multi-tenancy. Foram encontradas propostas de arquitetura para aplicações multi-tenancy (Koziolek, 2010; Bezemer et al., 2010; Bezemer and Zaidman, 2010; Pervez et al., 2010b; Tsai et al., 2010d; Yuanyuan et al., 2009; Jing 57

73 3.5. MAPEAMENTO DAS EVIDÊNCIAS and Zhang, 2010; Cheng et al., 2009; Koziolek, 2011) e para plataformas de suporte a multi-tenancy (Weissman and Bobrowski, 2009; Oh et al., 2011; Azeez et al., 2010). Dentre essas propostas algumas já foram aplicadas à indústria, como é o caso do Force.com (Weissman and Bobrowski, 2009) e EXACT (Bezemer et al., 2010). Force.com é uma plataforma de desenvolvimento de software que utiliza arquitetura dirigida à metadados para construção de aplicações multi-tenancy. Nessa arquitetura tudo que é exposto para os desenvolvedores e usuários da aplicação é internamente representado como metadado. Formulários, relatórios, workflows, priviégios de acesso, customizações específicas do tenant e lógica de negócio, tudo é armazenado como metadados. Outro exemplo de arquitetura dirigida à metadados pode ser encontrada em (Oh et al., 2011). Em (Bezemer et al., 2010) Bezemer apresenta uma arquitetura utilizada no desenvolvimento de aplicações na empresa EXACT, uma empresa de desenvolvimento de software especializada em ERP, CRM e aplicações financeiras. Em sua arquitetura os autores apresentam 3 componentes básico para a implementação de aplicações multi-tenancy: componente de autenticação, customização e banco de dados. Além disso os autores apresentam um estudo de caso e uma lista de lições aprendidas. Outros autores apresentam Arquiteturas Orientadas a Serviço que implementam requisitos de multi-tenancy como é o caso de (Jing and Zhang, 2010),(Azeez et al., 2010) e (Pervez et al., 2010b). Em (Jing and Zhang, 2010) os autores apresenta OSaaS, uma arquitetura que utiliza tecnologias SOA para desenvolvimento de aplicações SaaS. (Azeez et al., 2010) apresenta uma arquitetura para implementar multi-tenancy a nível de SOA, que permite a usuários executar seus serviços e outros artefatos SOA em um framework multi-tenancy SOA. Já (Pervez et al., 2010b) apresenta uma arquitetura para SaaS que foca nos aspectos de segurança e balanceamento de carga em ambiente de cloud computing. Além das propostas de arquitetura citadas anteriormente, foi encontrado também uma proposta de estilo arquitetural, o SPOSAD, que é descrito em (Koziolek, 2010) e (Koziolek, 2011). SPOSAD descreve componentes, conectores, e elementos de dados de uma arquitetura multi-tenancy, bem como restrições impostas nesses elementos. Os autores também apresentam os benefícios do uso dessa arquitetura e informações que podem auxiliar em decisões de projeto. Em (Tsai et al., 2010d) os autores apresentam uma arquitetura de duas camadas que foca em escalabilidade, que trabalha a nível de serviço e aplicação para economizar o uso de recursos, e a idéia chave é aumentar os recursos somente onde houver gargalos. Várias técnicas de duplicação de recursos computacionais são propostas, incluindo duplicação 58

74 3.5. MAPEAMENTO DAS EVIDÊNCIAS preguiçosa e duplicação pro-ativa para alcançar a melhor performance do sistema. Além da arquitetura esse trabalho apresenta um algoritmo para alocação de recursos para cluster em ambientes de cloud. Já em (Yuanyuan et al., 2009) os autores apresentam uma arquitetura multi-tenancy para sistemas de suporte a negócios (BSS - Business Support System) e discute brevemente uma abordagem para alcançar configurabilidade, seguranca e escalabilidade na arquitetura. Focando em escalabilidade de dados, os autores propõem um particionamento horizontal baseado em grupos de entidades pela análise das relacões entre as entidade do sistema. (Takahashi et al., 2010) esse trabalho propõe uma arquitetura de sistema autônomo para infraestrutura de SaaS escalável para atender ao crescimento e acesso multi-tenancy de aplicações SaaS. Os autores propõe o conceito e arquitetura do Cache L4, que tem o objetivo de aumentar a eficiência SaaS com otimizações no uso do hardware. (Calero et al., 2010) os autores apresentam a arquitetura de um sistema de autorização multi-tenancy apropriado para um serviço de middleware para PaaS. Cada empresa pode prover vários serviços de cloud que podem colaborar com outros serviços tanto da mesma organização quanto de organizações diferentes. Esse sistema de autorização suporta acordos de colaboração entre empresas(também conhecidos como federações) Q3 - Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicação multi-tenancy Um sistema de banco de dados para SaaS deveria oferecer esquemas flexíveis, que podem ser extendidos para diferentes versões da aplicação e dinamicamente modificados enquanto o sistema está sendo usado. Como já mencionado nas seções e 3.5.2, os trabalhos (Aulbach et al., 2008) e (Aulbach et al., 2009), apresentam técnicas para mapear variabilidade de tenants em um banco de dados. Os autores descrevem essas técnicas e realizam experimentos com o objetivo de identificar a técnica que apresenta os melhores resultados em bancos de dados como Microsft SQL Server, IBM DB2 e HBase. Os autores concluiram que o banco de dados ideal para SaaS ainda não foi desenvolvido e apresentam algumas sugestões sobre como ele deveria ser projetado. Em SaaS, sistemas de workflow são uma boa opção para o baixo acoplamento, customização, arquitetura de computação baseada em web e serviços web. Além disso, podemos dinamicamente customizar serviços e processos de negócio. Para alcançar isso, o suporte a transação de processos de negócio tem se tornado cada vez mais importante. Em meio aos protocolos de serviços web atuais, existem alguns protocolos relevantes para suporte a processamento de transações. Em (Wang et al., 2008b) os autores propõem um 59

75 3.5. MAPEAMENTO DAS EVIDÊNCIAS mecanismo de compensação flexível que suporta deploymente customizável e processo de compensação. (Arya et al., 2010) apresenta informações sobre a natureza da configurabilidade em SaaS, como pode ser provido e quais tecnologias são necessárias para suportá-la. De acordo com os autores, as principais tecnologias habilitadoras de cloud computing são: web 2.0, RIA (Rich Internet Application), SOA, Cloud Computing e virtualização. Além disso os autores definem GUI, workflow, dados e controle de acesso como os principais aspectos configuráveis em SaaS, e descrevem vários métodos utilizados para manipulação de metadados, segurança e serviços compartilhados, bem como módulos de customização e extensão de tenants. (Jansen et al., 2010) apresenta uma visão geral de como técnicas de realização de customização de linha de produtos de software podem ser aplicadas para realizar customização durante o desenvolvimento de aplicações multi-tenancy. Os autores apresentam um catálogo de técnicas de realização de customização para aplicações web e mostram como são implementadas na prática usando dois estudos de caso. O catálogo auxilia desenvolvedores web e arquitetos de software a selecionar a técnica correta durante a implementação de aplicações multi-tenancy. Sem esse tipo de informação, desenvolvedores de aplicações multi-tenancy precisam reinventar a roda e não se beneficiam de padrões arquiteturais existentes. Em muitos casos, se a aplicação de software apenas com requisitos comuns não consegue atender de forma aceitável à maioria dos clientes, uma forte capacidade de configuração e customização irá tornar-se uma fator chave no sucesso da aplicação. Em (Sun et al., 2008), o conceito de configuração e customização no contexto de SaaS são esclarecidos, e é introduzido um modelo de competência e um framework para ajudar fornecedores de SaaS a planejar a oferta de customização e configuração em suas aplicações. Em (Kwok et al., 2008b) autores apresentam o desenvolvimento de uma aplicação multi-tenancy para gerenciamento de contrato eletrônico. No decorrer desse trabalho os autores descrevem vários métodos usados para gerenciamento de metadados, compartilhamento de serviços e segurança. Ainda de acordo com os autores os atributos para o sucesso de uma aplicação multi-tenancy são configurabilidade, eficiência e escalabilidade. Durante esse trabalhos os autores enfatizam multi-tenancy e customização. (Li et al., 2009) explora os desafios existente na área de customização em ambiente multi-tenancy e propõe um modelo de customização de relacionamentos. Em seu trabalho os autores apresentam o modelo de customização de objetos como o mais importante e 60

76 3.5. MAPEAMENTO DAS EVIDÊNCIAS apresenta níveis de customização de objetos: dados, serviço, processo e interface gráfica. Os autores discutem o relacionamento entre objetos em cada um desses níveis. Caso não seja implementadoo corretamente, a realização de customização de tenants separadamente por diferentes aplicações de negócio, leva à muita duplicação de código e metadados. Em (Kong et al., 2010), os autores propõem um modelo de customização multi-nível para aplicações SaaS que suporta compartilhamento de customização através de diferentes aplicações multi-tenancy virtualizadas. Além disso os autores apresentam uma arquitetura de armazenamento de dados multi-tenancy dirigida a metadados que implementa modelo de customização multi-nível. Ao final do trabalho é realizada uma comparação do modelo proposto com o modelo antigo através de experimentos. (Tsai et al., 2010a) apresenta um framework para customização multi-camada, para suportar e gerenciar a variabilidade de aplicaçãoes SaaS e requisitos específicos dos tenants. Ontologia é usada para derivar a customização e informações de implantação para os tenants. O framework também possui uma engine de recomendação para suportar a implantação de novos tenants usando informações de tenants existentes. Um estudo de caso é usado para demonstrar o modelo proposto. (Zhang et al., 2007), nesse trabalho é proposto uma política de customização baseada em WSDL (Web Service Definition Language). A política proposta é aplicada para permitir a customização de SaaS e facilitar a integração entre SaaS. Para permitir a implementação dessa abordagem os autores apresentam um framework chamado WS- Policy. Já (Mietzner et al., 2008), como já citado na seção apresenta uma abordagem baseada em SCA para implementar variabilidade entre tenants. Em (Jegadeesan and Balasubramaniam, 2009), os autores propõem o uso de orientação à aspectos para modularizar fatores de variabilidade como interesses transversais ou aspectos. Além disso é proposto uma forma de compor esses interesses com um módulo básico da aplicação que os autores chamam de kernel, possibilitando a criação de variantes do serviço. Essa abordagem visa oferecer o máximo de flexibilidade para os tenants enquanto garante fácil configurabilidade e reuso. (Mietzner et al., 2009b) apresenta como técnicas de modelagem de variabilidade, já conhecidas no contexto de linha de produtos de software, podem ser usadas para modelar variabilidade em SaaS. É aplicado o conceito de variabilidade interna e externa da engenharia de linha de produtos de software para o problema de customização e implantação em aplicações SaaS. (Lizhen et al., 2010) propõe a modelagem de variabilidade usando metagrafos para gerenciar a variabilidade para configuração e customização de aplicações SaaS. Essa 61

77 3.5. MAPEAMENTO DAS EVIDÊNCIAS abordagem pode sistematicamente, segundo os autores, descrever pontos de variabilidade e seus relacionamentos, e garantir a qualidade de entradas de configuração feitas pelos consumidores. Os benefícios dessa abordagem são demonstrados no trabalho através de um exemplo simples Q4 - Quando a adoção da arquitetura multi-tenancy é viável? Não encontramos trabalhos que tratam diretamente da viabilidade de multi-tenancy. Ainda assim, foi possível coletar evidências em alguns trabalhos encontrados que apontam cenários em que a adoção de multi-tenancy é viável. O principal ponto que deve-se considerar é a capacidade da equipe de desenvolvimento de implementar requisitos funcionais e não funcionais relacionados a multi-tenancy como compartilhamento de recursos de hardware, configurabilidade, compartilhamento de aplicação, autenticação, armazenamento de dados, customização, etc. Implementar esses requisitos podem gerar um custo bem maior do que simplesmente manter 2 ou 3 versões de uma aplicação, em alguns casos. De acordo com (Kwok et al., 2008b), com um único código base da aplicação para suportar vários tenants, o tempo total de implantação em um novo cliente é menor. Além disso, a atualização da aplicação é mais simples e centralizada pelo fato de existir apenas um única versão do código fonte e uma única instância da aplicação(ou um número muito reduzido). Há de se levar em consideração que tanto novas implementações quanto bugs serão propagados para todos os clientes de uma só vez, isso exige uma boa bateria de testes para garantir a qualidade da aplicação. Desconsiderar a criticidade de uma boa bateria de testes nesse ambiente pode inviabilizar a adoção de multi-tenancy. De acordo com (Aulbach et al., 2008), multi-tenancy torna-se menos atrativo em cenários onde a complexidade da aplicação é crescente. De acordo com os autores, single-tenant é a abordagem mais adequada para aplicações mais complexas. Em muitos casos existem dados sigilosos que os usuários não desejam que saiam dos limites físicos da empresa. Na maioria dos casos isso pode inviabilizar a adoção de uma aplicativo no modelo SaaS que funcione em ambiente multi-tenancy. Uma abordagem para que os provedores de serviço não percam clientes nesse perfil é desenvolver uma aplicação multi-tenancy que forneça algum tipo de integração com aplicações externas. Dessa forma o cliente poderia contratar o serviço e usar apenas as funcionalidades que não manipulam dados sigilosos, deixando que os dados sigilosos sejam tratados por uma aplicação em seu próprio data center. Em (Mietzner et al., 2009a), os autores apresentam uma abordagem de como combinar diferentes padrões multi-tenancy em uma aplicação 62

78 3.6. DISCUSSÃO orientada a serviços. Em (Bezemer and Zaidman, 2010) os autores apresentam duas barreiras que pode influenciar na adoção de multi-tenancy: empresas podem ter receio financiar o custo inicial de reengenharia de suas aplicações existentes para multi-tenancy Desenvolvedores de software que mantém a aplicação podem ficar incomodados com os problemas de manutenção adicionais que a introdução de multi-tenancy pode causar devido ao fato desses novos aplicativos serem altamente configuráveis. 3.6 Discussão Plataformas de SaaS como Salesforce.com permitem que muitas customizações da aplicação sejam realizadas sem a necessidade de programação através da especificação de regras de negócio que são simples o suficiente para não-programadores implementarem. Grandes empresas de TI como HP e IBM tem investido bastante nessa área, isso é comprovado com o fato de vários artigos encontrados durante esse estudo serem escritos por membros dessas empresas. Além disso, algumas empresas também vendem aplicativos que podem ser configurados para executar como SaaS em nuvens privadas; SAP por exemplo, pode ser usado como um SaaS oferecido dentro das empresas. A primeira dificuldade encontrada durante as pesquisas foi identificar quais os requisitos de uma aplicação multi-tenancy que são essenciais para sua implementação. Durante a tentativa de identificá-los, foi possível perceber que duas características chave de multi-tenancy são o auto grau de automação nas atividades de manutenção da aplicação e uma interface amigável para que o usuário possa realizar suas customizações, reduzindo ao máximo a necessidade de intervenções por parte de desenvolvedores e administradores de sistema. Durante o a condução do mapeamento sistemático foi possível notar a existência de muitos trabalhos associados à multi-tenancy e armazenamento de dados. Propostas de métodos, técnicas e até um SGBD multi-tenancy foi proposto. Embora esse seja o campo de multi-tenancy onde mais se encontrou publicações, ainda é um campo onde existem muitos pontos de melhoria, principalmente pelo fato do armazenamento de dados influenciar diretamente no tempo de resposta de todas as operações que manipulam dados. Vários experimentos foram realizados com as abordagens existentes para armazenamento de dados em aplicações multi-tenancy mas não foi encontrada na literatura um 63

79 3.6. DISCUSSÃO consenso sobre qual abordagem é a melhor. Migração de dados, modelagem dos dados, tempo de resposta, armazenamento distribuído, integração com ferramentas de BI, todos esses fatores podem influenciar na escolha de uma abordagem para armazenamento de dados. Atualmente, novas formas de armazenamento de dados estão surgindo como: HBase 1, Cassandra 2, Hipertable 3, MongoDB 4, CouchDB 5, etc. Esses sistemas armazenam dados de uma forma diferente do usado nos modelos relacionais e compõem um movimento chamado NoSQL. Uma lacuna pouco explorada foi a utilização dessas novas tecnologias no desenvolvimento de aplicações multi-tenancy, dado que bancos de dados NoSQL surgiram como uma solução para a questão da escalabilidade no armazenamento e processamento de grandes volumes de dados(diana et al., 2010). A necessidade de uma nova tecnologia de BD surgiu como consequência da ineficiência dos bancos de dados relacionais em lidar com a tarefa de manipulação de grandes volumes de dados. Vale ressaltar que o modelo relacional foi proposto na década de 70, quando as aplicações de banco de dados caracterizavam-se por lidar com dados estruturados, ou seja, dados que possuem uma estrutura fixa e bem definida, e esse não é o caso de aplicações multi-tenancy que podem ser customizadas(lóscio et al., 2011). O crescente surgimento de APIs(DuVander, 2011) web mostra que a utilização desse tipo de abordagem faz muito sentido no contexto de aplicações web e SaaS. Um exemplo de sucesso é o Tweetdeck, uma aplicação cliente do twitter que foi desenvolvida utilizando a API disponibilizada pelo twitter aos desenvolvedores e teve grande aceitação pelos usuários do twitter.com. O valor real da aquisição não foi declarado, mas especula-se algo em torno de 40 milhões de dólares(bbc News, 2011). Outro exemplo de sucesso é o marketplace desenvolvido pela Salesforce, o AppExchange, que possui mais de 1 milhão de aplicações cadastradas, desde extensões da aplicação de CRM do Salesforce até aplicações para outros propósitos. Exemplos como esse mostram quão vantajoso é trazer desenvolvedores independentes para o mercado de SaaS. A realidade é que para entender o campo de customização de aplicações multi-tenancy é necessário entender o contexto no qual essas aplicações estão surgindo. Dado que não é possível atender com uma única aplicação a necessidade de todos os clientes, como

80 3.6. DISCUSSÃO já foi mencionado anteriormente, enfrenta-se em aplicações multi-tenancy o desafio de permitir de alguma forma que o cliente adicione novas regras e customize a aplicação ou faça extensões que auxiliem na solução de seus problemas específicos. Durante esse trabalho foram encontrados vários estudos relacionados ao tema, muitos deles utilizando trabalhando com metadados, orientação a aspectos, SOA, etc. Customização de aplicações já é um tema bastante explorado pelos pesquisadores da área de linha de produtos de software. Basicamente podemos considerar que a customização de aplicações multi-tenancy é equivalente a variabilidade de linha de produtos de software em tempo de execução. Uma iniciativa de customização de aplicações multitenancy tomando-se como base os conhecimentos de linha de produtos de software é apresentado em (Jansen et al., 2010). Dado que SaaS tem como objetivo prover software para uma grande massa de consumidores, o atendimento aos requisitos de alocação de recursos, monitoramento, escalabilidade e performance são requisitos não funcionais que podem até ser ignorados em uma aplicação comum, mas que são de vital importância em aplicações multi-tenancy, principalmente se a aplicação estiver hospedada em um ambiente de cloud onde a tarifação é paga por consumo. Nesses ambientes uma aplicação mal projetada pode levar a custos operacionais tão altos que podem inviabilizar o funcionamento da aplicação, dado o valor que deverá ser pago para manter a infraestrutura de servidores funcionando. Por outro lado, em uma contexto onde a alocação de recursos é feita de forma inteligente, o monitoramento indica quais recursos estão ociosos e quais os gargalos da aplicação, a elasticidade(capacidade de aumentar e diminuir os recursos de hardware) é realizada de forma automática e inteligente, os custos operacionais podem ser diminuidos drasticamente se a aplicação consumir somente o que é estritamente necessário para atender aos requisitos de SLA definidos aos cliente. A realização desse mapeamento foi de crucial importância para verificar a viabilidade de implementação de uma solução multi-tenancy. Numa decisão como essa é necessário verificar não só a aderência da tecnologia com relação a necessidades imediatas, mas também para necessidades que podem surgir futuramente. O mapeamento sistemático ajudou a identificar que customização, armazenamento de dados, segurança e alocação de recursos são pontos críticos no desenvolvimento de uma aplicação multi-tenancy e precisam ser implementados de forma eficiente para o bom funcionamento da aplicação. O cruzamento de dados realizado na Figura 3.8, ajudou a identificar a ausência de uma ferramenta que desse suporta à migração de sistemas single-tenant para multi-tenancy. Com isso identificou-se uma lacuna na área que pode inviabilizar em alguns casos a 65

81 3.7. AMEAÇAS A VALIDADE adoção de uma abordagem multi-tenancy, dado o fato de várias empresas já possuírem sistemas legados com dados pré-cadastrados. Esses dados, na maioria dos casos são artefatos de negócio de importância muito elevada para serem descartados. No Capítulo 4 poder-se-á verificar que foi necessário a implementação de uma ferramenta para auxiliar na migração de um sistema single-tenant para multi-tenancy. Soluções para requisitos futuros da aplicação que será descrita no Capítulo 4 também poderam ser identificadas, como é o caso da possível adoção de SOA para realizar a integração de sistemas, métodos para otimização de performance em aplicações multitenancy, soluções para monitoramento de aplicações multi-tenancy, virtualização de aplicações, etc. O Capítulo 4 apresenta detalhadamente como cada problema foi resolvido e como as informações obtidas apartir do mapeamento sistemático foram utilizadas para chegar à uma solução. 3.7 Ameaças a validade Existem alguns fatores identificados no processo de mapeamento sistemático que foram considerados ameaças a validade do trabalho. Esses fatores são descritos a seguir: Questões de pesquisa: o conjunto de questões definido pode não cobrir de forma satisfatória a área de desenvolvimento de aplicações multi-tenancy. Para mitigar essa ameaça, foram realizadas reuniões de discussão com outros pesquisadores da área para calibrar as questões. Dessa forma, mesmo que não se tenha selecionado as melhores questões de pesquisa, tentou-se chegar o mais próximo possível disso. Abrangência da pesquisa: não é possível garantir que todos os estudos relevantes foram selecionados. É possível que algum estudo relevante não tenha sido selecionado no processo de pesquisa. Mitigou-se essa ameaça realizando o processo de revisão dos trabalhos mais de uma vez em momentos diferentes. Qualidade da avaliação: durante o agrupamento dos trabalhos nas facetas definidas pode haver ocorrido alguma classificação errada, dado que a classificação ocorre baseada exclusivamente na leitura dos artigos realizada pelo autor desse trabalho. Para minimizar esse risco, após a classificação dos trabalhos, foi realizada uma segunda leitura em cada trabalho para verificar se o trabalho estava devidamente associado às facetas corretas. Falta de familiaridade com a área pesquisada: os termos usados nas strings de pesquisa podem ter muitos sinônimos e existe a possibilidade da ausência de algum 66

82 3.8. CONSIDERAÇÕES FINAIS desses sinônimos influenciar na pesquisa, de forma que algum trabalho relevante não tenha sido encontrado com as strings de busca definidas. Para mitigar esse problema foi foi realizado uma pesquisa inicial que teve o objetivo de auxiliar na familiarização com os termos da área. 3.8 Considerações Finais Este capítulo apresentou um mapeamento sistemático realizado na área de multi-tenancy. Inicialmente foi apresentado a metodologia utilizada para conduzir o mapeamento e a seguir sua aplicação e os resultados encontrados no mapeamento. Nenhum mapeamento sistemático na área foi encontrado, embora tenha-se encontrado vários estudos sobre o tema. Durante a condução do mapeamento foram definidas algumas facetas que tiveram o objetivo de agrupar os trabalhos por campos de pesquisa existentes dentro de multi-tenancy, para que pesquisadores interessados em multi-tenancy possam focar seus esforços em um desses campos ou mais. Foram identificados os campos mais pesquisados e as principais descobertas em cada um deles. Por fim, baseado em evidências encontradas nos estudos foram respondidas as quatro perguntas definidas no início do mapeamento sistemático. O capítulo a seguir apresenta como os conhecimentos adquiridos através do mapeamento sistemático foram utilizados durante o desenvolvimento de uma aplicação multi-tenancy em uma empresa real. 67

83 4 Aplicação na Indústria Como um dos objetivos desse trabalho é verificar a aplicabilidade dos conceitos relacionados à multi-tenancy no mercado de software, esse capítulo apresenta um case de desenvolvimento de uma aplicação SaaS multi-tenancy em uma empresa startup que atua no segmento de reuso de software. No decorrer desse capítulo serão apresentadas as experiências adquiridas da junção dos conhecimentos obtidos através do mapeamento sistemático descrito no capítulo anterior e dos resultados da aplicação desses conhecimentos na prática. Nesse capítulo a seção 4.1 apresenta o cenário no qual a aplicação multi-tenancy foi desenvolvida e seus requisitos, a seção 4.2 descreve a metodologia utilizada para combinar mapeamento sistemático e desenvolvimento da aplicação. A arquitetura adotada na aplicação e a metodologia para sua definição são descritos na seção 4.3,já a seção 4.4 descreve como foi realizado o processo de migração de dados da aplicação legada para a nova aplicação no modelo multi-tenancy e por fim a seção 4.5 apresenta as considerações finais do capítulo. 4.1 Problema O objetivo do projeto era desenvolver uma ferramenta de suporte a atividades de engenharia de software para auxílio no processo de desenvolvimento de SPL(Software Product Lines). A versão inicial da ferramenta deverá permitir ao usuário cadastrar informações relacionadas ao levantamento de requisitos e definição de escopo de uma linha de produtos de software. Posteriormente seria adicionado à ferramenta funcionalidades relacionadas ao armazenamento e busca de assets reutilizáveis desenvolvidos pelos usuários da ferramenta. No contexto de SPL, onde uma grande variedade de produtos são derivados de uma 68

84 4.1. PROBLEMA plataforma comum, e podem mudar e evoluir, é importante gerenciar a variabilidade da Linha de Produtos e a rastreabilidade entre os artefatos. (Cavalcanti et al., 2011) apresenta um metamodelo que tem como objetivo coordenar as atividades relacionadas ao desenvolvimento de uma SPL, pelo gerenciamento de diferentes fases da SPL e suas responsabilidades, e da manutenção da rastreabilidade e variabilidade entre os diferentes artefatos. Esse metamodelo é representado utilizando a notação UML na Figura 4.1. O metamodelo é dividido em cinco sub-modelos, que descrevem funcionalmente a aplicação que será desenvolvida: Gerenciamento de Projeto: módulo da aplicação responsável por armazenar informações sobre o projeto da SPL, suas fases do desenvolvimento, tarefas, membros responsáveis por essas tarefas e o papel de cada um no projeto. Além disso, podem ser documentadas as decisões de projeto, descrição de alternativas à essas decisões, justificativa para decisões, notas explicativas, membros da equipe envolvidos na decisão e momento em que a decisão foi tomada. Gerenciamento de Risco: é importante para os projetos de software por causa do grau de incerteza que envolve a maioria dos projetos. Os riscos resultam de requisitos fracamente definidos, dificuldades de estimar esforço e recursos necessários para o desenvolvimento de software. Além disso, dependência de habilidades individuais e mudança nos requisitos devido à mudanças na necessidade dos clientes, também pode influenciar nos riscos associados ao projeto. Escopo: agrupa as funcionalidades para auxiliar na identificação e documentação das features de uma SPL. Em alguns casos pode ser necessário construir uma árvore contendo todos os tipos de features existentes em um produto como features mandatórias, alternativas ou opcionais. Além disso é necessário gerenciar relacionamentos entre features, por exemplo, features obrigatórias(identificadas apartir de relações de dependência entre features) e excludentes(features que não podem co-existir em um mesmo produto). Requisitos: gerencia os requisitos e casos de uso associados a cada feature e a cada módulo da aplicação documentada. Durante a elicidação, o módulo suporta variações de requisitos entre os produtos derivados apartir da SPL documentada e apresentar o que o sistema deverá fazer e como as variações serão suportadas. Teste: gerencia como os casos de teste do sistema interagem com os outros artefatos. Os casos de teste são derivados dos casos de uso documentados. Essa estratégia 69

85 4.2. METODOLOGIA permite que cada mudança em casos de uso ou pontos de variação da SPL possam ser propagadas para os casos de teste. Além dos requisitos do metamodelo, ainda existiam alguns fatores que poderiam influenciar nas decisões de projeto: A aplicação seria incialmente provida como SaaS para um grupo de 20 clientes, que validariam os requisitos da aplicação durante o uso da versão beta; Os clientes deveriam ter a possibilidade de contratar e usar a aplicação sem nenhuma intervenção manual da empresa provedora do serviço; Cada cliente deveria poder gerenciar seus próprios usuários; A aplicação iria executar em um ambiente virtualizado com 613MB de memória e 30GB de armazenamento; Os requisitos da aplicação deveriam ser elicidados e implementados de forma incremental; A aplicação deveria aproveitar o máximo de recursos possível. Diante das características citadas acima, multi-tenancy apresentou-se como uma alternativa viável para esse projeto. A necessidade de prover uma aplicação web que o cliente contratasse sem a intervenção do provedor de serviço fortaleceram a escolha da abordagem SaaS. Já recursos limitados de hardware e a necessidade de prover a aplicação para 20 clientes que poderiam ter vários usuários à utilizando simultaneamente, exigiam o máximo de otimização no uso do hardware. Dentre os 3 tipos de SaaS apresentados na seção 2.2, multi-tenancy apresentou-se como a melhor escolha por permitir a melhor abordagem para otimização de recursos e facilidade de prover software como serviço com modelo de pagamento por uso. Essa é uma aplicação real que foi desenvolvida e entrou em produção antes da apresentação desse trabalho. As seções a seguir descrevem como essa aplicação foi desenvolvida 4.2 Metodologia Para conduzir a etapa de desenvolvimento de um aplicativo na indústria seguiremos o processo definido na Figura 4.2. De acordo com a figura, a primeira etapa consiste em definir uma arquitetura do aplicativo a ser desenvolvido. Para realizar essa atividade foram 70

86 4.2. METODOLOGIA Figura 4.1 Metamodelo para SPL(Fonte: (Cavalcanti et al., 2011)) 71

87 4.3. DEFINIÇÃO DE ARQUITETURA Figura 4.2 Metodologia utilizada para desenvolvimento de aplicação na indústria(fonte: Elaboração própria) utilizadas informações obtidas através do resultado do mapeamento sistemático e da lista de requisitos da aplicação. Apartir dessas informações foi possível identificar as propostas de arquitetura que mais se adequam aos requisitos da aplicação. A segunda etapa foi escolher as tecnologias que seriam utilizadas para a implementação dos requisitos funcionais e não funcionais da aplicação, além da migração dos dados já cadastrados que anteriormente eram manipulados por uma aplicação legada. Durante a etapa de implementação foi adotado SCRUM como metodologia de desenvolvimento, o que facilitou a realização de releases incrementais e rápidos. Vantagens da adoção de SCRUM com metodologia para gerenciamento ágil de produtos SaaS pode ser visto em (Agarwal, 2011). Por fim, na terceira etapa é realizado a coleta de feedback dos usuários, de forma que seja possível melhorar a aplicação no tocante a requisitos funcionais e não-funcionais. Uma sequência de vários ciclos compostos da etapa de "implementação"e "validação da aplicação", é realizada com o objetivo de proporcionar uma evolução incremental do produto. 4.3 Definição de Arquitetura Modelos arquiteturais possuem um importante papel como ponte entre os requisitos do sistema e a sua implementação, além de serem considerados o primeiro conjunto de decisões de projeto relacionadas ao atendimento dos requisitos no sistema (Babar et al., 2004). Arquitetura de software está sendo cada vez mais utilizada em projetos de desenvolvimento de software para representar as soluções computacionais. Isso ocorre devido às facilidades que ela oferece como, por exemplo, a possibilidade em abstrair informações, 72

88 4.3. DEFINIÇÃO DE ARQUITETURA o que diminui a complexidade e facilita o entendimento da solução. Nos últimos anos, arquitetura de software tem sido cada vez mais importante devido ao aumento da complexidade das aplicações que vem sendo desenvolvidas. Nos últimos tempos, aplicações tem se tornado mais complexas, difíceis de enteder, e demasiadamente caras de se desenvolver apartir do zero. Isso fortalece a necessidade de reusar e adaptar arquiteturas de software existentes, otimizando os custos do projeto (Ciaccia et al., 1997). Para que seja possível reusar uma arquitetura de software existente, é necessário efetuar uma avaliação dessa arquitetura para verificar se ela é adequada ao cenário onde pretende-se aplicá-la. O processo de avaliação de arquitetura de software tipicamente inclui a aplicação de um método de avaliação. Existem diversos métodos disponíveis com diferentes técnicas e objetivos como: SAAM, ATAM, ALPSM, SBAR, SALUTA, SAAMCS, ESAAMI, ASAAM, SACAM e DoSAM(Graham and Roy, 2008). Contudo, a análise dos métodos identificados e resultados obtidos por surveys (Babar et al., 2004; Dobrica and Niemela, 2002) identificaram quatro problemas principais: grande subjetividade dos métodos, elevado custo de aplicação, dificuldades para avaliar simultaneamente o atendimento a vários requisitos de qualidade e contexto limitado para a aplicação de alguns dos métodos. O elevado custo de aplicação de métodos de avaliação está relacionado ao destes terem sido desenvolvidos para projetos de grande porte, que geralmente possuem alta disponibilidade de recursos. Com isso, somente um pequeno número de empresas conseguem aplicar de forma correta as avaliações (Lattanze, 2005). Diante de tantos métodos de avaliação era necessário identificar o método mais adequado ao contexto do projeto. Babar (Babar and Gorton, 2009) realiza um survey que tem o objetivo de identificar como as técnicas de revisão de arquitetura estão sendo utilizadas no mercado. Segundo seu trabalho, as quatro técnicas mais comuns aplicadas para revisão de uma arquitetura de software são baseadas em experiência, prototipagem, técnicas baseadas em cenários e técnicas baseadas em checklists. Após a análise das técnicas de revisão de arquitetura identificou-se que a quantidade de pessoas necessárias para realizar uma revisão de arquitetura, a quantidade de documentação que precisaria ser gerada e o esforço necessário para realizar as atividades inviabilizariam a adoção dessas técnicas por uma equipe pequena, como era o caso da startup onde essa aplicação foi desenvolvida. Para realizar a definição da arquitetura que seria adotada foi criada uma adaptação do processo apresentado em (Meier et al., 2008). Os passos para definição e avaliação de arquitetura utilizados nesse trabalho são descritos a seguir: 73

89 4.3. DEFINIÇÃO DE ARQUITETURA 1. Identificação dos objetivos da Arquitetura: nessa etapa os objetivos da arquitetura pretendida são claramente definidos. Objetivos claros ajudam a focar na resolução do problema e identificar quando uma arquitetura adequada foi encontrada. 2. Visão geral da aplicação: nessa etapa o objetivo é entender o tipo de aplicação, restrições de implantação, identificar estilos arquiteturais importantes e determinar tecnologias relevantes para a implementação de uma possível solução. 3. Pontos Críticos: são identificados pontos críticos da arquitetura da aplicação para entender as áreas onde os erros normalmente acontecem. Os prontos são agrupados em termos de atributos de qualidade e interesses transversais. 4. Possíveis Soluções: apartir das informações obtidas até esse ponto é possível verificar a existência de arquiteturas pré-existentes que possivelmente possam ser adotadas para a solução pretendida. A escolha de arquiteturas candidatas leva em consideração a adequação aos requisitos funcionais e não-funcionais da aplicação, pontos críticos e restrições de deployment. 5. Proposta de solução de arquitetura: caso existam arquiteturas pré-existentes ou estilos arquiteturais que sejam adequados ao contexto, nessa fase é realizado a escolha de uma proposta. Caso não seja encontradas propostas de arquiteturas, uma arquitetura deve ser definida baseado nos requisitos funcionais, não-funcionais e pontos críticos. 6. Prototipagem: nessa etapa é desenvolvido um pequeno protótipo que servirá como prova de conceito e tem como objetivo identificar possíveis problemas de implementação durante a adoção da proposta selecionada. 7. Avaliação dos resultados: Após a implementação do protótipo, os pontos positivos e negativos da abordagem são apresentados de forma a verificar se a solução de arquitetura implementada no protótipo é adequada para o produto a ser desenvolvido Identificação dos objetivos da Arquitetura Diante de um cenário onde era necessário atender a interesses dos usuários finais, clientes, desenvolvedores e do próprio provedor de serviço, foi necessário identificar quais eram esses interesses que poderiam influenciar no projeto: 74

90 4.3. DEFINIÇÃO DE ARQUITETURA Usuários finais da aplicação: interessados em requisitos funcionais corretos e usabilidade Clientes do provedor de serviço: preço acessível, atendimento aos requisitos funcionais do negócio, retorno de investimento Desenvolvedor: separação entre requisitos multi-tenancy e requisitos funcionais da aplicação, facilidade de execução de testes. Provedor de serviços: uso eficiente de recursos computacionais, prazo e custo. Apartir dos interesses dos stakeholders e dos requisitos funcionais e não funcionais, definimos o objetivo que nossa arquitetura deveria alcançar: Consumo de recursos computacionais otimizados; Independência entre requisitos funcionais e requisitos relacionados a implementação de multi-tenancy(autenticação e autorização, configurabilidade, acesso a dados, etc...); A aplicação será executada em ambiente web, tendo como principal cliente o browser; A arquitetura deve facilitar o desenvolvimento de testes automatizados; A arquitetura deve permitir que os módulos relacionados aos requisitos multitenancy sejam reutilizados em projetos futuros; A arquitetura deve facilitar a integração da aplicação SaaS com outras aplicações utilizadas pelo cliente; Visão geral da aplicação Apartir dos requisitos funcionais identificou-se 3 perfis de atores necessários para o funcionamento da primeira versão da aplicação: Usuário Final: é o usuário da aplicação responsável por cadastrar as informações sobre as linhas de produto de software documentadas através de nossa aplicação. Esse usuário poderá acessar funcionalidades relacionada a gerencia de projetos, gerencia de risco, gerencia de escopo, gerencia de requisitos e gerencia de testes. 75

91 4.3. DEFINIÇÃO DE ARQUITETURA Figura 4.3 Diagrama de Caso de Uso da Aplicação Alexandria(Fonte: Elaboração própria) Consumidor de SaaS: é o usuário do lado do cliente que possui maior privilégio no uso da aplicação. Além do acesso a todas a funcionalidades disponibilizadas para o perfil Usuário Final, esse perfil é associado ao usuário que contrata nosso software através de uma interface web. Esse usuário é responsável pelo gerenciamento dos outros usuários(cadastro, exclusão de usuários, alteração de dados do usuário) Provedor de serviço: poderá ter acesso à funcionalidades de gerenciamento e monitoramento dos tenants da aplicação. A Figura 4.3 apresenta um diagrama de caso de uso que tem o objetivo de apresentar uma visão geral dos requisitos funcionais da aplicação. Esse diagrama foi construído apartir das informações já descritas na seção 4.1. Para implementar nossa aplicação, identificou-se alguns estilos arquiteturais em (Team, 2009), que poderiam servir como base para a definição de arquitetura da aplicação: Cliente/Servidor: como o sistema deveria funcionar na web esse estilo arquitetural apresentou-se como uma solução a ser escolhida. Nele é apresentado o conceito de cliente e servidor, onde o servidor recebe requisições de vários clientes. 76

92 4.3. DEFINIÇÃO DE ARQUITETURA Baseado em componentes: esse estilo arquitetural decompõe o projeto de software em componentes funcionais ou lógicos que expõem interfaces de comunicação bem definidas que contenham métodos, eventos e propriedades. Baseado em camadas: esse estilo arquitetural é focado no agrupamento funcional da aplicação em camadas distintas, empilhadas verticalmente. A funcionalidade em cada camada está relacionada a um papel ou responsabilidade comum. A comunicação entre camadas é explícita e fracamente acoplada. Orientado a Objetos: estilo arquitetural baseado no paradigma orientado a objetos, no qual ocorre a divisão de responsabilidades do sistema em objetos reusáveis e coesos, que contém dados e comportamentos relevantes. Uma proposta final de arquitetura pode sofrer influência de vários estilos arquiteturais. A decisão de qual estilo arquitetural pode influenciar a solução proposta depende de quais benefícios cada estilo pode oferecer. A Tabela 4.1 apresenta os pontos que foram considerados quando definimos que os quatro estilos arquiteturais supracitados poderiam beneficiar nossa solução final. Escolhidos os estilos arquiteturais que seriam tomados como base, o proximo passo seria escolher as tecnologias que seriam utilizadas para a implementação da solução. Um ponto levado em consideração aqui foi o fato dos desenvolvedores já possuirem experiências prévias com desenvolvimento de aplicações na plataforma Java. Com o objetivo de evitar que seja gasto muito tempo com curvas de aprendizado de novas tecnologias, decidiu-se buscar para a implementação tecnologias ou propostas baseadas nessa plataforma. Dado que um dos objetivos do projeto seria criar uma solução que proporcionasse o máximo de reuso possível, encontrou-se 2 abordagens relevantes. A primeira abordagem seria o desenvolvimento de uma aplicação web, cuja modularização seria implementada utilizando OSGi (Kaegi and Deugo, 2008; Stoev and Dimov, 2008). A segunda abordagem seria a utilização de Grails 1, um framework de desenvolvimento de aplicações web que utiliza uma abordagem baseada em plugins, na qual várias funcionalidades da aplicação podem ser implementadas como plugins reutilizáveis. Antes da escolha de qualquer abordagem deve-se levar em consideração alguns pontos críticos que são apresentados na seção seguinte

93 4.3. DEFINIÇÃO DE ARQUITETURA Estilo Arquitetural Cliente/Servidor Benefícios A aplicacão deverá suportar vários clientes. A aplicacão deverá ser acessada através do browser. Centralização de armazenamento de dados, backup e funcionalidades de gerenciamento. A aplicação poderá suportar diferentes tipos de clientes de diferentes tipo de dispositivos. Baseado em componentes Possibilidade de obter componentes de fornecedores externos. Possibilidade de criar uma arquitetura plugável que permita, com o mínimo de esforço possível, substituir ou atualizar componentes individuais. Baseado em camadas Diminuição da complexidade da aplicação através do agrupamento funcional em diferentes áreas de interesse. Melhorar a manutenibilidade e extensibilidade da aplicação através da minimização de dependencias. Possibilidade de implementação de regras de negócio complexas e configuráveis, que poderiam ser agrupadas em uma camada específica. Orientado a Objetos Capacidade de modelar a aplicação baseada em objetos e ações do mundo real. Necessidade de encapsular lógica e dados juntos em componentes reusáveis. Tabela 4.1 Estilos arquiteturais escolhidos e suas influências em nossa arquitetura 78

94 4.3. DEFINIÇÃO DE ARQUITETURA Pontos Críticos e Soluções Para definir as tecnologias e a proposta de arquitetura mais adequadas para nosso caso, foi necessário definir alguns atributos de qualidade desejáveis para nossa aplicação, como pode ser visto na Tabela 4.2. Além dos pontos críticos considerados, antes de propor qualquer solução, fez-se necessário verificar a existência de propostas de arquitetura para aplicações multi-tenancy existentes na literatura. Foram analisadas as arquiteturas encontradas durante o mapeamento sistemático realizado no Capítulo 3. Na seção foram identificados 2 tipos de arquiteturas: definições de arquitetura para aplicações multi-tenancy (Yuanyuan et al., 2009; Jing and Zhang, 2010; Koziolek, 2010; Bezemer et al., 2010; Bezemer and Zaidman, 2010; Azeez et al., 2010; Pervez et al., 2010b; Tsai et al., 2010d; Calero et al., 2010; Oh et al., 2011; Koziolek, 2011) e para plataformas que suportam aplicações multi-tenancy (Weissman and Bobrowski, 2009; Cheng et al., 2009; Takahashi et al., 2010). Para a escolha da arquitetura de nossa aplicação foram analisadas apenas as propostas de arquitetura para aplicações. A principal preocupação na escolha seria identificar uma arquitetura que já tivesse sido validada na indústria, que tivesse maior aderência aos requisitos de nossa aplicação e aos atributos de qualidade definidos. Além disso era necessário verificar a possibilidade de atendimento a requisitos futuros de segurança, performance, alocação de recursos, armazenamento de dados, modularização e todos os outros pontos importantes em uma aplicação multi-tenancy que foram vistos no mapeamento sistemático. Nem todos esses requisitos foram atendidos de imediato, mas era de fundamental importância que a abordagem escolhida desse suporte a tais requisitos. Partindo desse princípio a arquitetura escolhida como referência para nossa implementação foi a apresentada por Bezemer (Bezemer et al., 2010). Embora essa arquitetura tenha sido a escolhida, não foi descartado a possibilidade de utilização de conceitos e abordagens apresentadas nos outros trabalhos. Outro ponto crítico é que já existia uma aplicação legada implementada na linguagem de programação python, que já possuía dados pré-existentes. Essa aplicação legada já implementava alguns requisitos do meta-modelo implementado(cavalcanti et al., 2011), mas não adotava o modelo de Software como Serviço(SaaS). Antes da implantação da primeira versão da aplicação seria necessário realizar a migração dos dados já cadastrados pela aplicação legada. A separação de interesses entre requisitos relacionados ao negócio principal da aplicação e requisitos inerentes a multi-tenancy também é um fator crítico que deve ser levado em consideração. A aplicação deveria ser implementada de forma o código 79

95 4.3. DEFINIÇÃO DE ARQUITETURA de regra de negócio sofresse o mínimo de interferência possível do código associado a implementações de multi-tenancy. A arquitetura escolhida como referência foi a que melhor se adequou a esse cenário Proposta de solução de arquitetura Multi-tenancy afeta quase todas as camadas de uma aplicação típica e possui um grande potencial para ser implementado como interesse transversal. Para reduzir a complexidade do código, a implementação de requisitos multi-tenancy deve ser separada da lógica de negócio o máximo possível. Caso contrário, a manutenção pode se tornar um pesadelo, porque: Implementar código de requisitos da arquitetura multi-tenancy juntamente com a lógica de negócio dos tenants, exige que todos os desenvolvedores sejam reeducados para entenderem os conceitos de multi-tenancy; Misturar multi-tenancy com código de lógica de negócio dos tenants leva ao aumento da complexidade da implementação, pois é mais difícil manter o controle de onde o código multi-tenancy é introduzido. Estes problemas podem ser superados integrando cuidadosamente multi-tenancy na arquitetura. No restante desta seção, descrevemos os componentes da arquitetura abordada por Bezemer (Bezemer et al., 2010) para implementação de multi-tenancy como um interesse transversal. A Figura 4.4 apresenta a descrição dessa aplicação e as subseções seguintes descrevem cada componente da aplicação. Autenticação Pelo motivo de uma aplicação multi-tenancy ter apenas uma instância da aplicação e do banco de dados, todos os tenants usam o mesmo ambiente físico. A fim de oferecer a customização do ambiente e ter certeza de que os tenants podem acessar somente os seus próprios dados, tenants devem ser autenticados. Enquanto autenticação de usuário é, possivelmente, já presente na aplicação de destino, um mecanismo separado de autenticação de tenants específicos pode ser necessário, por duas razões: (1) geralmente é muito mais fácil introduzir um mecanismo de autenticação adicional, do que mudar um já existente, e (2) autenticação de tenants permite que um único usuário faça parte de mais do que uma organização lógica, o que estende a idéia de autenticação de usuários com "grupos". 80

96 4.3. DEFINIÇÃO DE ARQUITETURA Atributo Disponibilidade Integridade Conceitual Flexibilidade Interoperabilidade Manutenibilidade Gerenciabilidade Performance Reusabilidade Escalabilidade Segurança Testabilidade Usabilidade Considerações Como planejar backups e restaurações Como projetar a aplicação para atualizações em tempo de execução Como isolar a aplicação de dependencias externas Como criar um caminho Como criar um plano para atualização de tecnologias Como evoluir a aplicação sem prejudicar o cliente Como tratar regras de negócio dinamicamente Como tratar dinamicamente interface com o usuário Como tratar mudanças em dados e lógica de processamento Como tratar mudanças em requisitos de negócio Como prover interoperabilidade entre aplicacões enquanto elas evoluem Como isolar sistemas através de interfaces de serviço Como reduzir dependências entre camadas e componentes Como implementar uma arquitetura plugável Como monitorar operações e saúde do sistema Como modificar o comportamento do sistema baseado em sua carga Como determinar uma estratégia de caching Como gerenciar recursos eficientemente Como reduzir duplicaçãode código entre componentes e camadas Como compartilhar funcionalidades através de sistemas Como compartilhar funcionalidades através de componentes e camadas Como ajustar a aplicação para aumento e diminuição de carga Como lidar com os picos no trafego e carga Como lidar com autenticação e autorização Como proteger-se de entradas mal intencionadas Como proteger dados sensíveis Como projetar a aplicação para testabilidade Como projetar testes de unidade Como evitar armadilhas comuns de experiência com usuário Tabela 4.2 Atributos de qualidade desejáveis na arquitetura 81

97 4.3. DEFINIÇÃO DE ARQUITETURA Figura 4.4 Arquitetura de Referência adotada(fonte: (Bezemer et al., 2010)) Configuração Em uma aplicação multi-tenancy a customização deve ser possível através de configuração. A fim de permitir que o usuário tenha uma experiência como se ele estivesse trabalhando em um ambiente dedicado, é necessário permitir pelo menos os seguintes tipos de configuração: Estilo de Layout(Layout Style): O componente de configuração de estilo de layout permite o uso de temas e estilos específicos. Configuração Geral (General Configuration) O componente de configuração geral permite a especificação de configurações específicas, como configurações de chave de criptografia e detalhes do perfil pessoal. Entrada e saída de arquivo (File I/O) O componente de configuração de I/O de arquivo permite a especificação de caminhos de arquivos, que podem ser usados para, por exemplo, geração de relatório. Fluxo de trabalho (Workflow) O componente de configuração de fluxo de trabalho permite a configuração de fluxos específicos. Por exemplo, configuração de fluxos é necessária em uma aplicação de planejamento de recursos empresariais - 82

98 4.3. DEFINIÇÃO DE ARQUITETURA ERP, em que o fluxo de requisições pode variar significativamente para diferentes companhias. Banco de dados (Database) Em uma aplicação multi-tenancy há uma grande exigência para o isolamento dos dados. Porque todos os tenants usam a mesma instância de um banco de dados é necessário ter certeza de que eles podem acessar somente seus próprios dados. Atualmente sistemas de gerenciamento de dados (Data Base Management Systems - DBMS) de prateleira não são capazes de lidar com multi-tenancy, isso deve ser feito em uma camada entre a camada lógica de negócios e o pool de banco de dados de aplicações. As principais tarefas dessa camada são as seguintes: Criação de novos tenants no banco de dados: Se a aplicação armazena ou recupera dados que podem ser de tenants específicos, é tarefa da camada de banco de dados criar os registros do banco de dados correspondente quando um novo tenant se inscreveu para a aplicação. Adaptação de consulta: A fim de prover um isolamento de dados adequado, a camada de banco de dados deve ter certeza que consultas são ajustadas de forma que cada tenant possa acessar somente seus próprios registros. Balanceamento de carga: Para melhorar o desempenho de uma aplicação multi-tenancy é necessário um balanceamento de carga eficiente para o pool de banco de dados. Note que qualquer acordo feito no SLA de um tenant e quaisquer restrições impostas pela legislação do país onde o tenant está localizado deve ser satisfeita. Por outro lado, nossa expectativa é a de que é possível criar algoritmos de balanceamento de carga mais eficientes usando as informações coletadas sobre as características de funcionamento dos tenants Tecnologias Após a escolha de uma arquitetura de referência para ser adotada por nossa aplicação, tem-se a necessidade de escolher as tecnologias que serão adotadas para a implementação. Devido ao perfil da equipe de desenvolvimento optou-se por escolher tecnologias que executassem na plataforma Java para aproveitar a experiência da equipe. Durante a 83

99 4.3. DEFINIÇÃO DE ARQUITETURA escolha dessas tecnologias avaliou-se a possibilidade do uso de JSF 2, Struts 2 3, Spring Framework 4 e Grails 5. Apartir de reuniões com os envolvidos observou-se que Grails apresentava um conjunto de recursos que poderiam dar produtividade para a equipe de desenvolvimento que não foram encontrados nas outras tecnologias como geração de CRUD (Create, Read, Update e Delete), arquitetura baseada em plugins que permite a criação e reuso de componentes, e total integração com frameworks e APIs Java. O Grails é um framework web open-source que utiliza a linguagem Groovy 6, e outros frameworks consagrados como Hibernate 7, Spring Framework e Sitemesh 8. Uma descrição visual da arquitetura do Grails é apresentada na Figura 4.5. O Grails foi projetado para desenvolver aplicações CRUD de forma simples e ágil, utilizando o modelo de "escrever código por convenção"introduzido pelo Ruby on Rails. O Grails propõe-se a trazer a produtividade do Ruby on Rails para a plataforma Java, porém ele possui uma grande vantagem, já que é baseado na linguagem Groovy. Groovy (padronizado pela JSR-241) é uma linguagem dinâmica e ágil para a plataforma Java, que possui muitas características de linguagens de script como Ruby, Python e Smalltalk, e além disso aplicações Groovy podem utilizar classes Java facilmente. Linguagens de script estão ganhando cada vez mais popularidade, devido a quantidade reduzida de código fonte necessário para implementar determinadas funcionalidades, se comparado com uma implementação em Java. A aplicação que está sendo desenvolvida, em particular se beneficiará da capacidade de definir métodos e propriedades em tempo de execução, disponibilizado pela linguagem Groovy. Essa característica da linguagem Groovy é chamada de metaprogramação. Em uma linguagem estática como Java, o acesso a uma propriedade ou invocação de um método é resolvido em tempo de compilação. Em comparação, Groovy não resolve o acessos à propriedades ou invocação de métodos até que a aplicação seja executada (Richardson, 2009). Uma aplicação que utiliza essa linguagem pode dinamicamente definir métodos ou propriedades em tempo de execução, isso vai de encontro à necessidade de customização das aplicações, dado que, com a utilização desse recurso, pode-se adicionar atributos e customizar comportamentos de um tenant específico futuramente. Outro ponto que influenciou bastante na escolha de Grails foi sua arquitetura baseada

100 4.3. DEFINIÇÃO DE ARQUITETURA Figura 4.5 Arquitetura do Grails Framework(Fonte: (Judd et al., 2008)) em plugins. Grails não se propõe a ter todas as respostas e soluções para o desenvolvimento de aplicações web. Ao invés disso, ele provê uma arquitetura baseada em plugins e um repositório mantido pela comunidade de desenvolvedores onde é possível encontrar plugins que implementam as mais diversas funcionalidades como segurança, AJAX, teste, busca, geração de relatórios, web services, etc. Essa abordagem proporciona o reuso e permite que funcionalidades de difícil implementação possam ser adicionadas na aplicação de forma bastante simples. Além das tecnologias relacionadas à programação, foi necessário escolher a tecnologia utilizada para armazenamento de dados. Como já existiam dados legados cadastrados em um banco de dados relacional, decidiu-se adotar o SGBD PostgreSQL. A escolha desse SGBD deu-se pelo fato do mesmo ser open-source bastante consolidado no mercado e possuir integração com várias ferramentas de relatórios, o que poderia facilitar futuras extrações de dados para os clientes Prototipagem Apartir da escolha da arquitetura de referência, das tecnologias a serem adotadas e da divisão dos módulos da aplicação chegou-se a proposta de arquitetura apresentada na Figura 4.6. Em nossa proposta a nossa aplicação possui 5 módulos associados à lógica de negócio da aplicação, esses módulos foram descritos anteriormente na seção 4.1. Foi adotado o Framework Grails para auxílio ao desenvolvimento da aplicação web e juntamente com ele foram adotados alguns de seus plugins. Para validar nossa arquitetura foi desenvolvido um protótipo contendo uma parte pequena dos requisitos funcionais da aplicação. Nesse protótipo serão implementados os cadastros de Projeto, Módulo e Features. A implementação do protótipo tem o objetivo de verificar a viabilidade de implementação e o atendimento dos objetivos da arquitetura. 85

101 4.3. DEFINIÇÃO DE ARQUITETURA Figura 4.6 Arquitetura da Aplicação Como mencionado anteriormente na seção 4.3.4, existe uma grande necessidade de separar código de lógica de negócio de código relacionado aos requisitos multitenancy. Com o objetivo de implementar os requisitos multi-tenancy de forma reutilizável, a solução foi implementar esses requisitos como um plugin do Grails, dessa forma aplicações futuras poderiam se beneficiar do código implementado. Uma vantagem do uso dessa abordagem é que dentro de um plugin grails é possível adicionar não só classes implementadas em Groovy ou Java, mas também páginas da camada de visão e outros tipos de arquivo. Antes de implementar os requisitos multi-tenancy como plugin foi realizado uma pesquisa no repositório de plugins do Grails para verificar se já existia algo semelhante ao que pretendia-se implementar. Durante a pesquisa foi encontrado o plugin Multi-tenancy Core 9 que implementa as funcionalidades de 2 dos componentes mencionados em nossa arquitetura de referência(bezemer et al., 2010), o componente de autenticação e o componentes de acesso ao banco de dados. Esse plugin implementa a funcionalidade de associar um usuário da aplicação a um tenant específico e além disso realiza de forma dinâmica o filtro dos dados durante uma consulta ao banco de dados, de forma que um usuário da aplicação tenha acesso apenas aos dados vinculados ao seu tenant. Para utilizar esse plugin foi necessário apenas instalá-lo na aplicação e adicionar uma anotação MultiTenant nas classes de domínio da aplicação. Essa anotação indica que todos os objetos dessa classe deverão ser gerenciados pelo plugin e sempre que um registro for salvo no banco deverá ser associado ao tenant do usuário que estiver logado no momento. Um exemplo simplificado de uma classe Groovy com essa anotação é apresentada na Figura A autenticação e controle de acesso pode ser realizado através da integração desse

102 4.3. DEFINIÇÃO DE ARQUITETURA Figura 4.7 Exemplo de classe escrita em linguagem Groovy que utiliza o plugin Multi-Tenancy Core plugin com o Spring Security 10, um framework de controle de acesso bastante utilizado em aplicação Java. A Figura 4.8 apresenta a tela de autenticação gerada pelo próprio plugins do Spring Security. De forma integrada com o plugin Multi-tenancy Core, ele associa cada usuário logado ao tenant ao qual ele pertence. Figura 4.8 Tela de autenticação gerada pelo Spring Security Plugin O terceiro componente mencionado em nossa arquitetura de referência é o componente de configuração. O objetivo desse componente de gerenciar as configurações relacionadas