A arquitetura de referência da computação em nuvem do NIST define cinco atores principais: consumidor de nuvem, provedor de nuvem, auditor de nuvem, agente de nuvem e operadora de nuvem (Figura 1). Esses indivíduos principais têm papéis importantes no campo da computação em nuvem. Cada ator é uma entidade (uma pessoa ou uma organização) que participa de uma transação ou processo e/ou executa tarefas na computação em nuvem. Por exemplo, um consumidor da nuvem (Cloud Consumer) é um indivíduo ou organização que adquire e usa produtos e serviços na nuvem. O provedor de produtos e serviços é o provedor de nuvem (Cloud Provider). Devido às possíveis ofertas de serviços (Software, Plataforma ou Infra-estrutura) permitidas pelo provedor de nuvem, haverá uma mudança no nível de responsabilidades para alguns aspectos do escopo de controle, segurança e configuração. O Agente de Nuvem (Cloud Broker) atua como intermediário entre consumidor e provedor e ajudará os consumidores através da complexidade das ofertas de serviços em nuvem, bem como poderá criar serviços em nuvem de valor agregado. O auditor de nuvem (Cloud Auditor) fornece uma função inerente valiosa ao governo, conduzindo o monitoramento independente de desempenho e segurança dos serviços em nuvem. A operadora de nuvem (Cloud Carrier) é a organização que tem a responsabilidade de transferir os dados, um pouco semelhante ao distribuidor de energia da rede elétrica.

Figura 1 – Atores de Nuvem Computacional

Fonte: NIST-Cloud Computing Standards Roadmap – Special Publication 500-291, Version 2, Jul/2013

Consumidor de Nuvem (Cloud Consumer)

O consumidor da nuvem é o principal interessado que o serviço de computação em nuvem é criado para oferecer suporte. Um consumidor de nuvem representa uma pessoa ou organização que mantém um relacionamento comercial e usa o serviço de um provedor de nuvem. Um consumidor de nuvem procura o catálogo de serviços de um provedor de nuvem, solicita o serviço apropriado, configura contratos de serviço com o provedor de nuvem e usa o serviço. O consumidor da nuvem pode ser cobrado pelo serviço provisionado e precisa organizar os pagamentos de acordo. Dependendo dos serviços solicitados, as atividades e os cenários de uso podem ser diferentes entre os consumidores da nuvem, conforme mostrado na Tabela 1. Alguns exemplos de cenários de uso são listados na Figura 3.

Tabela 1 – Consumidor de Nuvem e Provedor de Nuvem

Modelos de serviço	Atividades do Consumidor	Atividades de Provedor
SaaS	Usa aplicativo / serviço para operações de processos de negócios.	Instala, gerencia, mantém e suporta o aplicativo de software em uma infraestrutura de nuvem.
PaaS	Desenvolve, testa, implementa e gerencia aplicativos hospedados em um sistema em nuvem.	Provisão e gerenciamento de infraestrutura e middleware em nuvem para os consumidores da plataforma; fornece ferramentas de desenvolvimento, implantação e administração para os consumidores da plataforma.
IaaS	Cria / instala, gerencia e monitora serviços para operações de infraestrutura de TI.	Provisiona e gerencia o processamento físico, o armazenamento, a rede e o ambiente de hospedagem e a infraestrutura de nuvem para os consumidores de IaaS.

Os aplicativos SaaS geralmente são implantados como serviços hospedados e acessados por meio de uma rede conectando consumidores e provedores de SaaS. Os consumidores de SaaS podem ser organizações que fornecem a seus membros acesso a aplicativos de software, usuários finais que usam diretamente aplicativos de software ou administradores de aplicativos de software que configuram aplicativos para usuários finais. Os consumidores de SaaS acessam e usam aplicativos sob demanda, e podem ser cobrados pelo número de consumidores ou pela quantidade de serviços consumidos. O último pode ser medido em termos do tempo em uso, da largura de banda da rede consumida ou da quantidade / duração dos dados armazenados.

Para PaaS, os consumidores de nuvem empregam as ferramentas e os recursos de execução fornecidos pelos provedores de nuvem com o objetivo de desenvolver, testar, implantar e gerenciar aplicativos hospedados em um sistema de nuvem. Os consumidores de PaaS podem ser desenvolvedores de aplicativos que projetam e implementam software de aplicativos, testadores de aplicativos que executam e testam aplicativos em vários sistemas em nuvem, implementadores de aplicativos que publicam aplicativos em um sistema em nuvem e administradores de aplicativos que configuram e monitoram o desempenho de aplicativos em uma plataforma. Os consumidores de PaaS podem ser cobrados pelo número de consumidores, pelo tipo de recursos consumidos pela plataforma ou pela duração do uso da plataforma.

Para IaaS, os consumidores são provisionados com os recursos para acessar computadores virtuais, armazenamento acessível pela rede, componentes de infraestrutura de rede e outros recursos fundamentais de computação, nos quais os consumidores podem implantar e executar softwares arbitrários. Os consumidores de IaaS podem ser desenvolvedores de sistemas, administradores de sistemas e gerentes de tecnologia da informação (TI) interessados em criar, instalar, gerenciar e monitorar serviços para operações de infraestrutura de TI. Os consumidores de IaaS são provisionados com os recursos para acessar esses recursos de computação e são cobrados pela quantidade de recursos consumidos.

Figura 3 – Exemplos de serviços disponíveis para Consumidores de Nuvem

Provedor de Nuvem (Cloud Provider)

Um provedor de nuvem pode ser uma pessoa, uma organização ou uma entidade responsável por disponibilizar um serviço para os consumidores em nuvem. Um provedor de nuvem cria os serviços de software / plataforma / infraestrutura solicitados, gerencia a infraestrutura técnica necessária para fornecer os serviços, provisiona os serviços nos níveis de serviço acordados e protege a segurança e a privacidade dos serviços. Conforme ilustrado na Figura 4 – Provedor de nuvem: Atividades principais, os provedores de nuvem realizam tarefas diferentes para o provisionamento dos vários modelos de serviço.

Figura 4 – Principais atividades do Provedor de Nuvem

