Entrevista sobre o livro Entrega Contínua em Java

O livro Entrega Contínua em Java de Daniel Bryant e Abraham Marín Pérez foi lançado no final de 2018, quase uma década após o livro original "Entrega Contínua" de Dave Farley e Jez Humble ser lançado e mais de duas décadas após o primeiro lançamento público do Java.

O InfoQ procurou os autores para entender melhor a partir de sua experiência por que era necessário um livro sobre Entrega Contínua especificamente para o Java e para o ecossistema JVM.

InfoQ: Quase 10 anos após o lançamento do livro Entrega Contínua, o que levou a necessidade de um livro que abordasse especificamente a entrega contínua em Java?

Daniel Bryant e Abraham Marín Pérez: Embora o clássico livro Entrega Contínua de Dave Farley e Jez Humble tenha sido lançado há uma década, vimos, em nossa experiência em consultoria, que as pessoas ainda estão com problemas com alguns conceitos. A verdade é que a entrega contínua é uma tarefa difícil. Mas mesmo após as pessoas finalmente entenderem o que é essa prática, sentimos que muitos desenvolvedores ainda tinham dúvidas sobre a melhor forma de executá-la. Em outras palavras, notamos uma lacuna entre a teoria e a prática. Estávamos interessados em "estar sobre os ombros de gigantes", ou seja, usar o que já sabíamos para então compartilhar o aprendizado prático no livro.

Ao focar em um subconjunto específico da população (desenvolvedores Java), pudemos discutir sobre a entrega contínua de uma maneira mais prática: com ferramentas, bibliotecas e configurações reais. Certamente as opções que escolhemos não são as únicas do mercado, mas, ao fazer a curadoria cuidadosa desse conjunto específico, ajudamos os leitores a iniciar em ritmo acelerado a jornada rumo à entrega contínua.

InfoQ: Quais são as principais conclusões que os leitores devem obter ao ler o livro?

Bryant e Marín Pérez: Uma mensagem importante que tomamos muito cuidado para transmitir é que não há decisões certas ou erradas, apenas escolhas mais ou menos adequadas. Cada empresa é diferente, e com necessidades diferentes temos soluções diferentes. Também estávamos interessados em permitir que os desenvolvedores Java que não estão familiarizados com a parte operacional ou de configuração da entrega de software reconheçam métricas importantes, identifiquem pontos chave e aprendam como fazer as melhores compensações ao adotar a entrega contínua.

No livro, tentamos descrever o que implica a prática geral da entrega contínua, quais são os principais desafios e uma série de medidas possíveis que podem ser tomadas para resolvê-los. Fazendo referência ao excelente trabalho de Steve Smith, acreditamos que a entrega contínua se refere principalmente ao fornecimento de valor aos clientes, e é alcançada quando a estabilidade e a velocidade podem satisfazer a demanda dos negócios. Apontamos várias métricas úteis que podem ser seguidas para permitir que os desenvolvedores a convencer a gerência de possíveis problemas e gargalos, além de demonstrar melhorias à medida que adotam algumas de nossas práticas recomendadas.

Como mencionamos, também esperamos que o leitor retire do livro uma lista de tecnologias ou ferramentas específicas para o Java que podem experimentar ao implementar as práticas de CD. Geralmente recebemos e-mails ou DMs do Twitter solicitando recomendações técnicas e, portanto, colocamos no livro todas as nossas ferramentas favoritas.

Se estiverem procurando uma proposta geral, uma mensagem resumida é que a entrega contínua é um exercício introspectivo e iterativo. No final do dia, devem analisar a própria prática, encontrar os pontos negativos e iterar para melhorar o processo. A entrega contínua implica em melhoria contínua.

InfoQ: No livro, comenta-se sobre a evolução do Java. Poderiam resumir brevemente as principais mudanças na última década e como isso afetou, ou não, o modo de pensar na Entrega Contínua no Java?

Bryant e Marín Pérez: Um dos principais benefícios da entrega contínua é o menor tempo de lançamento no mercado. Construindo uma empresa que possa efetivamente introduzir mudanças estáveis continuamente, criamos uma organização que responde melhor às mudanças. Uma das queixas tradicionais contra as aplicações em Java foi sempre a verbosidade, e que deixa o Java normalmente é em favor de linguagens mais expressivas, onde acham que podem ser mais produtivos. A evolução do Java nos últimos anos foi, principalmente, focada em abordar esses problemas. Recursos como lambdas, inferência de variável local ou pattern matching estão disponíveis em outras linguagens há muitos anos e agora estão lentamente sendo implementadas no Java.

