1 Introdução

O grupo Cloud Computing Use Case reuniu consumidores e fornecedores da nuvem para definir cenários de uso comum para o caso de computação em nuvem. Os cenários de caso de uso demonstram os benefícios econômicos e de desempenho da computação em nuvem e são baseados nas necessidades do maior número possível de os consumidores.

O objetivo deste documento é destacar as potencialidades e as necessidades que precisam ser padronizadas em um ambiente de nuvem para garantir a interoperabilidade, facilidade de integração e portabilidade. Deve ser possível executar todas os casos de uso descritos neste documento sem usar tecnologias fechadas ou proprietárias. A computação em nuvem deve evoluir como um ambiente aberto, maximizado as escolhas dos clientes e reduzindo estratégias de bloqueio por parte dos provedores de solução.

Os casos de uso:

Fornecem um contexto prático baseado na experiência de usuários para as discussões sobre interoperabilidade e padrões.

Deixam claro que as normas existentes devem ser utilizadas. Chamam a atenção da indústria sobre a importância do Open Cloud

Computing. Deixam claro onde existem padrões de trabalho a ser implementado. Se um

caso de uso em particular não pode ser construído hoje, ou se ele só pode ser construído com APIs e/ou produtos proprietários, a indústria precisa de definir normas para que esse caso de uso seja possível.

Um caso de uso que descreve claramente uma tarefa comum e expõe as dificuldades de realizá-la é a melhor justificativa possível para qualquer esforço de padronização.

O Open Cloud Manifesto (opencloudmanifesto.org) é uma declaração dos princípios para a manutenção da abertura em computação em nuvem. Dois meses após ao seu anúncio, 250 organizações subscreveram-se como adeptos. Esta atividade em grupo é feito à luz dos seis princípios do Open Cloud Manifesto:

Provedores de computação em nuvem devem trabalhar juntos para garantir que os desafios para a adoção da nuvem sejam tratados através da colaboração aberta e com o uso adequado de normas.

Provedores de computação em nuvem devem utilizar e adotar as normas existentes, sempre que apropriado. A indústria de TI tem investido fortemente em normas existentes e organismos de padronização, não há necessidade de duplicar ou reinventá-los.

Quando novos padrões (ou da adaptação às normas existentes) são necessários, temos de ser criteriosos e pragmáticos para evitar a criação de muitas normas. Devemos garantir que as normas promovam a inovação, não inibi-la.

Qualquer esforço da comunidade em torno da nuvem aberta deve ser orientado as necessidades do cliente, não apenas as necessidades técnicas

dos provedores de computação em nuvem, e deve ser testado ou avaliado em relação aos requisitos reais do cliente.

Organismos de padronização da computação em , grupos de advocacia e as comunidades devem trabalhar em conjunto e manter-se coordenados, certificando-se que esforços não entrem em conflito ou se sobreponham.

Provedores de computação em nuvem não deve usar sua posição no mercado para prender os clientes em suas plataformas proprietárias e limitar sua escolha de fornecedores.

Este artigo é parte do esforço em curso para tornar estes princípios uma realidade.

2 Definições e Taxonomia

As definições e taxonomia a seguir ajudam a fornecer uma visão geral dos conceitos de computação em nuvem. No entanto, o foco deste documento não é definir a computação em nuvem em si, mas definir cenários de nuvem e casos de uso com base em requisitos e aplicações do mundo real. Nosso objetivo é estabelecer cenários de casos de uso que sejam claros, interessantes e úteis, independentemente da forma como os cenários podem ser definidos ou classificados em uma taxonomia.

2.1 Definições de Conceitos de Computação em Nuvem