Para SaaS, o provedor de nuvem implementa, configura, mantém e atualiza a operação dos aplicativos de software em uma infraestrutura de nuvem para que os serviços sejam provisionados nos níveis de serviço esperados para os consumidores da nuvem. O provedor de SaaS assume a maioria das responsabilidades de gerenciar e controlar os aplicativos e a infraestrutura, enquanto os consumidores da nuvem têm controle administrativo limitado dos aplicativos.

Para PaaS, o provedor de nuvem gerencia a infraestrutura em nuvem da plataforma e provisiona ferramentas e recursos de execução para os consumidores da plataforma desenvolverem, testarem, implementarem e administrarem aplicativos. Os consumidores têm controle sobre os aplicativos e possivelmente as configurações do ambiente de hospedagem, mas não podem acessar a infraestrutura subjacente à plataforma, incluindo rede, servidores, sistemas operacionais ou armazenamento.

Para IaaS, o provedor de nuvem provisiona o processamento físico, o armazenamento, a rede e outros recursos fundamentais de computação, além de gerenciar o ambiente de hospedagem e a infraestrutura de nuvem para os consumidores de IaaS. Os consumidores de nuvem implantam e executam aplicativos, têm mais controle sobre o ambiente de hospedagem e sistemas operacionais, mas não gerenciam ou controlam a infraestrutura de nuvem subjacente (por exemplo, servidores físicos, rede, armazenamento, hipervisores etc.).

As atividades dos provedores de nuvem podem ser discutidas em maiores detalhes a partir das perspectivas de: implantação de serviços, orquestração de serviços, gerenciamento de serviços em nuvem, segurança e privacidade.

Implantação de Serviços

Conforme identificado na definição de computação em nuvem do NIST, uma infraestrutura de nuvem pode ser operada em um dos seguintes modelos de implantação: nuvem pública, privada, comunitária ou híbrida.

Uma nuvem pública é aquela em que a infraestrutura de nuvem e os recursos de computação são disponibilizados para o público em geral por meio de uma rede pública. Uma nuvem pública é de propriedade de uma organização que vende serviços em nuvem e atende a um grupo diversificado de clientes.

Para nuvens privadas, a infraestrutura de nuvem é operada exclusivamente para uma única organização. Uma nuvem privada dá à organização acesso exclusivo e uso da infraestrutura e dos recursos computacionais. Ele pode ser gerenciado pela organização ou por terceiros e pode ser implementado na própria organização (por exemplo, nuvens privadas no local) ou terceirizado para uma empresa de hospedagem (ou seja, nuvens privadas terceirizadas).

Semelhante a nuvens privadas, uma nuvem de comunidade pode ser gerenciada pelas organizações ou por terceiros, e pode ser implementada no local do cliente (por exemplo, nuvem de comunidade no local) ou terceirizada para uma empresa de hospedagem (ou seja, nuvem de comunidade terceirizada). No entanto, uma nuvem da comunidade atende a um conjunto de organizações que têm considerações comuns de segurança, privacidade e conformidade, em vez de atender a uma única organização, como ocorre com uma nuvem privada.

Uma nuvem híbrida é uma composição de dois ou mais modelos de implantação na nuvem (privado, comunitário ou público) que permanecem como entidades exclusivas, mas são unidos por uma tecnologia proprietária ou padronizada que permite a portabilidade de dados e aplicativos. Conforme discutido nesta seção, as nuvens privadas e as nuvens da comunidade podem ser implementadas no local ou terceirizadas para terceiros. Portanto, cada nuvem constituinte de uma nuvem híbrida pode ser uma das cinco variantes.

Orquestração de Serviços

A orquestração de serviços refere-se à organização, coordenação e gerenciamento da infraestrutura em nuvem para fornecer os recursos de otimização dos serviços em nuvem, como uma maneira econômica de gerenciar recursos de TI, conforme determinado pelos requisitos estratégicos de negócios. A Figura 5 mostra os requisitos gerais e processos para provedores de nuvem para construir cada um dos três modelos de serviço.

Figura 5 – Serviço de Orquestração de Provedor de Nuvem

Uma estrutura de três camadas é identificada para um sistema de nuvem generalizado na Figura 5. A camada superior é a camada de serviço, na qual um provedor de nuvem define e provisiona cada um dos três modelos de serviço. É aqui que os consumidores da nuvem consomem serviços de nuvem por meio das respectivas interfaces de nuvem.

A camada intermediária é a camada de abstração e controle de recursos. Essa camada contém os componentes do sistema que um provedor de nuvem usa para fornecer e gerenciar o acesso aos recursos de computação física por meio da abstração de software. A camada normalmente inclui elementos de software, como hypervisors, máquinas virtuais, armazenamento de dados virtuais e outros componentes de abstração e gerenciamento de recursos necessários para garantir o uso eficiente, seguro e confiável. Embora a tecnologia de máquina virtual seja comumente usada nesta camada, outros meios de fornecer as abstrações de software necessárias não são impedidos. Essa camada fornece “prontidão de nuvem” com as cinco características definidas na definição NIST de computação em nuvem.

A camada mais baixa da estrutura é a camada de recursos físicos, que inclui todos os recursos de computação física. Essa camada inclui recursos de hardware, como computadores (CPU e memória), redes (roteadores, firewalls, switches, links de rede e interfaces), componentes de armazenamento (discos rígidos) e outros elementos da infraestrutura de computação física. Também inclui recursos de instalações, como aquecimento, ventilação e ar condicionado (HVAC), energia, comunicações e outros aspectos da planta física.

Note-se que, neste quadro, o posicionamento horizontal das camadas implica uma pilha em que a camada superior tem uma dependência na camada inferior. A camada de abstração e controle de recursos cria recursos de nuvem virtual sobre a camada de recursos físicos subjacente e oferece suporte à camada de serviço na qual as interfaces de serviços de nuvem são expostas. Os três modelos de serviço podem ser construídos um sobre o outro (ou seja, SaaS baseados em PaaS e PaaS baseados em IaaS) ou diretamente na infraestrutura de nuvem subjacente. Por exemplo, um aplicativo SaaS pode ser implementado e hospedado em máquinas virtuais a partir de IaaS ou diretamente sobre recursos de nuvem sem usar IaaS.

Gerenciamento de Serviços em Nuvem

O Cloud Service Management inclui todas as funções relacionadas a serviços que são necessárias para o gerenciamento e a operação desses serviços exigidos ou propostos a usuários em nuvem. Conforme ilustrado na Figura 6, o gerenciamento de serviços em nuvem pode ser descrito da perspectiva do suporte, provisionamento e configuração de negócios e da perspectiva de requisitos de portabilidade e interoperabilidade.

Figura 6 – Gerenciamento de Serviços pelo Provedor de Nuvem

Segurança

Em novembro de 2012, o NIST publicou um White Paper – “Challenging Security Requirements for U.S. Government Cloud Computing Adoption”. Este documento fornece uma visão geral dos desafios de segurança de alta prioridade percebidos pelas agências federais como impedimentos à adoção da computação em nuvem.

Segurança é uma função transversal que abrange todas as camadas da arquitetura de referência, envolvendo segurança de ponta a ponta que varia da segurança física à segurança do aplicativo e, em geral, a responsabilidade é compartilhada entre o provedor de nuvem e o consumidor de nuvem federal. Por exemplo, a proteção da camada de recursos físicos (Figura 5) requer segurança física que nega acesso não autorizado ao prédio, instalação, recurso ou informações armazenadas. Os provedores de nuvem devem garantir que a instalação que hospeda serviços de nuvem seja segura e que a equipe tenha verificações de antecedentes adequadas.

Quando dados ou aplicativos são movidos para uma nuvem, os Consumidores de Nuvem garantem que a oferta em nuvem atenda aos requisitos de segurança e imponha as regras de conformidade. Várias agências do governo dos EUA fornecem orientações sobre segurança de computadores e que o sistema de nuvem deve oferecer suporte às orientações mais atualizadas. Também é importante observar que os requisitos de segurança, conformidade e política são uma função da jurisdição legal do país no qual os serviços em nuvem são fornecidos e podem variar de país para país.

Privacidade

Os provedores de nuvem devem proteger a coleta, processamento, comunicação, uso e disposição seguros, adequados e consistentes de informações pessoais (Personal Information – PI) e informações de identificação pessoal (Personally Identifiable Information – PII) no sistema de nuvem. PII é a informação que pode ser usada para distinguir ou rastrear a identidade de um indivíduo, como nome, número de segurança social, registros biométricos, etc., sozinho ou quando combinado com outras informações pessoais ou de identificação vinculadas ou vinculáveis a um indivíduo específico, como data e local de nascimento, nome de solteira da mãe, etc. O CIO Council Privacy Committee identificou a privacidade e a proteção das PII coletadas como um dos imperativos chave dos negócios do governo federal. Embora a computação em nuvem forneça uma solução flexível para recursos, software e informações compartilhados, ela também representa desafios adicionais de privacidade para os consumidores que usam as nuvens.

A Estratégia do Governo Digital, emitida pelo CIO em 23 de maio de 2012, estabelece uma nova visão de como o governo deve se conectar e fornecer serviços ao povo americano, aproveitando o poder da tecnologia digital e capacitando cidadãos e força de trabalho federal para acessar com segurança informações, dados e serviços digitais do governo em qualquer lugar e a qualquer hora (Recomendações).O Federal CIO Council divulgou Recommendations for Standardized Implementation of Digital Privacy Controls (Recomendações), que discute três controles fundamentais de privacidade: Inventário PII, Avaliação de Impacto da Privacidade (PIA) e Aviso de Privacidade. As Recomendações são que as agências identifiquem e considerem todas as PII que possam ser coletadas ou expostas por meio de uma tecnologia digital específica, analisem os riscos de privacidade durante o ciclo de vida dos dados, conduzindo e atualizando uma PIA (conforme necessário) e notificando os indivíduos sobre quando e como suas PII serão coletadas, usadas, retidas e divulgadas.

Ao promover a meta de ação marcante da Estratégia do Governo Digital para abordar questões de privacidade digital, retenção de registros e segurança, a Administração Nacional de Arquivos e Registros (NARA) emitiu orientações de Gerenciamento Eletrônico de Registros (ERM) para conteúdo digital criado, coletado ou mantido por agências federais. A NARA também atua como parceira de gerenciamento da E-Government ERM Initiative, coordenando o desenvolvimento e a emissão de ferramentas ERM e padrões de informações eletrônicas para suportar a interoperabilidade dos sistemas de registro de agências federais e melhorar o atendimento ao cliente (por exemplo, acesso a registros digitais).

Agente de Nuvem (Cloud Broker)

A arquitetura de referência do NIST, SP 500-292, define um Agente de Nuvem (Cloud Broker) como uma entidade que gerencia o uso, o desempenho e a entrega de serviços em nuvem e negocia relacionamentos entre provedores de nuvem e consumidores em nuvem. À medida que a computação em nuvem evolui, a integração de serviços em nuvem pode se tornar muito complexa para os usuários da nuvem gerenciarem. Nesses casos, um Consumidor da Nuvem pode solicitar serviços de nuvem de um Agente de Nuvem (Cloud Broker) em vez de entrar em contato direto com um Provedor de Nuvem. Os Agentes de Nuvem (Cloud Brokers) fornecem um único ponto de entrada para gerenciar vários serviços em nuvem. O principal recurso que distingue um Agente de Nuvem (Cloud Broker) de um Provedor de Nuvem (Cloud Service Provider) é a capacidade de fornecer uma única interface consistente para vários provedores diferentes, seja para fins comerciais ou técnicos. Em geral, os Agentes de Nuvem fornecem serviços em três categorias:

Intermediação: Um Cloud Broker aprimora um determinado serviço, melhorando alguns recursos específicos e fornecendo serviços de valor agregado para os Consumidores em nuvem. A melhoria pode ser o gerenciamento de acesso a serviços em nuvem, gerenciamento de identidades, relatórios de desempenho, segurança aprimorada, etc.

Agregação: Um Cloud Broker combina e integra vários serviços em um ou mais novos serviços. O Broker fornece integração de dados e serviços e garante a movimentação segura de dados entre o Consumidor de Nuvem e vários Provedores de Nuvem.

