Apostila - Módulo 0 - Fundamentos de Cloud Computing

Fundamentos
Bootcamp Arquiteto Cloud Computing
Leandro César Lopes Evangelista
2021
Bootcamp Arquiteto Cloud Computing
Leandro César Lopes Evangelista
© Copyright do Instituto de Gestão e Tecnologia da Informação.
Todos os direitos reservados.
Bootcamp Arquiteto Cloud Computing – Página 2 de 47

Sumário
Capítulo 1. A Nuvem ............................................................................................. 4
Introdução ............................................................................................................... 4
Capítulo 2. O mercado global de Cloud ................................................................. 6
O mercado global de Cloud .................................................................................... 6
Multicloud ................................................................................................................ 9
Razões para adotar a Multicloud .......................................................................... 12
Os 10 principais mitos da nuvem .......................................................................... 14
Desafios culturais ao migrar para a nuvem ........................................................... 21
5Rs do Gartner agora são os 6Rs da AWS .......................................................... 27
Capítulo 3. Conectividade com a nuvem ............................................................. 30
Introdução ............................................................................................................. 30
Desempenho e SLAs ............................................................................................ 32
Alta disponibilidade ............................................................................................... 32
Tempo inicial de provisionamento......................................................................... 33
Custos iniciais de Setup ........................................................................................ 33
Análises ................................................................................................................ 34
Express Route ...................................................................................................... 40
Capítulo 4. Overview AWS, GCP e AZURE ........................................................ 43
AWS: Alucinados pelos consumidores ................................................................. 43
Google Cloud ........................................................................................................ 43
Azure: Open-Source Best-Friend .......................................................................... 43
AWS EC2 - Elastic Compute Cloud ...................................................................... 44
Regiões e Zona de disponibilidade ....................................................................... 44
Azure Virtual Machines ......................................................................................... 45
Referências............... ............................................................................................... 47

Capítulo 1. A Nuvem
Introdução
Nosso propósito é compartilhar com você os cenários do mundo “Cloud”, já

que a transição é um caminho sem volta. Ou você a fará agora, ou nos próximos anos,
e de uma maneira mais intensa ou mais demorada; e essa decisão está diretamente
ligada a várias questões, desde técnicas, financeiras e culturais, à questões de
segurança da informação.
Além de analisar os impactos nos processos de negócio e de IT, você deve

compreender bem quais caminhos adotar nesta jornada sem fim.
A computação em nuvem deixa de ser discurso e se torna realidade no Brasil.
Veja a figura abaixo:
Figura 1 – Maiores prioridades da TI.
Segundo um estudo realizado pela empresa de consultoria em TI Logicalis,

quando o assunto são as prioridades tecnológicas, o tema de migração para soluções
em Cloud tem grande destaque entre os CEOs entrevistados. Além disso, reparem
que todas as outras prioridades também têm grande relevância com a nuvem.

Há uma tendência forte na ampliação do uso de Cloud pública e,
principalmente, na popularização dos modelos híbridos, em que nuvens públicas e
privadas se combinam para oferecer o melhor ambiente.
Figura 2 – Tipo de serviços de cloud.
Os motivos para a adoção cada vez maior da computação em nuvem estão

intimamente ligados à pressão dos negócios sobre a tecnologia. Os executivos
entrevistados afirmam que modernizar a infraestrutura de TI é o principal
impulsionador para cloud (59%) dentro das empresas. Em segundo lugar, citada por
44% dos respondentes, está a preocupação em melhorar a velocidade para atender
às demandas de negócios – comprovando a tese de que a computação em nuvem é
o primeiro passo para a digitalização dos negócios.
Fica evidente pelos resultados que as organizações estão percebendo os

benefícios da migração das aplicações de escritório – e-mail e ferramentas de
produtividade – para a nuvem. Essas aplicações, essenciais para as organizações, já
são adotadas em modelo de nuvem por 68% da amostra, no caso do e-mail, e 41%
no caso de produtividade.

Capítulo 2. O mercado global de Cloud
O mercado global de Cloud
Não poderíamos deixar de falar sobre os maiores provedores de IaaS do

mundo. O melhor driver para comparações com toda certeza é o famoso quadrante
mágico do Gartner.
Eles analisam com cuidado todos os aspectos dos provedores, detalhando as

suas forças e fraquezas.
Analisem abaixo o quadrante de Cloud IAAS e PASS mais recente, de agosto

de 2020. Em suma, o quadrante de líderes contém os principais fabricantes que estão
com grande destaque no mercado global. E no caso estamos falando de Amazon,
Microsoft e Google.
Os líderes se distinguem oferecendo um serviço adequado para adoção

estratégica e com um roteiro ambicioso. Eles podem atender a uma ampla gama de
casos de uso, embora não sejam excelentes em todas as áreas e possam não ser os
melhores provedores para uma necessidade específica e não atender a alguns casos
de uso. Eles têm um histórico de entrega bem-sucedida, participação significativa no
mercado e muitos clientes referenciáveis.

Figura 4 – Quadrante magico do Gartner IAAS e PAAS.
O Gartner destaca que as avaliações dos clientes estão atualmente focadas

principalmente em fornecedores para adoção estratégica, em uma ampla gama de
casos de uso. Embora os clientes ainda procurem por provedores mais focados,
específicos de cenários, esses provedores devem ser avaliados no contexto de um
workloads específico, em vez de comparada em um contexto de mercado mais amplo.

Além disso, os requisitos gerais do cliente continuam a se expandir, e ainda
há muitas necessidades não atendidas nesse mercado, resultando em maior espaço
para melhoria para todos os fornecedores em ambos os mercados.
Abaixo segue outro quadrante mágico, com o foco em prestadores de

serviços de cloud pública. Eles podem utilizar a infraestrutura das empresas de
datacenter do quadrante anterior.
Figura 5 – Quadrante mágico do Gartner IAAS Provedores de serviços.
O Quadrante Mágico mostra o posicionamento comparativo de fornecedores

no mercado. Os fornecedores podem melhorar substancialmente suas capacidades
de ano para ano, mas não conseguem um movimento significativo em sua posição,
já que esta é relativa ao mercado global.

Multicloud
A maioria das organizações buscará uma estratégia Multicloud, embora a

maioria também escolha um provedor de nuvem principal para uma finalidade
específica.
Como a maioria das organizações terá uma estratégia Multicloud, elas

também precisarão implementar o gerenciamento Multicloud para alcançar algum
grau de governança e ferramentas comuns para esses vários provedores de nuvem.
A maioria das organizações terá pelo menos um tipo de sistema que usa uma
arquitetura Multicloud, geralmente por meio do uso de um provedor de infraestrutura
de nuvem como serviço (IaaS) em conjunto com vários componentes de plataforma
como um serviço (PaaS) de provedores diferentes. No entanto, muito poucas
organizações migrarão aplicativos de um provedor de nuvem para outro. Tais
migrações geralmente exigem esforço manual significativo, em vez de serem
altamente automatizadas.
Recomendações
Os líderes de arquitetura empresarial e inovação tecnológica que planejam a

estratégia de nuvem ou arquitetam aplicativos baseados em nuvem devem:
Escolher um provedor estratégico principal para uma função específica, como

IaaS, para maximizar a capacidade de explorar os recursos de um provedor,
concentrar as habilidades dos funcionários e os relacionamentos de parceiros de
terceiros, simplificar o gerenciamento de fornecedores e maximizar os descontos. No
entanto, adotar uma estratégia Multicloud para maximizar o acesso a opções de
tecnologia e recursos inovadores e reduzir os riscos de concentrar tudo em um único
fornecedor.
Implementar o gerenciamento nativo do provedor de nuvem para simplificar a

integração, aproveitar rapidamente os novos recursos inovadores e maximizar o valor.
No entanto, buscar uma abordagem de gerenciamento Multicloud que também

permita que você adote políticas, procedimentos, processos e ferramentas comuns,
quando valiosos.
Usar uma arquitetura de aplicativo Multicloud quando necessário para

explorar recursos exclusivos de vários provedores, como APIs específicas verticais.
Não use uma arquitetura Multicloud para tentar economizar dinheiro; isso adiciona
uma complexidade significativa e aumenta os custos do ciclo de vida da aplicação.
Análise
A maioria das organizações já adotou vários provedores de computação em

nuvem para diferentes sistemas e casos de uso. Cada vez mais, porém, as
organizações estão adotando vários provedores de nuvem pública que competem
diretamente pelos mesmos tipos de casos de uso. Uma estratégia Multicloud pode
ajudar um cliente a obter acesso a uma gama mais ampla de recursos, especialmente
recursos inovadores de ponta. No entanto, uma estratégia Multicloud também cria
desafios de gerenciamento e governança Multicloud. A maioria dos aplicativos não
migra entre provedores de nuvem devido a desafios de portabilidade, mas a maioria
dos aplicativos não exige essa portabilidade. No entanto, um número crescente de
aplicativos terá uma arquitetura Multicloud – compondo os serviços de vários
provedores de nuvem pública – criando desafios de integração e operações.
Definição
Multicloud refere-se ao uso de serviços em nuvem de vários provedores de

