Trabalhando com computação em nuvem

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.
Fonte: Blackboard/Shutterstock
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.
Fonte: Wright Studio/Shutterstock
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.
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013
Figura 1 – Um consumidor de nuvem usando um servidor virtual em um ambiente IaaS.
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.
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013
Figura 2 – Consumidor da nuvem acessando um ambiente PaaS pronto.
O ponto de interrogação indica que o consumidor está separado dos detalhes de implementação da plataforma.
Fonte: Shutterstock
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.
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013
Figura 3 – 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.
Fonte: O autor
Fonte: O autor.
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.
Fonte: Shutterstock
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 demais 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 escolha pelo 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:
Fonte:Shutterstock
1.
Interface de usuário baseada na web, geralmente acessível em qualquer dispositivo conectado à internet;
Fonte:Shutterstock
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.
Atenção! Para visualização completa da tabela utilize a rolagem horizontal
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 forneceremmenos 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ção e 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).
Atenção! Para visualização completa da tabela utilize a rolagem horizontal
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:
Fonte: SergeyBitos/Shutterstock
SISTEMA DE ARQUIVOS EM REDE
A manipulação de arquivos é semelhante à maneira como as pastas são organizadas nos sistemas operacionais (NFS, CIFS);
Fonte: Profit_Image/Shutterstock
DISPOSITIVOS DE REDE DE ÁREA DE ARMAZENAMENTO
O acesso é transmitido pela rede (iSCSI, Fibre Channel);
autor/shutterstock
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.
Atenção! Para visualização completa da tabela utilize a rolagem horizontal
APLICABILIDADE DOS MODELOS DE SERVIÇO EM NUVEM
VERIFICANDO O APRENDIZADO
1. CONSIDERE UMA EMPRESA SEM ATUAÇÃO NO NEGÓCIO DE RH QUE NECESSITA EXECUTAR APLICATIVOS DE FOLHA DE PAGAMENTO,
GERENCIAMENTO DE RELACIONAMENTO COM CLIENTE (CRM) E SOFTWARE DE CONTABILIDADE. NESSE MOMENTO, OS GESTORES SE
PERGUNTAM SE COMPENSA REALIZAR A COMPRA DE SOFTWARE E SERVIDORES, GERENCIAR SERVIDORES E PAGAR PESSOAS PARA
GERENCIAR, CORRIGIR, PROTEGER E FORNECER OUTRAS TAREFAS SEM VALOR AGREGADO PARA MANTER ESSES SERVIÇOS EM
EXECUÇÃO. CONSIDERANDO QUE O CONTEXTO SE REFERE APENAS AOS APLICATIVOS CITADOS, QUAL DAS OPÇÕES A SEGUIR
CONSTITUI A MELHOR ALTERNATIVA, CONSIDERANDO A EXISTÊNCIA DOS MODELOS DE SERVIÇOS EM NUVEM:
A) Comprar os aplicativos e executá-los no local.
B) Contratar um provedor de serviços IaaS.
C) Contratar um provedor de serviços PaaS.
D) Contratar um provedor de serviços SaaS.
2. ANALISE O QUADRO A SEGUIR:
SUPONHA QUE UMA EMPRESA DESEJA ESCOLHER UM PROVEDOR QUE ATUE NO MODELO DE SERVIÇOS EM NUVEM E OFEREÇA,
ENTRE OUTRAS POSSÍVEIS FUNCIONALIDADES, OS GERENCIAMENTOS DAS CREDENCIAIS E SENHAS PARA ADMINISTRADORES DE
RECURSOS EM NUVEM E DAS CONFIGURAÇÕES DE SEGURANÇA; AS SELEÇÕES DE OPÇÕES DE FAILOVER, DE CLUSTER DE RECURSOS
DE TI, DE MONITORAMENTO DE MÉTRICAS SLA, DE INSTÂNCIAS DE RECURSOS, PODENDO ESCOLHER CONFIGURAÇÕES E OPÇÕES
DISPONÍVEIS RELACIONADAS A HARDWARE, E DE REGIÕES GEOGRÁFICAS NAS QUAIS OS RECURSOS DE TI BASEADOS EM NUVEM
DEVEM SER HOSPEDADOS. PELAS DESCRIÇÕES DAS FUNCIONALIDADES, É RECOMENDÁVEL QUE A EMPRESA CONTRATE UM
PROVEDOR DE SERVIÇOS QUE OFEREÇA O MODELO:
A) On-premisse.
B) IaaS.
C) PaaS.
D) SaaS.
GABARITO
1. Considere uma empresa sem atuação no negócio de RH que necessita executar aplicativos de folha de pagamento, gerenciamento de relacionamento com cliente
(CRM) e software de contabilidade. Nesse momento, os gestores se perguntam se compensa realizar a compra de software e servidores, gerenciar servidores e pagar
pessoas para gerenciar, corrigir, proteger e fornecer outras tarefas sem valor agregado para manter esses serviços em execução. Considerando que o contexto se refere
apenas aos aplicativos citados, qual das opções a seguir constitui a melhor alternativa, considerando a existência dos modelos de serviços em nuvem:
A alternativa "D " está correta.
As soluções SaaS se enquadram em muitas categorias diferentes. Os mais populares são aplicativos de negócios empresariais como CRM, ERP (Enterprise Resource Planning),
contabilidade, recursos humanos e folha de pagamento.
2. Analise o quadro a seguir:
Suponha que uma empresa deseja escolher um provedor que atue no modelo de serviços em nuvem e ofereça, entre outras possíveis funcionalidades, os
gerenciamentos das credenciais e senhas para administradores de recursos em nuvem e das configurações de segurança; as seleções de opções de failover, de cluster
de recursos de TI, de monitoramento de métricas SLA, de instâncias de recursos, podendo escolher configurações e opções disponíveis relacionadas a hardware, e de
regiões geográficas nas quais os recursos de TI baseados em nuvem devem ser hospedados.Pelas descrições das funcionalidades, é recomendável que a empresa
contrate um provedor de serviços que ofereça o modelo:
A alternativa "B " está correta.
A IaaS oferece como serviço a infraestrutura de um sistema de computação (em geral com o uso de virtualização), com armazenamento e recursos de rede. O cliente pode comprar
esses recursos como um serviço totalmente terceirizado, em vez de obter os próprios servidores, software, espaço de datacenter ou equipamento de rede.
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.
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013.
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.
Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013.
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 uma quantidade 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.
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013.
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.
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013
Figura 4 – Fases do ciclo de vida dos serviços em nuvem.
PRECIFICAÇÃO
A computação em nuvem impõe um novo desafio financeiro às empresas de tecnologia: Como precificar corretamente os modelosde 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:
Fonte:Shutterstock
Concorrência no mercado e requisitos regulatórios;
Fonte: Shutterstock
Custos indiretos no design, desenvolvimento, implantação e operação de serviços em nuvem e outros recursos de TI;
Fonte: Shutterstock
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:
Fonte:Shutterstock
Custos que dependem do tipo de alocação de recursos de TI (ex.: Sob demanda versus reservada);
Fonte:Shutterstock
Taxas fixas ou variáveis, conforme o tipo de alocação de recursos (cota fixa de uso, ou uso dinâmico);
Fonte:Shutterstock
Descontos à medida que a escalabilidade dos recursos de TI aumenta progressivamente;
Fonte:Shutterstock
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.
Atenção! Para visualização completa da tabela utilize a rolagem horizontal
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
Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013.
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.
MODELOS DE PRECIFICAÇÃO PARA COMPUTAÇÃO EM NUVEM
VERIFICANDO O APRENDIZADO
1. CONSIDERE O MESMO CENÁRIO DESCRITO NO ESTUDO DE CASO, MAS AGORA COM UM BANCO DE DADOS QUE RESIDE EM UM
CLUSTER DE ALTA DISPONIBILIDADE SEPARADO.
FAÇA A ANÁLISE DOS DADOS APRESENTADOS E, COM BASE NELES, MARQUE A ALTERNATIVA CORRETA:
A) A empresa deverá desistir da sua aplicação.
B) A empresa pode focar nos custos iniciais e optar por migrar a aplicação para a nuvem.
C) A decisão de migrar o aplicativo para a nuvem não é suportada pela análise de TCO.
D) Tanto a análise dos custos iniciais quanto a dos custos contínuos são favoráveis à migração para a nuvem.
2. SE UMA EMPRESA CONSUMIDORA DE UM SERVIÇO EM NUVEM REALIZA UM ACOMPANHAMENTO DOS RELATÓRIOS DAS MÉTRICAS DE
USO DE UM SERVIDOR DURANTE O USO ATIVO DELE, APÓS O PROVISIONAMENTO EM UM PROVEDOR IAAS, DIZ-SE QUE REALIZA O
GERENCIAMENTO DE CUSTOS EM QUAL FASE DO CICLO DE VIDA DOS SERVIÇOS EM NUVEM?
A) Contrato de serviço.
B) Operação do serviço.
C) Provisionamento de serviço.
D) Oferta de serviço.
GABARITO
1. Considere o mesmo cenário descrito no estudo de caso, mas agora com um banco de dados que reside em um cluster de alta disponibilidade separado.
Faça a análise dos dados apresentados e, com base neles, marque a alternativa correta:
A alternativa "C " está correta.
Podemos montar uma tabela comparativa:
Custos iniciais Custos contínuos
No local (on-premisses) R$ 70.000,00 R$ 11.800,00
Baseados na nuvem R$ 90.000,00 R$ 13.995,00
Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Uma comparação dos TCOs em um período de três anos revela o seguinte:
TCO no local: R$70.000,00 adiantados + (R$11.800,00 x 36) em andamento = R$494.000,00;
TCO baseado em nuvem: R$90.000,00 adiantados + (R$13.995,00 x 36) em andamento = R$593.820,00.
2. Se uma empresa consumidora de um serviço em nuvem realiza um acompanhamento dos relatórios das métricas de uso de um servidor durante o uso ativo dele, após
o provisionamento em um provedor IaaS, diz-se que realiza o gerenciamento de custos em qual fase do ciclo de vida dos serviços em nuvem?
A alternativa "B " está correta.
Na operação do serviço, o uso ativo do serviço em nuvem irá produzir dados métricos de custo de uso.
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.
Fonte: Ralf Kleemann/Shutterstock
Figura 5 – Acordo de Nível de Serviço (ANS).
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. A organizaçã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 deexpectativas 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.
Fonte: H_Ko/Shutterstock
COMPOSIÇÃO
O SLA precisa ser estruturado em categorias que descrevem o serviço prestado:
NÍVEL DE SERVIÇO
TERMOS DE COMPROMISSO
PRAZOS DE CONTRATO
SUPORTE TÉCNICO
SLM
MTBF
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:
Fonte: macrovector_official/Freepik
SLA focado no cliente, em que são documentadas todas as especificações e expectativas explicadas pelo solicitante do serviço;
Fonte: Freepik
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,510 2,10 26,2
Atenção! Para visualização completada tabela utilize a rolagem horizontal
Fonte: Adaptado de Erl, Puttini e Mahmood, 2013.
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.
ACORDO DE NÍVEL DE SERVIÇO (SLA)
VERIFICANDO O APRENDIZADO
1. A EMPRESA ACME ESTÁ REVISANDO OS TERMOS E CONDIÇÕES DO SLA APÓS SOFRER UMA INTERRUPÇÃO NA NUVEM QUE DEIXOU
SEU SITE FORA DO AR POR DUAS HORAS. ELA CRIOU UMA LISTA DE REQUISITOS ADICIONAIS E GARANTIAS:
A TAXA DE DISPONIBILIDADE PRECISA SER DESCRITA EM MAIS DETALHES PARA PERMITIR UM GERENCIAMENTO MAIS EFICAZ DAS CONDIÇÕES
DE DISPONIBILIDADE DO SERVIÇO;
OS DADOS TÉCNICOS QUE SUPORTAM OS MODELOS DE OPERAÇÕES DE SERVIÇO PRECISAM SER INCLUÍDOS, VISANDO GARANTIR QUE A
OPERAÇÃO DE SERVIÇOS CRÍTICOS SELECIONADOS PERMANEÇA TOLERANTE A FALHAS;
MÉTRICAS ADICIONAIS QUE AUXILIAM A AVALIAÇÃO DA QUALIDADE DO SERVIÇO DEVEM SER INCLUÍDAS;
QUALQUER EVENTO RELACIONADO ÀS MÉTRICAS DE DISPONIBILIDADE QUE PRECISAR SER EXCLUÍDO DEVE SER CLARAMENTE DEFINIDO.
APÓS VÁRIOS ACORDOS, O REPRESENTANTE DE VENDAS DA ACME, O PROVEDOR DE NUVEM, PERCEBEU A SEGUINTE EVOLUÇÃO:
MARQUE A ALTERNATIVA CORRETA:
A) A nova taxa de disponibilidade medida irá eliminar qualquer probabilidade de inatividade do serviço.
B) A qualidade de serviço é uma métrica absoluta e universal.
C) Modificar o SLA implica aumentar os gastos com locação.
D) A inclusão do conjunto de métricas de confiabilidade e desempenho foi aprovada pela ACME.
2. UMA EMPRESA TEM UMA APLICAÇÃO LOCAL LEGADA COM CHAMADAS PARA MÓDULOS WEB, QUE ERA EXECUTADA NA PRÓPRIA
INFRAESTRUTURA. VISANDO AO CORTE DE CUSTOS, DECIDE CONTRATAR UMA PROVEDORA DE SERVIÇOS EM NUVEM, PARA ASSIM
VIRTUALIZAR O APLICATIVO, E CONCORDA COM O OS TERMOS DO SLA “PADRÃO” OFERECIDO PELA PROVEDORA. APÓS REALIZAR
TODA A MIGRAÇÃO, A EMPRESA CONTRATANTE PERCEBE QUE ALGUMAS FUNÇÕES NÃO FUNCIONAM, POIS O CÓDIGO POSSUI
ALGUMAS EXTENSÕES ESCRITAS ESPECIFICAMENTE PARA O TIPO DE PROCESSADOR DO SERVIDOR LOCAL.
MARQUE A ALTERNATIVA CORRETA QUANTO A UMA POSSÍVEL CAUSA/SOLUÇÃO PARA O CENÁRIO DESCRITO:
A) Diante do exposto, não será possível migrar a aplicação.
B) O SLA poderá ser revisto objetivando incluir cláusulas que garantam o fornecimento do sistema compatível.
C) O SLA deveria ter sido inteiramente escrito pelo cliente e submetido para o fornecedor com aprovação garantida.
D) O provedor deverá adquirir e incorporar a infraestrutura do cliente.
GABARITO
1. A empresa ACME está revisando os termos e condições do SLA após sofrer uma interrupção na nuvem que deixou seu site fora do ar por duas horas. Ela criou uma
lista de requisitos adicionais e garantias:
A taxa de disponibilidade precisa ser descrita em mais detalhes para permitir um gerenciamento mais eficaz das condições de disponibilidade do serviço;
Os dados técnicos que suportam os modelos de operações de serviço precisam ser incluídos, visando garantir que a operação de serviços críticos selecionados permaneça tolerante a falhas;
Métricas adicionais que auxiliam a avaliação da qualidade do serviço devem ser incluídas;
Qualquer evento relacionado às métricas de disponibilidade que precisar ser excluído deve ser claramente definido.
Após vários acordos, o representante de vendas da ACME, o provedor de nuvem, percebeu a seguinte evolução:
Marque a alternativa correta:
A alternativa "D " está correta.
A letra A está incorreta, pois considera-se que sempre existirá alguma probabilidade de inatividade do serviço. Na letra B, a qualidade de serviço é uma métrica geralmente baseada
na satisfação do cliente e não uma métrica absoluta e universal, como é afirmado. A letra C está incorreta, pois modificar o SLA nem sempre implica aumento de gastos com locação.
A letra D está correta, pois os SLAs devem ser combinados e concordados por ambas as partes, contratante e contratado.
2. Uma empresa tem uma aplicação local legada com chamadas para módulos web, que era executada na própria infraestrutura. Visando ao corte de custos, decide
contratar uma provedora de serviços em nuvem, para assim virtualizar o aplicativo, e concorda com o os termos do SLA “padrão” oferecido pela provedora. Após realizar
toda a migração, a empresa contratante percebe que algumas funções não funcionam, pois o código possui algumas extensões escritas especificamente para o tipo de
processador do servidor local.
Marque a alternativa correta quanto a uma possível causa/solução para o cenário descrito:
A alternativa "B " está correta.
Lembre-se de que o SLA é um acordo entre as partes. Não existem obrigações nem certezas até o momento do estabelecimento do contrato.
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.
<
REFERÊNCIAS
AWS. Regiões, zonas de disponibilidade e Zonas locais. In: Amazon Web Services. Consultado em meio eletrônico em: 22 jun. 2020.
ERL, T.; PUTTINI, R.; MAHMOOD, Z. Cloud Computing: Concepts, Technology & Architecture. São Paulo: Prentice Hall, 2013.
KAVIS, M. J. Architecting the cloud: design decisions for cloud computing service models (SaaS, PaaS, and IaaS). New Jersey: John Wiley & Sons, 2014.
KUROSE, J. F.; ROSS, K. W. Redes de computadores e a internet: uma abordagem top-down. 6. ed. São Paulo: Pearson, 2013.
LIU, F. et. al. NIST Cloud Computing Reference Architecture: Recommendationsof the National Institute of Standards and Technology. Special Publication 500. NIST, 2011.
TWIN, A. Total Cost of Ownership – TCO. In: Investopedia. Consultado em meio eletrônico em: 21 jun. 2020.
VAULX, F. de; SIMMON, E.; BOHN, R. NIST Cloud Computing Service Metrics Description. Special Publication 500-307. NIST, 2018.
EXPLORE+
Para aprofundar seus conhecimentos, assista aos vídeos:
“Inside a Google data center”, no canal G Suite no YouTube.
“O que é computação em nuvem com a AWS”, no canal Amazon Web Services no YouTube.
Não deixe de visitar também as seguintes páginas:
Amazon Web Services (AWS) − Serviços de computação em nuvem
Google Cloud – Serviços de computação em nuvem
IBM Brasil – Computação em Nuvem e Armazenamento
Microsoft Azure
Openstack
CONTEUDISTA
Fabio Henrique Silva
CURRÍCULO LATTES