Padrões para o desenvolvedor de workflows e implantação de microservices: Q&A com Rafael Schloming

Recentemente o InfoQ falou com Rafael Schloming, CTO e arquiteto-chefe da Datawire, e discutiu os desafios que as empresas modernas enfrentam com o desenvolvimento de software. Embora a implementação de microservices seja geralmente um efeito colateral do desejo de aumentar a velocidade por meio da decomposição e desacoplamento de aplicativos, há requisitos de workflow e implantação inerentes ao desenvolvedor que devem ser atendidos. Schloming discorre sobre isso e discute como o Kubernetes e o proxy de serviço Envoy (com planos de controle como o Istio e o Ambassador) podem atender a essa necessidade.

InfoQ: Uma premissa chave da sua apresentação no QCon, São Francisco/EUA, parece ser que as empresas que estão migrando de uma aplicação monolítica para uma arquitetura baseada em microservice também precisam quebrar seu processo monolítico. Pode explicar um pouco mais sobre isso?

Conteúdo relacionado de patrocinadores

Rafael Schloming: Na verdade, isso se baseia na premissa de que as pessoas não se importam necessariamente em migrar para microservices. O que realmente lhes interessa é aumentar a velocidade da feature. Microservices simplesmente acontecem como um efeito colateral de fazer as mudanças necessárias para aumentar essa velocidade.

É bastante comum para as empresas, à medida que crescem, chegarem a um ponto em que adicionar mais pessoas não aumenta a velocidade da feature. Quando isso acontece, geralmente é porque a estrutura ou processo que a organização usa para produzir recursos tornou-se o gargalo, em vez do número de colaboradores.

Quando uma empresa atinge essa barreira e começa a investigar por que o lançamento das features parece estar demorando mais do que parece ser razoável, dados os recursos disponíveis, a resposta geralmente é que cada feature exige a coordenação de muitas equipes diferentes.

Isso pode acontecer em duas dimensões diferentes. Seus colaboradores podem ser divididos em equipes por função: produto versus desenvolvimento versus controle de qualidade versus operações, ou por componente: por exemplo, front end versus modelo de domínio versus índice de pesquisa versus notificações. Quando uma única feature exige esforços de coordenação de muitas equipes, o fator principal para a entrega da feature é a rapidez e eficácia com que essas diferentes equipes podem se comunicar.

Empresas estruturadas dessa forma são efetivamente bloqueadas por um único processo monolítico que exige que cada feature seja compreendida (em algum nível) por gente demais na empresa.

InfoQ: Como consertar isso?

Schloming: Para dedicar um grupo de pessoas a um problema você precisa dividi-las em equipes, porque as pessoas simplesmente não podem se comunicar efetivamente em grupos muito grandes. Ao fazer isso, cria-se um conjunto de compensações. Você está criando regiões de comunicação e coordenação de alta fidelidade dentro de cada equipe, e criando uma comunicação de baixa fidelidade e uma coordenação relativamente pior entre as equipes.

Para melhorar a velocidade da feature pode-se organizar os colaboradores como equipes autônomas e autossuficientes responsáveis por uma feature inteira do começo ao fim. Isso vai melhorar a velocidade da feature de duas maneiras:

1. Uma vez que as diferentes funções (produto, desenvolvimento, controle de qualidade, e operações) são estimadas para uma única feature, pode-se personalizar o processo para essa área. Por exemplo: seu processo não precisa priorizar a estabilidade para uma nova feature que ninguém está usando.
2. Como todos os componentes necessários para essa feature pertencem à mesma equipe, a comunicação e a coordenação necessárias para lançar a feature podem ocorrer com muito mais rapidez e eficiência.

Dessa forma, quebra-se o processo monolítico que foi o fator principal da velocidade da feature e cria-se vários processos menores pertencentes às equipes das features independentes. O efeito colateral disso é que essas equipes independentes liberam suas features como microservices. É muito importante que se entenda esse efeito colateral: as empresas que buscam se beneficiar diretamente dos microservices sem entender esses princípios podem acabar exacerbando seus problemas ao criar várias equipes de pequenos componentes e, consequentemente, agravar seus problemas de comunicação.

InfoQ: Poderia explicar como isso se relaciona com as três fases de desenvolvimento em que os aplicativos avançam: prototipagem, produção, e missão crítica?

Schloming: Cada fase representa um compromisso diferente entre estabilidade e velocidade. Isso, por sua vez, afeta a maneira ideal de como lidamos com os diferentes tipos de atividades necessárias para entregar uma feature: produto, desenvolvimento, controle de qualidade, e operações.