nuvem pública para o mesmo propósito. É um caso especial de computação em
nuvem híbrida, que é um termo mais amplo.
A computação em nuvem híbrida é definida como o provisionamento, uso e

gerenciamento de serviços coordenados e baseados em políticas em uma mistura de
serviços em nuvem internos e externos.
Multicloud, não se refere ao uso simples de vários serviços de nuvem dentro

da organização - apenas o uso de vários provedores para o mesmo propósito. A
maioria das organizações usará muitos provedores de nuvem para finalidades

diferentes, mas isso não é computação Multicloud. Da mesma forma, a definição de
computação Multicloud não abrange o uso de serviços de nuvem privada. Referimo-
nos ao uso da computação em nuvem pública e privada como “nuvem híbrida”.
Seguem algumas considerações sobre Multicloud, que se dividem em três

tipos:
Estratégia Multicloud. A maioria das organizações terá uma estratégia de

fornecimento Multicloud. Isso requer uma estratégia para o gerenciamento de
fornecedores, uma estrutura para o posicionamento da carga de trabalho e uma
estratégia para desenvolver e manter as habilidades dos funcionários.
Gerenciamento Multicloud. Embora seja impraticável, e muitas vezes

abaixo do ideal, gerenciar vários provedores de nuvem de maneira idêntica, é melhor
ter uma abordagem coordenada para o gerenciamento e a governança do Multicloud.
Isso inclui a padronização de algumas políticas, procedimentos e processos. Ele
também inclui o compartilhamento de algumas ferramentas, especialmente
ferramentas que permitem a governança de custos e a otimização em vários
provedores de nuvem. Isso também afeta os desenvolvedores, especialmente em
organizações orientadas ao DevOps, pois afeta as ferramentas usadas durante o ciclo
de vida do aplicativo.
Arquitetura Multicloud. Alguns aplicativos abrangem vários provedores de

nuvem. De fato, alguns aplicativos podem ser um composto de vários tipos diferentes
de serviços e provedores. Por exemplo, pode haver IaaS e PaaS (IaaS + PaaS)
integrados de um único provedor, juntamente com outros elementos de PaaS de
vários provedores, como PaaS de integração, componentes específicos de vertical ou
serviços de API, como uma API de voz. Alguns aplicativos também podem ser
implantados em diferentes provedores de nuvem em momentos diferentes; por
exemplo, um aplicativo de trabalho em lotes pode ser implantado no provedor de
nuvem mais barato em um determinado momento.
Arquiteturas Multicloud
Existem dois tipos principais de arquiteturas Multicloud:

Arquitetura redundante: um sistema é implantado, em sua totalidade, em
vários provedores de nuvem.
Arquitetura composta: um único sistema é dividido em vários provedores de

nuvem; diferentes componentes do sistema vêm de diferentes provedores de nuvem.
Na arquitetura redundante, todo o sistema é replicado em dois ou mais

provedores de nuvem. Isso pode usar uma arquitetura ativa-ativa, em que todas as
cópias do aplicativo estão em uso contínuo, ou uma arquitetura ativa-passiva, em que
apenas algumas das cópias do aplicativo estão em uso. Por exemplo, em uma
implantação ativa-ativa, você pode optar por executar uma instância do seu site de
comércio eletrônico na Nuvem A e outra na Nuvem B e usar o balanceamento de
carga global para direcionar o tráfego de clientes entre esses dois sites. Em uma
implantação ativa-passiva, uma instância seria executada na nuvem A e outra na
nuvem B, mas o tráfego sempre iria para a nuvem A, a menos que você fizesse
failover para a nuvem B.
O disaster recovery de um provedor de nuvem para outro provedor de nuvem,

também é uma forma de arquitetura Multicloud redundante. Pode ter as
características das arquiteturas continuamente replicadas ou únicas.
E na arquitetura composta, a maioria dos sistemas usa um núcleo de nuvem

única. Nesse modelo, o núcleo do sistema – a maior parte de sua infraestrutura de
sistema e aplicativo, juntamente com grande parte de seus dados – é colocado em
um único provedor de nuvem. Se esses aplicativos tiverem componentes que usam
um ou mais serviços de outro provedor de nuvem, eles terão uma arquitetura
Multicloud composta.
Razões para adotar a Multicloud
As organizações normalmente adotam uma estratégia Multicloud por um ou

mais dos seguintes motivos:

Acesso a uma variedade de recursos: Nenhum provedor de nuvem único
oferece um conjunto abrangente de serviços. Como os provedores de nuvem são
diferenciados e possuem pontos fortes, pontos fracos e recursos exclusivos, a adoção
de uma estratégia Multicloud permite o acesso aos melhores recursos da categoria.
Ele permite que as equipes técnicas determinem o melhor posicionamento para um
determinado aplicativo, com base em seus requisitos comerciais e técnicos.
Acesso à inovação: Os provedores de nuvem às vezes ultrapassam um ao

outro em recursos. Para clientes para os quais o acesso imediato às inovações mais
recentes é de importância crítica, uma estratégia Multicloud permite que eles
aproveitem rapidamente os novos recursos assim que forem introduzidos no
mercado.
Acesso a uma ampla gama de localizações no mundo: Embora haja uma

sobreposição significativa nos locais do data center dos provedores globais de nuvem,
alguns provedores de nuvem podem ter locais exclusivos. Além disso, clientes com
requisitos geográficos incomuns podem precisar usar provedores de nuvem locais.
Redução do risco de concentração de fornecedores: Alguns clientes

acreditam que colocar a maioria de seus aplicativos em um único provedor de nuvem
cria o risco de que uma alteração de serviço possa ter um impacto generalizado em
seu portfólio geral de aplicativos. Alguns clientes também estão preocupados com o
potencial de interrupções massivas. Por exemplo, em 2012 e 2014, ocorreram
paralisações do Microsoft Azure que afetaram quase todas as regiões do Azure em
todo o mundo.
Redução do risco de viabilidade de fornecedor: Alguns clientes,

especialmente aqueles que usam provedores de nuvem menores, estão preocupados
com a estabilidade financeira do provedor, o comprometimento com o mercado ou a
longevidade do serviço em nuvem que estão usando atualmente. Consequentemente,
eles querem outras opções de nuvem.
Percebeu-se as vantagens de negociação de fornecedores da diversidade de

fornecedores. Alguns clientes acreditam que podem negociar melhores preços ou

melhores condições de contrato se tiverem a opção de usar vários provedores de
nuvem.
Provedores de nuvem herdados de uma fusão ou aquisição. As empresas

que crescem inorganicamente geralmente descobrem que as entidades obtidas de
fusões e aquisições usam outros provedores de nuvem. Essas empresas precisam
de uma estratégia Multicloud, mesmo que seu objetivo final seja consolidar
provedores de nuvem.
Os 10 principais mitos da nuvem
A computação em nuvem, por sua própria natureza, é singularmente

suscetível aos perigos dos mitos. É tudo sobre recursos entregues como um serviço,
com um limite claro entre o provedor do serviço e o consumidor. Do ponto de vista
do consumidor, "na nuvem" significa onde a mágica acontece, onde os detalhes da
implementação devem estar ocultos. Portanto, não deveria ser surpresa que tal
ambiente esteja repleto de mitos e mal-entendidos.
Os mitos às vezes são inofensivos, mas têm efeito sobre como nos
aproximamos das soluções:
Eles nos atrasam e nos distraem dos problemas reais e das soluções reais.
Eles podem nos levar a tomar decisões com base em suposições erradas ou
até mesmo perigosas.
Eles impedem a inovação.
Eles retardam o progresso em direção a metas reais e realizações e

resultados reais.
Eles nos assustam. Muitos mitos estão enraizados no medo e no mal-

entendido. Eles podem dirigir decisões e estratégias baseadas no medo e isso leva a
crenças e mantras que são os perigos reais.

Não há escassez de candidatos para os 10 principais mitos da nuvem. Abaixo
está uma lista que destaca alguns dos mais perigosos e enganosos.
Mito 1: A nuvem é sempre a melhor opção pois reduz custos
Raramente as considerações financeiras não fazem parte de um processo de

decisão de TI, especialmente quando esse processo diz respeito à computação em
nuvem. No entanto, o mito predominante sobre a nuvem é que ela sempre economiza
dinheiro. Embora esse seja o caso algumas vezes, há muitos outros motivos citados
para migrar para a nuvem, sendo o mais comum deles a agilidade.
O Gartner realizou uma pesquisa em 2014 mostrando que a redução de

custos representa apenas 14% das razões para o uso da nuvem pública pelas
organizações.
Enquanto os preços estão caindo, especialmente para a infraestrutura como

um serviço (IaaS), nem todos os preços de serviços em nuvem estão diminuindo (por
exemplo os da maioria dos softwares como serviço [SaaS]). Assumir que a nuvem
sempre economiza dinheiro pode levar a promessas limitadoras. Poupar dinheiro
pode acabar sendo um dos benefícios, mas não deve ser tomado como certeza.
Muitos mitos também têm ‘contra-mitos’ aparentemente contraditórios - neste