Computação em Nuvem: Computação em Nuvem (Cloud computing) é um modelo para permitir ubiqüidade, conveniência, acesso a rede sob demanda para um conjunto de recursos compartilhados de recursos de computação configuráveis (por exemplo: redes, servidores, armazenamento, aplicações e serviços) que podem ser rapidamente aprovisionados e disponibilizados aos usuários com o esforço mínimo de gestão ou interação do provedor de serviços. (Esta definição é a mais recente projeto da NIST “Working Definition of Cloud Computing” publicado pelo NIST - U.S. Government's National Institute of Standards and Technology)

2.1.1 Modelos de entrega

A definição de computação em nuvem do NIST define três modelos de entrega:

Software como Serviço (SaaS): o consumidor usa um aplicativo, mas não controla o sistema operacional, hardware ou rede de infra-estrutura em que está sendo executado.

Plataforma como um Serviço (PaaS): o consumidor utiliza um ambiente de hospedagem para suas aplicações. O consumidor controla os aplicativos executados no ambiente (e, eventualmente, tem algum controle sobre o ambiente de hospedagem), mas não tem controle sobre o sistema operacional, hardware ou infra-estrutura de rede que estão sendo executados. A plataforma é tipicamente uma estrutura do aplicativo.

Infra-estrutura como serviço (IaaS): O consumidor usa "recursos fundamentais de computação" como poder de processamento, armazenamento, componentes de rede ou middleware. O consumidor pode controlar o funcionamento do sistema operacional, do sistema de

armazenamento, aplicações instaladas e, possivelmente, componentes de rede, tais como firewalls e balanceadores de carga, mas não a infra-estrutura de nuvem na qual ele está.

2.1.2 Modelos de Implantação

A definição NIST define quatro modelos de implantação:

Nuvem Pública: Em termos simples, os serviços de nuvem pública são caracterizados como disponíveis ais clientes por um provedor de serviços através da Internet. O termo "público" não significa sempre livre, mesmo ele sendo grátis ou muito barato de usar. Uma nuvem pública não significa que os dados de um usuário é publicamente visível; vendedores de nuvem pública normalmente fornecem mecanismos de controle de acesso aos seus usuários. Provedores de nuvem pública fornecem soluções de elásticas, a um custo adequado para se usar as soluções.

Nuvem Privada: Uma nuvem privada oferece muitos dos benefícios de um ambiente de computação de nuvem pública, tais como elasticidade e baseado em serviço. A diferença entre uma nuvem privada e uma nuvem pública é que serviços baseados em uma nuvem privada, os dados e os processos são gerenciados na organização, sem as restrições de largura de banda da rede, riscos de segurança e requisitos legais ligados a utilização de serviços de uma nuvem pública. Além disso, os provedores de serviços de nuvem privada oferecem ao usuário maior controle da infra-estrutura de nuvem, segurança e resiliência porque o acesso do usuário e o uso da rede são protegidos e exclusivos.

Nuvem Comunitária: Uma nuvem comunitária é controlada e usada por um grupo de organizações que têm interesses comuns, tais como requisitos específicos de segurança ou uma missão semelhante. Os membros da comunidade compartilham acesso aos dados e aplicativos na nuvem.

Nuvem Híbrida: Uma nuvem híbrida é a combinação de uma nuvem pública e privada que interagem. Neste modelo os usuários normalmente terceirizam o armazenamento e processamento de informação relativos a processos de negócios que não são críticos na nuvem pública, enquanto mantém os dados e os serviços críticos aos negócios em seu controle.

2.1.3 Características essenciais

A definição NIST descreve cinco características essenciais de computação em nuvem:

Rápida Elasticidade: A elasticidade é definida como a capacidade de escala dos recursos tanto para cima quanto para baixo, conforme a necessidade. Para o consumidor, a nuvem parece ser infinita, e o consumidor pode comprar apenas o a quantidade de poder de computação que eles precisam. Esta é uma das características essenciais de computação em nuvem segundo a definição do NIST.

Serviço medido: Em um serviço medido, os aspectos do serviço na nuvem são controlados e monitorados pelo provedor de serviço em nuvem. Isto é crucial para o faturamento, controle de acesso, otimização de recursos, planejamento de capacidade e outras tarefas.

Auto-Atendimento Sob Demanda: Significa que um consumidor pode usar serviços da nuvem, conforme a sua necessidade e sem nenhuma interação humana com o provedor de serviço da nuvem.

Acesso Ubíquo pela Rede: Significa que o serviço do provedor de nuvem tem a capacidade de estar disponível na rede e acessível através de protocolos padronizados e por diferentes dispositivos (ricos ou magros em recursos).

Agrupamento de Recursos: O agrupamento de recursos permite a um provedor de nuvem servir os seus consumidores através de um modelo multi-clientes. Recursos físicos e virtuais são atribuídos e realocados de acordo com a demanda dos consumidores. Há um sentido da independência do local de forma 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 datacenter).

