Interoperabilidade

A interoperabilidade, no contexto de computação em nuvem, pode ter dois significados: um mecanismo de comunicação destinado a integrar diferentes aplicações executadas em múlti- plas nuvens; uma plataforma que possa ser executada por muitas linguagens de programação, em diversos provedores diferentes de nuvem.

O trabalho desenvolvido porAMIN et al.(2012) constitui o primeiro tipo de interope- rabilidade. O Intercloud Message Exchange Middleware (ICME) é um middleware que utiliza um padrão de comunicação por troca de mensagens e presença, chamado de Data Distribution Service(DDS), desenvolvido pelo Object Modeling Group (OMG). O serviço DDS depende de um componente chamado de Global Data Space (GDS), que funciona como um ponto central para o registro de tópicos, em um estilo de comunicação Publish/Subscribe, que desacopla os participantes da comunicação.

O ICME extende as funcionalidades providas pelo DDS, através da definição de um modelo de informação que reflete um cenário de computação em nuvem. Os participantes do modelo de informação fornecido pelo ICME são chamados de entidade. Um dos tipos de entidade é chamado de Message, que por sua vez pode ser de do tipo Request e Response. A entidade define os tipos possíveis de mensagem é denominado MessageType, e consiste em uma enumeração que possui uma entrada específica para cada mensagem. Cada mensagem se relaciona com uma QoS Policy, que é definida através de um conjunto de QoS Parameters.

A entidade chamada Resource Description contém uma descrição de todos os recursos da nuvem sob uma representação em forma de ontologia, descrito através do formato Web Ontology Language(OWL) (AMIN et al.,2012). A ontologia armazenada por esta entidade reflete a estrutura de implantação da nuvem, com cada nível hierarquia representando um objeto diferente como fornecedor, middleware,aplicação, capacidade, sistema operacional e outros. Esta ontologia é usada em conjunto com QoS Policies, que identificam o melhor caminho para a entrega de um Message para um Subscriber específico.

O modelo de comunicação oferecido pelo ICME é próprio para interação entre aplicações cujas partes são executada em domínios distintos. O eCaMid, em contrapartida foi pensado para ser executado em uma única nuvem, como um cluster único. O ICME poderia ser utilizado como intermediário de múltiplos clusters do eCaMid, cada um implantado em um conjunto de recursos diferentes, como, por exemplo, diferentes provedores de nuvem presentes em uma única federação.

O segundo tipo de interoperabilidade é implementado pelo middleware conhecido como IBM Altocumulus (MAXIMILIEN et al., 2009). O IBM Altocumulus visa tornar possível a implantação de uma aplicação sobre múltiplos provedores de IaaS públicos (i.e. AWS), provedores de PaaS (i.e. GAE) e nuvens privadas (como Eucalyptus). Além dos provedores de nuvem, o middleware também visa a implantação de aplicações em diferentes linguagens de

programação e frameworks, como Ruby on Rails1, Python/Django2, JavaEE3e Hadoop4. Por suportar esses diferentes frameworks, o Autocumulus visa execução de diferentes tarefas em múltiplas nuvens, como é o caso de criar instâncias, executar imagens e configurar componentes. Também é objetivo do middleware permitir a repetição da execução das mesmas tarefas, regras e topologias em múltiplas nuvens, assim como a capacidade de monitorar métricas que medem o desempenho das aplicações.

A arquitetura do Altocumulus é composto de um dashboard, que define uma interface para usuários do middleware, destinadada a definir as melhores práticas de implantação de aplicações e gerenciar as credenciais de acesso à diferentes provedores de nuvem. A API e o API Tester são componentes que expõem a API Representational state transfer (REST) do Altocumulus. O Core é um componente que implementa a API, que é usada pelo Dashboard e as aplicações dos usuários. O Core contém um conjunto de scripts, regras e adaptadores de nuvem que permitem a execução de ações em múltiplas nuvens para diferentes tipos de usuários (MAXIMILIEN et al.,2009).

O eCaMid, assim como o Altocumulus, foi pensado como uma plataforma que pudesse ser implantada em diversos provedores de nuvem. O eCaMid no entanto, tem um escopo mais restrito, por ser pensado como um middleware que deve ser implantado em nuvens do tipo IaaS para apoiar o desenvolvimento de aplicações orientadas a objeto que sejam compatíveis com a tecnologia Java. No entanto, como o eCaMid é um middleware orientado a objetos, sua principal função é fornecer um modelo de programação para aplicações de nuvem, enquanto o Altocumulusprovisiona e configura diferentes aplicações em diferentes tipos de nuvens diferentes.

O Altocumulus e o eCaMid poderiam funcionar de forma complementar, onde o primeiro seria usado para provisionar e configurar o segundo em diferentes provedores e máquinas virtuais.

5.2.4

Elasticidade