caso, a crença de que uma organização é capaz de igualar ou superar os pontos de
preço da nuvem pública. Mitos contrários geralmente são resultado de diferentes
perspectivas e podem levar a extremos que parecem ser contraditórios. A realidade
é que essas posições extremas são mantidas por pessoas diferentes
Conselho: Não assuma que você economizará dinheiro a menos que tenha
feito o trabalho duro de analisar a situação honestamente. Utilize o custo total de
propriedade (TCO) e outros modelos caso a caso.
Segmente a nuvem em casos de uso. Olhe além dos problemas de custo.

Além disso, verifique com especialistas financeiros as implicações que uma mudança

de despesas de capital (capex) para despesas de operação (opex) pode ter. Não
assuma que o opex é sempre melhor que o capex. Continue revisitando a análise,
pois o mercado e os preços mudam com frequência. Falaremos com mais detalhes
sobre analises financeiras para a nuvem no próximo capítulo.
Mito 2: Você precisa estar na nuvem para ser “o” bom
Esta é a manifestação da "lavagem de nuvens" desenfreada (referindo-se à

tendência de chamar coisas de nuvens que não são). Não são apenas os
fornecedores que fazem isso, embora muitos tenham sido culpados disso. Algumas
lavagens de nuvens são acidentais e resultam de uma confusão legítima, mas
algumas também se baseiam em crenças erradas que algo não pode ser "bom" a
menos que seja em nuvem. As áreas de TI também estão chamando cada vez mais
muitas coisas na nuvem como parte de seus esforços para obter financiamento e
atender às demandas e estratégias nebulosas da nuvem. O mito resultante é que as
pessoas estão caindo na armadilha de acreditar que, se algo é bom, tem que ser
nuvem ou, se não for baseado em nuvem, não pode ser bom.
Conselho: Muitos outros recursos (por exemplo, automação, virtualização)

não precisam ser levadas na nuvem. Permita que essas estratégias se mantenham
por conta própria. Evite expectativas perdidas.
Mito 3: A nuvem deve ser usada para tudo
Isso está relacionado ao Mito 2, e refere-se à crença de que as características

reais da nuvem são aplicáveis ou desejável para tudo. Claramente, existem alguns
casos de uso em que há uma grande compatibilidade. Os exemplos incluem cargas
de trabalho (workloads) altamente variáveis ou imprevisíveis, casos em que há
economias claras e aquelas em que o provisionamento e o reprovisionamento no
estilo self-service são fundamentais. A nuvem se encaixa onde o valor é colocado na
flexibilidade e o negócio tem a capacidade de consumir e pagar apenas o que é
necessário e quando necessário. No entanto, nem todos os aplicativos e cargas de
trabalho se beneficiam da nuvem. A menos que haja redução de custos, um sistema
legado que não muda não é um bom candidato.

Conselho: A nuvem pode não beneficiar todas as cargas de trabalho
igualmente. Nunca assuma que isso acontece. Analise os aplicativos caso a caso.
Não tenha medo de propor soluções ‘noncloud’ quando apropriado.
Mito 4: "O CEO disse que sim"
Quando questionados sobre qual é a sua estratégia de nuvem, muitas

empresas não têm uma e o padrão é muitas vezes (declarado ou não) que estão
apenas fazendo o que seu CEO quer. Às vezes, o CEO realmente dita que a nuvem
é a estratégia (sem uma conexão com uma meta de negócios real). Não
diferentemente de outros exemplos de "síndrome de revista de companhia aérea" e
as expectativas irrealistas muitas vezes estão por trás do interesse. Essa não é uma
estratégia de nuvem e geralmente é baseada em um ou mais dos mitos descritos
nesta nota.
Conselho: Uma estratégia de nuvem começa identificando os objetivos de

negócios e mapeando os benefícios potenciais da nuvem para eles, ao mesmo tempo
em que atenua as possíveis desvantagens. A nuvem deve ser pensada como um
meio para um fim.
Mito 5: Precisamos de uma estratégia de nuvem que contemple um

único fornecedor
É natural querer simplificar e padronizar. No entanto, a computação em

nuvem não é uma coisa simples, e uma estratégia de nuvem precisa ser baseada
nessa realidade. Os serviços de nuvem são amplos e abrangem vários níveis (IaaS,
SaaS), modelos (nuvem nativa), escopo (interno, externo) e sistemas. A natureza dos
serviços em nuvem e os padrões de interoperabilidade existentes, podem tornar a
questão das opções limitadoras menos importante, pois esses detalhes são
geralmente ocultados do consumidor. No entanto, mesmo que um fornecedor e uma
estratégia sejam possíveis, muitos compromissos significativos frequentemente terão
que ser feitos. Nesses casos, concentrar-se nas táticas subjacentes pode ser tão
importante quanto a estratégia geral.

Conselho: Uma estratégia de nuvem deve se basear no alinhamento de
metas de negócios com benefícios potenciais. Essas metas e benefícios são
diferentes em vários casos de uso e devem ser a força motriz para as empresas, em
vez de qualquer tentativa de padronizar uma oferta ou estratégia. Uma única
estratégia de nuvem faz sentido se usar uma estrutura de decisão que permita e
espere várias respostas.
Mito 6: A nuvem é menos segura que usar recursos locais
A computação em nuvem é percebida como menos segura. Isso é mais um

problema de confiança do que baseado em qualquer análise razoável dos recursos
reais de segurança. Até o momento, houve pouquíssimas violações de segurança na
nuvem pública - a maioria das violações continua a envolver ambientes de data center
local. A maioria dos provedores de nuvem investe significativamente em tecnologia e
segurança e percebe que seus negócios estariam em risco sem fazê-lo. No entanto,
assumir que eles são 100% seguros não é recomendado.
Há também uma visão oposta de que as plataformas de nuvem são realmente

mais seguras do que as plataformas locais. Isso pode, de fato, ser verdadeiro para
muitas empresas de pequeno ou médio porte, algumas das quais não podem fazer
os investimentos de segurança necessários, e mesmo para algumas grandes
empresas que reconhecem que seus esforços de segurança podem estar faltando.
Segurança não é uma entidade monolítica. Também é importante identificar

onde reside a responsabilidade de segurança e onde está a linha divisória. Por
exemplo, se um cliente usa um provedor de IaaS na nuvem, esse provedor é
responsável pela segurança no nível de IaaS, mas o cliente deve possuir a estratégia
geral de segurança e apropriar-se do aplicativo e de outros problemas de segurança
de nível superior.
Conselho: não assuma que provedores de nuvem não são seguros, mas
também não presuma que eles são. Os provedores de nuvem devem demonstrar
suas capacidades, mas, depois de fazer isso, não há motivos para acreditar que suas
ofertas não possam ser seguras. Existem empresas cujas capacidades de segurança

são formidáveis, mas as capacidades da maioria dos provedores de nuvem também
são. No entanto, os níveis de segurança dos provedores de nuvem variam. Avalie
suas capacidades reais e as capacidades de seu provedor em potencial e mantenha
ambos em padrões razoáveis. Assumir que os recursos locais são mais seguros pode
levar a uma falsa sensação de segurança.
Mito 7: A nuvem não é para uso de missão crítica
A computação em nuvem não é tudo ou nada. Está sendo adotado (e deve

ser adotado) em etapas e em casos específicos. Portanto, não é de surpreender que
os casos de uso antecipado (por exemplo, desenvolvimento/teste) não sejam, na
maioria das vezes, para sistemas de missão crítica. No entanto, muitas organizações
progrediram além dos casos de uso e experimentação iniciais e estão utilizando a
nuvem para cargas de trabalho de missão crítica. Alguns desses usos são
verdadeiros serviços em nuvem (SaaS, nativo da nuvem), enquanto outros são
modelos hospedados em que os benefícios da nuvem estão em um nível inferior, mas
ainda representam um uso genuíno. Há também muitas empresas (não apenas
pequenas startups) que "nascem na nuvem" e administram seus negócios
(claramente essenciais para a missão) completamente na nuvem.
Conselho: Missão crítica pode significar coisas diferentes. Se isso significa

sistemas complexos, abordagens como a adoção de uma abordagem em fases
podem facilitar o movimento para a nuvem. As soluções híbridas também podem
desempenhar um papel fundamental.
Mito 8: Cloud = Data Center
A maioria das decisões na nuvem não é (e nem deveria ser) sobre o

fechamento completo de datacenters e a migração de tudo para a nuvem. Uma
estratégia de nuvem também não deve ser igualada a uma estratégia de data center.
Nenhum dos dois deve ser feito em um vácuo – você precisa ter espaço no datacenter
para coisas que não estão na nuvem e, se você tirar as coisas do data center, há
implicações. Mas eles não são a mesma coisa. Em geral, a terceirização do

datacenter, a modernização do data center e as estratégias do data center não são
sinônimos da nuvem.
É comum que pessoas focadas em uma área (datacenter, por exemplo)

pensem que a computação em nuvem é apenas sobre isso. O uso contínuo do termo
"nuvens" (em vez de serviços em nuvem) leva à percepção de que cloud = data
center. O foco deve estar mais nos serviços de nuvem. Existem vários serviços de
nuvem, mesmo nas ofertas de nuvem de fornecedores. Por exemplo, no Amazon Web
Services, existe o Amazon Elastic Compute Cloud (EC2), o armazenamento em
nuvem do Amazon S3 e o Amazon Elastic Block Store (EBS).
Conselho: observe as decisões na nuvem com base na carga de trabalho