Na fase de prototipagem, há muita ênfase em liberar as features para os usuários rapidamente e, como não há usuários, há relativamente pouca necessidade de estabilidade. No estágio de produção, geralmente tenta-se equilibrar estabilidade e velocidade. Você quer adicionar recursos suficientes para aumentar sua base de usuários, mas também precisa que as coisas sejam estáveis o suficiente para manter seus usuários existentes satisfeitos. Na fase de missão crítica, a estabilidade é seu principal objetivo.

Se as pessoas estiverem divididas ao longo dessas linhas (produto, desenvolvimento, controle de qualidade, e operações), será muito difícil ajustar quantos recursos serão aplicados a cada atividade para uma única feature. Isso pode ser visto como novas features avançando muito lentamente porque elas seguem o mesmo processo que as features de missão crítica, ou podem aparecer features de missão crítica quebrando com muita frequência para acomodar a liberação mais rápida de novas features.

Ao organizar os colaboradores em equipes de features independentes, permite-se que cada equipe encontre a troca ideal entre estabilidade e velocidade para alcançar seu objetivo, sem forçar uma única troca global para toda a empresa.

InfoQ: Outra premissa fundamental da palestra foi que as equipes que criam microservices devem ser multifuncionais e capazes de obter acesso de autoatendimento aos mecanismos de implantação e às propriedades de plataforma correspondentes, como monitoramento, criação de log, etc. Poderia falar mais sobre isso?

Schloming: Existem dois fatores diferentes aqui. Primeiro, se a equipe é responsável por uma feature inteira, ela precisa de conhecimento em todos os componentes que fazem parte da feature, do front end ao back-end, e qualquer coisa entre eles. Em segundo lugar, se a equipe é responsável por todo o ciclo de vida da feature, do produto à operações, a equipe precisa de experiência em todas essas diferentes atividades relacionadas à engenharia - não pode ser apenas uma equipe de desenvolvimento.

Claro, isso pode exigir muita perícia, então como se mantém a equipe pequena? É preciso encontrar uma maneira em que as equipes das features alavanquem o trabalho de outras equipes sem que as vias de comunicação entre as equipes atrapalhem o caminho crítico do desenvolvimento da feature. É aqui que a infraestrutura de autoatendimento entra em ação. Ao fornecer uma plataforma de autoatendimento, uma equipe de feature pode se beneficiar do trabalho de uma equipe de plataforma sem precisar abrir um ticket e esperar que um ser humano aja com base nele.

InfoQ: Que tipo de ferramenta pode ajudar com o acesso de autoatendimento para implantação e também com a plataforma?

Schloming: O Kubernetes fornece ótimas premissas para esse tipo de coisa. Por exemplo, você pode usar namespaces e cotas para permitir que equipes independentes coexistam com segurança em um único cluster. No entanto, um dos maiores desafios aqui é manter um fluxo de trabalho de desenvolvimento produtivo à medida que seu sistema aumenta em complexidade. Como desenvolvedor, sua produtividade depende muito da rapidez com que você recebe feedback do código em execução.

Uma aplicação monolítica normalmente terá alguns componentes suficientes para que possam ser conectados manualmente, e executar o sistema local o suficiente para obter um feedback rápido da execução do código à medida em que é desenvolvido. Com microservices, chega-se rapidamente ao ponto em que isso não é mais viável. Isso significa que sua plataforma, além de poder executar todos os seus serviços em produção, também precisa fornecer um ambiente de desenvolvimento produtivo para seus desenvolvedores. Isso se resume a dois problemas:

1. Isolamento do desenvolvedor: com muitos serviços em desenvolvimento ativo não é possível que todos os desenvolvedores compartilhem um único cluster de desenvolvimento, ou tudo quebra o tempo todo. Sua plataforma precisa ser capaz de fornecer cópias isoladas de alguns ou de todos os seus sistemas apenas para fins de desenvolvimento.
2. Implantações do desenvolvedor (ou, em tempo real): uma vez que se tenha acesso a uma cópia isolada do sistema, precisa-se de uma maneira de executar o código no restante do sistema o mais rápido possível. Mecanicamente, isso é uma implantação porque você está pegando o código-fonte e executando-o em uma cópia em produção.