Esse foco nos recursos da linguagem fez com que algumas mudanças importantes em relação ao empacotamento e ao tempo de execução do software moderno estivessem ausentes há um bom tempo no Java. Por exemplo, o desejo dos desenvolvedores de minimizar o tamanho do artefato de implantação só foi possível pelo trabalho de modularização introduzido no JDK 9, e a adoção ainda é um projeto em andamento. Além disso, a JVM apenas reconheceu totalmente os limites de recursos ao executar em um container há aproximadamente dois anos no Java 10, e as correções necessárias só foram suportadas no JDK 8u131. O resultado de exemplos como esse foi que a utilização do Java em algumas plataformas mais recentes de nuvem e nos containers, ou a capacidade de usar parte da inovadora tecnologia de pipeline de entrega, foi adiada. Agora existem muitas ferramentas relacionadas para empacotar, testar e otimizar os tempos de execução, todas apontadas no livro.

Também é importante notar a recente mudança no lançamento de uma nova versão do Java, agora há um lançamento a cada seis meses, em oposição à cadência anterior de dois a três anos, isto também ajuda a entregar mudanças com mais frequência. Afinal, as pessoas que trabalham no Java são usuários da linguagem, que também querem se beneficiar da entrega contínua e estão fazendo todos os esforços possíveis para conduzir o Java nessa direção, enquanto mantêm a estabilidade que o levou à fama na empresa. Se os desenvolvedores quiserem adotar rapidamente os ganhos de desempenho ou novos recursos expostos em cada uma das novas versões do Java, mesmo que estejam adotando apenas as versões LTS, é muito útil ter um pipeline de entrega que teste automaticamente as aplicações.

InfoQ: Jez Humble disse em uma conversa que sem uma arquitetura de sistema modular "não estamos indo a lugar nenhum". Como profissionais experientes, qual a importância de uma arquitetura dissociada para uma Entrega Contínua eficaz?

Bryant e Marín Pérez: É absolutamente fundamental. A capacidade de implantar independentemente de novas funcionalidades nos módulos ou componentes de um sistema maior oferece muito mais opções para aumentar a velocidade e a estabilidade. A entrega contínua implica em mudança contínua e, a cada mudança, sempre há a possibilidade de erros. Também estamos construindo cada vez mais sistemas distribuídos complexos (que também são adaptáveis), que podem ser difíceis de entender e não falham deterministicamente. Quando estamos operando em um sistema complexo ou com uma alta taxa de alteração, a falha não é uma questão de "se", é uma questão de "quando". Depois de aceitarmos a certeza da falha, começamos a planejar as medidas de resolução dos problemas. É nesse ponto que ocorre a dissociação: ao criar limites claros entre as partes do sistema, criamos firewalls que podem limitar o impacto de um erro.

No livro, decidimos nos concentrar também no paradigma arquitetônico dos microservices por esse motivo: podemos obter muitos dos benefícios da entrega contínua se estivermos trabalhando em um monolito modular bem arquitetado, mas isso não fornecerá um limite de isolamento no ponto de implantação. É difícil acertar o design e a implementação de microservices, mas podem oferecer um sistema modular com isolamento, tanto em tempo de compilação quanto em tempo de execução.

InfoQ: Continuando neste assunto, diriam que as arquiteturas de microservices são sempre as melhores para a entrega contínua?

Bryant e Marín Pérez: Preferimos ser cautelosos com declarações "absolutas" como essa. As arquiteturas de microservices trazem diversos benefícios, mas também apresentam muitas desvantagens. Um monolito é incrivelmente simples de ser executado, e isso não é algo que devemos desconsiderar, já que a simplicidade também tem seu valor.

Quando escrevemos código, geralmente preferimos não dar muita atenção a quanto tempo essa implementação vai permanecer atualizada e, em vez disso, refatoramos quando julgamos adequado. Também preferimos aplicar essa filosofia à arquitetura. Talvez comecemos de maneira simples, com um monolito, e a quebra dele em microservices, conforme a necessidade. Em outras palavras, uma arquitetura de microservices nem sempre é a melhor arquitetura para começar, mas tende a ser uma boa opção para evoluir. Para os leitores que desejam aprender mais sobre este tema, recomendamos totalmente o novo livro de Sam Newman, Monolith to Microservices.