por carga de trabalho, em vez de usar uma abordagem "tudo ou nada". As estratégias
de terceirização de nuvem e datacenter estão relacionadas, mas não são a mesma
coisa. Assumir que a nuvem é "tudo ou nada" leva à análise errada. Procure vincular
as estratégias de nuvem e data center. Concentre-se em serviços de nuvem.
Mito 9: Migrar para a nuvem significa que você obtém automaticamente

todas as características da nuvem
A computação em nuvem tem atributos e características únicas. Os atributos

de nuvem do Gartner, por exemplo, incluem escalabilidade e elasticidade; eles usam
tecnologias de Internet baseadas em serviços (e self-service (autoatendimento)); eles
são compartilhados (e uniformes) e medidos pelo uso. Muitas migrações para a
nuvem são rehosting de "lift and shift" ou outros movimentos que não exibem essas
características em níveis mais altos. Estar "hospedado na nuvem" (mesmo se estiver
na nuvem IaaS) não significa que o que está hospedado também é um serviço de
nuvem. Existem outros tipos de migração na nuvem (refatoração e reescrita, por
exemplo) que normalmente oferecem mais dessas características. O caso de uso
mais comum para a nuvem, no entanto, são novos aplicativos.
Conselho: não assuma que "migrar para a nuvem" significa que as

características da nuvem são automaticamente herdadas de níveis inferiores (como
IaaS). Atributos de nuvem não são transitivos. Distinguir entre sistemas hospedados

na nuvem de serviços em nuvem. Há "meio-passos" na nuvem que têm alguns
benefícios (não há necessidade de comprar hardware, por exemplo) e podem ser
valiosos. No entanto, eles não fornecem os mesmos resultados.
Mito 10: Nuvem Privada = Virtualização
A virtualização é uma tecnologia de ativação comumente usada para

computação em nuvem. No entanto, não é a única maneira de implementar a
computação em nuvem (fornecedores de SaaS estabelecidos, como a
salesforce.com, fazem uso muito limitado dela, enquanto novas abordagens, como a
de conteinerização, estão ganhando força). Não só não é necessário, também não é
suficiente. Mesmo que a virtualização seja usada (e usada bem), o resultado não é a
computação em nuvem. Isso é mais relevante em discussões na nuvem privada em
que ambientes automatizados altamente virtualizados são comuns e, em muitos
casos, são exatamente o que é necessário. Infelizmente, eles são descritos
erroneamente como "nuvem privada" (veja o Mito 3 acima).
Conselho: Use o termo certo para descrever o que você está construindo.
Você não precisa estar na nuvem para ser bom. Evite expectativas erradas.
Desafios culturais ao migrar para a nuvem
Quando as organizações estão pensando em mover as cargas de trabalho

para a nuvem, o foco normalmente está na mudança de tecnologia e no quanto essa
mudança será difícil, conforme já falamos nos tópicos anteriores. No entanto, isso é
apenas metade do desafio. Mudar a cultura da empresa é igualmente, se não mais
importante, que mudar a tecnologia.
É verdade que mudar de servidores de rack, blades, switches TOR

roteadores, storage para usar serviços em nuvem em um ambiente compartilhado é
uma grande mudança técnica e foi descrita como uma mudança de paradigma no
pensamento de TI. Criação de instâncias através de um portal on-line pode ser
assustador para algumas organizações de TI legadas – principalmente porque você

não consegue ver as luzes piscantes dos servidores em que está trabalhando.
Qualquer mudança de tempo desta magnitude é introduzida, o medo do desconhecido
se arrasta. No entanto, com toda a honestidade, a peça técnica não é o maior desafio.
O maior desafio é mudar a cultura da equipe de TI que estará envolvida. Fazer com
que a organização entenda como essas mudanças podem ser positivas e como os
conceitos de nuvem podem impulsionar uma organização em um grupo eficiente e
simplificado é o maior obstáculo.
Primeiro, a mudança de cultura precisa vir de cima para baixo. Forçar

conceitos de nuvem em uma cultura de TI resistente pode tornar as coisas muito
difíceis e pode levar a falhas nas transformações da nuvem. Os técnicos de TI serão
rápidos em apontar isso, garantindo, assim, seu “papel” como gerente de qualquer
solução de HW à qual eles atendem atualmente. Sem uma mensagem consistente,
esses cenários continuarão a funcionar e os conceitos de nuvem de destruição nunca
sairão do papel.
A ideia de que uma organização tenha uma equipe de pessoas certificadas e

experientes que terão que mudar é o outro desafio. Quando essas equipes ouvirem
que terão que aprender uma nova tecnologia, os mais dissimulados sairão da zona
de conforto. Ninguém gosta de mudança, mas lidar com a mudança é a chave para o
sucesso. Existem três verdades na vida: a primeira, que vamos morrer; a segunda,
que vamos pagar impostos; e a terceira é a mudança.
É muito importante ajudar a organização a identificar as áreas que

apresentam o maior desafio de mudança. Fazer com que essas equipes se sintam
confortáveis e mostrar que isto faz parte da transformação digital.
Já participei de vários processos para estratégia de nuvem. Qual provedor

deve escolher? Qual parceiro deve escolher? Quão rápido deve fazer essa transição?
Ao longo de nossas conversas, continuei a fazer perguntas sobre seus negócios e
cultura da empresa, e não apenas sobre tecnologia e sua preferência por tecnologia.
Discutimos quão importante seria a transição cultural e que colocar uma estrutura em
torno dessa peça era tão importante quanto a tecnologia escolhida pela empresa.

Portanto, se você é uma organização que deseja se aventurar na nuvem,
certifique-se de considerar como essa transição afetará a cultura da empresa e
verifique se está preparada para enfrentar esse obstáculo, pois ela certamente terá
um impacto enorme no seu sucesso.
Uma empresa britânica de consultoria de TI, Riverbank IT Management, listou

as principais mudanças culturais ao migrar para a nuvem:
 Não subestime a necessidade de preparação técnica
Muitas organizações simplesmente não estão preparadas para mudar para a

nuvem.
É muito fácil começar a usar a nuvem. Antes que você perceba, seu ambiente
ficou fora de controle, e dezenas de pessoas que possuem credenciais de
administrador e podem destruir tudo.
É muito mais fácil estabelecer alguns padrões de segurança e governança no

começo do que tentar ajustá-los posteriormente.
 Finalmente trabalhando com outros departamentos
O Shadow IT tem sido um problema antes da computação em nuvem e

continua a ser uma dor de cabeça para os departamentos de TI com a incorporação
da nuvem.
As empresas devem realizar uma “anistia na nuvem” para descobrirem o que

tem dentro das organizações.
É provável que você já tenha soluções em nuvem operacionais em sua

empresa agora. Também é provável que seus canais formais não estejam cientes de
algumas dessas soluções, então vale a pena fazer com que seus departamentos
especifiquem explicitamente quais ferramentas eles usam para ver se alguma
eficiência adicional pode ser obtida através da agregação.

Se você não o fizer, os departamentos poderão ver os serviços na nuvem
como um buffet aberto para atender às suas próprias necessidades, levando a novos
vetores para dores de cabeça de TI sombreadas.
Isso pode levar à duplicação de serviços e, assim, desperdiçar investimentos,

aumentando o risco se os departamentos escolherem provedores de serviços que
não atendam às necessidades de conformidade; e reduzir o poder de barganha ao
tentar negociar acordos com provedores.
Os departamentos de TI devem ter a palavra final sobre quais serviços de

nuvem são adotados. No entanto, devem sempre serem alinhados ao negócio.
 Resistência à mudança
Se uma empresa leva a computação em nuvem a uma cultura de TI

resistente, o projeto pode se tornar tão difícil que provavelmente falhará.
Uma das questões-chave é, como dito antes, a mudança nas habilidades

necessárias. Muitos técnicos de TI, por exemplo, como especialização em suporte a
hardware, criação de servidores blade e assim por diante, podem descobrir que, se
quiserem continuar, terão que conseguir um emprego em um provedor de nuvem.
Você provavelmente terá alguns funcionários que não são felizes a menos
que possam enxergar os detalhes físicos. É importante ficar longe dessa mentalidade
e entender que os detalhes físicos são abstraídos; eles não são mais seu problema,
você está pagando a outra pessoa para se preocupar com eles para você.
Os servidores não devem mais ser tratados como animais de estimação, eles
precisam ser gerenciados como um todo.
Perder o acesso aos servidores físicos deixa as pessoas inquietas e pode

afetar sua confiança e, portanto, sua capacidade. Em alguns casos, os funcionários
podem se rebelar contra uma estratégia de nuvem antes mesmo de entrar em vigor
e, portanto, causarão interrupções na organização enquanto o plano estiver sendo
executado.

Algumas pessoas vão se rebelar porque acreditam que seus empregos
estarão em risco.
Há uma falsa percepção de que a nuvem removerá ou reduzirá a necessidade

de TI interna. Isso pode levar a uma situação em que as equipes de TI desafiam a
nuvem como uma opção, o que pode precipitar o deslize em direção a mais Shadow
IT.
As funções de TI podem se adaptar, e esses novos papéis podem ser

igualmente ou até mesmo mais recompensadores.
Devemos envolver todo mundo desde o início. Quando as pessoas recebem

tempo e poder para avaliar as tecnologias de nuvem, elas são mais propensas a
fornecer uma avaliação justa da tecnologia. Também é provável que se sintam
fortalecidos e com uma mente mais aberta.
 Mantendo todos atualizados, o tempo todo
Transparência, comunicação frequente e inclusão devem abordar as

preocupações dos funcionários e, ao mesmo tempo, ajudar a equipe de TI a manter
o foco.
É uma nova maneira de trabalhar talvez para muitas equipes de TI e, na

verdade, para muitas organizações. No entanto, manter todos informados sobre o que
está acontecendo, por que está acontecendo e quando está acontecendo pode ajudar
a dissipar qualquer preocupação que a equipe possa ter.
E manter as pessoas atualizadas não é apenas uma simples notificação por

e-mail de que um novo aplicativo estará disponível ou que um servidor não estará
funcionando no fim de semana - também significa aumentar a conscientização por
meio de treinamento e outros métodos.
O treinamento eficaz é um dos desafios que as empresas precisam resolver

para responder às preocupações e ajudar a fazer com que a nuvem funcione para
eles.

 Gerenciando as expectativas em torno da mudança
Uma das primeiras coisas que os líderes de TI precisam fazer é colocar suas
equipes na mentalidade de que as coisas vão mudar.
O que isso significa para os gerentes é que eles precisam ficar de olho nas
mudanças comportamentais dos funcionários. A nuvem pode permitir o acesso a
sistemas e dados corporativos de qualquer lugar, a qualquer momento, e isso pode
significar que a organização adotará uma abordagem de “trabalho flexível”, que é em
si uma decisão estratégica.
 Mantendo os dados seguros
Os dados estão seguros na nuvem? Você pode colocar sistemas essenciais

na nuvem? Bem, essas são esperançosamente perguntas que o líder de TI respondeu
antes de avançar com a computação em nuvem. Falaremos mais sobre segurança
no capítulo 4.
No entanto, uma coisa é certa: as mudanças na maneira como as

organizações funcionam significam que os dados vão cada vez mais residir nos
laptops e outros dispositivos dos funcionários. Os funcionários trazem suas próprias
soluções em nuvem para o ambiente de trabalho, baixando e usando ferramentas
como o Dropbox.
Isso traz seus próprios desafios para TI e RH, pois aumenta as chances de
violações de segurança, tanto acidentais quanto mal-intencionadas, pois os dados
corporativos são armazenados fora do perímetro da empresa.
 Medo do desconhecido
Ligados à “resistência à mudança” e à “manutenção de dados seguros”,

muitos funcionários ficam impressionados com o medo do desconhecido quando se
trata de nuvem. Mas isso não significa apenas que os funcionários se rebelarão contra
a computação em nuvem – outros podem apenas tentar evitar novas maneiras de
trabalhar, novos aplicativos e novos serviços que são fornecidos pela nuvem,

tornando-os improdutivos. E esse medo vai até os diretores de TI e executivos
seniores também.
O principal especialista da QA, Paul Gregory, diz:
Quando falo com diretores e gerentes de TI, eles são frequentemente

relutantes à nuvem e citam a segurança como a principal
preocupação. Mas quando as camadas são removidas e demonstro a
conformidade de segurança e regularidade (através da
documentação) com a qual a maioria dos data centers de nuvem
pública está em conformidade - o que excede em muito as empresas
com as quais estou falando - você encontra as preocupações reais
sobre a computação em nuvem: claro, o desconhecido. (GREGORY,
Paul).
5Rs do Gartner agora são os 6Rs da AWS
A Amazon Web Services atualizou os famosos 5Rs do Gartner. As estratégias

foram escritas em 2011, portanto precisamos caminhar para frente. A Amazon propõe
6 estratégias de migração mais comuns, conforme a figura 6.
Figura 6 – Estratégias de migração.

Rehosting - também conhecido como "lift-and-shift".
Descobrimos que muitos dos primeiros projetos de cloud gravitam em direção

ao novo desenvolvimento usando recursos nativos da nuvem, mas em um grande
cenário de migração legado em que a organização procura dimensionar sua migração
rapidamente para atender a um caso de negócios, descobrimos que a maioria dos
aplicativos foi rehosted. A GE Oil & Gas, por exemplo, descobriu que, mesmo sem
implementar nenhuma otimização de nuvem, poderia economizar cerca de 30% de
seus custos com a nova hospedagem.
A maioria dos rehosting pode ser automatizada com ferramentas (por

exemplo, AWS VM Import/Export, Racemi), embora alguns clientes prefiram fazer isso
manualmente conforme aprendem como aplicar seus sistemas herdados à nova
plataforma de nuvem.
Também descobrimos que os aplicativos são mais fáceis de

otimizar/reprojetar quando já estão em execução na nuvem. Em parte, porque sua
organização terá desenvolvido melhores habilidades para fazê-lo, e em parte porque
a parte difícil – migrar o aplicativo, os dados e o tráfego – já foi feita.
Replatforming - às vezes chamado de “lift-tinker-and-shift”.
Aqui, você pode fazer algumas otimizações na nuvem para obter algum
benefício tangível, mas, de outra forma, não está alterando a arquitetura principal do
aplicativo. Você pode estar procurando reduzir o tempo gasto gerenciando instâncias
de banco de dados migrando para uma plataforma de banco de dados como serviço,
como o Amazon RDS (Amazon Relational Database Service) ou migrando seu
aplicativo para uma plataforma totalmente gerenciada como o Amazon Elastic
Beanstalk.
A Amazon cita uma grande empresa de mídia que migrou centenas de

servidores da Web para a AWS e, no processo, migrou do WebLogic (um contêiner
de aplicativo Java que requer uma licença cara) para o Apache Tomcat, um
equivalente de código aberto. Essa empresa de mídia economizou milhões em custos
de licenciamento, além da economia e da agilidade obtidas ao migrar para a cloud.

Repurchasing - Mudança para um produto diferente.
Geralmente, vejo a recompra como uma mudança para uma plataforma

SaaS. Movendo um CRM para o Salesforce.com, um sistema de RH para o Workday,
um CMS para o Drupal e assim por diante.
Refactoring/Re-architecting - Repensando como o aplicativo é arquitetado

e desenvolvido, geralmente usando recursos nativos da nuvem.
Isso geralmente é impulsionado por uma forte necessidade comercial de

adicionar recursos, escala ou desempenho que, de outra forma, seriam difíceis de
alcançar no ambiente existente do aplicativo.
Você está procurando migrar de uma arquitetura monolítica para uma

arquitetura orientada a serviços (ou sem servidor) para aumentar a agilidade ou
melhorar a continuidade dos negócios.
Retire - se livrar de.
Depois de descobrir tudo no seu ambiente, você pode perguntar a cada área
funcional que possui cada sistema. Descobrimos que até 10% (eu já vi 20%) de um
portfólio de TI empresarial não é mais útil e pode ser simplesmente desativado. Essas
economias podem impulsionar o caso de negócios, direcionar a atenção escassa da
sua equipe para as coisas que as pessoas usam e diminuir a área de superfície que
você precisa proteger.
Retain - Geralmente, isso significa “revisitar” ou não fazer nada (por

enquanto).
Talvez você ainda esteja apresentando alguma depreciação, não esteja

pronto para priorizar um sistema que foi atualizado recentemente ou que não esteja
inclinado a migrar alguns aplicativos. Você deve migrar apenas o que faz sentido para
o negócio; e, à medida que a gravidade do seu portfólio muda do local para a nuvem,
você provavelmente terá menos motivos para reter.

Capítulo 3. Conectividade com a nuvem
Introdução
A rede pavimenta o caminho para a nuvem. Portanto, questões ligadas a

conectividade podem onerar ou até mesmo inviabilizar um projeto de cloud
computing. Empresas cuja sede ou algumas unidades ficam em regiões remotas – e,
portanto, com pouca oferta de telecomunicações – devem avaliar detalhadamente se
o uso de recursos em nuvem é viável, tanto em termos de custo quanto de
disponibilidade. Mesmo nos grandes centros, a necessidade de links dedicados ou de
backups de conectividade podem encarecer os projetos, o que faz desse um tema de
fundamental importância na equação da migração, por isto temos um capítulo
exclusivo.
Os líderes de infraestrutura e operações geralmente não conseguem

selecionar a melhor solução entre a conectividade da WAN e os serviços de nuvem
pública, causando um fraco desempenho. Vamos analisar as melhores opções com
o foco em requisitos de desempenho e custo.
Principais desafios
À medida que as cargas de trabalho saem do data center ou nascem na