2.1.4 Outros TErmos

Interoperabilidade

Portabilidade

Integração

Acordo sobre Nível de Serviço (ANS): Do inglês Service Level Agreement (SLA), o ANS é um contrato

Federação

Corretor (Broker): Um corretor não tem recursos na nuvem de sua propriedade, mas relaciona-se com provedores beaseado em acordos de nível de serviço requeridos pelos consumidores. O consumidor desconhece que o corretor não controla os recursos.

Multi-Clientes (multi-tenant): É a propriedade de múltiplos sistemas, aplicações ou dados de diferentes organizações hospedarem-se no mesmo hardware físico.

Cloud bursting: é técnica usada pelas nuvens hibrídas para prover recursos adicionais para as nuvens privadas de acordo com as suas necessidades.

Política

Governança

Máquina Virtual ou Virtual Machine (VM):

Application Programming Interface (API) ou Interface de Programação da Aplicação:

2.2 Taxonomia

Esse diagrama define a taxonomia para computação em nuvem:

Neste esquema, os consumidores usam os serviços prestados através da nuvem, os provedores de serviços gerem a infra-estrutura da nuvem e os desenvolvedores criam eles próprios os serviços. Note que os padrões abertos são necessários para a interações entre esses papéis. Cada papel é discutido em mais detalhe nas seções seguintes.

2.2.1 Consumidor

O consumidor do serviço é o usuário final ou a empresa que realmente usa o serviço, seja ele software, plataforma ou infra-estrutura como um serviço.

Dependendo do tipo de serviço e de seu papel, o consumidor trabalha com diferentes interfaces de usuários e de programação. Algumas interfaces de usuário se parecem com um outro aplicativo qualquer, o consumidor não precisa saber sobre a computação em nuvem para usar o aplicativo. Outras interfaces de usuário fornecem funções administrativas, tais como inicializar e interromper o funcionamento de máquinas virtuais ou gerenciar o armazenamento na nuvem. Consumidores que escrevem código de aplicativos usam diferentes interfaces de programação (API), dependendo da aplicação que estão escrevendo.

Consumidores trabalham com ANS e contratos também. Normalmente, estes são negociados através de intervenção humana entre o consumidor e o provedor. As expectativas dos consumidores e a reputação do provedor são elementos-chaves dessas negociações.

2.2.2 Provedor de Serviço

O provedor entrega serviço ao consumidor. A tarefa real do provedor varia dependendo do tipo de serviço:

Para software como serviço (SaaS), o provedor instala, gerencia e mantém o software. O provedor não necessariamente é o proprietário da infra-estrutura onde o software está em execução. Independentemente disso, o consumidor não tem acesso à infra-estrutura, eles podem acessar apenas o aplicativo.

Para plataforma como serviço (PaaS), o provedor gerencia a infra-estrutura da nuvem para a plataforma, normalmente um framework para um determinado tipo de aplicação. O aplicativo do consumidor não pode acessar a infra-estrutura sob a plataforma.

Para infra-estrutura como serviço (IaaS), o provedor mantém o sistema de armazenamento, banco de dados, filas de mensagens ou outros middleware, ou o ambiente de hospedagem das máquinas virtuais. O consumidor que usa o serviço como se fosse uma unidade de disco, banco de dados, fila de mensagens, ou uma máquina, mas eles não podem acessar a infra-estrutura que hospeda os sistemas.

No diagrama de prestador de serviços, a camada mais baixa da pilha é o firmware e o hardware em que tudo se baseia. Acima está o núcleo do software, ou o sistema operacional ou o gerenciador de máquina virtual que hospeda a infra-estrutura sob a nuvem. Os recursos e imagens virtualizadas incluem os serviços básicos de computação de nuvens, como o poder de processamento, armazenamento e middleware. As imagens virtuais controladas pelo gerenciador de VMs incluem as próprias imagens e os metadados necessários para gerenciá-los.

Crucial para as operações do prestador de serviços é a camada de gestão. No nível mais baixo, o gerenciamento exige medição para determinar quem usa os serviços e em que medida, o provisionamento para determinar como os recursos

são alocados para os consumidores e o monitoramento para acompanhar o status do sistema e seus recursos.

No nível mais alto, o gerenciamento envolve o faturamento para recuperar os custos, o planejamento de capacidade para garantir que as exigências dos consumidores serão atendidas, gestão do nível de serviço (ANS) para garantir que os termos acordados entre o fornecedor e o consumidor sejam respeitados, e relatórios para os administradores.

Segurança se aplica a todos os aspectos das operações do prestador de serviços. (Os muitos níveis de requisitos de segurança estão fora do escopo deste artigo.) Padrões abertos aplicáveis às operações do provedor também. Um conjunto adequado de normas visam simplificar as operações dentro do provedor e a interoperabilidade com outros provedores de serviços.

2.2.3 Desenvolvedor

O desenvolvedor do serviço cria, publica e monitora o serviço na nuvem. Estes são tipicamente "a linha de negócios" das aplicações que são entregues diretamente aos usuários finais através do modelo SaaS. Aplicações escritas nos níveis de IaaS e PaaS serão posteriormente utilizados pelos desenvolvedores de SaaS e provedores de computação em nuvem.

Ambientes de desenvolvimento para a criação de serviços variam. Se os desenvolvedores estão criando uma aplicação SaaS, é bem provável que eles escrevam códigos para um ambiente hospedado por um provedor de nuvem. Neste caso, a publicação do serviço é implantá-lo na infra-estrutura do provedor de nuvem.

Durante a criação do serviço, a análise envolve a depuração remota para testar o serviço antes de disponibilizá-lo aos consumidores. Quando o serviço é

publicado, a atividade de análise consiste em monitorar o desempenho do serviço e realizar as alterações necessárias.

2.3 Relacionamento entre as normas e taxonomias

Existem quatro formas diferentes em que as normas afetarão os cenários de casos de uso na nuvem. Normas terão um impacto em cada tipo de serviço de nuvem, através dos diferentes tipos de serviços na nuvem, entre a empresa e a nuvem e dentro da nuvem privada de uma empresa.

2.3.1 Padrões em todos os tipos de serviços em nuvem

Enquanto a computação em nuvem se torna mais comum, as aplicações usarão provavelmente diferentes tipos de serviços em nuvem. Um aplicativo pode usar um serviço de armazenamento de nuvem, uma fila de mensagens na nuvem e gerenciar (start / stop / monitor) de máquinas virtuais rodando na nuvem. Normas para definir como estes diferentes serviços devem trabalhar juntos para agregar valor.

2.3.2 Padrões Dentro dos tipos de serviços na nuvem

Dentro de cada tipo de serviço da nuvem (IaaS, PaaS ou SaaS), padrões abertos tornam-na possível evitar estratégias de bloqueio de clientes por parte dos provedores.

Para infra-estrutura como serviço (IaaS), um conjunto padrão de APIs para trabalhar com bases de dados na nuvem permitem que aplicativos possam trabalhar com dados de vários fornecedores. Esta API comum dará aos usuários a liberdade de trocar de provedor de banco de dados na nuvem sem grandes mudanças e tornaria muito mais fácil de integrar novas fontes de dados às aplicações existentes. APIs comuns para outros serviços de infra-estrutura na nuvem , tais como armazenamento, filas de mensagens ou MapReduce proporcionaria benefícios semelhantes, como padronizar os formatos comuns para os dados e o modo de intercâmbio. No caso de máquinas virtuais, um

formato de máquina virtual comum é crucial. Os usuários devem ser capazes de pegar uma VM construída e implantada em um provedor da nuvem e implantá-lo em outro sem alterações.

Para plataforma como serviço (PaaS), muitas das plataformas disponíveis na nuvem são frameworks de aplicação. Esses frameworks normalmente fornecem serviços comuns tais como interfaces de usuário, armazenamento e bancos de dados, mas eles só são acessíveis por meio de APIs do framework.

Para o software como serviço (SaaS), padrões abertos aplicam-se no nível do aplicativo. Muito pouco das normas de trabalho aqui é específico para nuvem, assim esses padrões estão além do escopo deste artigo. Por exemplo, um aplicativo processador de texto baseado na nuvem devem suportar as normas para a portabilidade de documentos, a exigência de suportar padrões em um aplicativo processador de texto não tem nada a ver com o fato dele está sendo executado na nuvem.

