Um novo livro escrito por Len Bass, Ingo Weber e Liming Zhu, chamado DevOps: Perspectiva de um Arquiteto de Software“, parte da série SEI em Engenharia de Software, analisa a forma como o DevOps afeta decisões de arquitetura, e o papel de um arquiteto de software nesse universo.

Os autores focam nos objetivos de DevOps: enviar softwares para produção tão rapidamente quanto possível, minimizando o risco, time-to-market e o equilíbrio desses valores contra a qualidade.

DevOps é um conjunto de práticas destinadas a reduzir o tempo entre o envio de uma alteração para um sistema e seu envio para produção em um prazo bem curto, assegurando ao mesmo tempo a alta qualidade.

Essas práticas fundamentais são:

1. Engajar-se em operações como um cliente e parceiro, em que “uma das partes interessadas é a primeira classe”, em desenvolvimento. Compreender e satisfazer os requisitos para implantação, registro, monitoramento e segurança no desenvolvimento de um aplicativo.
2. Envolver os desenvolvedores em tratamento de incidentes. Os desenvolvedores é que tomam a responsabilidade pelo seu código, certificando-se de que ele está funcionando corretamente, ajudando (e muitas vezes assumindo o papel de socorristas) para investigar e resolver problemas em produção. Isso inclui o papel de um “engenheiro de confiabilidade” em cada equipe de desenvolvimento, alguém que é responsável por coordenar alterações e ajustes com operações, para garantir que as mudanças sejam implantadas com sucesso.
3. Garantir que todas as alterações de código e configurações sejam feitas usando mecanismos automatizados, rastreáveis ​​e repetíveis – como um gasoduto de implantação.
4. Implantação contínua de mudanças do check-in para produção, para maximizar a velocidade de entrega, usando essas condutas.
5. Infraestrutura como código. Operações de provisionamento e configuração através de software, seguindo os mesmos tipos de práticas de controle de qualidade (controle de versão, comentários, ensaios) como software de aplicação.

Cultura e colaboração entre desenvolvedores e operações, valores compartilhados e questões organizacionais, o lado mais suave do DevOps, são considerados apenas na medida em que são fatores que podem afetar a velocidade ou a qualidade time-to-market de entrega.

Arquitetura em Nuvem e microsserviços

Como referência para os arquitetos, o livro centra-se em considerações de arquitetura para DevOps. Ele aborda como os sistemas baseados em nuvem trabalham, conceitos de virtualização e especialmente micro-serviços.

Enquanto DevOps não exige necessariamente grandes mudanças arquitetônicas, os autores argumentam que a maioria das organizações que adotam DevOps acham que uma abordagem baseada em microsserviços, como as pioneiras Netflix e Amazon fazem, minimizam as dependências entre diferentes partes do sistema e entre equipes diferentes, e isso também irá minimizar o tempo necessário para obter as alterações em produção – o primeiro passo do DevOps.

A lei de Conway também entra em jogo aqui. O trabalho em DevOps geralmente é feito por pequenas equipes ágeis multifuncionais resolvendo problemas end-to-end de forma independente, o que significa que eles vão naturalmente acabar construindo serviços para empresas pequenas e independentes:

Ter uma arquitetura composta de pequenos serviços é uma resposta a ter pequenas equipes.

Mas há desvantagens e custos em uma abordagem baseada em microsserviços.

Como Martin Fowler e James Lewis salientam, os microsserviços introduzem muitos mais pontos de falha. O que significa que a resiliência tem de ser concebida e construída sobre cada serviço. Serviços não podem confiar em seus clientes ou em outros serviços externos. Você precisa adicionar verificação defensiva de dados e antecipar falhas de outros serviços, implementar tempos e novas tentativas, e deixar pra lá alternativas ou comportamentos padrão de segurança se outros serviços não estiverem disponíveis. Você também precisa criar o seu serviço para minimizar o impacto do fracasso de outros serviços, e para tornar mais fácil e mais rápido recuperar ou reiniciar caso seja necessário.

