Unidade 4 Conceitos DevOps

Prévia do material em texto

Conteudista: Prof. Me. Artur Marques
Revisão Textual: Luciene Oliveira da Costa Granadeiro
Material Teórico
Material Complementar
Referências
Conceitos DevOps
DevOps
É uma metodologia de desenvolvimento de software que pretende integrar funções de
desenvolvimento de software e operações de software num mesmo ciclo. Para isso ocorrer, é
mandatório um alto nível de maturidade e coordenação envolvendo todas as áreas
relacionadas desde negócios, passando por engenharia, desenvolvimento, testes e qualidade
entre outros.
 Trata-se de um processo integrado e requer também alto grau de automação para garantir a
entrega constante, ou seja, Automação de Infraestrutura e Entrega Contínua.
1 / 3
Material Teórico
 Objetivo
Conhecer a cultura DevOps e seu impacto nas organizações.
Figura 1 – Ciclo de desenvolvimento e operação DEVOPS 
Fonte: Reprodução
Conforme o excerto do artigo de Mueller (2010), podemos de�nir que DevOps segue os
princípios ágeis de desenvolvimento em todas as suas etapas.
“Valores do DevOps: Creio que os valores fundamentais do DevOps são efetivamente capturados
no Manifesto ágil - com talvez uma leve emenda para se concentrar no serviço geral ou
software totalmente entregue ao cliente em vez de simplesmente "software de trabalho".
Algumas de�nições anteriores do DevOps, como "People Over Process, Over Tools", de Alex
Honor , faz eco das declarações básicas do Agile Manifesto e solicita a colaboração direta de
dev + ops (nesse caso literalmente apoio de desenvolvimento e operações).
- MUELLER, 2010, p.2
Princípios DevOps: Não há consenso, mas no nível conceitual é principalmente o alargamento
dos princípios ágeis para incluir sistemas e operações em vez de interromper suas
preocupações no checkout de código.
Métodos DevOps: Alguns dos métodos como Scrum com operações, Kanban com operações
etc. (embora geralmente com mais foco na integração de operações com dev, QA e produtos
nas equipes).
Práticas DevOps: Técnicas especí�cas utilizadas como parte da implementação dos conceitos e
processos acima. Integração contínua e implantação contínua. Para tanto utilizar a
virtualização e a computação em nuvem como prática comum para acelerar a mudança no
mundo da infraestrutura moderna.
DevOps Tools: Houve uma explosão de ferramentas em lançamento (jenkins, travis, teamcity),
gerenciamento de con�gurações (fantoche, chef, ansible, cfengine), orquestração (zookeeper,
noah, mesos), monitoramento, virtualização e contêineres (AWS, OpenStack , vagabund, docker)
e muito mais.”
Figura 2 – Ciclo de desenvolvimento e operação DevOps
com sugestão de ferramental para cada item do processo 
Fonte: Reprodução
Conceitos de DevOps: Continuous Integration (integração
contínua)
É uma prática de desenvolvimento em que os desenvolvedores integram o código em um
repositório compartilhado com frequência, de preferência várias vezes ao dia. Cada integração
pode então ser veri�cada por uma construção automatizada e testes automatizados. Embora o
teste automatizado não seja estritamente parte da integração contínua, normalmente está
implícito.
Um dos principais benefícios da integração regular é que você pode detectar erros
rapidamente e localizá-los com mais facilidade. Como cada mudança introduzida é
normalmente pequena em relação ao todo, localizar com precisão a mudança especí�ca que
introduziu um defeito pode ocorrer rapidamente.
Integração contínua se tornou uma prática recomendada para o desenvolvimento de software
e é guiada por um conjunto de princípios-chave. Entre eles, estão o controle de revisão,
automação de build e testes automatizados.
O processo de integração contínua permite que os desenvolvedores integrem as alterações de
código em um repositório compartilhado continuamente. O código, nesse processo, é
continuamente testado e incorporado de forma mais suave.
Conceitos de DevOps: Continuous Delivery (entrega
contínua)
É a capacidade de obter mudanças de todos os tipos, incluindo novas funcionalidades,
alterações de con�guração, correções de bugs e experimentos em produção, ou nas mãos de
usuários, de forma segura e rápida de forma sustentável.
As práticas no centro da entrega contínua que nos ajudam a alcançar vários benefícios
importantes são:
Lançamento de baixo risco: é tornar as implantações de software eventos de baixo risco
que podem ser realizados a qualquer momento, sob demanda, aplicando padrões como
implantações com tempo de inatividade zero que são indetectáveis para os usuários.
Tempo de lançamento no mercado mais rápido: não é incomum que a fase de integração
e teste, correção do ciclo de vida de entrega de software em fases tradicional consuma
semanas ou até meses. Quando as equipes trabalham juntas para automatizar a
construção e implantação, provisionamento de ambiente e processos de teste de
regressão, os desenvolvedores podem incorporar integração e teste de regressão em seu
trabalho diário e remover completamente essas fases.
Maior qualidade: utilizar ferramentas automatizadas que descobrem regressões em
minutos, as equipes �cam livres para concentrar seus esforços na pesquisa do usuário e,
em atividades de teste de nível superior, como teste exploratório, teste de usabilidade e
teste de desempenho e segurança. 
Custos mais baixos: qualquer produto ou serviço de software bem-sucedido evoluirá
signi�cativamente ao longo de sua vida útil. Ao investir em construção, teste,
implantação e automação de ambiente, reduzimos substancialmente o custo de fazer e
entregar mudanças incrementais no software.
Produtos melhores: a entrega contínua torna mais econômico trabalhar em pequenos
lotes. Isso signi�ca que podemos obter feedback dos usuários durante todo o ciclo de vida
da entrega com base no software em funcionamento.
Conceitos de DevOps: Continous Deployment
(implantação contínua)
Signi�ca que cada mudança passa pelo pipeline e, se todos os testes forem aprovados, ela irá
automaticamente para a produção. Com essa abordagem, você pode ter várias implantações de
produção em um único dia, dependendo da rapidez com que a equipe está realizando as
alterações. 
Portanto, a implantação contínua é uma etapa na qual cada mudança no código-fonte é
implantada na produção automaticamente, sem a aprovação explícita de um desenvolvedor. O
trabalho de um desenvolvedor normalmente termina na revisão de uma solicitação pull de um
colega de equipe, e mesclá-la com o branch master, estamos falando do repositório central de
código em um controlador de versão. Um serviço assume a partir daí, executando todos os
testes e implantando o código para produção, enquanto mantém a equipe informada sobre o
resultado de cada evento importante.
A implantação contínua exige uma cultura altamente desenvolvida de monitoramento,
disponibilidade e capacidade de recuperação rápida.
A maioria das empresas começou a adotar práticas DevOps tornando o DevOps Engineer uma
das funções mais procuradas no setor de TI hoje. Mas quais são as habilidades procuradas?
Veja:
Fundamentos e scripts do Linux
Conhecimento em várias ferramentas e tecnologias DevOps
Gerenciamento do código-fonte
Gerenciamento de con�guração
Integração Contínua
Teste contínuo
Monitoramento contínuo
Containerização
Integração contínua e entrega contínua
Infraestrutura como código
Principais conceitos de DevOps
Habilidades pessoais
Desa�ador, não é mesmo? Nossa recomendação é para começar com o básico, Linux, bash e
outros. Foque na sequência nas práticas de DevOps. Cremos que habilidades pessoais vistas
hoje como as “famosas” soft skills deverão ser desenvolvidas por você em paralelo. As
exigências do mercado estão �cando maiores a cada dia e soft skills são ainda vistas como um
diferencial. Aproveite, pois, com certeza, isso em breve será obrigatório.
Talvez devamos usar uma de�nição mais especí�ca para DevOps baseada no que acabamos de
escrever logo acima, não é mesmo?
DevOps é o domínio de engenharia responsável pelo design, implementação e gerenciamentode estruturas, integração contínua e entrega contínua, que mais recentemente também
agregou ao termo a responsabilidade pelo design e gerenciamento de contêineres (serviços,
micro serviços, e tudo o mais que envolve isso).
Pessoas, processos e ferramentas são os três pilares de um projeto de desenvolvimento
de software. Ao adotar uma cultura DevOps, eles devem estar devidamente alinhados com as
necessidades atuais. A organização de processos que resulta em um ciclo de vida de
desenvolvimento de software reduzido e a infraestrutura certa de ferramentas e tecnologias,
sem dúvida, promoverá a implementação perfeita do DevOps. No entanto, as equipes e, em
particular, as pessoas nessas equipes devem ser uma prioridade. Deve haver um sentimento
de comunidade, compartilhando um objetivo comum e contribuindo para uma causa comum.
E para que isso aconteça, a gestão deve ter como objetivo manter todas as equipes alinhadas.
No modelo tradicional de desenvolvimento de software, desenvolvedores e operações tinham
funções separadas. Mas, no DevOps, os dois grupos trabalham como uma equipe totalmente
responsável pelo aplicativo do início ao �m. Um dos princípios básicos é o controle e a
responsabilidade dos serviços desde o início até o �m. Tradicionalmente, os desenvolvedores
escreveram código e operações implantando esse código, mas que leva a todos os tipos de
ine�ciências de diferenças na produção de problemas de desempenho e ambientes
imprevisíveis.
Para que o código seja de alta qualidade, ele precisa de testes regulares, portanto, DevOps exige
teste automatizado. De forma geral, isso acelera o SDLC e permite que os desenvolvedores
corrijam problemas em “movimento”. O lema é teste frequentemente, teste antecipadamente;
isso é para detectar e reti�car os defeitos antes que eles entrem em produção. A automação
permitirá a execução de mais testes, além da economia de tempo, o qual poderia ser gasto em
testes manuais. Teste de con�guração de middleware, exame regular de alterações de rede e
banco de dados, suporte ao processo de desenvolvimento por meio de carga automatizada,
teste de unidade ou regressão, tudo contribui para a otimização em DevOps.
A manutenção de alta frequência e estabilidade de implantação é um dos princípios
fundamentais do DevOps. Portanto, a implantação do código deve ser automatizada, repetível e
previsível em pequenos lotes. Assim, as equipes que implantam com mais frequência do que
uma vez por semana também podem corrigir o código mais rápido, resolver prontamente as
vulnerabilidades de segurança recém-descobertas e entregar valor aos clientes regularmente.
Não haverá necessidade de esperar até a próxima janela de atualização agendada para
implantar mudanças de emergência.
Para fazer isso funcionar, devemos considerar uma cadência de sprint ágil semanal. Assim,
não será problema determinar quais equipes podem agregar valor com mais frequência do que
outras.
Tido como um fator-chave em DevOps é o fato que devemos estabelecer monitoramento
contínuo e observabilidade em integração contínua e entrega contínua. O problema-chave
aqui são as falhas, por isso, monitoramos continuamente para permitir a identi�cação rápida
dessas falhas, de tal forma que minimizaremos o seu impacto nos negócios, isso melhorará a
visibilidade e facilitará o aumento da produtividade da equipe.
Aqui vão algumas dicas, as ferramentas de monitoramento mais populares são Sensu,
Prometheus e Nagios, mas precisamos de ferramentas de alerta como Slack, PagerDuty e
ServiceNow, que podem fornecer às equipes informações importantes sobre os problemas que
ocorreram para que eles possam agir. Porém, não adianta apenas avisar e fazer com que os
desenvolvedores resolvam bugs, é importante termos controle, In�uxDB, Splunk e AWS podem
armazenar as métricas que ajudarão a agregar e aprender com os dados coletados, todos
crescem.
Lembre-se de que integração contínua é uma prática de desenvolvimento de implementar
pequenas mudanças e checá-las para repositórios de controle de versão regularmente. As
equipes de desenvolvimento que praticam a integração contínua provavelmente terão que
con�gurar testes automatizados para veri�car se as alterações no código não quebraram
nenhum recurso ou teste existente. Isso acontece muito, portanto, redobre a atenção aqui, a
quebra do branch do teste simplesmente para a execução e impede a liberação em última
instância, porque faltarão partes inteiras da funcionalidade que não foram testadas, por
exemplo.
Falamos de ferramentas, mas é bom dar uma lida e assistir a este vídeo, pois ele mostra essa
integração e consumo de ferramentas no DevOps.
Conheça as principais ferramentas OpenSource para DevOps
ACESSE
IaC: Infrastructure as Code
Nos últimos anos, as coisas mudaram dramaticamente. Tendências como a computação em
nuvem revolucionaram a maneira como as organizações projetam, desenvolvem e mantêm
sua infraestrutura de TI.
A computação em nuvem fornece recursos de computação sob demanda, que são separados
do hardware físico e da con�guração subjacente necessária. Os sistemas de
software autônomos fornecem esses recursos de computação na nuvem para alcançar a
automação que a computação em nuvem oferece. Por causa dessa automação, é possível
controlar e manipular os recursos disponíveis programaticamente, fazendo interface com os
provedores de nuvem. Dessa forma, as mudanças na infraestrutura como escalonamento de
recursos podem ser implementadas de forma mais rápida e con�ável e operadas
principalmente sem interação manual, mas ainda com a capacidade de supervisionar todo o
processo e reverter as mudanças se algo não sair de acordo com o planejado.
De�nir exatamente o que é uma infraestrutura em nuvem pode ser amplo e complexo, porque
tem vários componentes, incluindo: servidores, software, dispositivos de rede e outros
recursos de armazenamento. Todos são necessários para criar aplicativos que são acessados
por meio da nuvem. Esses aplicativos podem ser recuperados remotamente pela Internet,
serviços de telecomunicações, redes de longa distância e outros meios de comunicação em
rede.
A parte que nos interessa aqui é IaaS, ou seja, infraestrutura como serviço porque ela oferece o
máximo de controle interno, permitindo acesso e manutenção direta à maioria dos recursos
http://%3C%20https//www.interop.com.br/blog/ferramentas-devops/
de nuvem. 
Ela é amplamente automatizada e escalonável, pois os clientes podem comprar recursos
conforme necessário, sem depender de hardware interno. Os serviços em nuvem são
gerenciados principalmente por uma empresa ou provedor, tem vários gigantes trabalhando
nisso como Amazon, Microsoft, Alibaba e Google, entre outros, incluindo aplicativos, dados,
tempo de execução, middleware e sistemas operacionais. Esses provedores são responsáveis
pelos serviços, armazenamento, rede e virtualização.
É importante você saber que uma infraestrutura de nuvem como serviço, assim como toda
tecnologia de nuvem, é acessada pela internet por meio de um datacenter do provedor, que é
responsável por manter e gerenciar o hardware local tradicional, como servidores e outros
dispositivos de armazenamento, bem como networking e visualização. Isso signi�ca que a
equipe de TI da empresa contratante tem liberdade e controle para gerenciar aplicativos,
dados, middleware e outros sistemas operacionais inclusive.
Claro, nem tudo é facilidade, existem serviços de infraestrutura importantes, como
monitoramento de rede, segurança, faturamento a gente chama isso de “billing”, recuperação
de desastres e balanceamento de carga. Também há automação e orquestração avançadas para
simpli�car o desempenho e o gerenciamento do aplicativo, bem como facilitar a instalação de
sistemas operacionais, implantar middleware, iniciar máquinas virtuais e criar
armazenamento de carga de trabalho, backups e, claro, testar a recuperação do que foi feito o
backup – chamamos isso de restore.
Quatro itens são preocupantese necessitam de planejamento antes de migrar:
Gerenciamento de Serviços e Recursos
Integração de ferramentas de gerenciamento de data center
Relatórios, Visibilidade, Con�abilidade, Segurança
interfaces para usuários, administradores e desenvolvedores
Lembre-se de que os recursos de computação e armazenamento de dados são frequentemente
virtualizados na computação em nuvem, tornando mais fácil para os usuários aproveitarem
esses recursos com mais simplicidade e menos desperdício.
Conforme esse volume de virtualização e a complexidade crescem, à medida que a escala da
infraestrutura continua a se expandir, o gerenciamento da infraestrutura se reduziu a lidar
com várias instâncias menores ao mesmo tempo, ao invés de algumas instâncias grandes. 
A natureza cíclica da infraestrutura moderna tornou imperativo transformar a maneira como a
infraestrutura é projetada, desenvolvida, con�gurada, gerenciada e mantida nesse ambiente
virtualizado, e é aí que entra a infraestrutura como código.
Infraestrutura como código ou IaC como também é conhecida é a abordagem de automatizar a
implantação e as alterações da infraestrutura, de�nindo os estados de recursos desejados e
seus relacionamentos mútuos no código. O código é escrito em linguagens de ferramentas IaC
especializadas e legíveis por pessoas. Os recursos reais na nuvem são criados ou modi�cados
quando você executa o código. Isso, então, solicita que a ferramenta faça interface com o
provedor de nuvem ou sistema de implantação em seu nome para aplicar as alterações
necessárias, sem usar a interface da web de um provedor de nuvem. 
O código pode ser modi�cado sempre que necessário, após a execução do código, a
ferramenta IaC cuidará de encontrar as diferenças entre a infraestrutura desejada no código e
a infraestrutura real na nuvem, tomando medidas para tornar o estado real igual ao desejado.
Conforme escritos de SAVIC (2020), para que o IaC funcione na prática, os recursos criados
não devem ser modi�cados manualmente depois, pois isso cria discórdia entre a
infraestrutura esperada no código e o estado real na nuvem. 
Diz ainda que os recursos modi�cados manualmente podem ser recriados ou excluídos
durante as futuras execuções do código, e toda essa personalização seria perdida. Para que
possamos incorporar as modi�cações, é necessário que acrescentemos as modi�cações no
código da infraestrutura.
Portanto, IaC permite a criação de recursos de forma consistente, sem erros, ao mesmo tempo
em que reduz o gerenciamento e o tempo de con�guração manual. Vejamos algumas
vantagens e benefícios da IaC conforme SAVIC (2020).
“Os principais benefícios do IaC são:
Velocidade: a infraestrutura como código fornece o elemento de velocidade ao permitir que os
usuários con�gurem a infraestrutura no menor período possível, simplesmente executando
um script. Isso pode ser feito para todos os ambientes, desde o desenvolvimento até o
controle de qualidade, produção e teste, trazendo maior e�ciência para todo o ciclo de vida do
desenvolvimento.
Responsabilidade: Como os arquivos de con�guração de Infraestrutura como Código podem
ser controlados como qualquer outro arquivo de código-fonte, há transparência total sobre o
impacto de cada con�guração. Essa transparência ajuda a corrigir a responsabilidade pelo que
está funcionando e pelo que não está.
Consistência: eliminar a necessidade de manuseio manual da infraestrutura diminui o risco de
erro humano. Isso signi�ca que não há discrepâncias, inconsistências, erros ou lapsos de
comunicação na forma como a infraestrutura é projetada, implantada ou gerenciada. Os
arquivos de con�guração atuam como uma fonte única. Eles podem ser implantados várias
vezes sem risco de erros. 
Implementação : remover a interação de provisionamento manual com provedores de nuvem
signi�ca uma velocidade de implementação mais rápida.
Recuperação : identi�car problemas na con�guração pode signi�car recuperação rápida de
falhas.
Consistência : os recursos de implantação são sempre os mesmos, resolvendo a fragilidade da
infraestrutura.
Modi�cação : a modi�cação de recursos pode ter um tempo de resposta rápido.
Reutilização : reutilização de partes da arquitetura de infraestrutura em projetos futuros.
Figura 3 – Exemplo de �uxo de trabalho IaC. “Em um
�uxo de trabalho IaC, você pode ativar a infraestrutura
repetidamente de maneira padronizada, o que signi�ca
que o desenvolvimento e o teste de software são um
processo mais rápido porque os ambientes de
desenvolvimento, preparação, teste de garantia de
qualidade e produção são separados. Você pode repetir o
processo de escrever código e testá-lo ao vivo,
implantando a infraestrutura quantas vezes forem
necessárias. Depois que sua infraestrutura escrita atender
a todos os requisitos, você pode implantá-la nos
ambientes de nuvem desejados. Quando surgem novos
requisitos, você pode reiterar o processo.” Extraído de
(SAVIC, 2020, p.3). 
Fonte: Reprodução
- SAVIC, 2020, p.3
Controle de versão : armazenamento do código de infraestrutura em sistemas de controle de
versão.
Visibilidade : escrever a con�guração como código atua como documentação para a
infraestrutura.”
Como você já deve ter percebido, para controlar IaC, é importante usarmos um software de
controle de versão como o GIT no GitHub ou outro VCS – Version Control Software (software de
controle de versão) se for o caso. Portanto, as declarações de infraestrutura �cam facilmente
recuperáveis, com alterações visíveis para todos, e fornece instantâneos em pontos históricos
da con�guração, para que sempre possamos voltar para uma versão anterior se novas
modi�cações criarem erros. Aqui é importante pontos de retorno ou rollback, claro, aqui
voltamos a falar de GMUD.
Isso torna redundante o uso de ferramentas de con�guração interativas ou con�guração de
hardware físico.
Figura 4 – Visão da IaC. “Simpli�cando, o IaC permite que
você gerencie a infraestrutura de tecnologia apenas
usando arquivos de con�guração. Portanto, diferentes
pessoas lidando com as con�gurações e gerenciamento
manualmente da infraestrutura de TI, as discrepâncias e
inconsistências se tornam uma parte inevitável das
- NERO, 2020, p.1
“Infraestrutura como código refere-se ao processo de provisionamento e gerenciamento de
infraestruturas de TI, como redes, balanceadores de carga, máquinas virtuais, data centers e
topologia de conexão em um modelo descritivo por meio de arquivos de de�nição legíveis por
máquina com a ajuda do controle de versão usado por a equipe DevOps como código-fonte.”
con�gurações manuais da infraestrutura. Tudo isso pode
ser tratado com um único arquivo de código. Como a
infraestrutura é gerenciada de maneira e�caz e executada
apenas com texto, você pode ajustá-la de acordo com seus
requisitos e colocá-la sob controle de origem, como faria
com qualquer outro arquivo de código-fonte.”  
Fonte: Adaptado de NERO, 2020, p.2
Infraestrutura Mutável versus Imutável
As equipes de DevOps se ocuparam em dar as boas-vindas aos clientes com lançamentos
novos e contínuos; sem saber, também deram boas-vindas às vulnerabilidades de aplicativos. 
Infraestrutura mutável é a infraestrutura de TI sujeita a alterações de acordo com os requisitos
do desenvolvedor, aplicativo ou implantação. Com a chegada a uns 10 anos do DevOps, até
mesmo os desenvolvedores têm direitos de acesso para alterar a infraestrutura para o
ambiente de teste ou pré-produção, se não para o ambiente de produção. Isso tem trazido
sérios problemas de segurança que é claro, afeta também a privacidade de dados em última
instância porque as vulnerabilidades criam brechas importantes que ampliam a superfície de
ataques para os chamados black hats.
Para Thota (2020), essas decisões dos desenvolvedores em alterar o ambiente ou a
infraestrutura eram necessárias para acelerar os lançamentos e aumentar o nível de satisfação
dos clientes. Então, ameaças à segurança, como não acompanhar o processo de
documentação, tornando o rastreamentode versão difícil avançando para a segurança do
ambiente, teste, controle de qualidade impactando também os gerentes de produto que
começaram a ter di�culdade em acompanhar as mudanças de con�guração, foram
acumulando fragilidades para a segurança.
Quando se trata de proteger a infraestrutura, o acesso aos sistemas ou ao servidor é a prática
mais comum, seguido de patch de atualização e gerenciamento de vulnerabilidade para
atualizar o software oportunamente. Por �m, o gerenciamento de APIs é outro desa�o em
infraestrutura.
Uma coisa é certa e todos da área de TI sabem disso, apesar de DevOps e a automação terem
ajudado, por outro lado, o gerenciamento de con�guração complicou-se exponencialmente.
Frequentemente, em uma infraestrutura mutável, as equipes de DevOps enfrentam a situação
em que alguém modi�cou o servidor, levando a um servidor de produção ruim, resultando em
tempo de inatividade ou consequências desconhecidas e infelizmente desastrosas.
Infraestrutura mutável como código cria um ecossistema onde apenas um conjunto especí�co
de pro�ssionais pode resolver os problemas relacionados a servidores especí�cos, também
conhecidos como �ocos de neve ou snow �akes. Isso signi�ca que o processo de resolução de
problemas pode ser interrompido ou prejudicado se a pessoa ou equipe designada não estiver
disponível a qualquer momento. Na verdade, por mais que se queira enxergar benefícios, e
existem alguns, a infraestrutura mutável coloca as operações de negócios em risco de
variações na con�guração. Variações na con�guração não são coisas boas de acontecerem em
ambientes de produção que devem ser estáveis e evitar paradas de negócios e listas
intermináveis de aberturas de chamado de usuários bravos e gerentes caçando culpados na
área de TI. Isso, ao longo do tempo, atinge o desempenho do projeto no longo prazo.
Mudar de infraestrutura mutável para imutável ainda é caro, porém, necessário ao longo do
tempo. Inclui práticas de gerenciamento e manutenção de servidores e convencimento da
equipe de segurança e desenvolvimento de TI a se esquecer de seu ambiente anterior e adotar
novos princípios. Portanto, estamos descrevendo aqui que é necessária a mudança de
comportamento, mindset profundo. Flores (2020) coloca de forma clara os prós e contras da
infraestrutura mutável:
“Prós da infraestrutura mutável
Sua equipe de TI não precisa criar servidores do zero sempre que uma mudança é
necessária.
Você pode distribuir atualizações para servidores individuais, o que torna o
processo de atualização mais rápido.
Bem, vamos ao contraponto, a infraestrutura imutável não é capaz de mudar, tornando-a mais
resiliente. Como cada componente de Infraestrutura como Código aqui é feito sob medida para
especi�cações precisas, também é uma solução mais futurística. Nero (2020) a descreve como
não tendo espaço para lidar com pequenos desvios individualmente. Se uma mudança for
necessária, toda a infraestrutura é provisionada novamente para atender a esses requisitos e a
antiga é desativada. 
Embora possa parecer um exercício inútil, ele se mostra imensamente e�caz em alcançar
uniformidade e consistência em infraestrutura como código. É o resultado da virtualização,
amplamente suportada pela computação em nuvem. Nesse modelo, tanto o software quanto
- FLORES, 2020, p.3
Você pode garantir que a infraestrutura utilizada atenda às necessidades
especí�cas de cada usuário.
Você pode entender cada servidor em um nível individual, o que torna mais fácil
diagnosticar problemas.
Contras da infraestrutura mutável
Como cada servidor é único na con�guração, �ca mais difícil diagnosticar e
gerenciar cada servidor. Isso é chamado de desvio de con�guração.
Controle de versão indiscreto - As alterações feitas no servidor não são
documentadas, o que torna o rastreamento difícil e o diagnóstico quase
impossível.
As atualizações podem falhar devido a vários motivos, como falha de DNS ou
conectividade de rede ruim, que demoram para serem reconhecidos e corrigidos.
A depuração é demorada devido a problemas de rastreamento de atualização. 
Você pode acabar com várias versões de uma atualização sem qualquer percepção do
problema.”
o hardware são mantidos na nuvem, o que signi�ca que as empresas não precisam se
preocupar em provisionar uma nova infraestrutura ou descartar a existente para atender a
seus requisitos de mudança.
Em suma, a infraestrutura não pode ser modi�cada depois de implantada. Quando mudanças
são necessárias, você precisa implantar novamente, adicionar infraestrutura e desativar a
infraestrutura antiga. Pode parecer pouco, mas é muito, porque evitamos a implementação de
uma atualização problemática como ocorre no modelo mutável, e apenas transferir usuários
quando tiver certeza da funcionalidade do novo servidor. Além do mais, você não acaba com
várias máquinas inutilizáveis, isso aumenta o custo da solução sobremaneira. Isso diminui
desvios na con�guração e consequentemente no gerenciamento desta.
As “coisas” devem ser simples quando lidamos com ambientes interativos complexos e
repletos de mudanças. Portanto, a codi�cação das práticas de segurança em IaC dá disciplina a
todo o processo de implantação de novos ambientes em infraestrutura imutável. 
Depois que todas as práticas de segurança são codi�cadas e colocadas em modo de
automação, não há espaço para erros manuais e falsas interpretações. Isso aumenta
signi�cativamente a segurança como um todo, pois há apenas um servidor que as equipes
precisam cuidar, fazer alterações, atualizar e, em seguida, destruir.
Figura 5 –Diferença entre Infraestrutura como código
mutável x imutável. 
Flores (2020) destaca as vantagens e desvantagens da infraestrutura como código mutável:
“Vantagens da infraestrutura imutável
Controle de versão discreto - cada versão do servidor é independente da outra.
Você não terá duas versões em execução ao mesmo tempo.
A infraestrutura imutável oferece suporte à implantação automática. Esse tipo de
infraestrutura é construído principalmente em torno da virtualização. 
Portanto, você não precisa se preocupar com provisionamento e desprovisionamento de
hardware e software conforme necessário. 
No ambiente de nuvem, você pode documentar todos os processos realizados para criar um
recurso. Conforme os ataques cibernéticos continuam a crescer, a infraestrutura imutável se
torna ainda mais importante porque fornecem proteção de segurança contra injeções de
malware em servidores, código comprometido, patching e vulnerabilidades de atualização, além
disso, bloqueiam muitas maneiras pelas quais os cibercriminosos podem acessar a
infraestrutura.
- FLORES, 2020, p.4
Rastreamento mais fácil - Como você cria novas versões do servidor quando
precisa fazer alterações, pode rastrear o erro de cada versão. Não há zona
intermediária.
É mais fácil testar servidores diferentes e distribuir atualizações, pois as
con�gurações em cada servidor são consistentes.
Você gosta de previsibilidade, pois os servidores permanecem os mesmos.
Ótimo para ambientes interdependentes, como tecnologias de nuvem.
Você pode reverter as implantações, pois as versões anteriores não são afetadas.
Contras da infraestrutura imutável
Você não pode modi�car os servidores existentes. Em caso de problemas,
servidores com a mesma con�guração precisam de uma revisão completa.
Você precisa externalizar o armazenamento de dados em vez de copiá-lo para um
disco local.
Há formas de se implementar diferentes e as chamamos de declarativas e imperativas.
Conhecer a infraestrutura declarativa versus imperativa como código pode signi�car a
diferença entre ter uma vida fácil ou um pesadelo total.
Modelos Declarativos versus Imperativos
Na abordagem imperativa, a responsabilidade de de�nir as etapas exatas necessárias para
atender a uma meta �nal é do usuário. Isso signi�ca que o usuário deve especi�car as
instruções de instalação do software, criação do banco de dados, con�guração e assim por
diante.Uma abordagem declarativa, por outro lado, concentra-se na de�nição do estado �nal, e não
nas etapas exatas. Um usuário especi�ca, ou declara o número de cargas de trabalho a serem
armazenadas em contêineres ou virtualizadas, o aplicativo e as máquinas que precisam ser
implantadas e como cada uma será con�gurada. No entanto, você não precisa se preocupar
com as etapas exatas necessárias para concluir esses processos. Um código é executado para
completar as operações necessárias para atingir o estado �nal declarado pelo usuário.
As diferenças entre os modelos declarativo e imperativo podem ser resumidas em uma frase: o
imperativo se concentra em como, e o declarativo se concentra em quê. Um descreve o que
precisa acontecer; as minúcias para torná-lo assim são deixadas para o sistema. Em
contraste, a programação imperativa envolve escrever código que segue etapas explícitas para
resolver um problema, concluir uma tarefa ou alcançar o resultado desejado.
Gerenciamento de con�guração dentro da infraestrutura como código é fortemente
dependente de linguagem adequada a essa programação. Vejamos o exemplo do Puppet, ele é
declarativo: o sysadmin descreve um estado �nal desejado e a ferramenta tenta alcançá-lo. Sua
linguagem de domínio especí�co é usada para criar descrições de alto nível do estado do
servidor desejado, em oposição às instruções e ações a serem realizadas. Portanto, nos
scripts ou manifestos, que contêm informações de con�guração, podem ser usadas quantas
vezes quiserem, para obter os mesmos resultados, ou seja, se o estado �nal desejado já tiver
sido alcançado, no caso do Puppet, ele simplesmente ignora o item em questão, então os
usuários só precisam se preocupar com o estado �nal desejado do sistema a ser con�gurado,
não com a sequência de etapas necessárias para chegar lá.
Por outro lado, peguemos o Chef, concorrente do Puppet, ele é absolutamente imperativo. Os
usuários de�nem comandos e sua ordem de execução em instruções de con�guração
chamadas Receitas, que por sua vez podem ser organizadas em Livros de Receitas para
facilitar o gerenciamento.
Vejamos este exemplo:
Esta receita veri�ca o JDK 7 no nó de destino – se ele existir, o Chef instalará o OpenJDK 7.
Caso contrário, um aviso será gerado. Observe que as Receitas do Chef são estruturadas como
listas sequenciais de comandos, em oposição aos Manifestos de Marionetes, que contêm
apenas descrições dos estados �nais desejados. 
“Vamos, analisar três perspectivas: a de um programador, administrador de sistema e
desenvolvedor FULL STACK .
Apaixonado por escrever código e�ciente, estruturado e fácil de entender, o programador não
é o maior fã de modelos declarativos que empregam abstrações pesadas. Ele está acostumado
a ditar como as coisas devem acontecer com loops for, instruções condicionais, variáveis e
assim por diante. A lógica de negócios do software em que ele trabalha é principalmente de
natureza imperativa.
Melhor ajuste: ferramentas obrigatórias de CM como Chef
O administrador de sistemas  gosta de administrar de maneira restrita, e por um bom motivo:
se a infraestrutura cair, a empresa para de repente. Ele é um mago do Bash, pro�ciente em
Python e Perl e prefere usá-los a aprender novas linguagens como Ruby. Ele prefere o modelo
declarativo ao invés do imperativo, mas está ciente dos desa�os que o primeiro tem no
gerenciamento de infraestruturas de nuvem dinâmicas.
Melhor ajuste:   ferramentas híbridas de CM como Ansible ou SaltStack
Podemos perceber, em linhas gerais, sem causar muita controvérsia e respeitando ambas as
formas que o estilo declarativo parece ser mais vantajoso para infraestrutura como código.
Observe, no entanto, as limitações. Por um lado, essas vantagens podem não se aplicar a
outras formas de programação, como vimos no exemplo dado por Upguard (2020). Com o
estilo declarativo, estamos dando uma grande quantidade de controle sobre como as
alterações são feitas em seus provedores de serviços em nuvem. Isso pode ser problemático
dependendo dos padrões da sua organização. Seria melhor adotarmos o caminho do meio,
claro, sem “�car em cima do muro”, mas temos um compromisso que é empregar uma
abordagem híbrida, portanto, manter a infraestrutura como declarativa e, em seguida, usar o
estilo imperativo para o código de implantação para gerenciar outros requisitos.
Em suma, o modelo declarativo funciona bem para IaC, pois podemos criar infraestrutura em
grande escala que não exigir muito gerenciamento por parte da equipe. A implementação
subjacente lidará com os detalhes do recurso, então poderemos nos concentrar em lidar com
o que desejamos fazer. Porém, apesar de o modelo imperativo fornecer mais controle, ele
exige mais trabalho por parte do time de desenvolvedores. Temperança é o caminho.
Engenharia de Plataforma
O surgimento de microsserviços, orquestração de contêineres e coisas do gênero
introduziram novos desa�os de engenharia. Equipes de engenharia de plataforma foram
formadas em várias organizações para assumir essas responsabilidades. Em alguns aspectos,
- UPGUARD, 2020, p.6
O desenvolvedor full stack  pode atravessar a pilha com facilidade e adora a ideia de abstrair a
infraestrutura para o código. Normalmente, quando experiente, é um ninja em Ruby/RoR, é fã
tanto do Chef quanto do Puppet. Pode apreciar os méritos de cada modelo; para ele, qualquer
tipo de ferramenta torna seu trabalho de construir e lançar continuamente software de
qualidade mais rápido, mais e�ciente e menos sujeito a erros.
Melhor ajuste: qualquer um dos modelos. Puppet, Chef e SaltStack são opções viáveis.”
a função de um engenheiro de plataforma não mudou drasticamente em relação a outras
funções relacionadas ao DevOps.
Conforme os escritos de Daigler (2020), empresas maduras com infraestrutura legada estão se
mobilizando em preparação para a grande migração para a nuvem, e os provedores de nuvem
estão prontos para aceitá-los de braços abertos. Mas, com essa migração, vem a necessidade
de conhecimento em nuvem e orquestração de contêineres; será que não é o momento de se
devem formar uma equipe de engenharia de plataforma. Essa tendência está em franca
ascensão no mundo, grande parte motivada pela rápida adoção de Kubernetes e IaC.
A engenharia de plataforma permite que os desenvolvedores de aplicativos coloquem o
software nas mãos dos usuários de maneira mais fácil. Algumas dessas maneiras podem
padronizar as implantações do Kubernetes de uma organização, garantindo que a
infraestrutura seja auditável, automatizando vários processos de implantação e escrevendo
documentação para desenvolvedores de aplicativos. Aqui, podemos pensar de forma
evolucionária, a�nal, lá para os anos de 2001-2003 DevOps era bastante ad hoc.
Daigler (2020) nos explica de forma clara onde DevOps se diverge da Engenharia de Plataforma
e isso é bom:
“Para descrever melhor a função da engenharia de plataforma em uma organização, vamos
considerar um exemplo. Suponha que uma seguradora fundada na década de 1980 comece a
mudar sua infraestrutura para a nuvem. Agora, suponha que nessa organização os
engenheiros de software estejam divididos em duas categorias: desenvolvimento de aplicativos
e infraestrutura. Antes da era da nuvem, era comum que os engenheiros de infraestrutura se
parecessem com uma equipe de backend que oferecia APIs. 
Essas responsabilidades são geralmente cumpridas por meio do uso de infraestrutura como
código (IaC). Algumas infraestruturas comuns como ferramentas de código são Terraform,
Vagrant, Chef, Puppet e AWS CloudFormation. Várias dessas ferramentas são de código aberto.
Geralmente, a plataforma construída por engenheiros de plataforma é composta por essas
Figura 6 – Fluxo de um exemplo de infraestrutura
implementada com ferramentas utilizadas. A �gura
ilustra como a infraestrutura, à medida que os
engenheiros de código e plataforma se encaixam em uma
equipe de desenvolvimento, e também como essas
ferramentas, em última análise,levam a mais recursos.
Tal como acontece com muitas tecnologias, existem
diferentes abordagens para a infraestrutura como código.
Os mais comuns são modelos declarativos e imperativos.
Estruturas declarativas, como a oferecida pelo Kubernetes,
exigem que os usuários de�nam um estado desejado. Em
um modelo declarativo, o sistema desenvolve um plano
para atingir e manter o estado especi�cado.  
- DAIGLER, 2020, p.3
ferramentas de código aberto. Os engenheiros de plataforma de uma organização adaptam a
infraestrutura como ferramentas de código às necessidades dos desenvolvedores de
aplicativos da organização.”
Fonte: DAIGLER, N. The Rise of Platform Engineering . 2020.
 
Indicações para saber mais sobre os assuntos abordados
nesta Unidade:
Vídeos
CÓDIGO FONTE TV. O que é DevOps.
NORONHA, J. iMasters. DevOps na Vida Real.
2 / 3
Material Complementar
DevOps // Dicionário do Programador
https://www.youtube.com/watch?v=iwf6kcvxeD4
AKITA, F. Entendendo "Devops" para Iniciantes em Programação (Parte 1).
DevOps na Vida Real - Jeferson Noronha
Entendendo "Devops" para Iniciantes em Programação (Parte 1) | …
https://www.youtube.com/watch?v=KbvfV01tSig
https://www.youtube.com/watch?v=bwO8EZf0gLI
AKITA, F. Entendendo "Devops" para Iniciantes em Programação (Parte 2). 
Entendendo "Devops" para Iniciantes em Programação (Parte 2) | …
https://www.youtube.com/watch?v=mcwnQVAn0pw
3 / 3
Referências
DAIGLER, N. The Rise of Platform Engineering. 2020. Disponível em:
<https://softwareengineeringdaily.com/2020/02/13/setting-the-stage-
for-platform-engineering/> Acesso em: 25/04/2021.
 NERO, T. O que é infraestrutura como código e como você pode
aproveitá-la? 2020. Disponível em:
<https://www.cuelogic.com/blog/infrastructure-as-code> Acesso em:
25/04/2021.
 FLORES, K. Mutable Vs Immutable Infrastructure – A Comprehensive Guide
to Choose the Best. 2020. Disponível em: <https://www.bridge-
global.com/blog/mutable-vs-immutable-
infrastructure/#:~:text=Cons%20of%20Mutable%20Infrastructure&tex
t=Indiscrete%20versioning%2D%20The%20changes%20you,time%20t
o%20recognize%20and%20�x. >. Acesso em: 25/04/2021.
 MUELLER. E. What Is DevOps?  2010, Disponível em:
<https://theagileadmin.com/what-is-devops/> Acesso em: 25/04/2021.
 SAVIC, H. Infraestrutura conforme código explicado. 2020.  Disponível
em: <
https://www.digitalocean.com/community/conceptual_articles/infrastr
ucture-as-code-explained> Acesso em: 25/04/2021.
 THOTA, N. Como a infraestrutura como um código e servidores
imutáveis aceleram DevSecOps em aplicativos. 2020. Disponível em:<
https://dzone.com/articles/how-infrastructure-as-a-code-amp-
immutable-
servers#:~:text=Mutable%20Infrastructure%20is%20the%20IT,%2C%
20application%2C%20or%20deployment%20requirements.&text=With
%20DevOps%2C%20even%20developers%20have,not%20to%20the%2
0Production%20environment.> Acesso em: 25/04/2021.
UPGUARD. Declarative vs. Imperative Models for Con�guration
Management: Which Is Really Better? 2020. Disponível em:
<https://www.upguard.com/blog/declarative-vs-imperative-models-
for-con�guration-management>. Acesso em: 25 abr. 2021.