Você já leu aqui neste blog que DevOps não é o novo ALM, sobre o profissional DevOps, sobre ferramentas… mas, o que é realmente DevOps?

TL;DR… não tem! Você vai ter que ler o textão mesmo…

No início

No meu primeiro emprego, lá pelo fim da década de 90… Não! Temos que ir mais longe!

Lá nos anos 80 e início dos anos 90… Não! Mais longe!

“No início… tudo era trevas!…” Tá não vamos exagerar, mas vamos ter que voltar lá para o início da computação… lá atrás no início não havia distinção, não existia desenvolvedores e operações, se você fazia uma coisa tinha que fazer a outra. Até mesmo por que não tinha quase ninguém que fizesse algo relacionado a computadores. Quem não viu recentemente filme como uma parte da história de Turing, construindo a sua máquina, codificando o software básico, o único que era executado. Não havia redes, não havia infra-estrutura, parque, CPD ou mesmo Datacenter. Era o operador/engenheiro/programador e UMA máquina.

Woodstock

Nos anos 60 surgiram programadores, analistas e os operadores. Enquanto os dois primeiros estavam focados em escrever código, o último tinha uma função bem básica: operar a máquina. Ou seja era preciso alimentar a máquina com os programas escritos por outros, cuidar dela, manter ela em funcionamento, coletar resultados… e aí, a TI começou a se dividir.

Disco

Nos anos 70 e 80 tivemos a popularização dos minicomputadores e posteriormente os computadores pessoais, PC’s. A Apple, também representada recentemente nas telas de cinema, mostrava engenheiros construindo seus computadores, mas não mais para uso exclusivo e sim para as massas! Eram criadas linhas de produto, haviam linguagens de programação, a meta era que essas máquinas não estivessem somente nos escritórios onde começavam a se proliferar substituindo máquinas de escrever, faziam relatórios, guardavam informações que antes estavam somente no papel.

Let’s rock!

Se nas décadas passadas as máquinas chegavam as casas, e depois dormitórios, com cada pessoa tem uma exclusivamente para o seu uso… Por que não, interligarmos todas elas? Na década de 90 as redes de computadores ganhavam protocolos, hardware e monitoramento; transformando as ilhas de profissionais em colaboradores. Era possível compartilhar. E aqueles operadores ganhavam poderes para administrar essa conectividade e a responsabilidade de manter tudo no ar, enquanto que os programadores e analistas se afastavam dessa responsabilidade e mantinham a atenção no código.

Alguns cuidavam do abstrato e outros do físico.

Dance

E então veio a virada do milênio, o temível bug não deu as caras no apocalipse anunciado, porém a TI fervia em problemas… problemas que a indústria já estavam resolvendo. E surgiram os programas de qualidade total, as famosas metodologias de processo, RUP, UML; criados para melhorar a comunicação entre o desenvolvimento e operações, era preciso que o desenvolvedor dissesse para ops o que deveria ser feito para instalar o software que eles estavam produzindo; era preciso que operações explicasse a infra que poderia suportar um sistema distribuído para dev…

Mas a separação já existia a tempos, a comunicação não existia mais, só desentendimentos. Era preciso re-aproximar os dois… Mais do que isso, era preciso que eles se torna-sem UM novamente.

Fotografia do caos

Depois do meu primeiro emprego, na área de automação predial, no qual eu usava AutoCAD, e comecei a programar em VBA… eu migrei para desenvolvimento.

Se você viveu a febre da implantação da metodologia RUP, deve se lembrar do diagrama da baleias, vou colocar ele aqui por puro saudosismo.

Diagrama RUP

Diagrama RUP, fonte https://en.wikipedia.org/wiki/File:RUP_Workflows2.gif

O RUP mostrava uma preocupação com o ambiente logo no início de um projeto, o Environment é contruído em pequenas porções ao longo das iterações. Porém, esse processo não era executado em “colunas” e sim nas “linhas”! Ou seja, o ambiente só era pensado no fim do projeto… então o desenvolvedor não sabia onde ele iria funcionar e, pior, muitas vezes operações não sabia que vinha um projeto novo por aí!

Isso se repete até hoje. Inclua aí a rotatividade, documentações incompletas, metodologias mal executadas, projetos mau feitos… e tudo virou um caos!

Streaming

E então chegamos aos últimos anos… com o boom das startups! Apesar da Apple, Microsoft, Google, terem começado anos atrás, e na garagem, como uma boa startup. Nós últimos anos que temos visto uma avalanche de startups sendo criadas, crescendo e sendo vendidas a preços estratosféricos.

Hoje é possível ter acesso a equipamentos avançados para se montar uma linha de produção altamente eficiente… Não quer montar a linha? É possível terceirizar, alugar, até mesmo emprestar essas máquinas. Quer montar uma empresa de serviços? Não é preciso alugar um espaço, comprar equipamentos, móveis… infraestrutura de máquinas e rede… faça na nuvem! Teve um insight e quer testar a ideia antes de qualquer coisa? É possível também, com custo reduzido, do notebook, em sofá, num café… usando uma máquina na outra ponta, fazendo cálculos… de graça!

Essas empresas não podem se dar ao luxo de terem problemas de comunicação. Não podem esperar meses por um software, que parece nunca ficar pronto. Mais do que isso, não podem ter dúvidas de como tudo isso irá funcionar.

DevOps

Bem vindo a era da colaboração, ou, bem vindo de volta as origens: developers & operations, funcionando junto, lado a lado. Ou como UM só. E é só isso…

Sim, só isso.

Uma startup já nasce com um ambiente colaborativo, por que ela precisa disso, ou irá morrer.

Já as grandes empresas, dividias em seus silos, áreas, departamentos, … precisam descobrir uma nova cultura, precisam mudar, ou evoluir. Ou continuarão nos programas de qualidade, de melhoria, de planejamento; desconectados, punitivos; sem conseguirem avançar.

Desconfie de qualquer vaga de DevOps. Se ela existe, é por que não tem colaboração, por que as pessoas vão continuar cada uma no seu silo, no seu quadrado. E isso não é DevOps

Desconfie também de ferramentas de DevOps, pois nenhuma delas irá trazer uma nova cultura. Ela pode ajudar, mas não vai mudar o que está enraizado na empresa, por mais flexível e interessante que ela seja. E isso também não é DevOps.

DevOps é colaboração, é militância, é principalmente cultura, pois é preciso que se queira fazer. E cultura, a gente vive ela e mantemos. Não dá para instalar, comprar ou contratar.

Emmanuel Brandão