Qual é a diferença entre DevOps e Automação?

Vejo que sempre que alguém faz o DevOps, trata-se principalmente de automatizar coisas como implantação etc.

Mas onde a automação termina e o DevOps começa?

Uma grande parte do DevOps está possibilitando o lançamento com muita frequência. Isso inclui construção automatizada, teste automatizado etc. Você pode dizer que, para atingir seus objetivos, o DevOps precisa usar a automação para ser eficiente.

Veja como o DevOps e a automação estão relacionados. O DevOps não é apenas automação, há mais do que isso. Por outro lado, a automação não é usada exclusivamente por "pessoas do DevOps". Muita automação estava ocorrendo na TI antes do DevOps aparecer.

Por favor, não considere o diagrama acima para representar tudo o que é DevOps ou tudo isso é automação. É para ajudar o leitor a imaginar como os dois conceitos estão relacionados.

A automação é um atributo-chave do DevOps, mas não é a história completa. A pergunta é como "Qual a diferença entre time-boxe e Scrum?".

Você ouvirá o DevOps chamado de 'cultura', 'movimento', 'metodologia' e todos os tipos de coisas que não serão suficientes para que você entenda, mesmo que essas descrições sejam precisas. Em resumo, o DevOps trata da confluência de metodologias, automação e virtualização do Agile que permitem um novo ciclo de feedback no gerenciamento / controle / direção de um projeto de software.

Com a automação agressiva, as coisas que costumam levar muito tempo e estão sujeitas a erros humanos agora acontecem rapidamente e sem incidentes. Como resultado, tendemos a fazê-los com mais frequência. Um exemplo primário disso é uma 'implantação na produção'. Costumávamos salvar grandes lotes de trabalho e implantá-los fora do horário comercial no caso de "algo dar errado". Mas agora podemos implantar mudanças várias vezes ao dia, de uma maneira que as chances de "algo dar errado" são drasticamente reduzidas e de uma maneira que o impacto de algo dando errado é muito menor quando ocorre.

Uma vez implantado esse processo repetitivo, começamos a vê-lo como um 'pipeline'. Os requisitos entram, o código implantado na produção sai. Automatizamos tudo nesse pipeline - testes, documentação, mesclagens, implantações e mais testes, e assim por diante ... Como as pessoas se concentram na automação, elas não veem a 'mentalidade de pipeline' que a impulsionou. Essa é a metodologia de gerenciamento - a atenção prestada no pipeline - que torna o DevOps mais do que a automação.

Uma vez implementada essa automação, os loops de feedback entram em ação. Começamos a medir coisas como o tempo do ciclo, para que possamos descobrir o que antes tentávamos adivinhar com estimativas. As coisas sobre a arquitetura que dificulta a automação / entrega contínua tendem a ser substituídas por padrões arquiteturais alternativos que facilitam a automação / entrega contínua (vários grandes exemplos disso estão documentados no livro 'Bancos de dados evolutivos'. 'Implantações verdes / azuis' são outra )

Observe que eu pude fornecer essa descrição sem falar sobre Jenkins, Check, Puppet, Ansible, Vagrant, AWS ou qualquer outra ferramenta que a suporta. É isso que entendemos por palavras-chave de nível maior, como 'metodologia'. No final, qualquer conjunto de ferramentas pode ser substituído ... O que nos resta são os princípios básicos de gerenciamento habilitados pela automação e o foco no pipeline.

O DevOps é realmente uma mudança cultural - pretende-se derrubar as barreiras tradicionais entre operações e desenvolvimento (e realmente também com o controle de qualidade e o restante dos negócios!). A idéia é que, em vez de ter 'silos' departamentais, você possa trabalhar diretamente com outras equipes para fazer as coisas com mais rapidez e eficiência.

É tudo sobre remover restrições e otimizar processos. A automação entra nisso muito porque ter processos repetíveis ajuda a remover restrições. Por exemplo: se alguém da operação tiver que fazer um processo de liberação manual para distribuir o código para um ambiente, há algumas coisas que podem atrapalhar - uma é que deve haver alguém na operação livre para fazer a implantação, e dois, há menos confiança no processo de liberação porque o trabalho manual é propenso a erros.

O DevOps inclui automação, mas isso é apenas parte dela. O DevOps é uma mudança cultural para dividir os silos entre as diferentes partes da organização para fornecer um fluxo de valor completo. Proporcionar uma cultura em que os negócios, o desenvolvimento, a garantia da qualidade, a infraestrutura, a segurança, as operações etc. trabalhem juntos para agregar valor a quem quer que seja o usuário final. O DevOps não é uma ferramenta, você não pode comprá-lo, precisa mudar sua cultura.