nuvem, as arquiteturas de rede e os métodos de conectividade costumam ser
inadequados da perspectiva de segurança, desempenho e disponibilidade.
Novas e crescentes expectativas para a nuvem (por exemplo, flexibilidade,

agilidade e redução de custos) estão forçando os líderes de infraestrutura e
operações a avaliar novos projetos de rede e avaliar diferentes opções e provedores
de fornecimento de nuvem.
Os riscos e benefícios de diferentes opções de conectividade na nuvem não

são bem compreendidos pelas empresas, portanto, muitas vezes, fazem escolhas de
conectividade abaixo do ideal.

O que eu recomendo para os responsáveis pela arquitetura de redes:
‒ Escolha conexões de internet individuais para requisitos modestos ou

se planeja usar apenas um provedor de nuvem.
‒ Escolha a conectividade de WAN para nuvem baseada na operadora.
‒ Use plataformas de interconexão definidas por software para otimizar a

agilidade (SD-WAN).
Em 2020, mais de 30% das organizações estarão conectadas a provedores

de nuvem usando alternativas à Internet pública padrão, o que representa um
aumento significativo do que temos hoje, principalmente aqui no Brasil.
No entanto, infelizmente, as empresas geralmente abordam a conectividade

de WAN para a nuvem pública como uma reflexão tardia e, como resultado, eles
geralmente experimentam problemas significativos de desempenho durante o
dimensionamento. Eles não seguem consistentemente as práticas recomendadas:
‒ Desenvolvendo um projeto e experimentando a partir de uma

perspectiva técnica durante os estágios piloto de um projeto de adoção
da nuvem.
‒ Acompanhando um piloto de tecnologia, considerando o impacto do

dimensionamento do projeto na nuvem e na WAN.
Como resultado, quando a solução em nuvem é disponibilizada, geralmente

a adoção aumenta rapidamente, problemas de desempenho se desenvolvem
rapidamente, incluindo gargalos de desempenho, como resiliência e tempo de
atividade, segurança e intervalos de gerenciamento de rede/sistema. Felizmente,
existem maneiras melhores de superar esses problemas em escala. Vamos ver
quatro opções principais de conectividade de nuvem pública disponíveis atualmente:
Opção nº 1. Conectividade direta com a Internet.

Opção nº 2. Conectividade direta de WAN com nuvem pública (por exemplo,
Embratel, Vogel).
Opção nº 3. Plataformas de interconexão definidas por software (poucas

opções aqui no Brasil).
Opção nº 4. Hubs de rede estratégicos que fornecem recursos de nuvem em

nuvem (por exemplo, Equinix).
Desempenho e SLAs
Os serviços baseados na nuvem que usam a Internet, não se comprometem

com contratos de nível de serviço padrão (SLAs) baseados em desempenho de rede
para latência, jitter e pacotes descartados. Em contraste, as interconexões em nuvem
oferecem SLAs restritos, enquanto alguns provedores de serviços de rede e
provedores de interconexão definidos por software, oferecem SLAs equivalentes aos
serviços Multiprotocol Label Switching (MPLS), enquanto outros não. Uma
consideração crítica para conexões diretas da nuvem WAN é a de que os padrões de
QoS sejam respeitados de ponta a ponta. As soluções de interconexão definidas por
software geralmente precisam de circuitos de acesso e conexões cruzadas de
colocation, exigindo a consideração dos SLAs de vários provedores em toda a
solução de ponta a ponta.
Alta disponibilidade
As conexões com a Internet podem estar sujeitas a ataques de negação de

serviço (DoS) e outras interrupções de rede que não ocorrem em redes privadas
(Opção nº 2 a nº 4). As alternativas à conectividade com a Internet apresentam vários
níveis de alta disponibilidade, como failover automatizado e várias portas para
diversas infraestruturas; no entanto, os recursos variam entre provedores. Os serviços
diretos de conexão em nuvem WAN incluem failover automatizado quando os

serviços ou sites dos provedores de nuvem ficam off-line. Os níveis de resiliência
imediatamente disponíveis nos pontos de presença de interconexão definidos pelo
software (PoPs) variam, dependendo da demanda existente do cliente.
Tempo inicial de provisionamento
Isso envolve a rapidez com que o serviço e as dependências associadas

podem ser totalmente provisionados, de modo que uma conexão de rede possa ser
implantada de uma empresa para um serviço de nuvem. Como a conectividade com
a Internet é onipresente, uma conexão privada virtual (VPN) pode ser estabelecida
quase em tempo real. Para as WANs, os provedores estão construindo portais de
autoatendimento, portanto, uma vez que uma empresa assina esse serviço, eles
podem usar suas conexões WAN existentes. Interconexões em nuvem exigem tempo
para a compilação inicial, mas, uma vez em funcionamento, novas conexões de
nuvem pública/incrementais podem ser adicionadas rapidamente. As soluções de
interconexão definidas por software exigem que a empresa se conecte ao PoP de um
provedor, que pode ser tão rápido quanto uma conexão cruzada, mas também pode
exigir que os circuitos de acesso sejam provisionados. No entanto, uma vez
implementada, a flexibilidade e as mudanças subsequentes rápidas nas
interconexões são possíveis por meio de APIs ou de recursos de software simples.
Custos iniciais de Setup
A configuração de uma interconexão na nuvem pode ser demorada e exigir

um investimento significativo de capital para roteadores e equipamentos de
segurança na interconexão, a fim de obter o desempenho de longo prazo e a
economia de custos para a conectividade em nuvem pública. As infraestruturas de
Internet e WAN já estão em vigor, embora alguns provedores cobrem uma taxa de
instalação pelo seu serviço direto de conectividade de nuvem WAN. Plataformas de

interconexão definidas por software podem exigir custos de instalação para circuitos
de acesso a um PoP e taxas de interconexão dentro de um local de colocação.
É útil pensar nessas quatro opções como evolutivas, ou aditivas em

capacidades, em qualquer ordem ou combinação mais adequada à empresa. A
Internet direta é a mais simples e a mais provável de ser implementada em um teste
inicial, mas é a menos funcional a longo prazo. Assim, acreditamos que as opções nº
1 e nº 2 podem ser suficientes para a maioria das empresas; no entanto, esperamos
uma maior adoção da Opção nº 3 e nº 4 para atender aos requisitos técnicos de
solução, desempenho e agilidade e às complexas demandas de desempenho dos
requisitos de Multicloud. Cada uma das quatro opções tem seus benefícios, e eles
podem ser combinados para alcançar resultados deliberados; no entanto, os
responsáveis devem basear suas decisões em um entendimento claro dos requisitos
de negócios de longo prazo e dos méritos relativos de cada opção.
Análises
O grande volume e variedade de soluções SaaS baseadas em nuvem

significa que é quase certo que as empresas já estão usando pelo menos uma opção
de conectividade na nuvem.
À medida que as arquiteturas de datacenter híbridas se tornam mais comuns

e a confiança nas tecnologias de nuvem aumenta, as organizações provavelmente
buscarão várias abordagens de conectividade de nuvem simultaneamente para
atender às diferentes necessidades de negócios. Por exemplo, iniciativas de nuvem
baseadas em IaaS públicas podem exigir flexibilidade e baixo custo, enquanto
soluções baseadas em produção e baseadas em nuvem geralmente exigem
desempenho e consistência. Além disso, a conectividade de back-end (por exemplo,
banco de dados alimentando um aplicativo baseado em nuvem) e front-end (por
exemplo, usuários do O365) pode indicar abordagens técnicas totalmente diferentes.

Perguntas para consideração:
‒ Qual é a estratégia de nuvem da empresa IaaS, PaaS, SaaS?
‒ A conectividade em nuvem pode (ou deveria) ser planejada como parte

de um único esforço geral, em vez de esforços em silos, baseados em
projetos e de curta duração?
‒ Flexibilidade – com que rapidez a abordagem de conectividade

escolhida precisa se adaptar a requisitos novos e em constante
mudança, como volumes de tráfego, novos fornecedores de nuvem e
novos locais?
‒ Planejamento Multicloud – poucas empresas provavelmente

implementarão uma oferta de nuvem única e isolada; até que ponto a
conectividade entre instâncias de nuvem de diferentes provedores é
importante? O armazenamento de propriedade da empresa será
compartilhado entre várias ofertas de nuvem? As interações na nuvem
permanecerão com a TI retida (ou seja, bancos de dados)?
‒ Restrições financeiras – quanto a empresa está preparada para gastar

para configurar a solução e operá-la ao longo do tempo, e como você
está preparado para ser contratualmente comprometido?
‒ Capacidade de gerenciamento – a solução precisa ser simples de

configurar e gerenciar? Ou você está preparado para trocar alguma
simplicidade por benefícios incrementais?
‒ Desempenho, incluindo confiabilidade e disponibilidade – a

previsibilidade da chave de desempenho ou a variabilidade são
aceitáveis na busca por menores custos?
‒ Consistência geográfica – a solução deve estar disponível em todos os

locais com os mesmos recursos?

‒ Segurança e controle – a solução deve priorizar os fatores de segurança
e conformidade como requisitos críticos?
‒ Específicos do provedor de nuvem – para quais provedores você

precisa se conectar e onde estão seus PoPs de conectividade? Que
modelos de conectividade eles suportam?
Opção nº 1: Se os requisitos forem modestos ou você planeja usar apenas