InfoQ: Quais são alguns dos principais aspectos não técnicos que podem tornar a implantação da Entrega Contínua um sucesso ou um fracasso?

Bryant / Marín Pérez: Com base em nossa experiência em consultorias, o principal diferenciador não técnico é o envolvimento da gestão na prática da entrega contínua. A abordagem tradicional vê a TI como um centro de custo, e a gestão normalmente não se envolvem com o setor. Eles gerenciam o software em "projetos" e "programas", supondo que sejam atividades com prazo determinado e com uma entrega específica no final. A entrega contínua implica em uma abordagem holística com envolvimento constante, e a empresa não pode se dar ao luxo de simplesmente "deixar todo o trabalho para os técnicos".

Sem o envolvimento de pessoal não técnico, a entrega contínua não pode funcionar.

InfoQ: Recomendariam métricas ou indicadores para equipes e organizações com o objetivo de medir o progresso das iniciativas de Entrega Contínua?

Bryant e Marín Pérez: Esta é uma área muito interessante e que continua a evoluir à medida que aumentamos a compreensão do que a entrega contínua envolve. A referência nesse espaço é o livro Accelerate, de Nicole Forsgren, Jez Humble e Gene Kim, e aqui as quatro principais métricas que se correlacionam com as equipes de alto desempenho são, lead time, frequência de implantação, tempo médio para restauração (MTTR) e alteração na porcentagem de falha. Definitivamente não estamos perdendo tempo rastreando qualquer uma dessas métricas.

Steve Smith também fez algumas sugestões muito interessantes, no livro Measuring Continuous Delivery, o autor ajudou a desenvolver nosso pensamento em torno deste tópico. Aqui Smith foca, principalmente, em tópicos como implantação e criação de produtividade e estabilidade. Em uma nota relacionada, Abraham fez alguns trabalhos sobre como medir a eficácia do pipeline de construção automatizado, medindo o Tempo Médio, Máximo e Ponderado de Construção.

Por fim, as melhores métricas de negócios dependerão das necessidades organizacionais reais, já que a entrega contínua é focada em fornecer valor mais rápido, o que significa que as empresas precisam identificar o que seus clientes, ou a própria empresa, valorizam e depois definir métricas que medem quanto valor está sendo entregue e posteriormente acompanhá-las ao longo do tempo.

InfoQ: Quanta autonomia uma equipe de desenvolvimento Java deve ter sobre o sistema de entrega? Só precisam se preocupar com a definição e execução reais do pipeline? Precisam participar ativamente da configuração e execução das ferramentas do pipeline e da infraestrutura subjacente?

Bryant e Marín Pérez: Esse é um tópico bem controverso. Os desenvolvedores Java precisam estar envolvidos na configuração e execução do pipeline, porque claramente possuem participação no processo. Por exemplo, desejarão atualizar o JRE sem muita dor de cabeça, talvez usando containers do Docker e mantendo o controle da definição do Dockerfile. No entanto, esperar que os desenvolvedores Java controlem todos os aspectos do pipeline de entrega pode ser algo totalmente absurdo, tanto em termos das habilidades necessárias quanto do tempo necessário para cuidar do pipeline.

No outro extremo, temos empresas que criam equipes dedicadas a plataforma, DevOps e SRE que gerenciam todos os aspectos da configuração do pipeline. Isso gera uma equipe de profissionais dedicados e habilidosos e permite que compartilhemos o trabalho entre as equipes, às vezes a mesma infraestrutura pode ser compartilhada por uma empresa inteira, mas corre o risco de isso se transformar em um silo de conhecimento. O ponto ideal provavelmente está no meio termo que seria: Engenheiros do DevOps dentro da equipe ou muito alinhados com a equipe, mas fazendo parte de um grupo multifuncional, no qual podem juntar forças e compartilhar experiências. Se quiser saber mais sobre design de equipe e o impacto que podem causar na entrega do software, recomendamos o excelente livro Team Topologies, de Matthew Skelton e Manuel Pais.

InfoQ: No livro, são abordadas diferentes ações em termos da plataforma subjacente de CI/CD, de local à nuvem, IaaS, PaaS, Kubernetes e até Serverless. Quais são alguns dos principais fatores que as equipes devem considerar ao selecionar a plataforma?