Arbitragem: A arbitragem de serviço é semelhante à agregação de serviços, exceto que os serviços combinados / consolidados não são fixos. Arbitragem de serviço significa que um Broker tem a flexibilidade de escolher serviços de múltiplos provedores de serviços.

Um Cloud Broker pode fornecer:

Serviços de apoio comercial e de relacionamento (intermediação de negócios); e,
Serviço de suporte técnico (agregação, arbitragem e intermediação técnica), com foco principal no tratamento de problemas de interoperabilidade entre vários Provedores.

SLA em Nuvem Computacional

Para o International Journal of Engineering and Management Research no documento “Service Level Agreement Comparison in Cloud Computing”, 2014, os SLAs são usados há muitos anos em organizações e departamentos de TI para identificar os requisitos de suporte para clientes internos e externos de serviços de TI, definindo as expectativas do consumidor e do provedor de serviços de TI. É comum que os provedores de serviços de TI ofereçam serviços em diferentes níveis de qualidade com base no custo pago por um serviço. Um SLA é valioso para ajudar todas as partes a entender as compensações inerentes entre custo, cronograma e qualidade, porque seu relacionamento é declarado explicitamente. Como com qualquer tipo de contrato, a existência de um SLA não pode garantir que todas as promessas serão mantidas, mas define o que acontecerá se essas promessas não forem cumpridas.

Qualidades que podem ser definidas em um SLA

Em teoria, é possível especificar qualquer qualidade em um SLA, desde que todas as partes entendam como medir ou verificar sua conquista. Vimos duas categorias de qualidades que podem ser especificadas nos SLAs: mensuráveis e imensuráveis.

Qualidades mensuráveis – podem ser medidas automaticamente usando métricas; por exemplo, a porcentagem de tempo que um sistema está disponível.

Precisão – está relacionada à taxa de erro do serviço. É possível especificar o número médio de erros em um determinado período de tempo;
Disponibilidade – preocupa-se com o tempo médio de falha dos serviços, e os SLAs geralmente descrevem as consequências associadas a essas falhas. A disponibilidade é normalmente medida pela probabilidade de o sistema estar operacional quando necessário. É possível especificar:
- a resposta do sistema quando ocorre uma falha;
- o tempo que leva para reconhecer um defeito;
- quanto tempo demora para recuperar de uma falha;
- se o tratamento de erros é usado para mascarar falhas;
- o tempo de inatividade necessário para implementar os upgrades (pode ser zero);
- a porcentagem de tempo que o sistema está disponível fora do tempo de manutenção planejado.
Capacidade é o número de solicitações simultâneas que podem ser manipuladas pelo serviço em um determinado período de tempo. É possível especificar o número máximo de solicitações simultâneas que podem ser tratadas por um serviço em um bloco de tempo definido;
Custo está relacionado ao custo de cada solicitação de serviço. É possível especificar:
- o custo por pedido;
- o custo baseado no tamanho dos dados;
- diferenças de custo relacionadas aos tempos de pico de uso.
Latência está relacionada ao tempo máximo entre a chegada de uma solicitação e a conclusão dessa solicitação;
Tempo relacionado ao provisionamento (por exemplo, o tempo que leva para a conta de um novo cliente ficar operacional)
Mensagens confiáveis estão relacionadas à garantia de entrega de mensagens. É possível especificar:
- como a entrega de mensagens é garantida (por exemplo, exatamente uma vez, no máximo uma vez)
- se o serviço suporta a entrega de mensagens na ordem correta
Escalabilidade está relacionada à capacidade do serviço de aumentar o número de operações bem-sucedidas concluídas em um determinado período de tempo. É possível especificar o número máximo de tais operações.

Qualidades imensuráveis – são aquelas que não podem ser medidas automaticamente de um determinado ponto de vista; por exemplo, determinar o custo de mudar um serviço (modificabilidade) é difícil de automatizar [Dobson 2005].

A interoperabilidade diz respeito à capacidade de uma coleção de entidades comunicantes compartilhar informações específicas e operá-las de acordo com uma semântica operacional acordada [Brownsword 2004]. É possível especificar os padrões suportados pelo serviço e verificá-los em tempo de execução. Desafios significativos ainda precisam ser superados para alcançar a interoperabilidade semântica em tempo de execução.
Modificabilidade – nesse contexto, está relacionada à frequência com que um serviço pode mudar. É possível especificar com que frequência o serviço de:
- mudanças na interface;
- Mudanças na implementação.
A segurança preocupa-se com a capacidade do sistema de resistir ao uso não autorizado, ao mesmo tempo em que fornece aos usuários legítimos acesso ao serviço. A segurança também é caracterizada como um sistema que oferece não-repúdio, confidencialidade, integridade, garantia e auditoria. É possível especificar os métodos para:
- autenticando serviços ou usuários;
- autorizar serviços ou usuários;
- criptografando os dados.

Áreas Cobertas por SLAs

A hospedagem na nuvem e os SLAs podem fornecer proteção em vários níveis diferentes nos sistemas operacionais de infraestrutura e nos aplicativos. Abaixo estão alguns dos níveis de cobertura importantes que podem ser cobertos por um SLA de nuvem.

SLA no nível da instalação
Em uma estrutura de contrato de Colocation tradicional, o provedor de colocation normalmente oferecerá um SLA cobrindo as instalações do data center necessárias para suportar o hardware de propriedade do cliente. Estes incluem itens como energia, geradores no local, refrigeração, etc. Este tipo de cobertura é geralmente considerado o mínimo no mercado de hospedagem. Um provedor de serviços em nuvem (CSP) geralmente escolhe uma instalação de colocation que mantém um SLA em nível de instalações.

SLA no nível da plataforma
O próximo nível de proteção em um contrato de hospedagem de nuvem pública geralmente abrange o servidor físico, a plataforma de virtualização e o hardware de rede pertencentes ao provedor de serviços de nuvem e usados pelo cliente de hospedagem na nuvem. Normalmente, o servidor físico e o software de virtualização são cobertos por um SLA de plataforma. A rede na nuvem (rede entre os Cloud Servers) pode ser coberta por um SLA de disponibilidade separado.

SLA no nível do sistema operacional
O sistema operacional (SO) é a próxima área de cobertura potencial para um SLA de hospedagem na nuvem. Os provedores de serviços em nuvem que oferecem um SLA no nível do sistema operacional geralmente fornecem algum grau de serviços gerenciados a um cliente. Esse serviço adicional permite que o fornecedor garanta que o sistema operacional seja mantido adequadamente, de modo que esteja disponível de forma consistente e, em geral, tenha algumas ressalvas

SLA no nível do aplicativo
Esse tipo de SLA fornece proteção contra falhas em nível de aplicativo até e incluindo o aplicativo personalizado em execução no hardware do provedor. Esse tipo de SLA é extremamente raro no mercado de hospedagem na nuvem. De acordo com esse modelo, o provedor de hospedagem na nuvem está garantindo a disponibilidade e o desempenho do software de seus clientes, o que é um compromisso difícil de cumprir.

Comparação de SLAs de importantes Provedores

Fracas Garantias de Tempo de Atividade para Computação – Os provedores de nuvem considerados oferecem apenas poucas garantias de tempo de atividade para a execução de VMs e não especificam explicitamente a garantia de tempo de atividade por instância. O Amazon EC2 e o Terremark vCloud Express oferecem apenas garantia de tempo de atividade por data por data, em vez de por instância. O Rackspace Cloud Servers e o Storm on Demand implicitamente fornecem garantia de SLA por instância. O Azure Compute fornece garantias de tempo de atividade como um agregado sobre todas as instâncias em vez de por instância. O Azure Compute fornece garantias de tempo de atividade como um agregado sobre todas as instâncias em vez de por instância.
Nenhuma garantia de desempenho para computação – Nenhum dos provedores de nuvem considerados oferece garantias de desempenho para instâncias de computação. Como consequência, um cliente pode apenas esperar que suas instâncias recebam os recursos provisionados de CPU, memória, rede e disco. A falta de garantias de desempenho pode ser inaceitável em nuvens corporativas.
O cliente deve detectar a violação de SLA – Os provedores de nuvem considerados deixam o ônus de detectar violação de SLA no cliente, o que pode ser inaceitável para a empresa. A Verizon, um provedor corporativo de conectividade com a Internet, detecta violações de SLA por seu serviço de Internet dedicado.
Crédito de serviço – Os créditos de serviço para violação de SLA oferecidos pelo Amazon EC2, S3 e Terremark vCloud Express só podem ser aplicados a pagamentos futuros dos respectivos serviços de nuvem. O Amazon EC2 e S3, o Azure Compute and Storage e o Terremark vCloud Express reembolsam parcialmente o custo total dos serviços afetados, enquanto os Rackspace Cloud Servers e o Storm on Demand podem fornecer até 100% de reembolso. O Storm on Demand é único, pois oferece reembolso de 1000% do custo das instâncias afetadas. No entanto, é relativamente um novo provedor de IaaS.
Período do Relatório de Violação de SLA – Os SLAs de computação e armazenamento do Azure e Storm on Demand estipulam que um cliente deve relatar o incidente de violação de SLA dentro de cinco dias da ocorrência do incidente, que é mais rigoroso que o relatório de violação de 30 dias e o período de solicitação de reembolso oferecido por outros provedores de nuvem. O Azure permite que um cliente registre uma reivindicação 30 dias após relatar o incidente.
Jargão SLA – Um SLA é um documento legal e é o único remédio para um cliente por qualquer violação de serviço. A falta de padronização nos SLAs e o uso de SLAs como um veículo potencial de marketing dificulta a comparação dos SLAs de diferentes provedores de nuvem. Como exemplo, o Storm on Demand e a Rackspace garantem que sua rede de data center, HVAC e energia sejam 100% do tempo, mas qualificam-na com manutenção programada. Da mesma forma, a garantia de desempenho do Armazenamento do Azure não inclui o tempo necessário para transferir os dados para dentro e para fora do datacenter. Para um designer de aplicativo em nuvem, é importante prestar atenção a esses detalhes.
SLAs de armazenamento: desempenho vs. conclusão da solicitação – Para os SLAs de armazenamento, apenas o Azure fornece uma garantia de desempenho por transação, ou seja, o tempo de processamento de uma solicitação (que exclui o download de dados ou o tempo de upload). O Amazon S3 e o Rackspace Cloud Files não oferecem garantias de desempenho e, em vez disso, fornecem apenas uma garantia de conclusão de solicitação.
SLAs oferecidos por provedores de Internet de negócios – Descrevemos brevemente o SLA Dedicado da Internet oferecido pela Verizon [20] e como ele se compara aos SLAs oferecidos pelos provedores de nuvem. O SLA de Internet da Verizon compreende nove garantias de serviço, como disponibilidade, latência, latência de pacote de rede, tempo de resposta de ingresso para negação de serviço e tempo para reparo.

O Futuro do SLA para Nuvem

Nesta seção, os autores registram como um provedor de nuvem pode definir SLAs para serviços de nuvem no futuro:

Garantia de serviço: os provedores de nuvem considerados fornecem apenas garantias de tempo de atividade para serviços de IaaS. Os provedores de nuvem também podem querer oferecer outras garantias, como desempenho, segurança e tempo de resolução de ticket. Fornecer uma garantia de desempenho se torna necessário se os provedores de nuvem se sobrescrevem nos recursos dos servidores físicos para diminuir o número de servidores físicos usados e aumentar sua utilização. A assinatura excessiva dos servidores físicos implica que o desempenho de máquinas virtuais executadas em servidores físicos pode se tornar uma preocupação. Além disso, a colocação de uma máquina virtual com outras cargas de trabalho também pode afetar o desempenho da CPU, do disco, da rede e da memória de uma VM. Além disso, as empresas que compram serviços baseados em nuvem podem exigir um nível mínimo de garantia de desempenho. Portanto, pode ser necessário que um provedor de nuvem ofereça SLAs baseados em desempenho para seus serviços de computação de IaaS com um modelo de preços em camadas e cobra um prêmio pelo desempenho garantido.
Período de tempo de garantia de serviço e granularidade: O período de tempo de garantia de serviço e a granularidade determinam o rigor da garantia de serviço subjacente. Uma garantia de serviço é rigorosa se a métrica for baseada em desempenho para um recurso refinado durante um período de tempo pequeno, por ex. 99,9% das transações de memória em um intervalo de cinco minutos devem ser concluídas em um micro segundo. Essa garantia rigorosa pode ser reduzida agregando a garantia de serviço a um grupo de recursos (por exemplo, a porcentagem de tempo de atividade agregado de todas as instâncias deve ser maior que 99,5%). Os provedores podem usar uma combinação de granularidade de garantia de serviço e período de garantia de serviço para avaliar seus serviços adequadamente. Para cargas de trabalho empresariais e de missão crítica, um provedor de nuvem pode não ter escolha a não ser fornecer garantias de serviço mais refinadas.
Detecção de violação de serviço e crédito: Nenhum dos provedores considerados detecta automaticamente a violação de SLA e deixa o ônus de fornecer a prova de violação ao cliente. Esse aspecto pode não ser aceitável para clientes com cargas de trabalho críticas ou corporativas. Um provedor de nuvem pode diferenciar o preço de sua oferta se detectar e creditar automaticamente o cliente por violação de SLA. No entanto, o custo de ferramentas para medir, registrar e auditar automaticamente as métricas de SLA pode ser uma preocupação.
SLAs baseados em resultados: os provedores de nuvem considerados neste documento oferecem serviços de IaaS e PaaS. Usando esses serviços, um cliente pode implantar seus próprios aplicativos na nuvem. No entanto, no futuro, os provedores de nuvem podem oferecer serviços baseados em resultados no topo da nuvem, onde um provedor oferece uma solução completa para um cliente que usa a nuvem. Para serviços baseados em resultados, um provedor de nuvem precisa definir os SLAs para os resultados prometidos e como esses SLAs são mapeados para a infraestrutura de IaaS e PaaS subjacente que ele fornece.
Padronização de SLAs: A falta de padronização nos SLAs da nuvem dificulta a comparação efetiva entre os clientes. À medida que os serviços em nuvem amadurecem e a visão da computação em utilitários é percebida, é provável que a padronização do SLA seja o centro das atenções. A representação estruturada de SLAs (por exemplo, em XML) pode ser necessária para SLAs padronizados.

Portabilidade e Interoperabilidade em Nuvem Computacional

O Cloud Standards Customer Council em seu documento “Interoperability and Portability for Cloud Computing: A Guide Version 2.0”, 2017, https://www.omg.org/cloud/deliverables/CSCC-Interoperability-and-Portability-for-Cloud-Computing-A-Guide.pdf, define que, no contexto de Nuvem Computacional, Portabilidade trata da capacidade de um cliente mover e adaptar adequadamente seus aplicativos e dados entre seus próprios sistemas e serviços em nuvem e entre serviços em nuvem de diferentes provedores de serviços em nuvem e modelos de implementação de nuvem potencialmente diferentes. O principal problema causado pela falta de portabilidade é que pode ser necessário um esforço considerável para transformar o aplicativo ou dados de sua forma no sistema de origem para o formato requerido pelo sistema de destino. A portabilidade é diferenciada em duas áreas separadas: portabilidade de dados em nuvem e portabilidade de aplicativos em nuvem:

A portabilidade de dados em nuvem é a capacidade de transferir facilmente dados de um serviço de nuvem para outro serviço de nuvem ou entre um sistema de cliente de serviço de nuvem e um serviço de nuvem, em um formato eletrônico comumente usado. É a facilidade de mover os dados que são a essência aqui. Isso pode ser obtido pelo serviço de origem que fornece os dados exatamente no formato aceito pelo serviço de destino. Mas mesmo que os formatos não combinem, a transformação entre eles pode ser simples e direta de se conseguir com ferramentas comumente disponíveis. O primeiro aspecto da portabilidade de dados entre serviços em nuvem é que deve haver um recurso para recuperar dados do cliente do serviço de nuvem de origem e também uma capacidade de importar dados do cliente para o serviço de nuvem de destino. Isso é comumente feito através da existência de alguma API (ou interface da web) associada ao serviço de nuvem – pode ser uma API genérica, como uma das formas de FTP, por exemplo, ou pode ser uma API específica exclusiva da nuvem serviço. É importante observar que a API usada para o serviço de origem pode não ser igual à API usada para o serviço de destino e que diferentes ferramentas podem ser necessárias em cada caso.

A portabilidade de aplicativos em nuvem é a capacidade de transferir facilmente um aplicativo ou componentes de aplicativo de um serviço de nuvem para um serviço de nuvem comparável ou de um sistema do cliente de serviço de nuvem para um serviço de nuvem. A chave é a facilidade de mover os componentes do aplicativo ou aplicativo. O aplicativo pode exigir a recompilação ou religação para o serviço de nuvem de destino, mas não deve ser necessário fazer alterações significativas no código do aplicativo.

Por outro lado, a Interoperabilidade pode ser definida como uma medida do grau em que diversos sistemas ou componentes podem trabalhar juntos com sucesso. Mais formalmente, IEEE e ISO definem interoperabilidade como a capacidade de dois ou mais sistemas ou aplicativos trocarem informações e usarem mutuamente as informações que foram trocadas. No contexto da computação em nuvem, a interoperabilidade deve ser vista como a capacidade de serviços de nuvem pública, serviços de nuvem privada e outros sistemas diversos dentro da empresa para entender interfaces de aplicativos e serviços uns dos outros, configuração, formas de autenticação e autorização, formatos de dados, etc, a fim de trabalhar uns com os outros.

Na computação em nuvem, os componentes que interagem mais significativos são aqueles que pertencem ao cliente do serviço de nuvem, que interagem com os componentes do provedor de serviços em nuvem. A natureza da interação é uma conexão de rede usando uma interface ou API prescrita. Geralmente, existem várias interfaces separadas, cada uma lidando com um aspecto diferente do serviço de nuvem. Por exemplo, existem as interfaces funcionais do próprio serviço em nuvem, interfaces de autenticação e autorização, interfaces para administração dos serviços em nuvem e interfaces comerciais para faturamento e faturamento. O ideal de interoperabilidade é que as interfaces sejam padronizadas de alguma forma – ou seja, são interoperáveis - para que o cliente possa mudar para outro provedor de serviços de nuvem com impacto mínimo nos componentes do cliente.

É importante reconhecer que existem diferentes aspectos de interoperabilidade que podem ser descritos como facetas separadas. Veja mais em ISO/IEC 19941:2017 Information technology – Cloud computing – Interoperability and portability.

Desafios de interoperabilidade e portabilidade

Para interoperabilidade, há muitos desafios associados à computação em nuvem. Em geral, as interfaces e APIs dos serviços de nuvem não são padronizadas e os diferentes provedores usam APIs diferentes para os serviços de nuvem comparáveis.

É provável que o maior nível de interoperabilidade seja encontrado para os serviços de nuvem IaaS, em que a funcionalidade é geralmente equivalente e há várias interfaces padrão – algumas formalmente padronizadas, como a CDMI, outras sendo, de fato, padrões no mercado. Os serviços em nuvem de PaaS têm níveis mais baixos de interoperabilidade. Existem poucos padrões de interface para a funcionalidade PaaS, embora existam algumas plataformas de código aberto, como Cloud Foundry, que estão se tornando populares no mercado e onde diferentes provedores de serviços em nuvem usam a mesma plataforma de código aberto, suas interfaces são idênticas ou equivalentes.

São aplicativos SaaS que apresentam o maior desafio de interoperabilidade atualmente. Existem poucas APIs padrão para aplicativos SaaS – mesmo a mudança de um aplicativo SaaS para outro aplicativo SaaS com funcionalidade comparável geralmente envolve uma alteração na interface. Há um impacto resultante em ambos os usuários finais do serviço de nuvem para qualquer interface de usuário e também em quaisquer aplicativos ou sistemas pertencentes ao cliente de serviço de nuvem que usam APIs oferecidas pelo aplicativo SaaS.

Para portabilidade de aplicativos, os maiores desafios são para aplicativos criados para plataformas PaaS. Para os serviços de nuvem IaaS, há na prática uma série de padrões que permitem a portabilidade de aplicativos, como o OVF e o fornecimento de sistemas operacionais comumente usados, como o Linux. As plataformas de PaaS podem variar muito entre diferentes provedores – o ambiente de aplicativos pode diferir substancialmente, incluindo a maneira como os serviços de plataforma são oferecidos ao código do aplicativo e também em qual conjunto de serviços de plataforma está disponível. Por exemplo, para ser escalável e elástica, uma PaaS pode impor uma maneira específica de persistir e gerenciar dados que podem não ser suportados por outras plataformas de PaaS. As diferenças entre as plataformas de PaaS alternativas podem exigir uma reengenharia extensiva do código do cliente quando o código é movido entre essas plataformas. Duas tendências no mercado parecem oferecer uma promessa para aliviar a situação. Uma delas é a crescente adoção de plataformas PaaS de código aberto comuns, como Cloud Foundry, enquanto outra é o surgimento de tecnologias de conteinerização que permitem a subdivisão e a implantação independente de partes de um aplicativo, como Docker e Kubernetes.

Elementos envolvidos na interoperabilidade e portabilidade de serviços em nuvem

Primeiro vale a pena ter um modelo de uma aplicação, particularmente quando se considera a portabilidade da aplicação, como mostra a Figura 1.

O aplicativo consiste em um conjunto de artefatos que inclui conjuntos de instruções, metadados e conjuntos de dados diretamente associados ao aplicativo. O aplicativo tem um conjunto de dependências que devem ser fornecidas para que funcione corretamente. As dependências podem incluir tempos de execução, serviços de dados (como bancos de dados), gerenciamento de acesso, identidade e criptografia. Também pode incluir recursos de resiliência (instâncias redundantes com failover, por exemplo), funções do sistema operacional, recursos de virtualização e rede. Pode também incluir um conjunto mais amplo de serviços.

A Figura 2 ilustra alguns dos principais elementos associados ao uso de um serviço de nuvem e dos componentes, interfaces e dados associados a esse uso.

Neste diagrama, o Aplicativo nos sistemas do cliente e no serviço de nuvem representa o aplicativo do cliente no caso de serviços em nuvem IaaS e PaaS, mas no caso de um serviço SaaS, o aplicativo normalmente pertenceria ao provedor e seria gerenciado por o provedor.

Os Artefatos e Dependências representam as partes constituintes do aplicativo (conforme mostrado na Figura 1).

Os dados do cliente representam os dados do cliente do serviço de nuvem, que podem ser mantidos como registros em um banco de dados ou mantidos como objetos de dados em arquivos ou em um armazenamento de dados. Dados derivados representam dados que são criados e armazenados como resultado do uso do serviço pelo cliente, como registros de log ou informações de configuração.

A Figura 2 mostra três interfaces principais entre os sistemas do cliente e o serviço de nuvem: as interfaces funcionais, as interfaces de administração e as interfaces de negócios.

As interfaces funcionais estão associadas aos principais recursos funcionais oferecidos pelo serviço em nuvem.

As interfaces de administração envolvem recursos para administrar o serviço de nuvem e incluem recursos, como monitorar o serviço e gerenciar seu comportamento, incluindo aspectos de segurança, como identidades de usuário, tokens de autenticação e autorizações.

As interfaces de negócios envolvem recursos relacionados aos aspectos de negócios do serviço de nuvem, incluindo informações de assinatura, faturamento e faturamento.

É importante entender que cada uma dessas interfaces pode ter vários formulários. Por exemplo, os principais recursos do aplicativo podem ser apresentados nas interfaces funcionais para usuários finais como um aplicativo de navegador da Web ou como um aplicativo móvel. No entanto, os mesmos recursos também podem ser disponibilizados como uma API para consumo por aplicativos personalizados gravados ou comprados pelo cliente e executados nos sistemas do cliente. No ambiente de serviço em nuvem, as APIs geralmente são definidas por uma interface programática baseada em um protocolo comum, como REST / JSON ou SOAP.

