Os Padrões dos Gigantes da Web - DevOps

le 11/04/2014 par Sergio Luis Peixoto Fernandes
Tags: Software Engineering

O movimento DevOps põe em cheque a fronteira entre as equipes de desenvolvimento e de operações. Não que essa discussão seja nova, mas a reestruturação proposta pelo DevOps é mais profunda, e bastante coerente com as metodologias ágeis, já presentes em boa parte das equipes de desenvolvimento, mas ainda distantes das equipes de operações.

O DevOps inclui muitas lições aprendidas dos Gigantes da Web (Amazon, Facebook, LinkedIn, etc.), que perceberam que não adianta fazer o desenvolvimento ágil, e parar nos processos lentos das equipes tradicionais de operações. O Time to Market (TTM) é um conceito chave para o sucesso dessas empresas, e para melhorá-lo é preciso rapidez não só no desenvolvimento, mas em toda a cadeia do produto.

Há outras vantagens no DevOps, mas o ponto central é realmente o TTM.

Dev & Ops: Preocupações diferentes, mas com um mesmo objetivo

É importante notar que, apesar de cuidarem do mesmo produto, as equipes de desenvolvimento e operações jogam em times diferentes: tem objetivos e culturas distintas, e até mesmo opostas.

Devops_fig-1

Figura 1.

O desenvolvimento procura ser mais reativo, principalmente devido às pressões do negócio e do mercado. Novas funcionalidades, novas tecnologias, upgrades nos frameworks, deploys em ambientes de teste, etc.

A produção precisa de estabilidade e padronização. A estabilidade é fundamental porque é difícil prever todos os impactos das mudanças no código, na arquitetura ou na infraestrutura. Os efeitos colaterais de pequenas mudanças podem ter consequências graves nos ambientes. Já a padronização é importante para assegurar que regras, como as de segurança, sejam consistentemente aplicadas para assegurar a qualidade dos serviços da infraestrutura.

Mas no fundo as "Dev" e "Ops" tem um objetivo maior em comum: fazer o sistema funcionar com qualidade, na perspectiva do cliente final.

DevOps: Dando continuidade às Metodologias Ágeis

O DevOps é uma estensão do desenvolvimento ágil para incluir infraestrutura e operações. Os mesmos princípios válidos para as equipes de desenvolvimento, que buscam a auto-suficiência englobando profissionais do negócio ao desenvolvimento, se estendem agora com o DevOps até a equipe de operações. Com isso a equipe do produto passa a ter sob seu controle não só o ciclo de desenvolvimento, mas todas as etapas do seu produto, tendo sob seu controle o TTM e a qualidade do produto e do serviço.

Com DevOps, a equipe passa à ser responsável por todas as fases antes realizadas pelas equipes de infra:

  • Criação de ambientes e provisionamento - Tradicionalmente demorado devido à burocracia, aprovações e negociações, questões que desaparecem na ótica DevOps. A automação, a virtualização e a padronização dos ambientes podem tornar a vida da equipe mais fácil;
  • Deploy - Fase onde a maioria dos problemas de instabilidade aparecem. A chave é torná-lo mais frequente e usar muita automação;
  • Resolução de problemas - Onde o jogo de empurra acontece nas empresas. Com o DevOps a responsabilidade é sempre do time todo. O uso de boas ferramentas de monitoramento, a realização de post mortems para análize de incidentes, e a coleta de requisitos não-funcionais para realimentar o desenvolvimento, são algumas das práticas que elevam a qualidade dos serviços.

Os três pilares do DevOps: Infraestrutura como Código, Deploy Contínuo e Cultura de Colaboração

1. Infraestrutura como Código

É incrível como o deploy revela problemas, sejam eles de falta de planejamento, longos procedimentos manuais, diferença de ambientes, etc. A lista poderia ocupar páginas... Mas o impacto maior é sempre na equipe de operações: tipicamente metade do tempo das equipes de produção é consumida pelo deploy ou pelos problemas causados pelo deploy.

DevOps-Fig-02_fix

Figura 2. Fonte: Estudo de Deepak Patil (Microsoft Global Foundation Services) de 2006, via uma apresentação de James Hamilton (Amazon Web Services) http://mvdirona.com/jrh/TalksAndPapers/JamesHamilton_POA20090226.pdf

As automações do provisionamento, da disponibilização e configuração de ambientes, e do deploy podem reduzir muito desses 31% de custo do deploy.