Bryant e Marín Pérez: O principal fator que vimos afetando essa decisão é o apetite por vendor lock-in e o desejo relacionado de criar e gerenciar uma equipe de especialistas em plataformas.

Por um lado, a opção local é a mais complicada, e provavelmente a mais cara, de ser implementada, mas é a que oferece mais liberdade. Podemos escolher de tudo, desde o hardware e o sistema operacional até a plataforma de orquestração. Normalmente precisaremos de uma grande equipe de especialistas para executar essa abordagem.

Por outro lado, as modernas plataformas "serverless" e de função como serviço (FaaS) nos oferecem a menor escolha e dificultam a migração, no entanto disponibilizam muitas funcionalidades básicas "prontas para uso" que nos permitem concentrar nos negócios sem preocupação com questões adjacentes.

Não é incomum que as empresas mudem de ideia sobre esse assunto, à medida que amadurecem e as necessidades evoluem. A execução de uma plataforma híbrida também é a realidade de grandes empresas.

InfoQ: Quando o livro "Entrega Contínua" foi lançado em 2010, as implantações automatizadas ainda não eram a regra. A observabilidade também está nesse estágio inicial de adoção? Quais são as implicações da implementação da observabilidade da perspectiva do pipeline da aplicação, antes de ser realmente implementado em produção?

Bryant e Marín Pérez: Vemos cada vez mais organizações percebendo a importância da observabilidade, mas, ao adotarem de maneira precoce, muitas delas não estão obtendo o máximo benefício possível (ainda).

A observabilidade está ganhando relevância porque é uma das etapas básicas para aumentar a resiliência, o que, por sua vez, é cada vez mais uma necessidade básica da economia moderna. Os usuários esperam que os problemas sejam resolvidos rapidamente, geralmente antes que se tornem visíveis, e para isso precisamos ter um conhecimento profundo e em tempo real do sistema. A observabilidade nos dá isso.

O principal desafio que as empresas enfrentam ao tentar implementar a observabilidade em um pipeline de entrega contínua é que, muitas vezes, não sabem que tipo de métricas operacionais são relevantes para o caso particular até que tenham problemas à vista, portanto, há muitas suposições. Esse não é necessariamente um ponto ruim para iniciarmos, mas é necessário um processo de revisão contínua para garantir que as métricas escolhidas sejam relevantes.

InfoQ: Por fim, como podemos ver a atual evolução da Entrega Contínua no mundo Java e o que podemos esperar do futuro estado nas organizações em comparação ao atual?

Bryant e Marín Pérez: Acreditamos que as principais mudanças que veremos acontecerão na maneira como a empresa vê o desenvolvimento de software. A entrega contínua tornará obsoletos os conceitos como "hotfix" ou a dicotomia de "Projeto vs. BAU". A mudança se tornará a norma, e as empresas começarão a adotá-la em vez de resistir.

Em relação ao Java, a mudança sutil que provavelmente veremos é que as empresas adotarão novas versões do Java mais rapidamente, resolvendo assim o tradicional calcanhar de Aquiles do Java. A adoção mais rápida, juntamente com os ciclos de lançamento mais curtos que já podemos observar, criarão uma espiral de inovação que levará o Java a novos patamares. É um desafio prever todas as novas idéias que surgirão disso, mas estamos realmente ansiosos.

Sobre os autores do livro

Abraham Marín Pérez é desenvolvedor Java e Scala com mais de dez anos de experiência nos setores que variam de finanças à marketing, passando pelo setor público. Também ajuda a administrar a Comunidade Java de Londres e fornece conselhos de carreira no grupo Meet a Mentor London. Abraham gosta de compartilhar suas experiências com outras pessoas, o que o levou a criar o "Software de Manutenção do Mundo Real" (O'Reilly) e o co-autor de "Entrega Contínua em Java" (O'Reilly). Atualmente em Londres, Abraham gosta de fazer uma caminhada sempre que o clima inglês permite e de cozinhar quando o clima não está para passeio.

Daniel Bryant trabalha como consultor técnico independente e arquiteto de produtos na Datawire. A sua experiência técnica se concentra nas ferramentas 'DevOps', plataformas de nuvem e container, além de implementações de microservices. Daniel é um Java Champion e contribui para vários projetos de código aberto, também escreve para o InfoQ, O’Reilly e TheNewStack, e palestra regularmente em conferências internacionais como OSCON, QCon e JavaOne. Em seu tempo livre, gosta de correr, ler e viajar.