A elasticidade é uma característica bastante peculiar ao modelo de computação em nu- vem. A elasticidade é a capacidade de diminuir ou aumentar os recursos de nuvem de acordo com a demanda da aplicação, evitando os riscos associados ao subdimensionamento e superdimensi- onamento da infraestrutura. Para que um middleware ofereça suporte a elasticidade, ele deve apresentar meios para que a aplicação continue funcionando em decorrência da reconfiguração dinâmica da infraestrutura ou que o middleware forneça serviços específicos que gerencie de forma ativa a elasticidade, com a implantação e desligamento de outros nós. Os trabalhos que serão mostrados a seguir procuram atender pelo menos uma dessas características.

RANJAN et al.(2010), em seu trabalho, desenvolveu um middleware baseado em uma arquitetura P2P cuja finalidade é auxiliar na descoberta de serviços, provisionar aplicações em

1_{http://rubyonrails.org/}

2_{https://www.djangoproject.com/}

3_{http://www.oracle.com/technetwork/java/javaee/overview/index.html} 4_{http://hadoop.apache.org/}

nós específicos da infraestrutura de nuvem e proporcionar um mecanismo de balanceamento de carga. A vantagem do uso de plataformas P2P no contexto de elasticidade é a sua capacidade de se manter funcional mesmo em decorrência de desligamento e ativação de novas máquinas virtuais, e de conter mecanismos de comunicação de alta escalabilidade.

O middleware conhecido como Cloud Peers é parte de uma oferta de PaaS e é composto de três camadas. A primeira camdada consiste em uma infraestrutura de roteamento auto- organizável baseada em DHT, fornecendo um overlay para diversas máquinas virtuais, mantendo uma tabela de roteamento para cada endereço IP de um peer. A segunda camada oferece mecanismos de organização de dados, índices distribuído e replicação. Estes índices suportam o armazenamendo de chaves e queries multidimensionais, onde cada registro é armazenado em múltiplos nós, evitando a perda de informação em caso de falha de um peer. A terceira consiste em serviços de descoberta de nós, coordenação e troca de mensagens. Através dos serviços da terceira camada, são registrados as máquinas virtuais existentes, os serviços publicados em cada um e mecanismos de troca de mensagens baseado no padrão Publish/Subscribe (RANJAN et al., 2010).

O eCaMid também utiliza um mecanismo de comunicação P2P para localizar e coordenar diversos nós baseada em JGroups, mas que funciona de forma diferente de uma DHT. eCaMid e o Cloud Peers também diferem por suas finalidades. O principal foco do eCaMid é proporcionar um modelo de programação baseado em objetos distribuídos. Já a finalidade do Cloud Peers é prover mecanismos eficiente de provisionamento de aplicações em máquinas virtuais e oferecer serviços de localização e coordenação.

Um outro trabalho tem a finalidade de prover serviços de elasticidade (JAYARAM,2013). O middleware chamado de ElasticRMI fornece uma extensão ao middleware Remote Method Invocation(RMI), um middleware orientado a objetos que é parte do núcleo da linguagem java.

O ElasticRMI define um conceito de um Elastic Object Pool, um conjunto de objetos (baseados no padrão Object Group), que está distribuído em diferentes nós de uma infraestrutura. Invocações direcionadas a um dos objetos presentes no Elastic Object Pool são direcionadas aos demais membros, como um mecanismo de balanceamento de carga. Um sistema de armazena- mento chamado Hyperdex (HYPERDEX,2014) é usado para armazenar o estado dos objetos distribuídos. Um framework de gerenciamento de cluster, chamado Apache Mesos (APACHE MESOS,2014), é responsável por distribuir processos de um Elastic Object Pool entre várias máquinas físicas ou virtuais (JAYARAM,2013).

O eCaMid e o ElasticRMI são bastante semelhantes, pois ambos são middlewares orientados a objetos que visam manter serviços de suporte à elasticidade. Ambos utilizam o padrão de projeto Object Group para distribuir requisições remotas entre diversos nós.

Algumas características, no entanto, diferenciam o eCaMid e o ElasticRMI. Enquanto o balanceamento de carga realizado pelo ElasticRMI é realizado para um grupo formado por um conjunto de objetos semelhantes, o mesmo mecanismo, no eCaMid, é realizado para um grupo de nós semelhantes de uma mesma infraestrutura. Um nó do eCaMid pode conter vários

objetos distribuídos, que possuem alguma dependência entre si. O eCaMid também suporta estilos de comunicação Publish/Subscribe e a coordenação de tarefas periódicas em um cluster. O sistema de armazenamento e coordenação utilizado pelo eCaMid utiliza um modelo P2P que é embarcado no próprio middleware visando facilitar o deployment e configuração, enquanto o ElasticRMI depende de serviços instalados externamente como o Hyperdex e Apache Mesos. Estes serviços também precisam ser provisionados e dimensionados visando os requisitos não funcionais de escalabilidade, desempenho e disponibilidade para que o ElasticRMI possa adquirir estas mesmas características.

O ElasticRMI, no entanto, é capaz de realizar o redimensionamento do tamanho de um Elastic Object Pooldinamicamente, baseado em métricas de desempenho. Embora provedores de nuvem, tipicamente, não possuam instalações nativas de um framework como Apache Mesos, este poderia ser útil como parte de uma oferta de PaaS. O eCaMid ainda carece de um mecanismo semelhante, e poderia se beneficiar de ferramentas de provisionamento e implantação.