Conceitos de computação em nuvem

A computação em nuvem dá às pessoas acesso a recursos computacionais por meio de uma rede quando precisam deles. Esses recursos incluem capacidade de processamento, armazenamento, bancos de dados, redes e aplicações completas. Eles vêm de um conjunto compartilhado e podem ser disponibilizados e devolvidos rapidamente, com pouca interação com a equipe do provedor.

Da compra de equipamentos à solicitação de capacidade

Um provedor de nuvem fornece serviços; um cliente ou consumidor os utiliza. AWS, Microsoft Azure e Google Cloud são grandes provedores de nuvem pública. Provisionar um recurso significa deixá-lo pronto para uso. Desprovisioná-lo significa liberá-lo. Uma carga de trabalho é a aplicação ou processo, seus dados e os recursos necessários para executá-lo.

Na computação em nuvem pública, o provedor é proprietário dos equipamentos físicos e os mantém. Os clientes obtêm os serviços necessários e pagam de acordo com o modelo de precificação do serviço. Uma organização também pode operar sua própria nuvem privada. Seus departamentos continuam retirando recursos de um conjunto compartilhado, e o sistema mede seu uso, mesmo que nenhum provedor externo envie uma fatura.

Compare as formas de operar uma loja virtual

Com TI nas instalações da organização, uma empresa compra um servidor para seu próprio prédio. A equipe escolhe o hardware, espera a entrega, instala um sistema operacional, conecta a rede e então instala a loja. A empresa também cuida de energia, refrigeração, reparos e eventual substituição. Ela precisa planejar a capacidade antes que as vendas revelem quanto será necessário.

Com uma VM na nuvem, um funcionário seleciona um tamanho e uma localização em um console web. O servidor pode ficar pronto em minutos. Se o experimento terminar após um mês, o funcionário exclui a VM. As cobranças de computação dela terminam, mas o armazenamento mantido separadamente ou outros recursos ainda podem gerar custos.

A hospedagem de equipamentos em data center muda a localização dos servidores próprios; ela não altera, por si só, a forma como são provisionados. Da mesma forma, um servidor alugado e acessado pela internet pode ser hospedagem tradicional. O acesso à rede, por si só, é apenas uma parte do modelo de nuvem.

Três perguntas distintas

A definição do NIST separa as características essenciais, os modelos de serviço e os modelos de implantação. As características perguntam: “Funciona como uma nuvem?” O modelo de serviço pergunta: “Quais camadas o provedor gerencia?” O modelo de implantação pergunta: “Para quem é a infraestrutura?” Uma nuvem privada pode fornecer IaaS, e uma nuvem pública pode fornecer SaaS.

Os dados na nuvem têm uma localização física em equipamentos de armazenamento nos centros de dados. Os clientes frequentemente escolhem uma região, embora geralmente não selecionem um disco ou host específico. “Na nuvem” descreve o modelo de fornecimento, não dados sem localização.

A NIST SP 800-145 descreve cinco características essenciais da computação em nuvem. Cada uma responde a uma pergunta prática diferente sobre a obtenção e o uso de recursos. Um serviço precisa da combinação completa; um grande conjunto de servidores ou uma página de pedidos on-line, por si só, não é suficiente.

As cinco características

1. Autosserviço sob demanda: os clientes criam recursos por conta própria sempre que necessário. Uma pessoa desenvolvedora pode provisionar um volume de 100 GB às 2h da manhã por um console ou API sem esperar por um funcionário do provedor. Uma API é uma interface que permite a um software fazer requisições a outro sistema.
2. Amplo acesso à rede: mecanismos de rede padronizados disponibilizam os serviços a diferentes dispositivos. Funcionários podem usar o mesmo serviço pelo navegador de um laptop, por um aplicativo de celular ou por um software que chama uma API via HTTPS. O acesso ainda pode exigir autenticação e uma conexão de rede privada.
3. Agrupamento de recursos: o provedor atribui e reatribui capacidade de processamento, memória, armazenamento e rede entre os clientes. Cada cliente é um locatário. A separação lógica protege os locatários enquanto os recursos físicos são compartilhados. Os clientes frequentemente podem escolher uma região sem saber qual servidor exato está envolvido.
4. Elasticidade rápida: a capacidade pode aumentar e diminuir rapidamente com a demanda. Uma plataforma de vídeo pode usar 4 servidores normalmente, 40 para uma final ao vivo e 4 depois. A automação frequentemente realiza essas mudanças, mas a definição também admite mudanças rápidas iniciadas por uma pessoa.
5. Serviço mensurado: o sistema registra o uso em unidades adequadas, como segundos de computação, GB de armazenamento ou contas ativas. Provedor e cliente podem monitorar, controlar e relatar o consumo.

Aplique os critérios a dois serviços

Uma empresa aluga um servidor dedicado após preencher um formulário de vendas. A entrega leva três dias e uma ampliação exige um novo contrato. Ela paga R$ 200 por mês. A espera descarta o autosserviço sob demanda, e o processo de ampliação não tem elasticidade rápida. O equipamento dedicado não é obtido de um conjunto compartilhado. Essas observações identificam uma hospedagem tradicional.

A mensalidade fixa não resolve a questão da medição. A empresa de hospedagem ainda poderia registrar o tempo de CPU ou o uso da rede. Medição e cobrança são diferentes: um medidor registra o consumo; uma regra de precificação transforma alguma medida em cobrança.

Agora considere um serviço de e-mail. Um administrador pode adicionar ou remover caixas de correio imediatamente, os usuários se conectam de diferentes dispositivos, a infraestrutura agrupada atende a muitas organizações, a capacidade muda com a demanda por contas e o serviço informa os usuários ativos. Essa combinação atende às cinco características, mesmo quando sua cobrança é uma assinatura mensal.

Reconheça uma correspondência parcial

