03 - TRABALHANDO

Prévia do material em texto

DEFINIÇÃO
Apresentação das considerações sobre a aplicabilidade dos modelos de serviços em nuvem, dos modelos de custos/precificação, das métricas de Qualidade de Serviço (QoS) e do Acordo de Nível de Serviço (SLA) como fatores considerados no trabalho com a cloud computing.
PROPÓSITO
Compreender as considerações do uso do modelo de serviços na arquitetura de computação em nuvem, as métricas de Qualidade de Serviço (QoS), o Acordo de Nível de Serviços (SLA) e a precificação dos serviços, para a atuação geral na área de redes e a atuação especializada em serviços de cloud computing.
OBJETIVOS
MÓDULO 1 - Analisar as considerações para o modelo de nuvem
MÓDULO 2 - Identificar os modelos de custo e precificação
MÓDULO 3 - Descrever as métricas de Qualidade de Serviço e o Acordo de Nível de Serviço – ANS (Service Level Agreement – SLA)
INTRODUÇÃO
A computação em nuvem (do inglês cloud computing) é um conceito que faz referência à tecnologia que disponibiliza recursos sob demanda pela internet.
O National Institute of Standards and Technology (NIST) define a computação em nuvem como um modelo que possibilita acesso, de modo conveniente e sob demanda, a um conjunto de recursos computacionais configuráveis (por exemplo, redes, servidores, armazenamento, aplicações e serviços) que podem ser rapidamente adquiridos e liberados com mínimo esforço gerencial ou interação com o provedor de serviços.
O modelo de nuvem é composto por cinco características essenciais:
Autoatendimento sob demanda;
Amplo acesso à rede;
Acesso a um pool de recursos;
Elasticidade dinâmica;
Serviço mensurável.
O modelo de nuvem é composto por três modelos de serviço:
Infraestrutura como um Serviço (IaaS);
Plataforma como um Serviço (PaaS);
Software como um Serviço (SaaS).
O modelo de nuvem é composto por quatro modelos de implantação:
Nuvem privada;
Nuvem comunitária;
Nuvem pública;
Nuvem híbrida. (VAULX; SIMMON; BOHN, 2018).
Estudaremos os modelos de serviço e os modelos de implantação da computação em nuvem, além dos fundamentos de precificação dos serviços e das métricas de Qualidade de Serviço (Quality of Service – QoS) e de Acordo de Nível de Serviço (Service Level Agreement – SLA).
MÓDULO 1
Analisar as considerações para o modelo de nuvem
CONCEITOS
Os modelos de serviço em nuvem (ou modelos de entrega em nuvem) definem como esse tipo de serviço é oferecido aos clientes. Trata-se de uma combinação de recursos de Tecnologia da Informação (TI) oferecida pelo provedor de nuvem conforme a necessidade do cliente.
Vamos conhecer a seguir os modelos de entrega de serviço da computação em nuvem.
RECURSOS DE TECNOLOGIA DA INFORMAÇÃO (TI)
Recurso de TI é um artefato físico ou virtual, que pode ser baseado em software, como um servidor virtual ou um programa de software específico, ou baseado em hardware, como um servidor físico ou um dispositivo de rede.
INFRAESTRUTURA COMO UM SERVIÇO (INFRASTRUCTURE-AS-A-SERVICE – IAAS)
Representa um ambiente de TI independente, composto por recursos de TI centrados na infraestrutura, acessados e gerenciados a partir de interfaces e ferramentas baseadas em serviços em nuvem.
O ambiente pode incluir hardware, rede, conectividade, sistemas operacionais e outros recursos de TI. Diferentemente dos ambientes tradicionais de hospedagem ou de terceirização, em IaaS, os recursos de TI em geral são virtualizados e “embrulhados” em pacotes, visando simplificar o escalonamento antecipado do tempo de execução e a personalização da infraestrutura.
O objetivo geral desse ambiente é fornecer um alto nível de controle e responsabilidade sobre sua configuração e sua utilização, tendo recursos de TI geralmente entregues sem possuir uma pré-configuração, transferindo a responsabilidade administrativa para o consumidor de serviço em nuvem.
Um recurso central e primário de TI em um ambiente típico de IaaS é o servidor virtual. Este é alugado especificando requisitos de hardware do servidor, como capacidade do processador, memória e espaço de armazenamento local, como mostrado a seguir.
PLATAFORMA COMO UM SERVIÇO (PLATFORM-AS-A-SERVICE – PAAS)
Representa um ambiente predefinido “pronto para uso”, com um conjunto de produtos e ferramentas pré-empacotados, usados para suportar todo o ciclo de vida de entrega de aplicativos personalizados, geralmente composto por recursos de TI já implantados e configurados.
Um consumidor de nuvem pode querer usar e investir em um ambiente PaaS devido à:
Intenção de estender ambientes locais para a nuvem, com propósitos de escalabilidade e economia;
Substituição completa de um ambiente local;
Intenção de se tornar um provedor de nuvem e implantar os próprios serviços para serem disponibilizados a consumidores externos.
O consumidor é poupado da carga administrativa de configuração e manutenção dos recursos de TI de infraestrutura simples fornecidos pelo modelo IaaS.
O consumidor recebe um nível mais baixo de controle sobre os recursos de TI subjacentes que hospedam e provisionam a plataforma, conforme mostrado a seguir. Os produtos PaaS estão disponíveis em diferentes pilhas de desenvolvimento, como o Google App Engine, que oferece um ambiente baseado em Java e Python. O ponto de interrogação indica que o consumidor está separado dos detalhes de implementação da plataforma.
SOFTWARE COMO UM SERVIÇO (SOFTWARE-AS-A-SERVICE – SAAS)
Representa um aplicativo (software) oferecido como um serviço compartilhado. Esse modelo de entrega pode ser usado para disponibilizar, em larga escala, um serviço de nuvem reutilizável para vários consumidores. Os recursos podem ser utilizados para diferentes propósitos, como visto mais à frente.
O consumidor recebe um controle administrativo bastante restrito sobre os recursos. Também é possível encontrar uma situação em que a organização que atua como consumidor em um ambiente PaaS pode criar um serviço em nuvem que decide implantar, no mesmo ambiente, um modelo SaaS.
O consumidor recebe o acesso ao contrato de serviço em nuvem,
mas não recebe qualquer recurso de TI ou detalhes de implementação dos recursos.
Para entendermos melhor, vamos observar a seguir uma comparação dos níveis de controle entre os modelos básicos.
Quadro 1 – Comparação dos níveis de controle do modelo de entrega na nuvem.
Podemos observar que os três modelos de serviço da computação em nuvem possibilitam a combinação entre eles, gerando um amplo portfólio de recursos para o consumidor.
O consumidor pode utilizar distintos modelos de serviços em nuvem. Ou seja, é possível utilizar os serviços da Amazon como provedor de IaaS e o Azure como provedor PaaS.
APLICABILIDADE DOS MODELOS DE NUVEM
Para a tomada de decisão sobre qual modelo de nuvem é mais conveniente às necessidades do consumidor, vamos analisar alguns fatores:
FATORES TÉCNICOS
A organização provedora e consumidores podem desempenhar diferentes papeis no modelo de serviço em nuvem. Quanto menos serviços em nuvem a empresa cliente consumir, maior o grau de competência da equipe de TI da empresa, ou seja, menos serviços consumidos pela empresa na nuvem, maior será a área de TI da empresa cliente.
Ao observar o quadro 1, encontramos a disponibilização dos limites de papeis desempenhados pelo provedor e pelo consumidor. No caso do modelo SaaS, o provedor da nuvem desempenha um número maior de papéis e a empresa cliente, o consumidor, tem menos responsabilidade perante os serviços, permitindo que a área de TI seja menor.
E isso também significa que, no modelo IaaS, a empresa cliente terá que se preocupar com o gerenciamento de mais serviços de TI. Se ela não tiver boas habilidades de TI nas áreas de Computação Distribuída, Desenvolvimento Web e Arquiteturas Orientadas a Serviços (SOAs), talvez seja melhor se concentrar nos modelos de serviço SaaS e PaaS ou encontrar um parceiro que crie serviços em nuvem no IaaS.
Um exemplo de competência que pode pesar na escolha do modelo de serviço é o desenvolvimento de middleware, uma camada na qual o consumidor gerencia caso opte pelo modelo IaaS, mas que será gerenciado pelo provedor no caso da escolhapelo PaaS.
FATORES FINANCEIROS
O foco dessa categoria é mais direcionado para o Custo Total de Propriedade (Total Cost of Ownership – TCO) do que para o cálculo do preço por hora ou por mês de um serviço em nuvem. O TCO é uma estimativa que auxilia na determinação dos custos diretos e indiretos de um produto ou sistema. Por exemplo, o investimento em um novo sistema de computador tem um preço de compra inicial. Os custos adicionais geralmente incluem novo software, instalação, custos de transição, treinamento de funcionários, custos de segurança, planejamento de recuperação de desastres, suporte contínuo e atualizações futuras. Usando esses custos como guia, a organização compara as vantagens e as desvantagens da compra do sistema de computador, assim como os benefícios gerais para a empresa a longo prazo.
FATORES ESTRATÉGICOS
As estratégias de negócios contribuem para a decisão sobre qual modelo de serviço em nuvem selecionar. Exemplo: Se a velocidade para o lançamento de uma solução no mercado for grande, existe mais probabilidade de a escolha de SaaS (ou PaaS), em que a infraestrutura será abstraída do usuário final. Se o controle é a estratégia mais importante, é mais provável que uma solução de IaaS seja escolhida, fazendo a organização ter mais controle sobre a infraestrutura subjacente. As empresas muitas vezes acabam escolhendo um fornecedor de nuvem com base apenas em preferências técnicas, não levando em consideração as estratégias de negócios que estão impulsionando as iniciativas de nuvem.
FATORES ORGANIZACIONAIS
Uma avaliação da organização pode desempenhar um papel no modelo de serviço em nuvem que escolher: Quanto menor for a pilha de nuvens da empresa, maior o grau de competência da equipe. Voltando ao quadro 1, a pilha de nuvens do modelo SaaS, por exemplo, é menor do que a pilha de nuvens do modelo IaaS, significando que, no último modelo, a empresa terá que se preocupar com o gerenciamento de mais camadas da pilha. Se ela não tiver boas habilidades de TI nas áreas de Computação Distribuída, Desenvolvimento Web e Arquiteturas Orientadas a Serviços (SOAs), talvez seja melhor se concentrar nos modelos de serviço SaaS e PaaS ou encontrar um parceiro que crie serviços em nuvem no IaaS. Um exemplo de competência que pode pesar na escolha do modelo de serviço é o desenvolvimento de middleware, uma camada na qual o consumidor gerencia caso opte pelo modelo IaaS, mas que será gerenciado pelo provedor no caso da escolha pelo PaaS.
FATORES DE RISCOS
A gerência deve definir o grau de risco que uma empresa está disposta a assumir, conforme os objetivos do negócio; quantificar e qualificar os riscos identificados, como por quanto tempo a solução pode ficar inativa e quanto uma violação de segurança pode ser prejudicial.
Ao conceituar e analisar cada modelo de serviço em nuvem, podemos identificar quando é indicado usar o IaaS, o PaaS ou o SaaS. Vamos acompanhar os seguintes estudos de caso enquadrados por modelo de serviço.
QUANDO USAR O SAAS
Entre os três modelos de serviço em nuvem, o SaaS foi o primeiro a amadurecer. Nesse modelo, os provedores têm total controle sobre a infraestrutura, o desempenho, a segurança, a escalabilidade e a privacidade, por exemplo, geralmente não oferecendo o mesmo nível de flexibilidade que uma empresa teria se desenvolvesse o próprio aplicativo.
Em geral, são oferecidas duas formas de uso dos recursos aos consumidores:
1. Interface de usuário baseada na web, geralmente acessível em qualquer dispositivo conectado à internet;
2. APIs, de modo que os consumidores de serviços possam integrar recursos aos aplicativos existentes ou com outras soluções SaaS.
	Exemplo
	Suponha que a empresa BROKER é do ramo de administração de imóveis, não possuindo experiência na área de TI. Ela deseja contratar uma provedora de serviços em nuvem SaaS para oferecer um aplicativo on-line de venda e de aluguel de imóveis.