um provedor de nuvem, escolha conexões de Internet básica (individual).
Um método inicial comum para conectar uma empresa a um CSP (cloud

service provider) público é por meio de uma conexão segura com a Internet, como
uma maneira de lidar com questões de desempenho, disponibilidade ou custo. Cada
empresa e provedor de nuvem pública está conectado à Internet, portanto, as
conexões podem ser configuradas rapidamente por meio de gateways existentes,
usando acesso distribuído resiliente e não centralizado através do data center. A
desvantagem dessa abordagem é a falta de garantias de desempenho e possível
exposição a ataques distribuídos de DoS. A Figura 7 ilustra a conectividade de rede
corporativa baseada na Internet.
Figura 7 – Conectividade de rede corporativa baseada na Internet.
Conexões diretas à Internet podem ser necessárias, com base em fatores

como o tipo de sistema, quem está consumindo esse sistema e sua localização,
dentro ou fora da empresa. WANs definidas por software, incluem conexões privadas
e/ou públicas para filiais e provedores de nuvem com um controlador centralizado.

Eles desempenharão um papel mais importante em garantir dinamicamente o
caminho ideal da rede e o desempenho do aplicativo, de ponta a ponta.
Os responsáveis devem usar a conexão na nuvem baseada na Internet

quando precisarem:
‒ Tempo rápido para comercializar/implantação.
‒ Diversidade de circuitos para melhorar a resiliência.
‒ Uso/compromisso planejado de curto prazo – de algumas semanas até,

talvez, 18 meses.
‒ Design e simplicidade de configuração.
Para essas ofertas específicas, os responsáveis devem se concentrar nos

seguintes adicionais:
‒ Desempenho adequado da aplicação.
‒ QoS.
‒ Proteção contra DDoS.
‒ Segurança.
‒ Capacidade de suporte a serviços Multicloud.
Opção nº 2: se a simplicidade e a consistência do serviço forem requisitos-

chave, escolha a conectividade WAN-to-Cloud baseada na operadora.
Um segundo método de conectar uma empresa aos CSPs é usar a WAN

