Taxonomias para o Gerenciamento de Recursos em Múltiplas Nuvens

Durante as pesquisas realizadas nesta tese, nenhuma taxonomia de recursos con- templa os requisitos de um arquiteto de software em um ambiente de múltiplas nuvens. Nesta subseção, três taxonomias são propostas. A primeira determina quando gerenciar os recursos em múltiplas nuvens. Já a segunda determina como requisitos de um arquiteto de software em múltiplas nuvens podem ser configurados. Por fim, a última taxonomia proposta determina como gerenciar recursos em múltiplas nuvens, de acordo com as demandas de um arquiteto de software descritas na Subseção 2.2.

A Figura 4 ilustra a taxonomia proposta para se determinar quando gerenciar recursos em múltiplas de nuvens, tanto da perspectiva de um arquiteto de software quanto da perspectiva de um provedor.

No segundo nível da taxonomia, a perspectiva de um arquiteto de software é dividida em duas fases:pre-implantação e pós-implantação. O terceiro nível da taxonomia apresenta as situações nas quais os recursos podem ser gerenciados em múltiplas nuvens, tanto da perspectiva de um arquiteto de software quanto da perspectiva de um provedor. Da perspectiva de um

Figura 4. Taxonomia para determinar quando gerenciar MCR.

arquiteto de software, na pré-implantação, as situações que podem gerenciar recursos são: seleção de Nuvem, seleção de Serviço, posicionamento de serviço e de máquinas virtuais (Virtual Machine (VM)). Na seleção de nuvem um arquiteto de software precisa determinar a modularização de uma aplicação. A Figura 5 apresenta duas opções: única nuvem e múltiplas nuvens. No primeiro caso, a aplicação é implantada em apenas um provedor e, no segundo caso, ela deve ser implantada em múltiplas nuvens. Na taxonomia proposta, um arquiteto de software possui três opções para modularizar uma aplicação. A opção Grupo de Tarefas representa uma aplicação modularizada em vários grupos de tarefas (microsserviços, por exemplo), onde cada grupo de tarefas pode ser implantado em um provedor. As outras duas opções, baseiam-se em Tarefa e Serviço de uma aplicação, e podem ser implantadas em provedores de nuvem distintos. Neste trabalho, Tarefa representa um conjunto de serviços de nuvem. Em seguida, a seleção da nuvem deve basear-se nos requisitos de um arquiteto de software para um Grupo de Tarefas, Tarefa ou Serviço. Para as demais situações da perspectiva de um arquiteto de software tanto na pré-implantação quanto na pós-implantação observa-se os requisitos de um arquiteto de software, além dos funcionais, para selecionar e colocar os serviços e/ou máquinas virtuais (VMs) para executar uma aplicação em um provedor de nuvem.

Figura 5. Modularização de uma Aplicação para implantação.

Da perspectiva de um provedor as situações que podem ser gerenciadas são: posicio- namento de VM, seleção de data center, planejamento de capacidade e balanceamento de carga. Elas precisam ser gerenciadas pelo provedor de nuvem, através da observação dos requisitos de um arquiteto de software, de maneira a aumentar a lucratividade do provedor.

Conforme descrito nesta seção, para tornar possível o gerenciamento de recursos em múltiplas nuvens, é necessário configurar os requisitos de um arquiteto de software. Para isso, existem alguns aspectos que devem ser analisados: o estado,a multiplicidade e a granularidade dos requisitos. Assim, uma taxonomia é proposta para determinar como configurar os requisitos de um arquiteto de software, a qual é ilustrada na Figura 6. O estado de um requisito pode ser: estático, dinâmico e/ou híbrido. O estado estático indica que os requisitos são conhecidos antes da implantação de uma aplicação. O estado dinâmico indica que os requisitos aparecem ao longo do tempo (GUZEK et al., 2015). Por fim, os requisitos podem ser configurados nos estados estático e dinâmico, indicando que os requisitos podem ser conhecidos antes da implantação de uma aplicação e alterados após a implantação.

No aspecto de multiplicidade, um arquiteto de software pode configurar um ou vários requisitos para uma aplicação. Se vários requisitos forem configurados, as prioridades, a otimização ou ambas devem ser definidas. A prioridade determina o peso de cada requisito e a otimização determina quais requisitos devem ser maximizados ou minimizados. A granularidade significa a definição dos requisitos de um arquiteto de software para uma aplicação, grupo de tarefas, tarefa ou serviço. Se a definição dos requisitos for feita para uma aplicação, isso indicará que todos os componentes de uma aplicação têm os mesmos requisitos, mas se os requisitos forem definidos para um Grupo de tarefas, por Tarefa ou por Serviço, isso indicará que cada Grupo de tarefas, Tarefa ou Serviço de uma aplicação possui requisitos distintos.

Por fim, uma taxonomia é proposta para determinar como gerenciar os recursos em múltiplas nuvens, a qual é ilustrada na Figura 7. O aspecto modo indica se existe ou não a necessidade de intervenção humana durante o processo de gerenciamento de recursos. O modo automático indica que todo gerenciamento de recursos é feito sem intervenção de um arquiteto

Figura 6. Taxonomia para configurar os requisitos de um Arquiteto de Software para uma Aplicação em Múltiplas Nuvens.

de software, mas este pode definir se as soluções devem ser ótimas ou se devem ser viáveis. O modo interativo indica que o sistema de gerenciamento deve interagir com um arquiteto de softwarepara tomar uma decisão. No aspecto de granularidade o gerenciamento de recursos deve ser definido de acordo com a definição de requisitos de um arquiteto de software. As definições de requisito feitas por um arquiteto de software podem ser para a aplicação, ou para um Grupo de Tarefas, ou por Tarefa e ainda por Serviço.