Vamos verificar o que ela terá à disposição:
O modelo SaaS possui APIs refinadas e genéricas, projetadas para serem incorporadas como parte de soluções maiores. A empresa fornece um serviço similar ao Google Maps, com uma API que possibilita a incorporação de informações e de imagens de mapeamento por outros sites e aplicativos da web.
Alguns dos serviços são fornecidos de graça, e como são patrocinados por terceiros, eles executam uma forma de coleta de informações de segundo plano. A leitura do contrato do provedor de nuvem esclarece sobre qualquer atividade de fundo que o serviço possa executar.
O consumidor é isento das responsabilidades de implementar e administrar os ambientes de hospedagem subjacentes. Opções de personalização estão disponíveis, porém, são limitadas ao controle de uso em tempo de execução das instâncias de serviço em nuvem geradas especificamente pelo consumidor e para ele.
O consumidor da nuvem terá à sua disposição, por exemplo:
Gerenciamento de configurações relacionadas à segurança; opções selecionadas de disponibilidade e confiabilidade; custos de uso; contas de usuário, perfis e autorização de acesso;
Seleção e monitoramento de SLAs;
Definição de opções e limitações de escalabilidade manual e automatizada.
QUANDO USAR O PAAS
Nas primeiras soluções PaaS, os consumidores usavam uma linguagem de programação específica e executavam, na infraestrutura do provedor de serviços, o que não impunha restrições de flexibilidade para organizações com muitas arquiteturas, pilhas de tecnologia e necessidades de aplicativos diferentes.
A nova geração de provedores de serviços PaaS oferece suporte a várias pilhas, escolha da infraestrutura em que o software PaaS será implantado, suporte a vários idiomas, como Ruby, PHP, Python e Node.js.
Algumas tarefas de administração do sistema, como correções de segurança mensais, criação de log, monitoramento, dimensionamento e failover (tolerância a falhas) são oferecidas pelo provedor, para que os desenvolvedores possam se concentrar na criação de aplicativos prontos para a nuvem.
Como a plataforma é compartilhada por muitos clientes, muitos provedores de PaaS limitam a largura de banda de um usuário individual como proteção contra colisões e congestionamentos na rede, otimizam a utilização da CPU para reduzir a quantidade de geração de calor no data center e economizar energia ou limitam a atividade de banco de dados dos clientes. Os desenvolvedores devem entender as limitações da plataforma selecionada e projetar de acordo com elas.
Um típico IDE PaaS pode oferecer ampla variedade de ferramentas e recursos de programação, por exemplo, bibliotecas de software, bibliotecas de classes, estruturas, APIs. Os desenvolvedores podem criar, testar e executar o código do aplicativo na nuvem ou localmente enquanto usam o IDE para emular o ambiente de implantação na nuvem. Os aplicativos compilados ou concluídos são enviados para a nuvem e implantados nos ambientes prontos.
IDE
Integrated Development Environment (IDE) pode ser traduzido como Ambiente de Desenvolvimento Integrado e representa um software para ajudar no desenvolvimento de aplicações.
	EXEMPLO
	Suponha que a startup de comércio eletrônico START possui funcionários com boas experiências na área de TI. Ela deseja agora contratar os serviços de uma provedora de serviços em nuvem PaaS para oferecer uma plataforma de vendas on-line. Apesar de os ambientes PaaS fornecerem menos controle administrativo que os ambientes IaaS, eles ainda oferecem uma variedade significativa de recursos de gerenciamento. A START terá à disposição:
Seleção de plataformas de software e estruturas de desenvolvimento para ambientes prontos; tipos de instância, front-end ou back-end; dispositivos de armazenamento em nuvem para uso em ambientes prontos; monitoramento de métricas de SLA relacionadas ao PaaS;
Controle do ciclo de vida dos aplicativos desenvolvidos por PaaS (implantação, inicialização, encerramento, reinicialização e liberação); controle de versão de aplicativos e módulos implantados; recursos de escalabilidade (cotas de uso, limites de instância ativa, configuraçãoe implantação dos mecanismos automatizados de ouvinte de escala e balanceador de carga);
Gerenciamento de credenciais para desenvolvedores e administradores de recursos da nuvem; configurações gerais de segurança, como portas de rede acessíveis; custos de uso e recursos de TI;
Configuração de mecanismos relacionados à disponibilidade e à confiabilidade;
Estabelecimento e exibição de contratos de fornecimento de serviços (condições da conta, termos de uso).
QUANDO USAR O IAAS
O PaaS pode reduzir os custos, reduzindo a quantidade de trabalho e de recursos necessários para criar e implantar aplicativos, mas pode ficar caro quando os dados excedem os terabytes e a largura de banda, ou a demanda da CPU excede os níveis normais.
À medida que o tempo avança, o custo do IaaS pode se tornar tão baixo que os provedores de PaaS podem ter que seguir o exemplo para competir. Por exemplo, quando a Amazon reduz os custos de seu Elastic Compute Cloud (EC2), outros provedores de IaaS podem ter que fazer o mesmo.
O IaaS também foi adotado sobre o PaaS devido às interrupções. Quando um provedor PaaS ou SaaS sofre uma interrupção, deve-se esperar a correção do problema para que os serviços fiquem novamente on-line.
Os servidores virtuais são acessados no nível do sistema operacional por aplicativos de terminal remoto, como: Cliente de Área de Trabalho Remota (para ambientes Windows) e Cliente SSH (para ambientes Mac e Linux).
Um dispositivo de armazenamento em nuvem estará conectado diretamente aos servidores virtuais. Porém existe a opção de estar conectado a um recurso de TI hospedado fora da nuvem, por exemplo, um dispositivo local por meio de WAN ou VPN.
Os seguintes formatos para manipulação e transmissão de dados de armazenamento em nuvem são comumente usados:
SISTEMA DE ARQUIVOS EM REDE
A manipulação de arquivos é semelhante à maneira como as pastas são organizadas nos sistemas operacionais (NFS, CIFS);
DISPOSITIVOS DE REDE DE ÁREA DE ARMAZENAMENTO
O acesso é transmitido pela rede (iSCSI, Fibre Channel);
RECURSOS BASEADOS NA WEB
Baseado em objetos, a interface não é integrada ao sistema operacional, cujos arquivos são representados logicamente e podem ser acessados por meio de uma interface baseada na web (como o Amazon S3).
	EXEMPLO
	A APPOWER é uma grande empresa do ramo de comércio eletrônico que está avaliando a contratação de um provedor de serviços em nuvem IaaS, pois está desenvolvendo um serviço com requisitos de desempenho ou escalabilidade, que exigirá dos desenvolvedores o gerenciamento da memória, a configuração dos servidores de banco de dados e de aplicativos para maximizar a taxa de transferência, manipular o sistema operacional etc.
