Simples, facilidade de START, curva de aprendizado rápida e um enorme potencial para auxiliar (e muito) a vida de um administrador de sistemas. Esse é o Ansible, da Red Hat, que desde 2013 vem angariando uma legião de fãs, criando assim uma comunidade bem bacana. Neste primeiro, de uma série de artigos, tratarei do panorama geral, ou melhor, do contexto mais amplo sobre DevOps e automação na T.I.

1. Origem & Cronologia Before 'DevOps' There Was 'Agile'

2008 - Agile Conference - Toronto/Canadá

Durante a conferência, o programador Andrew Shafer divulga sua palestra em um anúncio intitulado "Infraestrutura Ágil". Somente um expectador comparece: Patrick Debois. Belga, consultor, gerente de projetos e adepto ao Manifesto Agile (2001).

Vendo a lista e constatando que haveria uma única pessoa, Shafer não vai à própria sessão que iria ministrar. Achava que não haveria interesse em seu tópico, por isso tal atitude. Mais tarde, naquele mesmo dia, Debois o encontra pelos corredores e iniciam uma longa conversa. Tempos depois juntos formariam o Agile Systems Administration Group.

2009 - O'Reilly Velocity Conference - Flickr

Passado um ano desde a Agile Conference, ocorre a Velocity Conference da Editora O'Reilly. Nela, dois engenheiros da Flickr (John Allspaw e Paul Hammond) dão uma palestra chamada de "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr".

Aqui eles explicam os resultados obtidos e desafios enfrentados ao aproximar as equipes de desenvolvimento e operações da própria Flickr. Coincidência ou não, Patrick Debois, o mesmo da Agile Conference, assiste remotamente o seminário e logo depois, lamenta em seu twitter não poder estar presente.

Como resposta, ele obtém de um seguidor a sugestão de criar a seu própria "Velocity" na Bélgica, sua terra-natal e residência. Debois aceita, mas não antes de escolher um nome para o evento. E assim o faz, juntando as três letras iniciais de 'development' e 'operations': nomeando-o de DevOpsDay.

Tal evento acontece em 30 de outubro de 2009, no mesmo ano, e acaba se espalhando ao redor do globo em vários países. A partir daí, Patrick Debois é creditado como "pai do termo DevOps" e sua disseminação mundo afora.

2. Mas afinal, como classificar o DEVOPS? Trata-se do que? Em teoria

Existe um extenso debate acerca do que significaria o termo DevOps. Até hoje não há consenso se tal palavra implica em uma cultura, uma metodologia, uma forma de comunicação entre equipes ou uma simples ideia. É possível encontrar discussões em andamento nos mais diversos meios: fóruns especializados, listas de e-mail, sites e na própria academia.

Sendo assim, ainda não temos uma sentença final e definitiva, por enquanto. Felizmente ou infelizmente, seja isso bom ou ruim. Todavia, uma "corrente" defende classificar o DevOps como uma filosofia. Em outras palavras, seria algo muito maior e bem mais abrangente do que os significados anteriormente citados (cultura, método ou comunicação).

Tenho que confessar que sou bastante simpático a esta definição e aceito utilizá-la para conceituar o DevOps. Mas você, querido leitor, não é obrigado a concordar comigo, muito menos ser seguidor desta escola de pensamento. Como indivíduos, somos livres para buscar e formar (por conta própria) a nossa opinião sobre determinado assunto, sem desconsiderar, é claro, os fatos e a realidade observada.

Além disso, antes de emitir qualquer opinião de cunho mais técnico, é muito importante pesquisar o "Estado da Arte" do que se está abordando/falando. Somente dessa maneira poderemos embasar nossa hipótese fundamentalmente bem e dar continuidade ao trabalho que outras pessoas iniciaram no passado, afinal, este é o princípio da Ciência moderna.

"Se eu vi mais longe, foi por estar sobre os ombros de gigantes"

Isaac Newton

3. Qual é o propósito de DEVOPS na prática?

Já ouviu falar naquela história de que programadores e sysadmins (de uma mesma empresa) não se dão tão bem assim?

Se sim, então provavelmente você é da área de TI. Mas calma, não estou me referindo às brigas de contato físico, intrigas pessoais ou disputas para ver quem é o melhor. Não, não é nada disso! Falo de um conflito de interesses, melhor dizendo, uma espécie de atrito entre os objetivos de cada time: sendo um deles a equipe de operações ou infra (sysadmins) e o outro sendo a equipe de desenvolvimento (programadores).

Explicando... Os desenvolvedores são constantemente cobrados pelos seus superiores para que agreguem valor, ou seja, atraiam o capital responsável por gerar receita e lucro, na forma de novas funcionalidades e/ou implementando recursos até então inéditos em suas plataformas/softwares/aplicativos.

Em contrapartida, os administradores de sistemas são orientados pelos gerentes e diretores a prezarem sempre pela estabilidade, disponibilidade e continuidade do ambiente computacional (datacenters, parque e servidores). Na prática, o que ocorre é a competição entre esses dois grupos para cumprir as etapas e processos alheios de cada um, não importando se o outro teve êxito ou não com os seus. Isso resulta muitas vezes em projetos incompletos, quebrados do ponto de vista do todo. É a famosa visão fragmentada.

Devido a essa problemática (pano de fundo), é bastante comum, até mesmo recorrente durante reuniões de equipes e conversas de trabalho haver questionamentos como:

• Velocidade ou estabilidade?
• Recursos ou usabilidade?
• Acesso ou controle?