Um departamento de TI pode executar muitas VMs enquanto os funcionários esperam dias para que cada solicitação seja aprovada e criada manualmente. A virtualização ajuda no agrupamento, mas esse processo não tem autosserviço. Adicionar um portal só é útil se a automação, o provisionamento rápido e a medição de uso o apoiarem.

Uma nuvem privada pode usar sua medição para relatórios de departamento ou cobranças internas. Portanto, o serviço mensurado se aplica mesmo sem uma fatura externa. A elasticidade também exige devolver capacidade: manter a capacidade de pico permanentemente deixa recursos ociosos após a queda da demanda.

A virtualização cria versões em software de recursos computacionais físicos. Ela permite que um servidor físico sustente vários computadores separados em software. Os operadores de nuvem combinam isso com automação, autosserviço e medição de uso para disponibilizar capacidade rapidamente.

Hosts, máquinas convidadas e hipervisores

Uma máquina virtual (VM) tem processadores virtuais, memória, discos e interfaces de rede. Ela executa seu próprio sistema operacional convidado e suas aplicações. O computador físico subjacente é o host. Um hipervisor cria as VMs, aloca capacidade física e mantém a memória e o armazenamento de cada VM logicamente separados.

Uma imagem de VM é um ponto de partida armazenado para uma máquina virtual. Um software pode criar uma VM a partir dessa imagem sem encomendar um novo servidor físico. Iniciar, redimensionar e excluir VMs favorece o provisionamento rápido e a elasticidade. O sistema de virtualização pode acompanhar o uso de recursos, o que permite a medição. Algumas plataformas também permitem a migração em tempo real, movendo uma VM em execução entre hosts para que a manutenção do hardware cause pouca ou nenhuma interrupção.

Resolva um exemplo de consolidação

Suponha que 12 servidores físicos de mesma potência usem, cada um, em média 10% da CPU. Sua carga média combinada é:

Isso equivale ao processamento de 1,2 servidor. Migrar as cargas de trabalho para VMs em dois hosts de mesma potência resulta em uma média por host de:

Dez máquinas físicas podem ser removidas, reduzindo gastos com energia, refrigeração e manutenção. Antes disso, a equipe também precisa verificar os picos de demanda de CPU e as necessidades de memória, discos e rede. O cálculo da média, por si só, não demonstra que dois hosts darão conta de todos os períodos de alta demanda ou de uma falha de host.

Compartilhar sem compartilhar dados

Multilocação significa que vários clientes usam uma infraestrutura compartilhada. O isolamento impede que um locatário acesse a memória ou os discos da VM de outro. Limites físicos compartilhados ainda podem afetar o desempenho: um locatário excepcionalmente ocupado pode disputar capacidade, no chamado efeito do vizinho barulhento. Controles de recursos limitam esse efeito. Hosts dedicados fornecem um servidor físico inteiro aos clientes cujos requisitos exigem isso.

A virtualização de armazenamento apresenta discos agrupados como volumes virtuais. A virtualização de rede fornece redes separadas definidas por software sobre conexões físicas compartilhadas.

Contêineres empacotam aplicações, bibliotecas e configurações enquanto compartilham um núcleo de sistema operacional. Uma VM tem um sistema operacional convidado completo; um contêiner não. Contêineres geralmente iniciam mais rapidamente e usam menos recursos, enquanto VMs oferecem uma separação mais forte no nível do sistema operacional e podem executar diferentes sistemas convidados. Contêineres frequentemente são executados dentro de VMs.

Uma nuvem também pode oferecer servidores diretamente no hardware por autosserviço. A virtualização é um fundamento importante, enquanto as cinco características do serviço determinam se a oferta como um todo é computação em nuvem.

Um modelo de serviço descreve o que o provedor fornece e o que o cliente gerencia. Imagine a tecnologia em camadas: prédios e equipamentos físicos, virtualização, sistema operacional, middleware e ambiente de execução, aplicação e dados. Um ambiente de execução é o ambiente de software que executa o código de uma aplicação, como Python ou Java.

Compare os três modelos padrão

Com a TI nas instalações da organização, ela gerencia toda a pilha. De IaaS para PaaS e SaaS, o provedor assume mais trabalho. O cliente ganha conveniência e abre mão de parte da liberdade para alterar o sistema subjacente.

Um blog, três formas de executá-lo

Um cliente IaaS inicia uma VM Linux, instala o servidor web, o banco de dados e o software de blog e mantém essas camadas. O provedor continua reparando o host físico e mantendo o hipervisor. A aplicação de correções ao sistema operacional convidado cabe ao cliente.

Um cliente PaaS implanta uma aplicação de blog em uma plataforma com suporte. O provedor fornece atualizações do sistema operacional e do ambiente de execução. O cliente mantém a aplicação e precisa seguir o processo de atualização da plataforma. No AWS Elastic Beanstalk, é possível ativar atualizações gerenciadas de correção e secundárias; os clientes mantêm os ambientes em versões com suporte e resolvem falhas de atualização. Se desativarem as atualizações gerenciadas, ficam responsáveis por aplicá-las.

Um cliente SaaS assina uma aplicação de blog pronta e começa a escrever. O provedor opera a aplicação, mas o cliente ainda controla quem pode publicar e qual conteúdo é compartilhado.

Reconheça exemplos comuns

Bancos de dados gerenciados, como Amazon RDS, Azure SQL Database e Google Cloud SQL, geralmente são tratados como PaaS: o cliente usa um banco de dados sem manter a plataforma de servidores subjacente.

Classifique o serviço, não a empresa que o vende. Um provedor pode oferecer os três modelos, e alguns produtos dividem as responsabilidades de formas que ficam entre as categorias clássicas. Leia as responsabilidades da oferta específica quando o nome, por si só, não for claro.

Nomes mais específicos seguem a mesma ideia. DBaaS significa banco de dados como serviço; FaaS significa função como serviço; XaaS é uma designação ampla para “qualquer coisa como serviço”. Qualquer que seja o nome, os dados do cliente e as decisões de acesso ainda precisam ter um responsável.