2.3.3 Padrões entre a nuvem e a Empresa

Mesmo com o advento da computação em nuvem, arquiteturas de classe empresarial, tais como Java EE, não vão sumir. Padrões que definem como um aplicativo corporativo comunica-se com recursos, tais como um banco de dados na nuvem ou uma fila de mensagens na nuvem deve permitir que os aplicativos usem os serviços de nuvem, com pouca ou nenhuma alteração. Descobrir como a integrar a computação em nuvem com as atuais arquiteturas e paradigmas de desenvolvimento será o grande desafio para este grupo.

2.3.4 Padrões dentro de uma empresa

Normas dentro de uma empresa serão determinadas por requisitos como interoperabilidade, rastreabilidade, segurança e gerenciamento, e será baseado em normas aplicáveis à relação entre empresas e a nuvem. A empresa vai interagir com uma combinação de nuvens privadas, públicas e híbridas.

2.4 Interfaces de Programação (APIs)

O principal mecanismo para a construção de soluções para computação em nuvem é a interface de programação (APIs) fornecida por provedores de computação em nuvem. Cloud APIs trabalham em quatro níveis diferentes e são classificados em cinco categorias básicas.

2.4.1 Níveis de APIs

Há quatro diferentes níveis de APIs. Cada nível requer que o desenvolvedor se concentre nas diferentes tarefas e estruturas de dados.

Nível 1 - The Wire: Neste nível, o programador escreve diretamente para o formato de requisição do protocolo. Se o serviço é baseado em REST, o desenvolvedor cria os cabeçalhos HTTP apropriados, cria o conteúdo para a requisição e abre uma conexão HTTP com o serviço. O serviço REST retorna os dados com um código HTTP de resposta para acompanhamento. Devido à

natureza simples de muitos serviços REST, é possível ser relativamente eficaz, escrevendo código neste este nível.

Se o serviço é baseado em SOAP, o desenvolvedor cria um envelope SOAP, acrescenta os cabeçalhos SOAP apropriados e completa o corpo do envelope SOAP com o dados necessários para a requisição. O serviço de SOAP responde com um envelope SOAP que contém os resultados do pedido. Trabalhando com serviços SOAP é necessário analisar o conteúdo XML dos envelopes, por essa razão, a maioria dos serviços SOAP são chamados com uma nível de API mais alto.

Nível 2 - Ferramentas específicas de um idioma: Desenvolvedores neste nível usam um kit de ferramentas específico para a linguagem de programação que irá trabalhar com requisições SOAP ou REST. Embora os desenvolvedores ainda estejam atentos ao formato e estrutura dos dados no nível do protocolo, muitos dos dados (manipulação de códigos de resposta e cálculo de assinaturas, por exemplo) são tratados pelo kit de ferramentas.

Nível 3 - Ferramentas específicas do serviço: o desenvolvedor usa um kit de ferramenta de alto nível para trabalhar com um determinado serviço. Trabalhando neste nível, o desenvolvedor é capaz de focar em objetos e processos de negócios. Um programador pode ser muito mais produtivo no que tange aos dados e processos que interessam a organização, em vez de se concentrar sobre a estrutura do protocolo.

Nível 4 – Kits de Ferramentas Independente de Provedor: Este é o mais alto nível de API. Um desenvolvedor trabalhando neste nível usa uma interface comum para a múltiplos provedores de computação em nuvem. Tal como acontece com o nível 3, o desenvolvedor concentra-se em objetos e processos de negócios. Mas ao contrário de nível 3, um desenvolvedor que trabalha no nível 4 não precisa se preocupar com qual provedor de serviço eles estão trabalhando. Um aplicativo escrito com um kit de ferramentas independente de provedor deve ser capaz de usar um provedor de nuvem diferente vendedor (consulte Alterando Provedores de Cloud a seguir) com alterações mínimas no código, se for necessário.

2.4.2 Categorias de APIs

Interfaces de programação podem ser divididas em cinco categorias:

Categoria 1 - Programação Ordinária: A interface de programação (API) usual em C#, PHP, Java, etc. Não há nada específico de nuvem nesta categoria.