Os microsserviços também aumentam o custo e a complexidade do sistema de teste end-to-end. O tempo de execução, desempenho e latência são degradados devido à sobrecarga de chamadas remotas. E o monitoramento e a solução de problemas em produção podem ser muito mais complicados, uma vez que uma única ação muitas vezes envolve muitos microsserviços trabalhando em conjunto (um exemplo é o LinkedIn, no qual uma única solicitação do usuário pode acionar uma cadeia de até 70 serviços).

DevOps em arquitetura: monitoramento

Em DevOps, o monitoramento se torna um fator muito mais importante do que arquitetura e design, a fim de atender aos requisitos de operações.

O capítulo sobre monitoramento explica o que você precisa para monitorar seu ambiente e por quê, trazendo métricas DevOps, desafios em sistemas de monitoramento sob mudança contínua, acompanhamento e monitoramento de microsserviços na nuvem, gerenciamento de log comum e ferramentas de monitoramento para sistemas online.

O monitoramento também se torna uma parte importante dos testes ao vivo em DevOps (Monitoramento como Teste) e desempenha um papel fundamental na implantação contínua. Os autores olham para tipos comuns de teste ao vivo, incluindo canaries, testes A/B e o famoso Exército Simio da Netflix em termos de verificação passiva (Chaos Monkey, Monkey Compliance) e teste ao vivo ativo (Chaos Monkey e Latency Monkey).

DevOps em arquitetura: segurança

A segurança é outra importante preocupação transversal em arquitetura de software abordada no livro. Ele olha para os fundamentos de segurança, incluindo a forma de identificar ameaças (usando o modelo STRIDE da Microsoft) e os recursos que precisam ser protegidos, CIA, gerenciamento de identidade e controles de acesso. Ele fornece uma visão geral dos controles de segurança em NIST 800-53, e questões de segurança comuns com VMs e em arquiteturas em nuvem (especificamente AWS).

Em DevOps, a segurança precisa ser conectada à implantação contínua:

1. Impondo que todas as alterações do código e de configuração sejam feitas através de implantação contínua.
2. Testes de segurança devem ser incluídos em diferentes estágios da fase de implantação contínua.
3. Protegendo o próprio produto, incluindo os logs e outros artefatos, e realizando verificações de segurança que precisam ser parte do monitoramento (como Monkey Compliance e Monkey Security da Netflix).

Implantação contínua

Desenvolvedores – e arquitetos – têm de assumir a responsabilidade para a construção de seus testes e implantação de vias automatizadas de testes. O livro explica como a implantação contínua aproveita a integração contínua e mostra abordagens comuns para gerenciamento de código e automatização de testes. E ele ainda enfatiza o papel das regras de acesso ao longo da implantação – decisões manuais ou controles automáticos em pontos diferentes para determinar se está ok seguir em frente, desde o desenvolvimento de testes para encenar os testes de produção e, em seguida, enviar o código final para a produção.

DevOps e arquitetura de software moderna

O livro faz um bom trabalho em explicar as práticas DevOps comuns, especialmente sobre implantação contínua, em um desenvolvimento, em vez de em operações de contexto. Ele também olha para questões contemporâneas na arquitetura de software, incluindo virtualização e microsserviços.

É menos acadêmico do que o outro livro de Bass, “Arquitetura de Software na Pratica“, e enfatiza a importância de operações do mundo real e relação a confiabilidade, segurança e transparência (acompanhamento e controle ao vivo de testes) em arquitetura e implementação.

Este é um livro escrito principalmente para arquitetos de software empresariais e gerentes que querem entender mais sobre DevOps, implantação contínua e seus serviços em nuvem.

Se você já é um profissional DevOps e trabalha com microsserviços na nuvem, provavelmente não vai encontrar nada de muito novo aqui.

Mas se você está pesquisando como aplicar DevOps em escala, ou como migrar sistemas corporativos legados para microsserviços na nuvem, ou se você for um desenvolvedor que quer entender as operações nas quais o DevOps pode melhorar o seu trabalho, este livro definitivamente vale a leitura.

***

Jim Bird faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://swreflections.blogspot.com.br/2015/06/software-architecture-in-devops.html