A APPOWER terá muito controle sobre como, e em que medida, os recursos de TI são provisionados, por exemplo:
Controles de escalabilidade (escala automatizada, balanceamento de carga); ciclo de vida (desligamento, reinicialização, inicialização de dispositivos virtuais); ambiente de rede virtual e regras de acesso à rede (firewalls, perímetros de rede lógica);
Gerenciamento da conexão de dispositivos de armazenamento em nuvem; pré-alocação de recursos de TI (reserva de recursos); credenciais e senhas para administradores de recursos em nuvem; credenciais para grupos de segurança; configurações de segurança; armazenamento de imagem do servidor virtual personalizado (importação, exportação, backup);
Seleção de opções de alta disponibilidade (failover, cluster de recursos de TI); monitoramento de métricas SLA; configurações básicas de software; instâncias de recursos, entre várias configurações e opções disponíveis relacionadas a hardware (recursos de processamento, RAM, armazenamento); regiões geográficas nas quais os recursos de TI baseados em nuvem devem ser hospedados;
Estabelecimento e exibição de contratos de fornecimento de serviços (condições da conta, termos de uso);
Rastreamento e gerenciamento de custos.
MÓDULO 2
Identificar os modelos de custo e precificação
CONCEITOS
Existe uma variedade cada vez maior de opções de serviços baseados em nuvem, exigindo a comparação entre as ofertas dos provedores de serviços em nuvem. É necessário ter requisitos claros, criar Acordos de Nível de Serviço (SLAs) que os reflitam e mensurá-los para validar a entrega dos serviços com o desempenho e as soluções.
Mensurar os dados sobre recursos, como qualidade de serviço, disponibilidade e confiabilidade, possibilita oferecer ao cliente as ferramentas e a oportunidade de escolher e compreender melhor o serviço que está sendo entregue.
Segundo o NIST (2018), uma métrica fornece o conhecimento sobre uma propriedade da nuvem pela sua definição (por exemplo, expressão, unidade, regras) e os valores resultantes da medição da propriedade. Ela também fornece as informações necessárias para reproduzir e verificar medições e resultados de medições.
ATENÇÃO
As métricas são importantes para apoiar a tomada de decisão na seleção dos serviços em nuvem, a definição e o cumprimento dos contratos de serviço, monitorando os serviços em nuvem, a contabilidade e a auditoria.
MÉTRICAS PARA AVALIAR A COMPUTAÇÃO EM NUVEM
Quanto à computação em nuvem, existem muitos sistemas e subsistemas a serem considerados, incluindo armazenamento, banco de dados e camadas de aplicativos. Ou seja, para garantir o serviço em nuvem de qualidade e bem-sucedido, é necessária a observação prévia das métricas operacionais, como dados de desempenho e transação, rastreamento de leitura/gravação do armazenamento, análises preditivas e custos, entre outras.
Vamos analisar a seguir algumas métricas de custos consideradas na computação em nuvem.
MÉTRICA DE CUSTO COMERCIAL
O objetivo da métrica de custo comercial é avaliar os custos estimados e o valor comercial dos leasings de recursos de TI baseados em nuvem quando comparados à compra de recursos de TI locais. Para isso, consideram-se os seguintes custos:
CUSTOS INICIAIS Investimentos iniciais feitos pelas organizações para financiar os recursos de TI que pretendem usar. Incluem custos para obter os recursos de TI e despesas necessárias para implantá-los e administrá-los. 
CUSTOS CONTÍNUOS Despesas exigidas por uma organização para executar e manter os recursos de TI que ela usa.
Veja, a seguir, alguns exemplos de escala de custos, para os custos iniciais e contínuos:
Quadro 2 – Exemplos de escala de custos, para os custos iniciais e contínuos.
Além dos custos apresentados, outras métricas de custos comerciais podem ser levadas em consideração,
como mostrado a seguir.
Quadro 3 – Exemplos de custos adicionais.
	Custo de capital
	Custo decorrente da captação de recursos necessários. Ex.: É mais caro obter um investimento inicial de R$ 150.000, do que obter esse valor por um período de três anos.
	Custos irrecuperáveis
	Recursos de TI que a empresa já tinha, ou seja, já foram pagos, e estão operacionais. Ao comparar custos iniciais com custos irrecuperáveis significativos, pode ser mais difícil justificar o leasing de recursos de TI baseados em nuvem como alternativa.
	Custos de integração
	Medem o esforço para tornar os recursos de TI compatíveis e interoperáveis em um ambiente externo, como uma nova plataforma em nuvem.
	Custos bloqueados (Locked-in)
	Nem sempre é possível fazer a portabilidade de um provedor para outro a longo prazo. Alguns consumidores de serviços em nuvem podem se tornar dependentes das características proprietárias de um ambiente em nuvem, existindo assim custos bloqueados associados a esse tipo de mudança, que podem diminuir ainda mais o valor comercial de longo prazo dos leasings de recursos de TI baseados em nuvem.