Categoria 2 - Implantação: Interfaces de programação para implantar aplicativos na nuvem. Além de todas as tecnologias de empacotamento específico para a nuvem específica, inclui mecanismos tradicionais de empacotamento, tais como pacotes .Net e arquivos EAR/WAR.

Categoria 3 - Cloud Services: Interfaces de programação que trabalham com serviços da nuvem. Como discutido na seção anterior, APIs para serviços em nuvem podem ser específico de um provedor ou neutro. Essas APIs são divididas em subcategorias de serviços de armazenamento na nuvem, bases de dados na nuvem, filas de mensagens na nuvem e outros serviços em nuvem. Um

desenvolvedor que escreve código usando APIs de serviços para a nuvem está ciente de que eles estão usando a nuvem.

Categoria 4 – Gerenciamento de Imagem e Infra-estrutura: Interfaces de programação para gerenciar imagens de máquinas virtuais e os detalhes da infra-estrutura. APIs para facilitar a cópia de imagens e a execução de ações como iniciar, parar, reiniciar e apagar imagens. APIs para gerenciamento de infra-estrutura controlam detalhes, tais como firewalls, gerenciamento de nós, gerenciamento de rede e balanceamento de carga.

Categoria 5 – Interfaces internas: Interfaces de programação para se comunicar com as diferentes partes de uma infra-estrutura de nuvem. Estas são as APIs usadas quando se quer mudar de fornecedores para a camada de rmazenamento em sua arquitetura em nuvem.

2.4.3 Papéis de Desenvolvedores

Para discutir as exigências dos desenvolvedores, é útil apontar os diferentes papéis que eles podem assumir. Requisitos para APIs e serviços de cloud variam de um papel para o outro. Aqui estão os papéis que discutiremos neste documento, juntamente com as categorias de APIs que usam:

Client Application Developer: Escreve aplicativos cliente baseados em nuvem para os usuários finais. Estes desenvolvedores usam APIs para serviços na nuvem (categoria 3).

Application Developer: Escreve aplicações tradicionais que usam a nuvem. Estes desenvolvedores usam APIs ordinárias (categoria 1), bem como APIs de serviços de cloud (Categoria 3).

Deployers: Empacotam, implantam e mantém aplicativos que usam a nuvem. A gestão do ciclo de vida é uma preocupação aqui também. Estes desenvolvedores usam APIs para implantação, serviços de nuvem e gerenciamento de imagens (categorias 2, 3 e 4).

Administradores: Trabalham com aplicações em vários níveis, incluindo a implantação e gestão de infra-estrutura. Estes desenvolvedores usam APIs das categorias 2, 3 e 4.

Provedores da Nuvem: Trabalham com a infra-estrutura sob as suas ofertas de cloud. Estes desenvolvedores usam APIs da categoria 5.

3. Cenários de Casos de Uso

Os cenários de uso corporativo da nuvem são destinados a ilustrar os mais típicos casos de uso da nuvem e não pretendem ser uma lista exaustiva de realizações dentro de um ambiente de nuvem.

Os gráficos desta seção têm elementos comuns a toda. Se um determinado elemento não se aplica a um caso de uso particular, é acinzentado ou desenhado com um linha tracejada. Como exemplo, o caso de uso da nuvem privada não envolvem usuários finais nem a nuvem pública, portanto, apenas a Organização aparece em cores.

Usuário Final para a Nuvem

Aplicações rodando na nuvem e são acessadas pelos usuários finais

Empresa na Nuvem e Usuários Finais

Aplicações rodando na nuvem pública e são acessadas pelos usuários finais e empregados

Empresa para Nuvem Aplicações da nuvem integradas com as capacidades internas da TI das empresas

Empresa para Nuvem para Empresa

Aplicações rodando na nuvem pública e interage com aplicativos de parceiros (cadeia de suprimento)

Nuvem Privativa Uma nuvem hospedada em uma organização protegida pelos seus firewalls

Mudando de Provedor de Serviço da Nuvem

Uma organização trabalhando com um provedor de nuvem decide mudar de provedor ou trabalhar com serviços adicionais de um outro provedor

Nuvem híbrida Múltiplas nuvens trabalham juntas, coordenadas por um corretor de nuvem que federa os dados, aplicações, identidade dos usuários, segurança e outros detalhes