Seja qual for seu papel dentro da empresa que trabalha, quero dizer, independente se você é um leitor "programador" ou um leitor "admin", deixo aqui um conselho: na próxima reunião que participar, aborde o DevOps como sugestão de pauta ou explique brevemente do que se trata. Pois, caso seus pares, bem como seus superiores ainda não o conheçam, será uma oportunidade de ser um protagonista ao propor algo que causará uma mudança de cultura radical e extremamente benéfica à organização.

Lembre-se sempre: a principal meta do DevOps é proporcionar uma melhor integração entre desenvolvedores e sysadmins. De que forma? Deve estar se perguntando:

• Facilitando a comunicação entre os mesmos;
• Eliminando barreiras e muros "invisíveis" quanto a responsabilidade ("já fiz a minha parte", "o problema não é meu", "na minha máquina funciona", "aumenta memória e processamento que resolve");
• Recompensando, favorecendo o trabalho em equipe (mesmo grupo) e intersetorial (times diferentes);
• Por último, mas não menos importante, tornar mais orgânica e fluida a entrega de valor da tecnologia dentro da empresa.

4. Dois lados, uma mesma moeda chamada devops

Para atingir o status de DevOps, podemos optar por dois caminhos distintos. São eles: a gerência de configuração ou a orquestração. Cada uma delas apresenta certas particularidades, assim como prós e contras. Para que fique claro, e não exaustivo, tentarei resumir ambas em poucas linhas, contudo separadamente.

A. Gerenciamento de configurações

Tradicionalmente opera em arquiteturas do tipo agente/servidor. Aqui o server memoriza e armazena as informações de todas as configurações desejadas para os nodes (nós). Normalmente, são arquivos estáticos que não suportam variáveis ou qualquer coisa de natureza dinâmica.

Funciona em intervalos regulares pré-definidos. O agente é executado na ponta do node, que busca pelo servidor central e aplica a última configuração estabelecida, sendo essa uma ação local ao nó em questão. Detalhe para o fato de que o servidor nunca se conecta aos seus alvos, o normal e habitual é justamente o oposto, os alvos se conectarem ao server.

Para aprofundar mais no tema, procure pelas seguintes palavras-chave em motores de busca: Escola GCONF, Mark Burgess, CFEngine, Gerência de Estados.

B. Orquestração

Consiste em executar uma ou mais tarefas de forma paralela e às vezes não em tempo real dentro de um sistema operacional ou em um grupo de máquinas. Sob a ótica da automação de infraestrutura, será sempre quando alguém se conecta em N sistemas e executa algo, pontualmente, sem exigências rígidas ou grandes controles.

Para aprofundar mais no tema, procure pelas seguintes palavras-chave em motores de busca: Containers, Docker, Orquestradores, Kubernetes.

5. E o Ansible? Orquestrador ou gerenciador?

Responder essa pergunta não é tão fácil. Até porque na Internet, já faz alguns anos que ocorre um eterno debate, por parte de alguns e um pouco acalorado (haha!), se o Ansible é ou não um orquestrador. Questionam até se ele apresenta características da cartilha do CFEngine, e por tabela, considerado um "discípulo" de Mark Burgess e sua escola GCONF.

Enfim, debates de lado e antes de expor o meu entendimento, gostaria de mostrar o que Michael DeHaan, nada menos do que o criador do Ansible, disse em um post no grupo de discussão do Ansible. Na verdade, peguei emprestado um resumo da postagem completa graças ao site ansible-br.org, cujo link segue FAQ :: Documentação Ansible-br.

Quanto ao grupo original, encontramos aqui:

• OT: Idempotence, convergence, and other silly fancy words we use too often

"Esta coisa de estado desejado de vez em quando é escrita de forma errada como 'Convergência'. Convergência, tipicamente, significa rodar o processo 4 ou 5 vezes até conseguir chegar no estado desejado. Isso é terrível se você quer dar somente um apenas um salto. A indústria está um pouco atormentada com a ideia de que coisas simples devem ser falada em termos complexos e o Ansible não é bem assim. O nosso objetivo é simples, falado em inglês claro: Get Stuff done (faça acontecer)."

Lendo todo o texto, a meu ver, Michael não estava preocupado em classificar sua ferramenta entre um dos dois tipos. Tão pouco em usar palavras complexas para explicar coisas simples. Seu intuito foi deixar bem claro que o Ansible é fácil, direto ao ponto e segundo ele mesmo, "faz as coisas acontecerem". O que é verídico baseando na experiência deste autor até aqui.

Sobre o que eu penso que o Ansible, bem, se olharmos a cartilha GCONF, o Ansible não segue completamente à risca. Pontos a serem destacados: ele não é rígido, não tem controle detalhado, nem tudo é idempotente (algumas coisa sim, outras não), é descentralizado devido à sua arquitetura sem agente, talvez o principal, o sentido da comunicação: a máquina controladora (podemos chamar de servidor) é quem se conecta aos nodes e não o contrário, como acontece no CFEngine.

Tendo isso em mente, classifico e defino o Ansible como majoritariamente um orquestrador, que eventualmente incorpora e acumula funções de gerenciamento de configuração.

Mas e você? Qual é a sua concepção a respeito do Ansible? Comentários são para isto. :)

Até a próxima!

Referências

• The Incredible True Story of How DevOps Got Its Name
• What is DevOps? Patrick Debois Explains - Linux.com
• DevOps - Wikipedia
• Agile System Administration - Google Groups