Já vimos que a virtualização "desacoplou" a infra de computação, armazenamento e redes dos recursos de hardware. Por isso, antes de falar sobre escalabilidade é bom termos uma noção de Infrastructure-as-Code (IaC), um approach que nos permite tratar (provisionar e gerenciar) a infraestrutura como um sistema de software.
💠O que é IaC?
É uma maneira de construir e gerenciar infraestrutura dinâmica e imutável. Além disso, como é código, nela podem ser adotas práticas de engenharia de software, sendo parte dos processos mais importantes na cultura DevOps, como o CI/CD.
Tudo bem, é uma infra como código, mas qual código?
As ferramentas de IaC usam linguagens declarativas de um nível mais alto, mais legíveis para humanos. Elas podem ser linguagens de serialização de dados como JSON e YAML ou Linguagens Específicas de Domínio (Domain Specific Languages, DSL) como o HCL da Hashicorp e o Bicep da Microsoft. Para mais informações sobre DSLs clique aqui.
💠O que a IaC tenta resolver?
Entre outros, os principais problemas que a IaC visa resolver são:
❄️Drift de configuração - dois ou mais ambientes que deveriam ser idênticos (como desenvolvimento, teste e produção) se tornam inconsistentes entre si, causando vulnerabilidades, uso ineficiente de recursos e menor resiliência. Isso pode levar a um segundo problema:
❄️Snowflake servers - com o tempo os servidores inconsistentes se tornam tão diferentes que não sabemos mais exatamente como funcionam. São difíceis de reproduzir e caso precisem sofrer alguma mudança os efeitos são imprevisíveis.
Assim, Kief Morris em Infrastructure as Code: Managing Servers in the Cloud destaca alguns princípios da IaC:
❄️Reprodutibilidade - deve ser possível reconstruir qualquer elemento de uma infraestrutura sem esforço (a versão do software, o hostname etc. devem estar nos scripts e ferramentas) e de forma segura
❄️Consistência - dois elementos da infra que fornecem o mesmo serviço devem ser quase idênticos, só mudando aquilo que os faz únicos (como o IP, p. ex.)
❄️Repetibilidade - qualquer ação na infra deve ser repetível
❄️Descartabilidade - uma frase de Bill Baker resume esse princípio:
Trate seus servidores como gado, não como pets
Explico: devemos pressupor que qualquer elemento da infra pode e será destruído ou substituído a qualquer momento, seja deliberadamente ou por falha do hardware.
Isso exige que toda mudança de impacto deva ser feita por meio de scripts automatizados que criam e configuram os servidores.
❄️Continuidade do Serviço - nosso serviço deve permanecer disponível mesmo quando há falha em algum elemento na infra. Nas palavras de Morris:
Rodar um serviço continuamente disponível sobre uma infraestrutura descartável
❄️Sistemas auto-testáveis - assim como no desenvolvimento de software, qualquer mudança no código deve ser acompanhada por testes automatizados
❄️Idempotência - uma dada task, script ou operação deve sempre gerar o mesmo resultado, independente do estado em que o ambiente se encontra
E o princípio mais importante:
❄️Versionamento - além de ser facilmente compartilhável, o código da infra versionado proporciona:
⚡Rastreabilidade - sabemos o que foi feito, por quem e o contexto
⚡Rollback - quando alguma mudança causa falha é possível saber como tudo estava antes
⚡Correlação - quando há versionamento e tudo está relacionado por tags (ou versões) é mais fácil rastrear e resolver problemas
⚡Visibilidade - todo o time é avisado quando uma alteração é commitada
⚡Transparência - arquivo versionados (scripts, configuração, definições) tendem a ser mais legíveis para humanos
⚡"Acionabilidade" - os sistemas de controle de versão permitem a existência de gatilhos, essenciais para o processo de CI/CD
Esses princípios junto a scripts facilitam a automação de processos e a escalabilidade de serviços.
Mas, então, o que é automação?
Automação não é só usar scripts em ferramentas para facilitar um tarefa manual, isso é o processo de tool building. Automação é eliminar a necessidade do trabalho manual de tal forma que o próprio script execute sua tarefa automaticamente (lembra dos gatilho do último princípio de IaC?) sem precisar de uma pessoa.
Agora sim, com esses conceitos em mente, ficará mais fácil entender a capacidade de escala e redundância da nuvem.
Top comments (0)