Olá, Habr! Apresento a vocês a tradução do artigo «As Origens do DevOps: O Que Há em um Nome?» do autor Steve Mezak.

Dependendo da sua perspectiva, o DevOps celebrará seu nono ou décimo aniversário este ano. Em 2016, um relatório da RightScale sobre o estado das nuvens observou que 70 por cento das pequenas e médias empresas estavam adotando métodos DevOps. Cada indicador que compõe essa avaliação aumentou desde então. Enquanto o DevOps se prepara para entrar na sua segunda década, seria interessante passear pelos meandros do passado e voltar às raízes do DevOps — e até à origem do próprio nome.

Antes de 2007: A Cadeia de Eventos Ideal

Antes de 2007, uma série de circunstâncias acabou dando origem ao que hoje é conhecido como DevOps.

Produção Enxuta já se estabeleceu como uma melhor prática. Também conhecida como o Sistema de Produção Toyota, a produção enxuta procura otimizar os processos no chão de fábrica. (Por sinal, a liderança da Toyota foi inicialmente inspirada nas técnicas originais de linha de montagem apresentadas pela Ford Motor Company). Melhoria Contínua — é um mantra para a produção enxuta. Na prática, os seguintes caminhos são constantemente avaliados:

1. Manter os níveis de estoques de matérias-primas e produtos acabados ao mínimo. A produção enxuta significa a mínima quantidade de matérias-primas para a produção de bens e a mínima quantidade de produtos acabados esperando para ser distribuídos ou enviados.
2. Minimização da fila de pedidos. Idealmente, os pedidos recebidos devem imediatamente se tornar pedidos finalizados. Uma métrica chave da produção enxuta sempre será o tempo desde a recepção do pedido até a entrega.
3. Maximização da eficiência do processo produtivo. A reorganização de processos e a automação melhorada se unem com o objetivo de produzir bens o mais rápido possível. Cada seção da produção ao longo do caminho (corte, soldagem, montagem, teste, etc.) é avaliada quanto à ineficiência.

No mundo da TI, os métodos tradicionais da cascata na modelagem de desenvolvimento de software já deram lugar a métodos ágeis e iterativos, como Agile. A velocidade era um grito de guerra, mesmo que a qualidade às vezes fosse sacrificada em busca de desenvolvimento e implantação rápidos. De maneira semelhante, a computação em nuvem, em particular Infraestrutura como Serviço (IaaS) e Plataforma como Serviço (PaaS) se estabeleceram como soluções maduras nos processos e na infraestrutura de TI.

Finalmente, conjuntos de ferramentas para Continuous Integration (CI) começaram a surgir recentemente. A ideia das ferramentas de CI foi concebida e apresentada por Grady Booch em 1991 em seu Método Booch.

2007-2008: O belga desapontado

O consultor belga, gerente de projetos e praticante de Agile Patrick Debois aceitou um cargo do governo da Bélgica para ajudar na migração de data centers. Em particular, ele trabalhou na certificação e verificação de prontidão. Suas responsabilidades exigiam que ele alinhasse ações e construísse relacionamentos entre as equipes de desenvolvimento de software e as equipes de operações servidores, bancos de dados e redes. Sua frustração com a falta de coesão e as barreiras que separavam os métodos de desenvolvimento e operações geraram descontentamento. O desejo por melhorias logo levou Debois à ação.
Em 2008, na conferência Agile em Toronto, Andrew Schaefer propôs moderar um encontro informal para discutir o tema "Infraestrutura Agile". E apenas uma pessoa compareceu para discutir o assunto: Patrick Debois. Sua discussão e troca de ideias impulsionaram o conceito de administração de sistemas de forma Agile. Nesse mesmo ano, Debois e Schaefer fundaram um grupo moderadamente bem-sucedido de Administradores de Sistemas Agile no Google.

2009: O caso de colaboração entre Dev e Ops

Na conferência O’Reilly Velocity, dois colaboradores do Flickr, o vice-presidente sênior de operações técnicas John Allspaw e o CTO Paul Hammond, apresentaram a agora famosa apresentação “10 implantações por dia: colaboração Dev e Ops no Flickr”.

A apresentação foi no estilo de um drama, Allspaw e Hammond encenaram uma complexa interação entre representantes de Desenvolvimento e Operações durante o processo de implantação de software, enquanto buscavam culpados e se acusavam mutuamente com o espírito de 'Esse não é meu código, são todos os seus computadores!' A apresentação deles confirmou que a única saída razoável é que a atividade de desenvolvimento e implantação de software seja suave, transparente e totalmente integrada. Com o tempo, essa apresentação se tornou lendária e agora é considerada historicamente como um marco fundamental quando surgiu na indústria de TI a demanda por uma metodologia conhecida hoje como DevOps.

2010: DevOps nos Estados Unidos da América

Com o aumento do número de apoiadores, a conferência DevOpsDays foi realizada pela primeira vez nos Estados Unidos da América em Mountain View (Califórnia), imediatamente após a conferência anual Velocity. Vamos para 2018: mais de 30 conferências DevOpsDays estão programadas, incluindo dezenas nos Estados Unidos.

2013: O Projeto 'Fênix'

Para muitos de nós, outro momento notável na história do DevOps foi a publicação do livro 'Projeto Fênix' por Gene Kim, Kevin Behr e George Spafford. Neste romance, a história de um gerente de TI é contada, que se encontra em uma situação sem saída: ele foi encarregado de salvar um projeto crítico de desenvolvimento de comércio eletrônico que não funcionou. Um mentor misterioso do gerente - um membro do conselho, obcecado pelas técnicas de produção enxuta - sugere ao protagonista novas maneiras de conceber TI e desenvolvimento de aplicações, antecipando o conceito de DevOps. A propósito, 'Projeto Fênix' nos inspirou a escrever o livro 'Mude para a terceirização, ou...' sobre uma história similar do mundo dos negócios, quando um vice-presidente de software utiliza DevOps durante o desenvolvimento de um novo grande produto em outsourcing.

DevOps para o Futuro

DevOps deve ser descrito mais como uma jornada ou, talvez, uma aspiração, do que como um destino final. DevOps, assim como a produção enxuta, busca a melhoria contínua, aumento de produtividade e eficiência, e até mesmo a implantação contínua. As ferramentas automatizadas para apoiar o DevOps continuam a evoluir.

Muito foi alcançado desde a criação do DevOps na última década, e esperamos ver ainda mais em 2018 e no futuro.

Fonte: habr.com