Devops_figura-3

Figura 3. Classificação das principais ferramentas

Essas ferramentas permitem a codificação da infraestrutura, como por exemplo instalação e iniciação de um serviços http, servidor Tomcat, criação de pastas para logs, etc.

Os objetivos são muitos:

  • Garantir um processo repetível, confiável e eficiente, sem a intervenção humana, que é péssima para processos repetitivos;
  • Melhorar a rastreabilidade - para analisar e entender os problemas;
  • Melhorar o "Time to Repair" (tempo de reparo) - em caso de desastre, é possível recriar rapidamente a infraestrutura. Estudos apontam que é mais barato recriar ambientes do que tentar torná-los infalíveis.

A automação acaba aproximando bastante as equipes de dev e ops, já que elas vão compartilhar o código e as ferramentas de provisionamento e de deploy. É possivel também dar mais autonomia aos desenvolvedores, para que eles montem seus próprios ambientes de teste ou integração, ganhando em flexibilidade para os desenvolvedores, e também na diminuição das tarefas de infra.

2. Deploy Contínuo

O Deploy Contínuo é o passo que falta para a Integração Contínua chegar à produção, trazendo o deploy para o pipeline de desenvolvimento.Mary Poppendieck, em "From Concept to Cash", fez a pergunta:

Quanto tempo a sua empresa leva para colocar em produção uma simples linha de código?

É aqui que está clara a divergência de objetivos entre as equipes. O desenvolvimento quer usar apenas parcialmente a infraestrutura, para simplificar o trabalho e entregar seus sistemas o mais rápido possível. Em contrapartida, a equipe de operações quer racionalizar a utilização e os custos dos ambientes, além de estabilizá-los com menos mudanças. Ironicamente, vemos que quanto menor a frequência de deploys, mais alto o Time to Repair (TTR), e portanto pior a qualidade do serviço entregue ao cliente final.

DevOps-Fig-04

Figura 4. Fonte: http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change-4608108

Isso acontece porque ao fazer poucos deploys, acumulam-se mais modificações para colocar em produção: mais linhas de código e mais complexidade, e com isso a capacidade de corrigir rapidamente eventuais problemas será menor, levando ao aumento do TTR.

Fazer deploys frequentes mantém baixo o tamanho das modificações, o que permite reduzir a fatia de 16% de "Incidente Management" da Figura 2.

DevOps-Fig-05

Figura 5. Fonte: http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change-4608108

A Figura 5 mostra um estudo feito no Flickr que relaciona o TTR em função das linhas de código introduzidas ou modificadas nos releases. Repare que os deploys da esquerda, com menos linhas de código, geraram incidentes com TTRs menores, enquanto os deploys maiores da direita geraram TTRs mais longos.

O deploy contínuo em produção pode ter seu risco reduzido com a utilização de patterns como "feature flipping" e "dark launch", além do uso de ferramentas modernas de monitoramento de métricas.

3. Uma cultura de colaboração ou um modelo organizacional

A distância entre as equipes de desenvolvimento e operações torna muito difícil unificar a visão e os objetivos em relação ao produto. Por isso o DevOps prega a cultura de colaboração e a autonomia das equipes de produto. A colaboração significa compartilhar as métricas técnicas e de negócios, dar acesso aos logs e ferramentas de monitoria, analisar incidentes em produção em conjunto, levantar requisitos não funcionais que facilitem a operação e a monitoria, etc. Um símbolo da falta de colaboração é a existência de tickets para solicitar serviços de infra.

Devops_fig-6

Figura 6. Equipe de Projeto

Já as equipes autônomas, são compostas por todos os perfis necessários para conceber, desenvolver e operar um produto. As especializações continuam existindo, mas agora dentro de uma única equipe de produto, com responsabilidade compartilhada entre todos. As grandes empresas web, como a Amazon, usam o lema "You build it, you run it" onde cada equipe é responsável pelo negócio, desenvolvimento e operação da aplicação em produção.

Devops_fig-7

Figura 7. A equipe de produto: "You build it, you run it"

Conclusão

DevOps não é mais que um conjunto de práticas para alavancar melhorias:

  • Ferramentas que permitem automatizar a infraestrutura;
  • Deploy contínuo, possivelmente em produção;
  • Cultura de Colaboração, usando princípios ágeis de melhoria contínua.

Devops_fig-8

Encontre outras práticas dos Gigantes da Web em vários artigos neste blog.

Referências: