quarta-feira, 25 de novembro de 2015

O Caô do Devops






Então, sua empresa tem problemas com a infraestrutura de TI que suporta suas aplicações. Grande novidade! Afinal de contas, qual empresa não tem? A questão é: Como você pretende resolver estes problemas? Contratando "Devops"?







Esse modelo de organizar a área de TI em dois mundos distintos, "Desenvolvimento" e "Operação", já se esgotou há tempos, porém, as empresas continuam investindo nessa ideia absurda e caquética.
Essa separação provoca vários problemas nas aplicações. Para começar, os Desenvolvedores são completamente isolados do mundo real, e os Operadores são completamente isolados do futuro das aplicações que irão trabalhar.

Por serem totalmente separados, não existe a noção de "equipe" entre eles, e o apontar de dedos é a prática mais comum, quando os problemas acontecem. Os Desenvolvedores querem inovação, os Operadores querem estabilidade. Mas ambos deixam de cooperar para que a inovação e a estabilidade aconteçam.

Devops ao resgate

Eu fico impressionado com a capacidade do Mercado de TI de absorver e distorcer completamente os conceitos. Os fornecedores se apressam em transformar ideias em "buzzwords", embutindo-as em seus "produtos", que acabam criando mais problemas do que resolvendo-os.

Devops está sendo assim. Apontada como solução para a separação existente entre Desenvolvedores e Operadores, esta filosofia tem sido completamente distorcida pelo Mercado. Logo surgiram: Produtos  "Devops", Metodologias "Devops" e até Consultores "Devops".
Não é por aí...

Os três pilares da salvação

Sem querer parecer estoico, gostaria de falar sobre as três características que toda infra moderna de TI deve incorporar: REA
  • R - Resiliência: capacidade de se recobrar facilmente ou se adaptar à má sorte ou às mudanças;
  • E - Elasticidade: capacidade de aumentar ou diminuir automaticamente a disponibilidade de recursos computacionais, de acordo com a demanda;
  • A - Automação: capacidade de gerar ambientes automaticamente, com base da ultima configuração salva, e de entregar continua e imediatamente as aplicações;
Estas três características fazem parte do que se conhece como "Infraestrutura Ágil". Sim, estamos roubando o sufixo "Ágil", porém, náo há melhor maneira de descrever como deveria se comportar a infra de TI que atende a projetos ágeis.

Existem alguns fundamentos das práticas ágeis que exigem a instalação de um ambiente de TI com as características REA, entre elas, a Entrega Contínua, que justifica por si só o investimento em tais práticas. A capacidade de entregar continua e frequentemente, qualquer versão do software, em qualquer ambiente desejado.

Se você não investe em uma Infraestrutura Ágil, então não adianta insistir em tolices, gastando tempo e dinheiro com produtos e consultores ágeis, nem contratando "Devops", pois, enquanto não se conscientizar que precisa mudar a organização da sua área de TI, nada mudará.

Como alcançar o Nirvana?

Meu caro, minha cara, pare para pensar no que é essencial para sua Empresa. O que você quer? Se você trabalha em uma Empresa moderna, então sabe que os aplicativos são parte fundamental do seu negócio, e que a velocidade do Mercado aumenta muito a concorrência, logo, é fundamental se adaptar rapidamente a ele.

O que você precisa é diminuir o lapso de tempo e o risco de atualizar seus aplicativos. Você, como todos os outros, aprendeu a valorizar as buzzwords, por exemplo: "Agile", "ROI", "Devops" etc. Então, acrescente mais uma: Infraestrutura Ágil e REA.

Primeiro passo: Foco

Jeff Bezos, fundador da Amazon, criou o conceito de "Time de 2 pizzas". Ele dizia que nenhuma equipe de projeto deveria ser tão grande, que não pudesse ser alimentada por duas pizzas. Por que? Para minimizar os problemas de comunicação.

A equipe que cuida de um projeto deve ser pequena e coesa, reunida em torno de um objetivo comum: Entregar e manter a aplicação. Neste cenário, Devs e Ops devem colaborar para criar novos releases, preservando a estabilidade do software.

Nada mais de "Passar para a Produção"! Até porque, "Produção" é apenas mais um ambiente, que pode ser gerado e destruído sob demanda. Atividades comuns, como: Planejamento de Capacidade e Segurança, podem continuar a serem exercidas por uma área em separado, mas as equipes devem ter o poder de planejar, implementar e entregar seus aplicativos e sua própria infraestrutura.

O foco é: Entregar e Manter a aplicação! Este deve ser o objetivo de uma equipe única e coesa.

Segundo passo: Engenharia

Deixe de lado a bruxaria e a superstição. Software não pode ser construído com base no "bom senso". Adote as práticas consagradas de Engenharia de Software. Nada de confiar em fornecedores e ferramentas milagrosas.

Abrace o ágil, mas não os "agilistas". Colocar Kanbans, fazer reuniões em pé e jogar Planning Poker, por si só, não o ajudarão a construir software de forma profissional. Se você gosta de "ágil", por que não adota as outras práticas, mais obscuras, como: TDD - Test Driven Development, Pair programming e Integração Contínua? É claro... É mais fácil colocar uma porcaria de Kanban... Eu entendo.

O SWEBOK, o livro de feitiços da Engenharia de Software, já prevê vários mecanismos para que você construa software de maneira organizada e profissional. Entre eles estão:
  • Teste automatizado e abrangente: Sim, o teste é pago pelo Cliente e deve fazer parte da Entrega. E ele deve ser abrangente, automatizando desde testes unitários até testes funcionais;
  • Integração contínua: Não basta existirem casos de teste automatizados. É necessário que eles sejam continuamente executados, como parte do seu ciclo de vida de aplicação. O "Build" de uma versão deve acontecer em um ambiente "sala limpa", e não na máquina do desenvolvedor, e todos os testes devem ser executados, gerando um pacote entregável de alta confiabilidade;
  • Entrega contínua: Você deve ir além, entregando automaticamente o pacote executável em um ambiente operacional, seja ele qual for (Desenvolvimento, Teste ou Produção). E você deve ser capaz de entregar (ao toque de um botão), qualquer versão do software (branch) em qualquer ambiente.
Terceiro passo: REA

Com tudo o que falamos antes, você tem o que precisa para criar um ambiente REA (Resiliente, Elástico e Automatizado), que é a base da Infraestrutura Ágil.
A primeira coisa que você deve fazer é particionar melhor o seu código fonte, de modo que seja composto de módulos autônomos e distribuídos. Uma maneira de fazer isto é utilizar Arquitetura de Microsserviços. Ferramentas como o Dropwizard podem te ajudar a implementar isto.

Resiliência: Se você modularizou sua aplicação corretamente, então é possível criar várias instâncias dos seus "módulos", que podem cooperar entre si para atender às requisições simultâneas. Então, se você vai ter múltiplas instâncias, é necessário ter algum mecanismo de monitoração ativa, que verifique os problemas e seja capaz de destruir e recriar novas instâncias. Seu sistema deve ser capaz de se recuperar de um erro, corrigindo e reportando as falhas.

Elasticidade: Você deve possuir algum componente que coordene e monitore as instâncias distribuídas, subindo ou destruindo instâncias, de acordo com a demanda.

Automação: Uma instância de um componente seu deve ser criada automaticamente, a partir do seu ciclo de vida, ou seja, com recuperação a partir de um repositório de código fonte, compilação em sala limpa, execução de testes e entrega em ambiente específico.

Algumas práticas e tecnologias auxiliam a criação de um ambiente REA, entre elas:
  • Conteinerização: A entrega e execução de aplicações em Containers Linux (Docker) totalmente imutáveis, o que evita o "Configuration Drift", reportado por Martin Fowler;
  • Coordenação: Uma ferramenta de coordenação de processos distribuídos, como o Apache Zookeeper, pode ajudar a manter a sincronia entre as instâncias de seus módulos;
  • Curadoria: Um componente que realize a curadoria das instâncias dos seus módulos, fazendo escalabilidade para cima ou para baixo, e destruindo instâncias problemáticas;
  • IaC: Infrastructure as Code. Está na hora de tratar sua infraestrutura da mesma forma que o seu código funcional. Chega de Operadores logarem nas máquinas e fazerem besteiras.

Exemplo

Quem lê meus artigos, sabe que eu gosto de matar a cobra e mostrar como fiz. Então, recomendo a leitura de um exemplo completo em meu blog: