Tema 3

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
javascript:void(0)
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 significaque, 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 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.
javascript:void(0)
EXEMPLO
Suponha que a startup de comércio eletrônico START possui funcionários com boas
experiências na área de TI. Ela deseja agoracontratar 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çã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, deinstâ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 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:
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 plataformada 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 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.
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 completa da 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
javascript:void(0)
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.
<
AVALIAÇÃO DO TEMA:
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: Recommendations of 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
javascript:void(0);