Computação sem servidor significa que o cliente usa código ou um serviço sem escolher, dimensionar ou manter seus servidores. Os servidores continuam fazendo o trabalho. O provedor gerencia a infraestrutura e o escalonamento, e as cobranças usam medidas específicas de cada serviço.

Acompanhe um evento por uma função

Com função como serviço (FaaS), o cliente envia uma pequena unidade de código. Um evento aciona uma execução: uma requisição web, um arquivo enviado, uma mensagem em fila ou um agendamento. Para um serviço de fotos, a sequência é:

1. Um cliente envia uma fotografia para o armazenamento.
2. O evento de envio inicia uma função.
3. A função cria e armazena uma miniatura.
4. A execução termina.

AWS Lambda, Azure Functions e Google Cloud Run functions são exemplos. As funções geralmente são escalonadas a zero quando ociosas e cobram por requisições e tempo de execução. A computação sem servidor também inclui serviços como Amazon S3, Amazon DynamoDB e Google BigQuery. Os dados armazenados podem continuar gerando cobranças enquanto nenhum código é executado. Planos de funções com capacidade sempre pronta também podem cobrar durante períodos sem atividade.

Calcule a fatura de uma função

Considere tarifas ilustrativas de R$ 0,20 por milhão de requisições e R$ 0,000017 por GB-segundo. Cada uma das 3 milhões de requisições usa 0,5 GB de memória por 200 milissegundos, ou 0,2 segundo.

Primeiro calcule o tempo total de execução e depois o uso de memória por tempo:

A computação custa R$ 5,10 e as requisições custam R$ 0,60, totalizando R$ 5,70. Neste exemplo de precificação, não há cobrança mínima nem de computação ociosa. Uma VM a R$ 0,05 por hora durante 730 horas custa R$ 36,50.

Cada requisição custa R$ 0,0000019 no exemplo. Dividir R$ 36,50 por esse valor resulta em cerca de 19,2 milhões de requisições. Acima desse volume, a VM tem um preço de tabela de computação menor, desde que consiga lidar com o trabalho. Armazenamento, uso da rede e administração também são importantes para uma comparação completa.

Entenda os limites de operação

Uma inicialização a frio é o atraso enquanto o serviço prepara um ambiente de execução. Uma função deve ser sem estado: execuções posteriores não devem depender da memória ou de arquivos locais de execuções anteriores. Coloque dados permanentes em um banco de dados ou serviço de armazenamento.

Cada oferta tem limites de execução. Invocações padrão do AWS Lambda têm duração máxima de 15 minutos. Alguns modos de invocação do Lambda Managed Instances permitem execuções mais longas; o modo de serviço aplicável determina o limite. Trabalhos longos devem respeitar as regras do serviço escolhido.

A computação sem servidor frequentemente é adequada para tráfego irregular, processamento de eventos, trabalhos curtos agendados e automação. O uso intenso e constante pode favorecer outras opções de computação. A necessidade de configurações personalizadas do sistema operacional também pode inviabilizar uma plataforma de funções. Gatilhos e APIs específicos do provedor podem dificultar uma migração futura.

A computação sem servidor costuma ser agrupada com PaaS. Sua infraestrutura gerenciada reduz o trabalho com servidores, enquanto o cliente continua protegendo código, permissões, configuração e dados.

Comece a escolha de um modelo de serviço pelos requisitos da carga de trabalho. Uma tecnologia familiar pode ser uma escolha ruim se criar uma manutenção que a equipe não consegue assumir. Um produto altamente gerenciado também pode ser uma escolha ruim se retirar o controle de que a aplicação precisa.

Pergunte o que precisa ser controlado

Use estas perguntas em ordem:

1. Uma aplicação pronta atende à necessidade do negócio? Considere SaaS.
2. A equipe está implantando sua própria aplicação em uma linguagem com suporte sem precisar controlar o sistema operacional? Considere PaaS.
3. O trabalho é curto, acionado por eventos e tem volume irregular? Considere funções sem servidor.
4. A equipe precisa controlar o sistema operacional convidado, instalar software especial ou migrar um servidor sem alterações? Considere IaaS.

PaaS e computação sem servidor se sobrepõem. A escolha útil é o serviço específico cujo modelo de execução, limites e ferramentas aceitas sejam adequados à aplicação.

Associe requisitos a modelos

Para a aplicação antiga, IaaS fornece controle de uma VM, não controle irrestrito do hardware físico do provedor. A compatibilidade e o suporte ainda precisam ser verificados. Para SaaS, confirme se os recursos e configurações disponíveis atendem aos requisitos antes de aceitar a conveniência.

Inclua o esforço operacional no custo

Suponha que uma VM custe R$ 40 por mês e precise de quatro horas de administração a R$ 50 por hora. A administração custa R$ 200, portanto o total é R$ 240. Um plano PaaS adequado custa R$ 90 com quase nenhuma administração neste exemplo. Sua tarifa de serviço mais alta vem acompanhada de um custo total menor.

A comparação do trabalho inclui aplicação de correções, monitoramento, cópias de segurança, atualizações de aplicações e as competências necessárias para responder quando algo falha. Transferir mais camadas para o provedor reduz algumas dessas tarefas, mas não elimina o gerenciamento da aplicação ou do acesso.

Combine modelos quando os trabalhos forem diferentes

Uma empresa pode usar SaaS para gerenciamento de relacionamento com clientes, PaaS para seu site, funções para processar novos pedidos e uma VM para um componente antigo. Cada serviço tem seu próprio limite de gerenciamento.

A portabilidade também faz parte da decisão. VMs e contêineres podem ser relativamente fáceis de mover quando suas dependências são portáveis. Plataformas gerenciadas e gatilhos de funções podem vincular o código a um provedor. Dependência de fornecedor é o esforço e o custo adicionais criados por essa dependência.

Uma decisão pode mudar com o tempo. Rehospedar uma aplicação em uma VM pode ser um primeiro passo útil, seguido mais tarde por uma migração de plataforma. O motivo para escolher IaaS deve ser um requisito atual, como o controle do sistema operacional, e não apenas a familiaridade.

Um modelo de implantação descreve os usuários para os quais a infraestrutura de nuvem é disponibilizada. Um modelo de serviço descreve as camadas fornecidas. São escolhas distintas: uma organização pode obter máquinas virtuais por meio de IaaS em uma nuvem pública ou privada.

Nuvem pública

A infraestrutura de nuvem pública está disponível para uso pelo público em geral. Um provedor é seu proprietário e a opera em seus centros de dados. AWS, Microsoft Azure e Google Cloud são exemplos; outros provedores incluem Oracle Cloud, IBM Cloud e Alibaba Cloud.

Os clientes compartilham a infraestrutura e geralmente acessam os serviços pela internet, embora o acesso por rede privada também seja possível. Eles evitam comprar equipamentos físicos, podem obter grandes quantidades de capacidade rapidamente e escolher entre locais no mundo todo. Eles também dependem das escolhas de serviços do provedor e da conectividade de rede, com menos controle do hardware físico.

“Pública” descreve quem pode se tornar cliente. Isso não significa que todos possam ver os dados de cada cliente. O isolamento e os controles de acesso separam os recursos. Tornar um contêiner de armazenamento legível publicamente é uma escolha de configuração, não uma característica inevitável da nuvem pública.

Nuvem privada

Uma nuvem privada é reservada para uma organização, possivelmente com muitos departamentos. A organização, terceiros ou ambos podem operá-la. Ela pode estar no prédio da organização ou ser hospedada em outro lugar.

A nuvem privada oferece controle mais próximo dos equipamentos, da localização e da configuração de segurança. Esse controle pode ajudar com requisitos contratuais ou regulatórios específicos. O operador precisa financiar a capacidade e empregar pessoas para operá-la. A expansão é limitada pelo hardware disponível, portanto há menos economias de escala do que em um grande provedor público.

Uma sala de servidores nas instalações da organização só é considerada uma nuvem privada quando fornece características de nuvem, incluindo autosserviço, agrupamento, elasticidade rápida e uso mensurado. Instalar VMs, por si só, deixa partes importantes desse modelo de serviço ausentes. O OpenStack é um exemplo de software usado para construir nuvens privadas.

Nuvem comunitária

Uma nuvem comunitária atende a um grupo específico de organizações com interesses comuns. Elas podem compartilhar uma missão, uma política de segurança ou requisitos de conformidade. Organizações membros, terceiros ou uma combinação deles podem operá-la, dentro ou fora de suas instalações. Vários hospitais poderiam compartilhar uma infraestrutura projetada em torno de seus requisitos comuns para dados de saúde.

Uma oferta exclusiva para o governo pode atender a uma comunidade, mas os critérios reais de elegibilidade e o arranjo operacional determinam sua classificação. A localização, por si só, não identifica um modelo de implantação. Uma nuvem privada hospedada continua privada mesmo estando no prédio de um fornecedor.

As organizações frequentemente mantêm algumas cargas de trabalho localmente e executam outras em nuvens públicas. Os nomes nuvem híbrida e multinuvem descrevem características diferentes desse arranjo. Uma empresa pode ter ambos ao mesmo tempo.

Conecte ambientes em um modelo híbrido

O NIST define nuvem híbrida como infraestruturas de nuvem distintas conectadas por tecnologia que permite a transferência de dados ou aplicações entre elas. Os componentes permanecem separados. Nas discussões cotidianas sobre nuvem, inclusive nos exames básicos dos provedores, híbrida geralmente significa nuvem pública conectada a uma nuvem privada ou a sistemas nas instalações da organização.

Uma conexão segura pode ser uma VPN criptografada pela internet ou uma conexão privada dedicada. Ferramentas compartilhadas de identidade e gerenciamento podem ajudar a equipe a operar os ambientes em conjunto. Azure Arc, AWS Outposts e Google Distributed Cloud oferecem suporte a diferentes formas de operação entre localidades; são exemplos, não produtos intercambiáveis.

O modelo híbrido pode manter registros sensíveis, software antigo ou sistemas de controle de equipamentos localmente, enquanto a nuvem pública hospeda um site ou atende à demanda adicional. Ele também apoia a migração em etapas e arranjos remotos de cópia de segurança ou recuperação. Esses benefícios trazem trabalho adicional de rede, segurança e gerenciamento.

Resolva um exemplo de expansão temporária para a nuvem pública

A nuvem privada de uma varejista processa 2.000 pedidos por minuto. Durante uma promoção, a demanda sobe para 5.000. A nuvem pública processa o excedente:

Sua parcela do trabalho no pico é:

Isso é expansão temporária para a nuvem pública: a capacidade adicional é usada durante os picos e liberada depois. A aplicação e as conexões de dados precisam permitir a divisão desse trabalho. Simplesmente assinar um segundo serviço não faz a expansão acontecer.

Use vários provedores públicos

Multinuvem significa usar serviços de dois ou mais provedores de nuvem pública. Uma empresa pode escolher a análise de dados de um provedor e a hospedagem web de outro. Os serviços podem ser usados separadamente; a multinuvem não exige mover a mesma carga de trabalho entre eles.

Os possíveis motivos incluem escolher a melhor opção para cada tarefa, atender a requisitos de localização, reduzir a dependência de um fornecedor ou combinar sistemas após uma fusão. Os custos incluem diferentes conjuntos de competências, ferramentas de segurança e faturas de transferência de dados.

Para uma startup sem centro de dados, a nuvem pública pode minimizar o gasto inicial com equipamentos. Uma organização com requisito de infraestrutura exclusiva pode escolher a nuvem privada. Uma fábrica que precisa de tempos de resposta locais muito curtos pode manter o controle das máquinas no local enquanto usa a nuvem pública para análise. O requisito de cada carga de trabalho orienta a decisão de posicionamento; usar mais ambientes aumenta o trabalho necessário para conectá-los e governá-los.

A capacidade na nuvem pode ser ajustada conforme o trabalho muda. Escalabilidade descreve essa capacidade de ajuste. Elasticidade acrescenta expansão e redução rápidas para que a capacidade acompanhe de perto a demanda. Ambas podem reduzir a necessidade de comprar equipamentos para a maior carga possível.

Escalone uma máquina ou altere a quantidade de máquinas

Alterar uma VM de 2 para 8 vCPUs é escalonamento vertical. Passar de 2 servidores web para 6 é escalonamento horizontal. Um balanceador de carga distribui as requisições recebidas entre as cópias. Cópias adicionais também podem fornecer redundância, desde que sejam implantadas para resistir às falhas relevantes.

Uma política de escalonamento automático pode adicionar uma VM depois que o uso de CPU permanecer acima de 70% por cinco minutos e remover uma quando permanecer abaixo de 30%. Um mínimo de duas e um máximo de dez mantêm a política dentro de uma faixa planejada. Uma única VM na nuvem não se ajusta sozinha apenas por estar na nuvem. Alguns serviços gerenciados cuidam do escalonamento para o cliente.

Calcule a capacidade economizada pela elasticidade

Um site de ingressos precisa normalmente de 4 servidores e de 20 durante 10 horas em um mês de 730 horas. Manter 20 funcionando o mês inteiro usa:

Com capacidade elástica, primeiro mantenha os quatro servidores normais durante o mês inteiro:

Depois adicione apenas os 16 servidores extras para o pico:

O total é 3.080 horas de servidor, cerca de 21% de 14.600. Contar 20 servidores extras durante o pico contaria os quatro servidores de base duas vezes. Manter apenas quatro permanentemente evitaria capacidade ociosa, mas deixaria o pico sem atendimento.

Provisione rapidamente e alcance usuários no mundo todo

Agilidade é a rapidez para obter recursos, testar uma ideia e entregar um resultado. Uma equipe pode alugar 50 VMs para uma análise de duas horas, usando 100 horas de VM, e depois liberá-las. Ela evita esperar que 50 máquinas sejam compradas e instaladas. Experimentos rápidos tornam menos custoso rejeitar uma ideia que fracassa.

Alcance global significa usar locais do provedor no mundo todo sem construir centros de dados no exterior. Posicionar uma aplicação mais perto dos usuários pode reduzir a latência, o atraso na comunicação. Ainda é necessário escolher uma localização adequada e atender aos requisitos de dados da carga de trabalho.

O trabalho do provedor com hardware também libera tempo da equipe para produtos e serviços.

Disponibilidade é a parcela de um período em que um serviço está funcionando e utilizável. Alta disponibilidade usa componentes redundantes para manter baixo o tempo de indisponibilidade quando algo falha. A confiabilidade também diz respeito a continuar funcionando corretamente e se recuperar de falhas.

Transforme uma porcentagem em tempo de indisponibilidade

Use a parcela indisponível do período:

Um mês de 30 dias tem 43.200 minutos. Com 99,95%, a parcela indisponível é 0,0005, portanto o tempo de indisponibilidade é de 21,6 minutos.

Um acordo de nível de serviço (SLA) estabelece o compromisso formal de um provedor e a compensação. A compensação frequentemente consiste em créditos de serviço, com condições de elegibilidade e exclusões, e não em indenização por todas as perdas do negócio. O SLA de um serviço pode depender do uso de várias instâncias ou localizações. Ofertas gratuitas ou em prévia podem não ter SLA.

Diferencie dependências de cópias redundantes

Se uma aplicação precisa tanto de sua camada web quanto do banco de dados, cada um pode interromper a aplicação. Em um modelo simplificado com falhas independentes e medições comparáveis, multiplique suas disponibilidades em decimal:

Isso equivale a cerca de 99,94%, abaixo de qualquer um dos componentes. Os compromissos de SLA, por si só, não estabelecem o tempo real de funcionamento da aplicação; dependências compartilhadas e regras de medição também importam.

Para duas cópias independentes em que qualquer uma é suficiente, ambas precisam falhar para interromper o serviço. Se cada uma está disponível 99% do tempo, cada uma tem uma parcela de falha de 1%:

A independência é essencial. Cópias que dependem da mesma fonte de energia que falhou não oferecem essa proteção.

Use a proteção e a medida adequadas

Os provedores oferecem centros de dados separados chamados zonas de disponibilidade, várias regiões e replicação gerenciada. Cópias em zonas separadas podem proteger contra a falha de um centro de dados; uma segunda região pode proteger contra um incidente regional mais amplo. Projetar e pagar por cópias adequadas continua sendo uma decisão do cliente.

A tolerância a falhas busca manter a operação sem interrupção após a falha de um componente. A alta disponibilidade pode permitir uma breve interrupção. A recuperação de desastres restaura serviços e dados após um incidente grave. Cópias de segurança protegem os dados, mas não mantêm um servidor que falhou atendendo requisições durante a restauração.

A previsibilidade inclui desempenho consistente e custos compreensíveis. Escalonamento e balanceamento de carga ajudam a gerenciar o desempenho; relatórios de uso, previsões, orçamentos e alertas ajudam a gerenciar os gastos. Maior disponibilidade geralmente exige recursos adicionais, portanto a meta deve refletir o custo da indisponibilidade para o negócio.

Os provedores de nuvem oferecem equipes de segurança, controles físicos e monitoramento em uma escala que muitas organizações não conseguem construir por conta própria. Eles também oferecem ferramentas que ajudam os clientes a aplicar regras consistentes. O benefício vem do uso dessas ferramentas e da atribuição clara das responsabilidades.

Use a segurança e as evidências de conformidade do provedor

Os provedores protegem prédios, equipamentos e redes físicas. Eles mantêm sua infraestrutura e fornecem atualizações de plataforma para serviços gerenciados. Os clientes podem usar controles de identidade, criptografia, firewalls, monitoramento de segurança e proteção contra ataques de negação de serviço distribuída, nos quais muitos sistemas inundam um serviço com tráfego.

Os provedores também passam por auditorias segundo normas e frameworks como ISO/IEC 27001 e SOC 2. Esses relatórios fornecem evidências sobre os controles do provedor. As regras de acesso, o tratamento de dados e a configuração dos serviços do cliente ainda precisam atender aos requisitos da organização. A auditoria do provedor é uma parte dessas evidências, não a aprovação de todas as aplicações executadas ali.

Mantenha o uso da nuvem dentro das regras da organização

Governança é o conjunto de políticas, processos e controles que alinham o uso da nuvem às regras de negócios, obrigações legais e orçamentos. Ela inclui muito mais do que reduzir faturas.

Por exemplo, uma organização pode restringir a criação de VMs a um conjunto aprovado de regiões. Uma política rejeita uma solicitação fora desse conjunto antes que o recurso exista. Etiquetas podem identificar a equipe responsável por uma VM, enquanto registros mostram quem a alterou. Cada ferramenta responde a uma pergunta diferente de gerenciamento.

Gerencie recursos de forma consistente

A Microsoft distingue o gerenciamento da nuvem, as capacidades usadas para operar recursos, do gerenciamento na nuvem, os métodos que as pessoas usam para controlá-los. O primeiro inclui escalonamento automático, verificações de integridade, substituição de recursos que falharam e alertas. O segundo inclui um portal, interface de linha de comando (CLI), APIs, kits de desenvolvimento de software (SDKs) e infraestrutura como código.

A infraestrutura como código (IaC) descreve recursos em arquivos que ferramentas de implantação podem ler. Um modelo para duas VMs web, um balanceador de carga e um banco de dados pode criar um ambiente de teste equivalente em minutos. A mesma descrição de recursos pode ser usada novamente sem precisar lembrar uma sequência de cliques manuais. Configurações específicas da região e outros valores necessários ainda precisam estar corretos.

A automação também pode programar desligamentos, aplicar atualizações ou fazer cópias de segurança. Menos ações manuais repetidas reduzem as oportunidades de configurações inconsistentes e podem diminuir os custos operacionais. Após um teste, excluir seus recursos encerra as cobranças específicas deles; cópias de segurança, discos ou outros serviços mantidos continuam sendo cobrados. Acompanhar esses recursos restantes faz parte do gerenciamento do ambiente.

A computação em nuvem transfere grande parte dos gastos da compra de ativos para o pagamento de serviços conforme são usados. Entender as medidas de uso é o primeiro passo para ler uma fatura e comparar a nuvem com equipamentos próprios.

Compare os tipos de despesa

A despesa de capital (CapEx) compra ativos usados por vários anos, como servidores e equipamentos de armazenamento. A contabilidade distribui seu custo por meio da depreciação. A despesa operacional (OpEx) paga custos contínuos, como eletricidade, assinaturas e serviços de nuvem, à medida que ocorrem.

Os custos de capacidade nas instalações da organização são em grande parte fixos: equipamentos comprados, espaço e equipe continuam custando dinheiro quando as máquinas estão pouco ocupadas. As cobranças de nuvem baseadas no consumo variam com o uso. Um compromisso ou assinatura por usuário ainda pode criar uma parte fixa na fatura de nuvem.

O pagamento conforme o uso permite que os clientes obtenham recursos sem um compromisso de uso de longo prazo. Liberar um recurso encerra suas próprias cobranças de uso. Apenas deixar de usar uma VM alocada não a libera, e excluir uma VM pode deixar discos ou cópias de segurança cobrados separadamente.

Leia uma fatura linha por linha

Use um mês de 730 horas e tarifas ilustrativas. Duas VMs funcionam o mês inteiro a R$ 0,10 por hora. Uma terceira funciona por 120 horas. O armazenamento tem média de 500 GB a R$ 0,02 por GB-mês, e 200 GB saem para a internet a R$ 0,09 por GB.

• Computação de base: dois períodos de 730 horas resultam em 1.460 horas de VM, ao custo de R$ 146.
• Computação adicional: 120 horas custam R$ 12.
• Armazenamento: 500 GB-mês custam R$ 10.
• Saída de dados: 200 GB custam R$ 18.

Some as cobranças separadas:

O total mensal é R$ 186. Saída de dados é a transferência de dados para fora da nuvem; entrada de dados é a transferência para dentro dela. Muitas ofertas tornam a entrada gratuita e cobram pela saída para a internet ou por transferências entre regiões. Um serviço de mídia que envia arquivos grandes aos usuários precisa incluir esses volumes de saída em sua estimativa.

Compare o custo total de propriedade

O custo total de propriedade (TCO) compara todos os custos relevantes ao longo do mesmo período. Para TI própria, inclua equipamentos e substituição, licenças de software, espaço, energia, refrigeração, segurança física, rede e tempo da equipe. Para a nuvem, inclua computação, armazenamento, transferências, licenças, administração e quaisquer custos de migração relevantes para a comparação.

Grandes provedores obtêm economias de escala ao comprar e operar equipamentos em grandes volumes e compartilhar esses custos entre os clientes. Seus custos unitários menores podem permitir preços atraentes. A economia de uma carga de trabalho específica ainda depende da utilização, do dimensionamento adequado e do plano usado. Executar continuamente recursos superdimensionados pode custar mais que um servidor próprio bem utilizado.

Gastos baseados no uso também exigem acompanhamento. Recursos esquecidos e escalonamento inesperado podem elevar uma fatura variável. Monitoramento, previsões, orçamentos e alertas ajudam a equipe a reagir enquanto os recursos ainda estão em execução.

A precificação em nuvem envolve uma escolha entre flexibilidade, compromissos de uso e risco de interrupção. Comece pelo uso esperado da carga de trabalho e escolha os termos adequados.

Compare as principais opções de precificação

A AWS oferece Reserved Instances e Savings Plans; o Azure oferece Reservations e savings plans; o Google Cloud oferece descontos por compromisso de uso. Os termos exatos variam, mas a pergunta central é se o uso previsível cobrirá o compromisso.

Exemplos de capacidade spot incluem AWS Spot Instances, Azure Spot Virtual Machines e Google Cloud Spot VMs. Eles são adequados para tarefas que podem parar e ser retomadas, como análise em lote ou renderização. O aviso pode ser muito curto: a AWS procura avisar com dois minutos de antecedência sobre interrupções por parada ou encerramento, mas não garante esse aviso; a hibernação pode começar imediatamente. As notificações do Azure Spot podem chegar até 30 segundos antes da remoção. Um serviço de finalização de compra ou banco de dados necessário continuamente precisa de proteção além de uma instância que pode ser interrompida.

Calcule o ponto de equilíbrio

Uma VM ilustrativa custa R$ 0,10 por hora sob demanda. Um compromisso de um ano custa R$ 0,06 por cada uma das 8.760 horas:

Divida esse custo anual pela tarifa horária sob demanda:

Isso representa 60% do ano. Acima de 5.256 horas, o compromisso é mais barato com essas tarifas. Em uso contínuo, a opção sob demanda custa R$ 876, portanto a economia é de R$ 350,40. Com 2.080 horas em horário comercial, a opção sob demanda custa R$ 208, menos que o compromisso integral. Aplicar a tarifa com desconto apenas às horas usadas deixaria de considerar o pagamento contratual.

Reduza a necessidade antes de buscar um desconto

O dimensionamento adequado ajusta os recursos à demanda medida. Uma VM de 8 vCPUs com uso médio de CPU de 10% é candidata a uma revisão. Antes de reduzi-la para 2 vCPUs, verifique os picos representativos e os requisitos de memória, armazenamento e rede. Se o tamanho menor atender a essas demandas e o preço for proporcional, o custo de computação cai para cerca de um quarto. Comprar um compromisso primeiro poderia fixar um recurso superdimensionado.

A programação de horários também importa. Um ambiente de teste executado por 10 horas em cada um de cinco dias úteis usa 50 das 168 horas de uma semana. Liberá-lo fora desses horários reduz o tempo de computação em cerca de 70%.

Inclua o software e outros termos de precificação

Os preços com licença incluída contêm a licença de software. O uso de licença própria (BYOL) usa licenças existentes quando seus termos permitem o uso na nuvem; o Benefício Híbrido do Azure é um exemplo. Os critérios de elegibilidade, o acompanhamento e qualquer requisito de hardware dedicado continuam se aplicando.

Outras ofertas usam assinaturas por usuário, faixas de volume, créditos de avaliação ou precificação de host dedicado. Uma combinação prática pode usar compromissos para a base estável, pagamento conforme o uso para demanda incerta e capacidade spot para trabalho em lote que pode ser retomado.

O modelo de responsabilidade compartilhada divide o trabalho de segurança, conformidade e operação entre provedor e cliente. A AWS chama a parte do provedor de segurança “da” nuvem e a parte do cliente de segurança “na” nuvem. O limite muda conforme o serviço, mas as decisões sobre dados e acesso do cliente nunca ficam sem um responsável.

Comece pelas camadas físicas

O provedor protege e opera prédios dos centros de dados, acesso físico, energia, refrigeração, redes físicas, hosts e virtualização. Os clientes se baseiam nesses controles e nas evidências de auditoria. Eles não aplicam correções ao hipervisor do provedor como parte do uso comum de IaaS.

Os clientes decidem como seus dados são classificados, protegidos, retidos e compartilhados. Eles gerenciam contas, identidades, direitos de acesso e configurações de serviço sob seu controle. Também protegem os dispositivos usados para acessar os serviços. Um provedor SaaS pode fornecer recursos de gerenciamento de dispositivos, enquanto a organização continua responsável por gerenciar os dispositivos de seus usuários.

Identifique onde o limite muda

A manutenção da plataforma segue procedimentos específicos de cada serviço. Algumas ofertas PaaS exigem ativar atualizações gerenciadas, migrar para uma versão com suporte ou resolver falhas de atualização. O cliente precisa seguir esses procedimentos, embora não opere um servidor de uso geral por conta própria.

Atribua três incidentes

Uma empresa usa um site em IaaS, um banco de dados PaaS gerenciado e e-mail SaaS. Surge uma vulnerabilidade no sistema operacional convidado. A empresa aplica a correção à VM do site; o provedor mantém os sistemas operacionais subjacentes ao banco de dados gerenciado e à aplicação de e-mail, conforme os procedimentos de atualização aplicáveis.

Em seguida, a senha de um funcionário é roubada. A empresa precisa redefinir o acesso, investigar as permissões e reforçar a proteção da conta em todos os serviços afetados. Migrar para SaaS não transferiu suas decisões de identidade para o provedor.

Por fim, arquivos de clientes ficam legíveis ao público porque a empresa ativou o compartilhamento aberto. A empresa precisa corrigir essa configuração e lidar com a exposição. A segurança física do centro de dados não pode impedir que um administrador autorizado escolha uma regra de compartilhamento insegura.

Divida os controles, não apenas os nomes

Alguns controles têm uma parte de cada lado. Os provedores aplicam correções à infraestrutura; os clientes aplicam correções ao software que controlam. Cada parte configura suas próprias camadas e treina sua própria equipe. Os controles físicos são herdados do provedor, enquanto as configurações das aplicações permanecem com o cliente.

A conformidade segue a mesma divisão. A certificação de um provedor cobre seus controles avaliados. O cliente precisa de evidências de que sua configuração, seu tratamento de dados e seus processos atendem aos requisitos de sua carga de trabalho. A documentação de responsabilidades e o contrato do serviço específico explicam o limite em detalhes.

