Continuação da Parte1.
Durante a leitura do Phoenix, sempre pesquisando mais sobre esse tal de DevOps, percebi que estava descobrindo um universo bem maior do que simplesmente CI/CD, build automático, versionamento Git ou testes de qualidade/automatizados. A quantidade de disciplinas, tecnologias e conceitos envolvidos é algo que extrapola qualquer conceito malformado ou simplista. Foi aí que as primeiras palavras chave entraram no jogo, cultura e mindset!
A premissa para adoção de DevOps é a mudança na cultura organizacional. Foi por esse motivo que a lista de livros aumentou e o Mindset entrou na fila de leitura, agora com 5 livros.
O curso em BH seria como um “intensivão” de aproximadamente 16h de aula presencial num fim de semana (sábado e domingo), e um complemento de aproximadamente 2 a 3 horas de aula online após alguns dias, ou seja, muito conteúdo para pouco tempo.
Começamos o sábado muito bem, com pessoas de diversas empresas, conhecimentos diversos, funções das mais variadas, e até mesmo objetivos e expectativas diferentes a respeito do DevOps, até porquê o conceito ainda seria esclarecido, não só ao longo do curso, mas ao longo dos estudos, o que traria cada vez mais clareza sobre o assunto. Cada aluno com sua experiência, expectativa, e visão de aplicação de DevOps dentro do seu setor, foi percebendo que o “bixo” DevOps era bem mais amplo que uma sopa de letrinhas e ferramentas. A união Dev + Ops foi ficando mais clara a medida que discussões surgiam, apesar do nome não ser algo novo, sendo difundido a partir de 2009, por Patrick Debois através do primeiro devopsdays.
Uma das coisas que mais me chamou atenção, foi que todos tinham tendência a citar formas de implementação utilizando diversas ferramentas, e não mecanismos arquiteturais. Ficou muito claro ao longo do curso que, independente da ferramenta ou tecnologia, os pontos que exigiam mais atenção, eram a cultura organizacional e a mudança de pensamento dos colaboradores dessa organização, principalmente dos líderes.
Curiosamente, testes é a outra disciplina que, junto a cultura organizacional, ocupa o segundo lugar em carga horária. Por que será?
Dois dos maiores desejos de organizações ao adotar DevOps, são o Continuous Delivery e Continuous Deployment. Desejo esse que, dentre diversos fatores, é diretamente proporcional à quantidade de testes automatizados, dos mais diversos tipos. Não há como automatizar um processo de entrega contínua de valor se não existe um processo onde erros, como os mais simples, são tratados na ponta, lá no pedido do cliente, na máquina do programador, ou mesmo após a entrega de diversas features. Nada pode seguir adiante sem que testes como os de integração e aceitação estejam 100%.
Legal, agora sabemos que cultura organizacional, mudança no pensamento e automação de testes, são alguns pilares para dar mais um passo no DevOps. Mas como entregar valor se não temos bem definido o que, quando e pra quem entregar? É aí que entram as metodologias ágeis de desenvolvimento de software.
Entre 1947 e 1975, utilizando Lean Manufacturing, Just-in-time e Kanban, Taiichi Ohno criou o famoso Toyota Production System. Acredito que ninguém daquela época, imaginaria que o desenvolvimento de software no século 21 seria baseado nesse modelo de sucesso, que hoje é referência para as mais diversas industrias.
Scrum, Agile, Kanban, Lean, etc, são as referências para que a entrega contínua de valor se torne realidade. Não havia mais como esperar o ciclo completo de um processo waterfall. Sendo assim, o backlog é uma peça crucial para que a entrega seja adequada, agregue valor para o cliente e que o Return of investment seja de acordo com o esperado.
Tudo está muito bonito até agora, uma sopa de letrinhas, um monte de automação para entrega de código, com qualidade, todas as features bem definidas pelos clientes, mas e agora, onde vamos entregar isso tudo?
Infraestrutura! É nesse emaranhado de servidores, regras de firewall, storages, etc que vamos colocar nossa aplicação disponível para o mundo!
Profissionais de infraestrutura suam para manter centenas de programas rodando, consumindo recursos, sem que muito possa ser feito. Por isso, toda automação, todos os testes e toda arquitetura de software deve ser bem planejada para que os serviços, ou melhor, microserviços sejam escaláveis, tenha capacidade de auto recuperação, não consumam mais recursos que o devido, suportem uma carga de requisições preestabelecida, dentre demais atributos de qualidade.
Por motivos como esses, dentre dezenas que posso citar, o conteúdo de Infraestrutura, gerenciamento de dados e dependências de componentes está em primeiro lugar na carga horária do curso.
Agora vem o calcanhar de Aquiles, governança! Essa palavrinha dá até arrepios em muitos gestores.
Agora imagine se além dessa automação toda, a governança conseguisse realizar seu trabalho, com normas, procedimentos, coletando evidências? O ITIL sofreu nos últimos anos muito preconceito por não se adequar a esse novo modelo de trabalho, sugerindo-se inclusive o “ITIL Lite”. Agora, com o lançamento do ITIL 4 (que pretendo escrever em breve), acredito que teremos novidades para o mundo DevOps.
Bastante coisa foi citada, mas não é tudo! Na parte 3 continuo para que este post não fique muito extenso.
Obrigado a todos e até breve!