corporativa responsável pela conectividade de nuvem direta. Nesse modelo, o NSP
(Network Solutions Provider's) já tem uma conectividade, pré-configurada, em um
CSP, portanto, adicionar conectividade é relativamente simples, em comparação a
uma empresa que solicita conexões de rede redundantes, roteadores de borda,
firewalls e espaço de rack associado para estabelecer conectividade diretamente no
PoP de cada CSP. Em essência, a operadora está efetivamente fornecendo uma linha

privada para um datacenter de colocation que oferece recursos diretos de nuvem em
nuvem, mas agrupa o trânsito e a interconexão como um único produto.
Nesse modelo, uma empresa pode adicionar dinamicamente CSPs e

capacidade, conforme necessário, à sua WAN existente, bem como modificar a
capacidade de interconexão sob demanda, normalmente por meio do portal NSP. A
Figura 14 retrata uma arquitetura de conectividade de nuvem WAN direta. Este
modelo também pode ser combinado com a Opção nº 1 (conectividade direta com a
Internet) descrita acima. Por exemplo, a conectividade de nuvem WAN direta pode se
conectar a uma interconexão de nuvem para casos de uso nos quais um NSP talvez
ainda não tenha uma conexão de nuvem direta com o CSP. Além disso, na
conectividade de nuvem WAN direta, uma empresa pode usar um serviço de firewall
gerenciado para minimizar o tráfego por meio do data center corporativo. Os serviços
de nuvem para nuvem que suportam aplicativos, como big data, podem fluir entre os
CSPs sem precisar fazer alterações por meio do data center corporativo.
Figura 8 – Conexão WAN-to-Cloud.
Os responsáveis devem usar esta conexão quando estiverem procurando:
‒ Simplicidade de gerenciamento – implementação rápida usando

operadoras e nuvens existentes.

‒ Fortes requisitos de desempenho e proximidade de interconexões.
‒ Custos mais baixos – o preço normalmente é menor do que a opção de

internet direta ou competitivo com as opções de colocation, porque a
conectividade com o NSP já foi estabelecida.
Para essas ofertas específicas, os responsáveis devem se concentrar nos

seguintes adicionais:
‒ A solução pode limitar os "alvos" da nuvem (ou seja, dois ou três

principais fornecedores de IaaS de grande escala, não centenas de
provedores de SaaS).
‒ Os clientes em potencial devem identificar onde as interconexões físicas

do CPS existem para evitar a introdução de maior latência.
‒ Os clientes em potencial devem documentar o lead time, o período de

compromisso e a capacidade de aumentar ou diminuir dinamicamente
a largura de banda da conexão para nuvens.
‒ Os clientes em potencial devem documentar a capacidade do NSP de

adicionar dinamicamente ou descartar conexões com ofertas de nuvem
específicas. Por exemplo, é possível estabelecer rapidamente (dentro
de uma semana) conectividade com o Provedor X e descartar a conexão
com o Provedor Y de maneira rápida?
Fiz questão de detalhar as duas principais opções para a realidade brasileira,

conforme já informei existem outras duas, mas que não vamos aprofundar, mas
fiquem à vontade para estudar também que são a Opção nº 3. Plataformas de
interconexão definidas por software e Opção nº 4. Hubs de rede estratégicos que
fornecem recursos de nuvem em nuvem.

Express Route
Dentre várias formas de acesso direto, WAN to Cloud, destaco o da Microsoft.

Aqui não estamos comercializando nada para nenhum fabricante, somente dando
exemplos práticos para ajudar no dia a dia. Inclusive a AWS possui sua solução que
é o Amazon Direct Connect
O Microsoft Azure ExpressRoute permite que você estenda suas redes locais
até a nuvem da Microsoft por meio de uma conexão privada, facilitada por um
provedor de conectividade. Com o ExpressRoute, você pode estabelecer conexões
com os serviços de nuvem da Microsoft, como o Microsoft Azure, o Office 365 e o
Dynamic 365.
A conectividade pode ocorrer de uma rede “qualquer para qualquer” (VPN IP),
uma rede Ethernet ponto a ponto ou uma conexão cruzada virtual por meio de um
provedor de conectividade em uma colocalização. As conexões de ExpressRoute não
passam pela Internet pública. Isso permite que as conexões de ExpressRoute
ofereçam mais confiabilidade, mais velocidade, latências menores e muito mais
segurança do que as conexões típicas pela Internet.
Principais benefícios:
Conectividade de Camada 3 entre sua rede local e a Microsoft Cloud por meio
de um provedor de conectividade. A conectividade pode ocorrer de uma rede
“qualquer para qualquer” (IPVPN), de uma conexão Ethernet ponto a ponto ou por
meio de uma conexão cruzada virtual via troca Ethernet.
‒ Conectividade com os serviços de nuvem da Microsoft em todas as

regiões da região geopolítica.
‒ Conectividade global com os serviços da Microsoft em todas as regiões.
‒ Roteamento dinâmico entre sua rede e a Microsoft por meio do BGP.
‒ Redundância interna em cada local de emparelhamento para

proporcionar maior confiabilidade.

‒ SLA do tempo de atividade da conexão.
Recursos:
Conectividade de Camada 3.
A Microsoft usa BGP, um protocolo padrão do setor para roteamento

dinâmico, a fim de trocar rotas entre sua rede local, suas instâncias no Azure e os
endereços públicos da Microsoft.
Redundância:
Cada circuito do ExpressRoute é formado por duas conexões com dois

roteadores de borda do Microsoft Enterprise (MSEEs) do provedor de
conectividade/borda de sua rede. A Microsoft exige uma conexão BGP dupla do
provedor de conectividade/da borda de sua rede, uma para cada MSEE. Você pode
optar por não implantar dispositivos redundantes/circuitos de Ethernet em seu lado.
No entanto, os provedores de conectividade usam dispositivos redundantes para
garantir que as conexões sejam entregues à Microsoft de forma redundante.
Opções de largura de banda
É possível comprar circuitos do ExpressRoute para várias larguras de banda.

As larguras de banda com suporte estão listadas abaixo. Isto depende também da
operadora escolhida:
‒ 50 Mbps;
‒ 100 Mbps;
‒ 200 Mbps;
‒ 500 Mbps;
‒ 1 Gbps;
‒ 2 Gbps;

‒ 5 Gbps;
‒ 10 Gbps.
Mais detalhes em: https://docs.microsoft.com/pt-br/azure/expressroute/.
Mais detalhes do mesmo serviço da IBM:

https://cloud.ibm.com/docs/infrastructure/direct-link/getting-started.html#introdu-o-
ao-ibm-cloud-direct-link.
Mais detalhes do mesmo serviço da AWS:

https://aws.amazon.com/pt/directconnect/.

Capítulo 4. Overview AWS, GCP e AZURE
AWS: Alucinados pelos consumidores
A cultura da Amazon sempre foi de fazer o possível pelos consumidores. Jeff

Bezos não tem só a cara de louco, ele realmente é louco pelo mercado.
Muitas das vezes, a AWS lança um produto sem ele estar nem mesmo pronto!
Isso é horrível? Sim! Porém abre uma vantagem absurda: a de ouvir os primeiros
clientes que aplicam para o teste da ferramenta.
AWS valoriza, capacita e apoia muito seus parceiros.
Google Cloud
Todos os grandes produtos da Google Cloud são frutos de anos de pesquisa

dentro da própria empresa.
Kubernetes: Nasceu no Google.
GCP preza pela inovação dos seus serviços. GCP, por sua vez, tem uma rede
de parceiros fraca e, francamente, não está nem aí para eles. Se tivesse uma boa
rede e um customer service decente, estaria despontando nessa briga, sem sombra
de dúvidas.
Azure: Open-Source Best-Friend
Desde que Satya Nadella assumiu como CEO da Microsoft, a estratégia da

empresa mudou muito. Você deve ter percebido isso após a compra do Github, pela
bagatela de U$ 7.5 bilhões. Mas o que talvez você não saiba, é que grande parte dos
novos serviços da Azure são sobre plataformas open-source amplamente adotadas.

O suporte da Azure e o apoio à rede de parceiros é bom, não é tão forte
quanto da AWS, mas muito melhor que o da Google. Com essa política, a Microsoft
diminui a fricção de adoção de cloud.
Isso sem contar que cloud híbrida já existe na Azure desde sua fundação,
principalmente para virtualização e bancos de dados.
AWS EC2 - Elastic Compute Cloud
O Amazon EC2 fornece os seguintes recursos:
‒ Ambientes de computação virtual, conhecidos como instâncias.
‒ Os modelos pré-configurados para suas instâncias, conhecidos como

Imagens de Máquina da Amazon (AMIs), que empacotam os bits de que
você precisa para seu servidor (incluindo o sistema operacional e
software adicional).
‒ Várias configurações de capacidade de CPU, memória,

armazenamento e redes para suas instâncias, conhecidas como tipos
de instância.
‒ Volumes de armazenamento persistentes para seus dados usando o

Amazon Elastic Block Store (Amazon EBS), conhecidos como volumes
do Amazon EBS.
‒ Vários locais físicos para seus recursos, como instâncias e volumes do

Amazon EBS, conhecidos como regiões e zonas de disponibilidade.
Regiões e Zona de disponibilidade
O Amazon EC2 está hospedado em vários locais no mundo todo. Esses locais
são compostos por regiões e zonas de disponibilidade. Cada região é uma área

geográfica separada. Cada região possui vários locais isolados conhecidos como
Zonas de disponibilidade. O Amazon EC2 lhe oferece a possibilidade de colocar
recursos, como instâncias e dados em vários locais. Os recursos não são replicados
entre as diversas regiões, a menos que você especifique isso.
Azure Virtual Machines
VM (Máquinas Virtuais) do Azure é um dos vários tipos de recursos de

computação sob demanda escalonáveis oferecidos pelo Azure. Normalmente, você
escolhe uma VM quando precisar de mais controle sobre o ambiente de computação
do que as outras opções oferecem. Este artigo fornece informações sobre o que você
deve considerar antes de criar uma VM, como criá-la e como gerenciá-la.
Uma VM do Azure oferece a flexibilidade da virtualização sem a necessidade

de comprar e manter o hardware físico que a executa. No entanto, você ainda precisa
manter a VM executando tarefas, como configurar, corrigir e instalar o software que
será executado nela.
Máquinas virtuais do Azure podem ser usadas de várias maneiras. Alguns

exemplos são:
‒ Desenvolvimento e teste – As VMs do Azure oferecem uma rápida e

maneira fácil de criar um computador com configurações específicas,
necessárias para codificar e testar um aplicativo.
‒ Aplicativos na nuvem – Como a demanda por seu aplicativo pode

flutuar, pode fazer sentido, em termos econômicos, executá-lo em uma
VM no Azure. Você paga por VMs extras quando precisa delas e as
desliga quando não são necessárias.
‒ Datacenter estendido – Máquinas virtuais em uma rede virtual do Azure

podem ser facilmente conectadas à rede de sua organização.

O número de VMs que o aplicativo usa pode ser escalado verticalmente e
horizontalmente para atender às suas necessidades.
O que é necessário pensar antes de criar uma VM?
Sempre há uma infinidade de considerações de design quando você cria uma

infraestrutura de aplicativo no Azure. Estes aspectos de uma VM são importantes a
considerar antes de começar:
‒ Os nomes dos recursos do aplicativo.
‒ O local onde os recursos são armazenados.
‒ O tamanho da VM.
‒ O número máximo de VMs que podem ser criadas.
‒ O sistema operacional que a VM executa.
‒ A configuração da VM após ela ser iniciada.
‒ Os recursos relacionados dos quais a VM precisa.

Referências
AWS. Disponível em: <https://aws.amazon.com/pt/>. Acesso em: 01 de fev. 2021.
GARTNER. Disponível em: <https://www.gartner.com/en>. Acesso em: 01 de fev.

2021.
MICROSOFT. Microsoft Docs. Disponível em: <https://docs.microsoft.com/en-us/>.

Acesso em: 01 de fev. 2021.

Apostila - Módulo 0 - Fundamentos de Cloud Computing

Enviado por

Direitos autorais:

Formatos disponíveis

Apostila - Módulo 0 - Fundamentos de Cloud Computing

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila - Módulo 0 - Fundamentos de Cloud Computing

Enviado por

Direitos autorais:

Formatos disponíveis

Fundamentos

Bootcamp Arquiteto Cloud Computing

Leandro César Lopes Evangelista

Bootcamp Arquiteto Cloud Computing – Página 2 de 47

Capítulo 1. A Nuvem ............................................................................................. 4

Capítulo 2. O mercado global de Cloud ................................................................. 6

O mercado global de Cloud .................................................................................... 6

Razões para adotar a Multicloud .......................................................................... 12

Os 10 principais mitos da nuvem .......................................................................... 14

Desafios culturais ao migrar para a nuvem ........................................................... 21

5Rs do Gartner agora são os 6Rs da AWS .......................................................... 27

Capítulo 3. Conectividade com a nuvem ............................................................. 30

Desempenho e SLAs ............................................................................................ 32

Alta disponibilidade ............................................................................................... 32

Tempo inicial de provisionamento......................................................................... 33

Custos iniciais de Setup ........................................................................................ 33

Express Route ...................................................................................................... 40

Capítulo 4. Overview AWS, GCP e AZURE ........................................................ 43

AWS: Alucinados pelos consumidores ................................................................. 43

Google Cloud ........................................................................................................ 43

Azure: Open-Source Best-Friend .......................................................................... 43

AWS EC2 - Elastic Compute Cloud ...................................................................... 44

Regiões e Zona de disponibilidade ....................................................................... 44

Azure Virtual Machines ......................................................................................... 45

Bootcamp Arquiteto Cloud Computing – Página 3 de 47

Nosso propósito é compartilhar com você os cenários do mundo “Cloud”, já

Além de analisar os impactos nos processos de negócio e de IT, você deve

A computação em nuvem deixa de ser discurso e se torna realidade no Brasil.

Veja a figura abaixo:

Figura 1 – Maiores prioridades da TI.

Segundo um estudo realizado pela empresa de consultoria em TI Logicalis,

Bootcamp Arquiteto Cloud Computing – Página 4 de 47

Figura 2 – Tipo de serviços de cloud.

Os motivos para a adoção cada vez maior da computação em nuvem estão

Fica evidente pelos resultados que as organizações estão percebendo os

Bootcamp Arquiteto Cloud Computing – Página 5 de 47

O mercado global de Cloud

Não poderíamos deixar de falar sobre os maiores provedores de IaaS do

Eles analisam com cuidado todos os aspectos dos provedores, detalhando as

Analisem abaixo o quadrante de Cloud IAAS e PASS mais recente, de agosto

Os líderes se distinguem oferecendo um serviço adequado para adoção

Bootcamp Arquiteto Cloud Computing – Página 6 de 47

O Gartner destaca que as avaliações dos clientes estão atualmente focadas

Bootcamp Arquiteto Cloud Computing – Página 7 de 47

Abaixo segue outro quadrante mágico, com o foco em prestadores de

Figura 5 – Quadrante mágico do Gartner IAAS Provedores de serviços.

O Quadrante Mágico mostra o posicionamento comparativo de fornecedores

Bootcamp Arquiteto Cloud Computing – Página 8 de 47

A maioria das organizações buscará uma estratégia Multicloud, embora a

Como a maioria das organizações terá uma estratégia Multicloud, elas

Os líderes de arquitetura empresarial e inovação tecnológica que planejam a

Escolher um provedor estratégico principal para uma função específica, como

Implementar o gerenciamento nativo do provedor de nuvem para simplificar a

Bootcamp Arquiteto Cloud Computing – Página 9 de 47

Usar uma arquitetura de aplicativo Multicloud quando necessário para

A maioria das organizações já adotou vários provedores de computação em

Multicloud refere-se ao uso de serviços em nuvem de vários provedores de

A computação em nuvem híbrida é definida como o provisionamento, uso e

Multicloud, não se refere ao uso simples de vários serviços de nuvem dentro

Bootcamp Arquiteto Cloud Computing – Página 10 de 47