Isso é bem diferente em alguns outros aspectos importantes. Quando você implanta em produção, há uma grande ênfase em políticas rigorosas e procedimentos cuidadosos: por exemplo, passar por testes, canary deploys, etc. Para essas implantações de desenvolvedores, há um grande ganho em produtividade por dispensar a segurança e o procedimento, e focar na velocidade: por exemplo, executando apenas o teste que falhou ao invés de toda a suíte de testes, não ter que esperar por um git commit e webhook, etc.

InfoQ: Poderia explicar um pouco mais sobre esses problemas e como resolvê-los?

Schloming: Para o isolamento do desenvolvedor, existem duas estratégias básicas:

• Copie todo o cluster do Kubernetes.
• Use um cluster Kubernetes compartilhado, mas copie recursos individuais (como serviços Kubernetes, implantações, etc.) para isolamento e, em seguida, use o roteamento de solicitação para acessar o código desejado.

Quase qualquer sistema crescerá ao ponto de exigir ambas as estratégias.

Para implementar o isolamento do desenvolvedor, você precisa garantir que todos os seus serviços sejam capazes de múltiplos versionamentos e você precisa de um roteador de camada 7, além de juntar isso tudo em um workflow seguro e produtivo no github. Para implementar multi versões, vi pessoas usarem de tudo, de sed a envsubst, a ferramentas mais sofisticadas como o Helm, o ksonnet, e o Forge, para modelar seus manifestos. Para um roteador de camada 7, o Envoy é uma ótima escolha e super fácil de usar, e está disponível em projetos como o Istio e o Ambassador API gateway que adicionam um plano de controle mais amigável

Para implementações de desenvolvedor (ou, em tempo real), existem duas estratégias básicas:

• Execute seu código no cluster do Kubernetes e otimize os tempos de construção / implementação.
• Compile e execute seu código localmente e, em seguida, direcione o tráfego do cluster Kubernetes remoto para o laptop, e do código em execução no laptop de volta para o cluster remoto.

Ambas as estratégias podem melhorar significativamente a produtividade do desenvolvedor. Ferramentas como o Draft e o Forge são voltadas para a primeira estratégia, e existem ferramentas como o kube-openvpn e o Telepresence para a segunda.

Uma coisa é certa, ainda falta muita bricolagem (Do it yourself) para montar uma solução viável.

InfoQ: Você mencionou o benefício que a tecnologia de service-mesh, como o Envoy, pode fornecer para comunicação entre serviços (tráfego "leste-oeste") em relação à observabilidade e tolerância a falhas. E quanto ao ingress (tráfego "norte-sul")? Há benefícios em usar tecnologia semelhante aqui?

Schloming: Sim. De fato, no que diz respeito a custo-benefício, é aqui que eu implantaria algo como Envoy primeiro. Colocando o Envoy no limite da sua rede, tem-se uma ferramenta poderosa para medir a qualidade do serviço que seus usuários estão vendo, e este é um bloco de construção chave para adicionar canary releases em seu workflow de desenvolvimento, algo que é crítico para qualquer produção ou serviços de missão crítica que você possua.

InfoQ: Como você acha que o ecossistema Kubernetes evoluirá no próximo ano? Algumas das ferramentas que você mencionou serão integradas nessa plataforma?

Schloming: Eu certamente não ficaria surpreso em ver uma integração mais profunda entre o Envoy e o Kubernetes. Uma coisa que certamente espero ver é alguma estabilização. Kubernetes e Envoy são peças fundamentais da tecnologia. Juntos, eles fornecem as partes centrais de uma plataforma extremamente flexível e poderosa, mas você precisa passar um tempo se especializando antes de poder utilizá-los.

InfoQ: Existe algo mais que você gostaria de compartilhar com os leitores do InfoQ?

Schloming: A equipe da Datawire está trabalhando em uma variedade de ferramentas de código aberto para melhorar a experiência do desenvolvedor do Kubernetes, e por isso estamos sempre ansiosos para obter feedback da comunidade. Os leitores podem entrar em contato conosco através do nosso site, Twitter, ou Gitter, e você sempre pode encontrar a gente nas conferências de tecnologia.

O vídeo da palestra do Schloming na QCon San Francisco 2017, "Microservices: Service-Oriented Development", pode ser encontrado no InfoQ, juntamente com um resumo da palestra.

Sobre o entrevistado

Rafael Schloming é co-fundador e arquiteto-chefe da Datawire. Ele é um especialista reconhecido mundialmente em sistemas distribuídos e de mensagens, e um autor especialista em especificação AMQP. Anteriormente, Rafael era Engenheiro de software sênior na Red Hat.