A automação é uma parte essencial do DevOps, pois permite a velocidade da entrega com qualidade. A automação para o processo de implantação é uma das áreas em que muitas pessoas se concentram primeiro, pois é uma das melhores maneiras de obter valor rapidamente e fornece um alto retorno do investimento, não apenas reduzindo o tempo para a implantação, mas também padronizando o processo e removendo erros.

Gostaria de acrescentar meus 2 centavos:
1) Automação :
     algo que hoje em dia temos que avançar. Tornou-se mais uma necessidade em que a maneira preferida seria automatizar peças, se não todo o processo. Essa abordagem oferece aos usuários (desenvolvedores) flexibilidade para usar uma etapa fixa, além de poderem personalizar conforme necessário.
     A vantagem dessa abordagem é que podemos automatizar as partes que queremos, enquanto o processo individual pode ser vinculado pelo desenvolvedor. Quanto mais granularizadas as etapas de automação, melhor o controle que elas têm.
     Além disso, existem muitas ferramentas para automação em espaços como automação robótica, automação SOP (para o setor de serviços), automação de relatórios (como Splunk), etc.
2) DevOps:
     Dado o estado da qualidade da entrega e a pontualidade esperada no mundo atual, é necessário estender a automação do processo de entrega do software. Para habilitar isso e agregar valor ao cliente da maneira mais rápida possível, o DevOps depende extensivamente de ferramentas de automação.
     A vantagem dessa abordagem é que, as etapas individuais podem ser automatizadas para obter consistência em toda a empresa, enquanto a orquestração geral pode ser modificada para se adequar ao processo necessário para esse projeto.
     As ferramentas de automação individuais (de certa forma), como Chef para implantação, Docker via Dockerfile, Maven para compilação etc. podem ser ligadas provavelmente através do Jenkins para fornecer a solução necessária e, ao mesmo tempo, reduzir o tempo necessário para implementação ou uso .
Espero que isso ajude a agregar qualquer valor ao processo de pensamento que você já possui.

Edit: Esqueci de acrescentar que eu tinha falado sobre o Processo e Ferramentas - 2 dos 3 aspectos no DevOps. Como mencionado pelos outros, o terceiro e igualmente importante aspecto é Pessoas. Uma das principais diferenças que eu assumiria entre isso e a automação seria que as pessoas são mais propensas a absorver a automação com mais frequência do que resistiriam ao DevOps. Eu sinto que isso se deve à natureza do próprio DevOps, pois a automação geralmente está associada a facilitar as coisas para eles, enquanto eles sentem que o DevOps está mudando a maneira como se sentem confortáveis.

O movimento do DevOps consiste em quatro áreas principais abreviadas como CAMS :

1. Cultura
2. Automação
3. Medição
4. Partilha

Aqui está o post de definição original de 2010.

Em cada área, existem algumas ferramentas, processos e práticas geralmente aceitas, embora o assunto não seja bem definido para as Melhores Práticas, na maioria dos casos existem algumas Boas Práticas a serem seguidas.

A automação por si só é um assunto um pouco mais amplo, mas no contexto do DevOps, é apenas um subconjunto do que está sendo abordado. Observe que lideramos a cultura, embora muitos profissionais de DevOps iniciantes no campo frequentemente o ignorem por sua própria conta e risco e pulem diretamente para a automação.

Automação e DevOps não são relacionados. O DevOps é mais parecido com a engenharia combinada, na qual os desenvolvedores de um site ou serviço são todos os operadores desse site ou serviço. Por que esse romance é? Na minha experiência, a primeira coisa que a equipe de operações fez quando algo mais emocionante do que um pontinho de rede aconteceu foi ligar para a equipe de desenvolvimento. Por que eles fizeram isso? Porque toda a equipe de Ops fez foi monitorar e manter uma lista de números de telefone de desenvolvimento para ligar.

Observe que eu não disse nada sobre automação.

Automação é repetir sucesso. Se eu executar as etapas a, bec, e o processo X sempre funcionar, as etapas a, bec serão boas candidatas à automação. Então eu posso usar o tempo para o que costumava ser um processo manual para fazer coisas que me fazem mais dinheiro. A automação é bem-sucedida quando é simples. A implantação de novos lançamentos, a execução de testes de integração, a torção de uma porca, o backup de dados, o equilíbrio de créditos x débitos etc. são ótimos candidatos à automação, pois as etapas são repetidas por uma pessoa ou um robô.

Nota : A novidade é que os desenvolvedores também são os operadores. Não há outro grupo. A cooperação no meu caso era rara. Se não houver nada no Guia de solução de problemas (também conhecido como TSG), você receberá uma ligação telefônica. Na minha experiência, Ops foi a primeira chamada em caso de retroescavadeira. Os problemas entre os serviços estavam fora da casa do leme.