A adoção da nuvem é uma decisão para cada carga de trabalho. Elasticidade, implantação rápida e serviços gerenciados podem ser valiosos, mas cada benefício precisa atender aos requisitos da organização. Identifique cada risco com precisão suficiente para escolher uma resposta.

Identifique dependências e limites de controle

A dependência de fornecedor ocorre quando APIs, serviços ou formatos de dados proprietários tornam a mudança de fornecedor lenta ou cara. Exportar grandes quantidades de dados também pode gerar cobranças de saída. Formatos abertos, ferramentas portáveis, contêineres e exportações de dados testadas podem reduzir o esforço de mudança. Cada opção acrescenta algum custo ou limita os recursos disponíveis, portanto a portabilidade é uma escolha a avaliar.

O provedor controla seus equipamentos, o projeto de suas instalações e o ciclo de vida de seus serviços. Os clientes se baseiam em contratos, documentação e auditorias independentes para obter evidências sobre a infraestrutura. Também precisam de uma resposta para quando um serviço muda ou é descontinuado.

Verifique conexões, localização e tempo de resposta

O acesso à nuvem depende da rede. Uma falha de conexão em um escritório pode impedir que os funcionários usem uma aplicação de nuvem que está funcionando normalmente. Uma região distante acrescenta atraso à comunicação. O controle de uma fábrica que precisa de respostas em milissegundos pode permanecer local, enquanto serviços de nuvem analisam os dados resultantes.

Residência de dados é onde os dados são armazenados e processados. Soberania de dados diz respeito às leis e à jurisdição aplicáveis a eles. Escolher uma região atende à questão da localização, mas contratos, condições de acesso e requisitos legais também importam. Uma organização pode precisar de uma região aprovada, uma oferta soberana adequada ou processamento local. Não se pressupõe uma regra legal específica para todos os países.

Associe cada risco a uma resposta prática

Um alerta de orçamento sinaliza um limite; ele não desliga recursos por conta própria. Limites de escalonamento ajudam a restringir a capacidade, enquanto um plano de recuperação lida com interrupções. Esses controles resolvem problemas diferentes.

Tome uma decisão fundamentada de adoção

Um escritório de advocacia com 40 pessoas considera um sistema SaaS de gerenciamento de documentos. Os benefícios esperados são acesso remoto, menos trabalho com servidores e a experiência de segurança do provedor. O escritório verifica se a localização do armazenamento atende a seus requisitos, se os documentos podem ser exportados em formatos padrão e se todos os usuários podem usar autenticação multifator.

Essas verificações relacionam cada preocupação a evidências: região e contrato para residência de dados, um teste de exportação para portabilidade e controles de conta para acesso. O escritório pode decidir migrar quando o serviço atender a esses requisitos. Uma carga de trabalho diferente, como um sistema local de controle de máquinas, pode permanecer nas instalações da organização.

As operações de nuvem também precisam de pessoas que entendam de segurança, custos e automação. O autosserviço rápido facilita a criação de novos recursos, portanto a governança precisa deixar claros seu responsável, sua finalidade e suas configurações permitidas.

Uma migração para a nuvem move aplicações, dados ou infraestrutura de sistemas existentes para uma nuvem. Comece com um inventário de aplicações, dependências, uso, custos e valor para o negócio. Depois escolha uma estratégia para cada carga de trabalho. Essa abordagem de portfólio evita impor a mesma migração a todos os sistemas.

Compare as sete estratégias

Os 7 Rs da AWS são um vocabulário útil:

O Google também usa termos como “migrar e melhorar” para mudança de plataforma e “reimaginar” para uma mudança mais ampla. A ação realizada é mais útil do que apenas memorizar as palavras de um fornecedor.

Diferencie migrações facilmente confundidas

A rehospedagem mantém o código e o projeto principal da aplicação sem alterações. Ela pode reduzir o esforço imediato da migração, mas mantém muitas responsabilidades de manutenção. Realocar move um ambiente de virtualização compatível inteiro e sua forma de operação, não apenas uma aplicação para uma plataforma de VM recém-escolhida.

A mudança de plataforma altera uma parte limitada do ambiente. Uma versão gerenciada do mesmo mecanismo de banco de dados pode eliminar a administração do servidor, preservando o projeto principal da aplicação. A recompra substitui o próprio produto. Substituir um software personalizado de gerenciamento de clientes por um CRM SaaS é recompra, embora ambos os produtos atendam à mesma finalidade de negócio.

A refatoração altera a arquitetura para obter benefícios como componentes escalonáveis de forma independente. Isso pode trazer valor substancial no longo prazo, mas o trabalho inicial pode não compensar para um sistema estável de baixo valor. Reter uma aplicação pode ser uma decisão deliberada enquanto se aguarda o fim de um contrato, um trabalho de compatibilidade ou uma revisão posterior.

Mova os dados e planeje a transição

Uma migração de banco de dados com pouco tempo de indisponibilidade pode começar com a cópia dos dados para um novo banco e depois replicar alterações posteriores enquanto o original permanece em uso. A equipe verifica se o destino está atualizado antes da transição para o novo sistema, a mudança combinada de usuários ou tráfego para ele.

A replicação reduz a quantidade de alterações que ainda precisam ser transferidas na transição. Ela não elimina a necessidade de verificar se os dados estão corretos, coordenar a mudança final e planejar como lidar com problemas. Para conjuntos de dados muito grandes, dispositivos físicos de transferência podem mover o volume inicial de dados quando a transferência pela rede é impraticável.

Revise as dependências antes de definir a sequência das migrações. Uma aplicação que ainda precisa de um banco de dados local pode exigir uma conexão ou uma migração coordenada. A rehospedagem pode ser uma primeira etapa seguida de otimização; um portfólio útil pode incluir desativar, reter, substituir e redesenhar.