Os aspectos de interoperabilidade de um serviço de nuvem estão relacionados principalmente às três interfaces entre os sistemas do cliente e o serviço de nuvem – como os usuários e aplicativos no ambiente do cliente interagem com as interfaces funcionais, administrativas e de negócios oferecidas pelo serviço de nuvem. É importante entender que a interoperabilidade das três interfaces pode ser independente uma da outra e que a interoperabilidade de uma interface não garante a interoperabilidade das outras.

A Portabilidade de Aplicativos está relacionada à capacidade de mover o código do aplicativo para ou do serviço em nuvem. Isso normalmente se aplica apenas aos serviços de IaaS e PaaS, pois, no caso de um serviço SaaS, o código do aplicativo pertence ao provedor de serviços de nuvem e não pode ser transferido para outro local pelo cliente. Um dos fatores mais importantes para a portabilidade do aplicativo é que o ambiente de destino precisa suportar os artefatos do aplicativo e as dependências do aplicativo.

A Portabilidade de Dados está relacionada à capacidade de mover dados para dentro e fora do ambiente de serviço em nuvem. Normalmente, são os dados do cliente do serviço de nuvem que são a preocupação da portabilidade de dados. No entanto, alguns dos dados derivados do serviço de nuvem também podem ser motivo de preocupação em relação a alguns serviços de nuvem e não devem ser negligenciados. Para dados de clientes de serviços em nuvem, a portabilidade de dados é geralmente mais preocupante para serviços em nuvem SaaS, pois para esses serviços, o conteúdo, esquemas de dados e formato de armazenamento estão sob o controle do provedor de serviços em nuvem e o cliente precisará entender como os dados pode ser importado para o serviço e exportado do serviço. Para serviços IaaS e PaaS, normalmente, o cliente do serviço de nuvem controla o conteúdo e os esquemas dos dados, com o serviço oferecendo recursos básicos de armazenamento, como um sistema de arquivos ou armazenamento de objetos.

Contêineres e Infraestrutura de Contêineres

Para a portabilidade de aplicativos, os contêineres e a infraestrutura de contêineres relacionados estão se tornando tecnologias-chave.

Para contêineres, a plataforma de contêineres Docker e a iniciativa Open Containers, estreitamente associada, oferecem uma abordagem padronizada para a implantação de código de aplicativo e pilhas de software associadas. Cada vez mais, os provedores de serviços em nuvem oferecem suporte a software implantado em contêineres do Docker, tornando o processo de portar aplicativos entre ambientes muito mais simples e direto. Isso se aplica principalmente aos serviços de nuvem IaaS e PaaS.

Também é o caso que o processo de implantação e gerenciamento dos conjuntos de contêineres que são necessários para qualquer aplicativo está em processo de padronização por meio da aceitação comum do conjunto de ferramentas de orquestração de contêineres de código aberto do Kubernetes.

No entanto, é importante reconhecer que os contêineres e seus conjuntos de ferramentas associados não são uma panaceia e têm alguns problemas próprios em relação à portabilidade e à interoperabilidade. A implantação de contêineres em diferentes ambientes de provedores de serviços em nuvem pode ter alguns problemas de interoperabilidade causados por diferenças nas interfaces disponibilizadas. A portabilidade pode ser um desafio, tanto em termos de níveis de software usados por diferentes provedores de serviços em nuvem, mas também devido a diferentes maneiras pelas quais o provedor de serviços em nuvem disponibiliza serviços para atender a várias dependências de aplicativos. Talvez não seja possível portar um aplicativo em contêiner sem fazer algumas alterações.

Automação

As tecnologias que facilitam a portabilidade de aplicativos e dados são as ferramentas de automação usadas atualmente para lidar com as operações do cliente relacionadas ao uso de serviços em nuvem. A automação é um elemento-chave da própria computação em nuvem e isso se aplica igualmente ao cliente do serviço de nuvem, como ao provedor de serviços em nuvem. Basicamente, os processos manuais são muito ineficientes e propensos a erros e, como resultado, as soluções de automação cresceram junto com a computação em nuvem para permitir o uso eficiente e preciso dos serviços em nuvem.

Um elemento-chave das ferramentas de automação é que as ferramentas normalmente possuem adaptadores que permitem que eles trabalhem com uma variedade de serviços em nuvem de diferentes provedores de serviços em nuvem. Em outras palavras, a ferramenta de automação permite a interoperabilidade com os serviços de nuvem de destino e também pode lidar com os problemas de portabilidade para dados e para aplicativos em que o ambiente no serviço de nuvem de destino varia. Assim, os clientes de serviços em nuvem podem facilitar as preocupações de interoperabilidade, utilizando ferramentas de automação que são capazes de interagir com uma variedade de serviços em nuvem e provedores de serviços em nuvem.

Padrões para Nuvem Computacional

Existem padrões disponíveis para suporte a muitas das funções e requisitos da computação em nuvem. Apesar de muitos desses padrões terem sido desenvolvidos no suporte a tecnologias de computação em épocas “pré-nuvem” (para serviços da Web e Internet), eles também suportam as funções e requisitos da computação em nuvem. Outros padrões estão sendo desenvolvidos para osuporte específico a funções e requisitos de computação em nuvem, como virtualização.

Para avaliar o estado de padronização no suporte à computação em nuvem, o NIST Cloud Computing Standards Roadmap Working Group compilou um Inventário de Padrões Relevantes para Computação em Nuvem http://collaborate.nist.gov/twiki-cloud-computing/bin/view/CloudComputing/StandardsInventory.

O Grupo de trabalho de taxonomia do NIST mapeou vários padrões associados aos serviços de nuvem computacional, apresentando-os esquematicamente na Figura 12 como um diagrama integrado de componentes de sistema, organização e processo. A taxonomia de computação em nuvem produzida pelo mesmo grupo de trabalho forneceu classificações adicionais para os aspectos de segurança, interoperabilidade e portabilidade da computação em nuvem.

Figura 12 – O Diagrama Combinado de Referências Conceituais

As seções a seguir mapearão os padrões de nuvem especificamente relevantes e capturarão seu status de maturidade padrão em formato de tabela. Alguns padrões podem se aplicar a mais de uma categoria da taxonomia da nuvem e, portanto, podem ser listados mais de uma vez.