MÉTRICAS DE CUSTO DE USO DA NUVEM
As métricas de custo de uso podem ser agrupadas da seguinte forma:
USO DA REDE
Geralmente é calculado medindo-se separadamente o tráfego de uso da rede de entrada e o tráfego de uso da rede de saída em relação aos serviços em nuvem ou outros recursos de TI.
USO DO SERVIDOR
As métricas de uso do servidor em geral são usadas para definir o valor a ser pago por umaquantidade de servidores e ambientes utilizados em ambientes IaaS e PaaS. Podemos utilizar, por exemplo, a alocação de instâncias de máquina virtual sob demanda.
DISPOSITIVO DE ARMAZENAMENTO EM NUVEM
O armazenamento em nuvem geralmente é cobrado pela quantidade de espaço alocado em um período predefinido. As taxas de alocação de armazenamento sob demanda geralmente são baseadas em incrementos de tempo curtos (como uma base horária). Já a métrica de dados de E/S (Entrada e Saída) transferidos mede a quantidade de dados de entrada e saída transferidos.
USO DE SERVIÇO EM NUVEM
O uso do serviço de nuvem em ambientes SaaS geralmente é medido usando as métricas: Duração da assinatura de uso do serviço de nuvem (ex.: Contratar um serviço SaaS por 1 ano); usuários registrados com acesso legítimo (ex.: Existe um valor para até 50 usuários – após esse limite, cobra-se por usuário individual); e número de transações atendidas pelo serviço de nuvem (ex.: Transações de cadastros de usuários).
A seguir, são mostrados alguns exemplos de métricas de custo de uso da nuvem. Em “Medidas de utilização / Métricas”, vemos alguns exemplos de medidas e de métricas que podem ser utilizadas por um determinado tipo de serviço em nuvem.
Em “Medição” vemos as unidades de medidas ou as maneiras de medir cada uma das métricas relacionadas. Em “Frequência” vemos a periodicidade das medições realizadas ao longo do tempo.
Em “Modelo de serviço” vemos o modelo básico de serviço em nuvem (IaaS, PaaS, SaaS) ao qual a métrica pode ser adequada. Em “Exemplo” há uma exemplificação de aplicação prática, ou como a métrica pode ser comercialmente explorada por um provedor de serviços em nuvem.
Quadro 4 – Exemplos de métricas de custo de uso da nuvem.
GERENCIAMENTO DE CUSTOS
Normalmente o gerenciamento de custos é centralizado nas fases do ciclo de vida dos serviços em nuvem, definidas a seguir e mostradas adiante.
DESIGN E DESENVOLVIMENTO DE SERVIÇO EM NUVEM
A organização que fornece o serviço define os modelos de preços e de custo mais conservadores;
IMPLANTAÇÃO DE SERVIÇO EM NUVEM
Determinação e implementação da arquitetura de back-end para medir o uso e a coleta de dados relacionados à cobrança;
CONTRATO DE SERVIÇO EM NUVEM
Negociações entre o consumidor e o provedor, para chegar a um acordo mútuo sobre as taxas com base nas métricas de custo de uso;
OFERTA DE SERVIÇO EM NUVEM
Oferta dos modelos de preços do serviço, usando modelos de custo e quaisquer opções de personalização disponíveis;
PROVISIONAMENTO DE SERVIÇO EM NUVEM
O uso do serviço e os limites de criação de instância podem ser impostos pelo provedor de nuvem ou definidos pelo consumidor;
OPERAÇÃO DO SERVIÇO EM NUVEM
O uso ativo do serviço produz dados métricos de custo de uso;
DESATIVAÇÃO DO SERVIÇO DE NUVEM
Quando o serviço é desativado temporária ou permanentemente.
PRECIFICAÇÃO
A computação em nuvem impõe um novo desafio financeiro às empresas de tecnologia: Como precificar corretamente os modelos de contratos e como conseguir o capital necessário para financiar os equipamentos e a infraestrutura?
Os modelos de precificação da computação em nuvem incluem os seguintes fatores de influência:
Concorrência no mercado e requisitos regulatórios;
Custos indiretos no design, desenvolvimento, implantação e operação de serviços em nuvem e outros recursos de TI;
Oportunidades para diminuir despesas pelo compartilhamento de recursos de TI e otimização de data center.
O cálculo pode ser influenciado por variáveis como:
Custos que dependem do tipo de alocação de recursos de TI (ex.: Sob demanda versus reservada);
Taxas fixas ou variáveis, conforme o tipo de alocação de recursos (cota fixa de uso, ou uso dinâmico);
Descontos à medida que a escalabilidade dos recursos de TI aumenta progressivamente;
Personalização de custo e preço.
Para entendermos melhor, vamos analisar o seguinte estudo de caso.
ESTUDO DE CASO
Uma empresa faz uma análise de Custo Total de Propriedade (TCO) para decidir se migrará um aplicativo herdado para um ambiente PaaS implantado em um cluster de servidor virtual composto por 2 servidores virtuais em execução em 1 servidor físico dedicado, que possui 200 GB de banco de dados. Os valores já são os melhores, escolhidos após várias consultas e análises de preços com fornecedores, como mostrados a seguir.
Quadro 5 – Estudo de caso.
	Custos iniciais no local (on-premises):
Licenciamento: O servidor físico que hospeda o aplicativo custa R$15.000,00; o software necessário para executar os 2 servidores virtuais custa R$30.000,00;
Mão de obra: R$3.000,00;
O armazenamento não foi avaliado como parte do plano.
Custos totais: R$15.000,00 + R$30.000,00 + R$3.000,00 = R$48.000,00.
Custos contínuos no local (on-premises):
Taxas ambientais: R$2.000,00;
Manutenção de hardware: R$300,00.
Custos totais:R$2.000,00 + R$300,00 = R$2.300,00.
Custos iniciais baseados na nuvem:
Se os servidores forem alugados de um provedor de nuvem, não haverá custo inicial de hardware ou software;
Mão de obra para solucionar problemas de interoperabilidade e configuração do aplicativo: R$2.000,00.
Custos contínuos baseados na nuvem:
Instância do servidor: R$2,00/hora por servidor virtual. Para 2 servidores virtuais: 2 x (R$2,00 x 720 horas) = R$2.880,00.
Servidor e armazenamento de banco de dados: R$2,50/GB por mês x 200 GB = R$500,00.
Rede: Consumo de saída R$0,15/GB e um volume mensal de 500 GB = R$75,00.
Mão de obra: R$1.000,00 por mês.
Os custos contínuos totais são: R$2.880,00 + R$500,00 + R$75,00 + R$1.000,00 = R$4.455,00.
Podemos elaborar uma comparação, conforme a seguir:
Tabela 1 – Tabela comparativa.
	 
	Custos iniciais
	Custos contínuos
	No local (on-premisses)
	R$ 48.000,00
	R$ 2.300,00
	Baseados na nuvem
	R$ 2.000,00
	R$ 4.455,00
Pelos dados apresentados, podemos avaliar o custo entre uma solução on-premise e uma solução na nuvem. Concluímos que a solução na nuvem é mais viável economicamente. Sendo assim, a empresa pode optar pela migração para a computação em nuvem.
MÓDULO 3
Descrever as métricas de Qualidade de Serviço e o Acordo de Nível de Serviço – ANS (Service Level Agreement – SLA)
CONCEITOS
Em relação à prestação de serviços, o Acordo de Nível de Serviço – ANS (Service Level Agreement – SLA) é essencial para alinhar os detalhes do trabalho entre aquele que o solicita e aquele que o disponibiliza. Com o SLA é possível estabelecer os requisitos referentes ao contrato, tanto em relação à entrega de um serviço adequado quanto para estabelecer as expectativas sobre o resultado.
Um SLA é um contrato entre o provedor de serviços de nuvem (Cloud Service Provider – CSP) e o consumidor de serviços de nuvem (Cloud Service Consumer – CSC), o qual define a expectativa do nível de serviço que o CSP promete fornecer ao CSC.
Conforme mostrado, O SLA é basicamente um documento que atua como um contrato entre o provedor e o cliente, ou seja, entre os assinantes. Ele é padronizado pela norma NBR ISO-IEC 20000-1, da Associação Brasileira de Normas Técnicas (ABNT), ou seja, segue um modelo único em todas as aplicações, especialmente para ser aprovado.
Os SLAs constituem uma peça fundamental para serviços baseados em nuvem, pois os CSPs assumem responsabilidades em nome do consumidor. Os consumidores precisam garantir que o provedor forneça serviços confiáveis, seguros, escalonáveis e disponíveis.
Podem existir vários provedores envolvidos na composição de um serviço em nuvem, sendo possível que uma empresa crie uma solução composta por serviços de cada modelo de serviço em nuvem.
Basicamente, o contrato é responsável em determinar os direitos e os deveres de cada parte envolvida, mensurando prazos, metas, indicadores e formas de suporte técnico.
Uma empresa pode usar, por exemplo, um IaaS CSP para fornecer a camada de infraestrutura, um provedor de PaaS para fornecer a camada de pilha de aplicativos e um conjunto de soluções de SaaS e APIs de terceiros para várias funções do utilitário.
Cada um dos CSPs que formam a plataforma da empresa possui os próprios SLAs. Aorganização deve considerar todos esses SLAs antes de se comprometer com contratos de serviço com os clientes.
O SLA preza por alguns objetivos. Entre eles, a simplificação e a clareza do serviço que será prestado, além da redução de conflitos e da eliminação de expectativas não compatíveis com o que será de fato realizado.
Para começarmos a definir um SLA precisamos determinar quais são as expectativas dos clientes, que podem ser influenciadas pelos seguintes fatores:
CRITICIDADE DOS SERVIÇOS PRESTADOS
Enquanto serviços de mídia social (p. ex. Instagram) não são de missão crítica, qualquer serviço que envolva transações financeiras, como banco on-line e comércio eletrônico, exigirá SLAs muito altos. Níveis de serviço ruins para esses tipos de negócios implicam impactos substanciais.
TIPO DE INTERAÇÃO ENTRE O PROVEDOR E O CONSUMIDOR
Se uma empresa, por exemplo, estiver construindo uma solução na Rackspace, ela deve entender os SLAs e elaborar uma estratégia no caso de a Rackspace apresentar uma interrupção. Se o serviço em nuvem for crítico, a arquitetura precisa levar em conta um plano de tolerância a falha se o provedor falhar. Outro exemplo, os SLAs podem conduzir à decisão de investir na construção de redundância total de todas as camadas da arquitetura em várias zonas de disponibilidade da Amazon Web Services – AWS (cada região é uma área geográfica separada; cada região tem vários locais isolados conhecidos como zonas de disponibilidade). (AMAZON, 2020)
CONSUMIDORES OU CLIENTES CORPORATIVOS
Muitos serviços ofertados aos consumidores para serviços não essenciais à missão não oferecem SLAs sobre desempenho, tempo de atividade e confiabilidade. Os termos dos serviços protegem fortemente o provedor no sentido de oferecer os serviços “como estão” para os consumidores. No máximo, os provedores se comprometem a aplicar esforços para proteger os dados e manter a privacidade. Os consumidores devem aceitar esses termos para participar.
CLIENTES PAGANTES OU NÃO PAGANTES
Quanto mais forte for o SLA, mais caro será gerenciá-lo e mantê-lo. O provedor de serviços em nuvem deseja gastar o menor esforço para permitir que o consumidor teste o serviço. Depois que o cliente passa para uma camada paga, aplicam-se níveis mais altos de serviço. Os clientes que usam serviços gratuitos em geral recebem SLAs mais baixos do que os clientes que usam soluções pagas. Muitas vezes os serviços “freemium” (para usuários não pagantes) são executados em máquinas de menor custo e com funcionalidades limitadas.
SETOR REGULAMENTADO OU SETOR NÃO REGULAMENTADO
Os SLAs para clientes que necessitam de serviços em um setor regulamentado devem ser mais fortes do que aqueles em um setor não regulamentado. Setores como assistência médica, bancos, seguros, governo, varejo e outros exigem SLAs fortes sobre desempenho, tempo de atividade, segurança, privacidade, conformidade e muito mais.
ANÔNIMO OU IDENTIFICÁVEL PESSOALMENTE
Alguns serviços em nuvem podem coletar informações de identificação pessoal, como dados biométricos, números de documentos pessoais, informações de cartão de crédito e outros dados fortemente regulamentados, que exigem altos níveis de SLAs de segurança e privacidade.
Uma empresa pode ser um consumidor de nuvem e um provedor de nuvem.
EXEMPLO
A empresa XPTO é um consumidor do provedor ACME, que oferece serviços em nuvem IaaS. Além das camadas de serviços de Aplicações e Dados, a XPTO tem acesso às camadas mais baixas da pilha de serviços, incluindo rotinas em tempo de execução, Middleware e SO. A XPTO então criou uma solução SaaS e se tornou um provedor em nuvem oferecendo acesso somente às camadas de Aplicações e Dados.
IMPORTÂNCIA DO SLA
O SLA é um documento essencial para o cliente e para o provedor, pois garante a entrega de um serviço satisfatório para ambas partes.
Olhando pelo prisma do cliente, o SLA pode ser comparado a uma espécie de comprovante de tudo o que foi especificado sobre o serviço contratado. Se algo ocorrer fora do planejado, é possível usar o SLA para contestar e chegar a um acordo.
Para os provedores de serviço, o SLA é essencial para organizar as tarefas e as etapas do processo de atendimento, e assim tudo acaba ocorrendo de forma prática e de acordo com os pedidos do cliente.
No estabelecimento do SLA é preciso que ambas as partes sanem todas as dúvidas e deixem bem claro o que é possível ou não, para manter a transparência e finalizar o acordo de forma satisfatória.
COMPOSIÇÃO
O SLA precisa ser estruturado em categorias que descrevem o serviço prestado:
NÍVEL DE SERVIÇO
Nessa etapa é definida a espécie do serviço que será prestado ao cliente (um processo de manutenção, implantação, atualização ou reparo de algum sistema ou ferramenta).
TERMOS DE COMPROMISSO
Nessa etapa é possível estruturar o contrato com segurança e transparência, garantindo que as duas partes entendam completamente a proposta e se comprometam a seguir tudo o que foi acordado nela.
PRAZOS DE CONTRATO
Os prazos da prestação do serviço são essenciais na elaboração do SLA.
Os prazos de contrato garantem que o provedor atenda às necessidades do cliente dentro do prazo estipulado. Dessa forma, uma contestação é possível caso ocorra algum atraso significativo.
Para a empresa, os prazos são ideais para organizar as tarefas da equipe e estipular o nível de prioridade de cada projeto. Por exemplo, aqueles serviços com uma data de entrega mais próxima à data atual devem ser priorizados pela equipe, para que nenhum atraso ocorra e cause conflitos com o cliente.
SUPORTE TÉCNICO
Os provedores de serviço em nuvem geralmente oferecem um suporte técnico por um período determinado após a finalização do projeto. Sendo assim, o apoio oferecido pelo provedor deve ser determinado quando o SLA está sendo formulado.
Seja por 48 horas após a finalização do serviço ou até por um ano, o suporte técnico funciona como uma garantia e deve ser analisado com cuidado, principalmente pelo provedor, antes de tomar um espaço no SLA.
SLM
O Gerenciamento de Nível de Serviço – GNS (Service Level Management – SLM) é um conceito que costuma ser confundido com o SLA. Na verdade, o SLM funciona como um sistema de avaliação da qualidade do serviço que está sendo oferecido e executado.
MTBF
O Tempo Médio entre Falhas (Mean Time Between Failures – MTBF) funciona como um ponto de avaliação da qualidade do serviço desenvolvido.
TIPOS DE SLA
Existem dois tipos de SLA:
SLA focado no cliente, em que são documentadas todas as especificações e expectativas explicadas pelo solicitante do serviço;
SLA focado no serviço, no qual o modelo não abre tanto espaço para as especificações do cliente, ou seja, o processo é padronizado e o solicitante precisa aceitá-lo como ele é.
MÉTRICAS DE QUALIDADE DE SERVIÇO
Os SLAs usam métricas de qualidade de serviço para expressar características mensuráveis de QoS.
Exemplos dessas métricas são:
DISPONIBILIDADE
Tempo de atividade, interrupções, duração do serviço;
CONFIABILIDADE
MTBF, taxa garantida de respostas bem-sucedidas;
DESEMPENHO
Capacidade do sistema (p. ex. processamento, memória etc.), tempo de resposta (p. ex. processamento, banco de dados etc.) e tempo de entrega garantidos;
ESCALABILIDADE
Garantia de flutuação de capacidade, capacidade de resposta;
RESILIÊNCIA
Tempo Médio para Transição (Mean-Time to Switchover – MTSO), Tempo Médio para Recuperação do Sistema (Mean-Time System Recovery – MTSR).
Um exemplo mostrado a seguir é o da taxa de disponibilidade. A disponibilidade geral de um recurso de TI pode ser representada como uma porcentagem do tempo de atividade. Isso significa que um tempo de atividade de 100% representa um recurso de TI sempre disponível.
Tabela 2 – Taxas de disponibilidade de amostra.
	Disponibilidade
	Tempo de inatividade/Semana (Segundos)
	Tempo de inatividade/Mês (Segundos)
	Tempo de inatividade/Ano (Segundos)
	99,5 %
	3000
	12618
	157488
	99,8 %
	1000
	4206
	52496
	99,9 %
	500
	2103
	26248
	99,95 %
	250
	1051,5
	13124
	99,99 %
	50,1
	210,3
	2624,8
	99,99 %
	5,10
	21,0
	262,4
	99,999 %
	0,5102,10
	26,2
Os sistemas de gerenciamento de SLA usam as métricas para atestar periodicamente a conformidade com as garantias do SLA. Também coletam dados relacionados ao SLA para vários tipos de análises estatísticas. Cada métrica de qualidade de serviço é definida usando as seguintes características:
SER QUANTIFICÁVEL
A unidade de medida é bem definida, absoluta e apropriada para que a métrica possa ser baseada em medições quantitativas;
SER REPETÍVEL
Os métodos de medição devem gerar resultados idênticos quando repetidos em condições idênticas;
SER COMPARÁVEL
As unidades de medida usadas por uma métrica precisam ser padronizadas e comparáveis;
SER FACILMENTE OBTIDA
A métrica possui uma unidade comum de medição não proprietária, que seja facilmente obtida e entendida pelos consumidores da nuvem.
Os clientes corporativos esperam relatórios mensais de SLAs baseados em métricas e geralmente solicitam o direito de executar os próprios contratos anuais de auditoria para rastrear SLAs relacionados à segurança e a regulamentações.
Pode estar incluída nesse documento uma lista de todas as certificações das várias auditorias anteriores, como SSAE18 (padrão de controles para proteção da confidencialidade e privacidade das informações na nuvem), HIPAA (segurança e privacidade de informações pessoais de saúde) e outras.
CONCLUSÃO
CONSIDERAÇÕES FINAIS
A computação em nuvem é considerada um símbolo da internet e como permite uma grande capacidade de armazenamento em computadores e servidores compartilhados na rede, realizar a migração de informações e de dados para a nuvem é uma estratégia cada vez mais adotada pelas empresas e pelos gestores de tecnologia. Isso vai ao encontro de uma das principais preocupações atuais dos CIOs das empresas: A redução de custos.
Atualmente usamos diversos aplicativos e serviços que funcionam em conformidade com o modelo de computação em nuvem. Entender os conceitos é extremamente importante para saber tomar boas decisões e atuar corretamente em uma infraestrutura de recursos de TI.
O preço no mercado da computação em nuvem é extremamente complexo e nada amigável. Em teoria, ela oferece um modelo bastante simples para consumir recursos de computação e armazenamento. Clientes demandam capacidade, o fornecedor a fornece e é pago por isso.
Ao se trabalhar com computação em nuvem, devemos conhecer os tipos de serviços fornecidos, como IaaS, PaaS e SaaS, além de entender o modelo de precificação adotado pelo provedor. Diante da variedade de recursos fornecidos pela nuvem, métricas de qualidade de serviço e acordo de nível de serviço são instrumentos de proteção tanto para o consumidor como para o provedor.
CIOS
O Chief Information Officer ou CIO é um título dado ao responsável pela tecnologia da informação da empresa, que pode ser o gerente de TI, o superintendente de TI, o diretor de TI ou o vice-presidente de TI.