Por que os microsserviços não estão funcionando para você

Um desenvolvedor de aplicativos, um membro da equipe de segurança e um engenheiro de confiabilidade de site (SRE) participam de uma reunião da empresa. Eles se dão bem?

Se eles estiverem trabalhando em uma organização que utiliza microsserviços, a resposta pode depender de quão bem eles conseguem evitar falar sobre trabalho. Cada uma dessas equipes pode ter um rótulo para a outra que reside no fundo de suas mentes… as pessoas com preocupações transversais. Pode haver muita pressão e atração entre essas três equipes, com os SREs solicitando registro e monitoramento centrais, a segurança impondo regras estritas e os desenvolvedores lidando com mais dessas preocupações transversais do que com o serviço real que estão desenvolvendo.

Acredito que todos devemos aprender a nos dar bem e valorizar o valor que cada equipe traz para a mesa. Tudo o que precisamos fazer é tornar as preocupações de cada uma dessas equipes mais gerenciáveis.

Vamos dar uma olhada no que são preocupações transversais, por que elas precisam existir e como abordá-las da maneira menos dolorosa possível. Descobriremos que os métodos que usamos para abordar questões transversais também eliminarão o impacto dos contratos de API menos que perfeitos que possam existir entre serviços.

Quais são as preocupações transversais?

Preocupações transversais são itens que dependem ou devem fornecer outras partes do sistema. Por exemplo, o desenvolvedor de um serviço simples pode ser solicitado a abordar as preocupações da equipe do SRE, que deseja incorporar o serviço do desenvolvedor em uma solução central de registro. Para o desenvolvedor, isso significaria não gastar tempo construindo a funcionalidade central do serviço, mas sim trabalhando na infraestrutura em torno desse serviço. Isto é extremamente frustrante para um desenvolvedor que não se inscreveu para esta tarefa.

E não se trata apenas de infra-estruturas: mesmo outros serviços que interagem ou dependem uns dos outros podem ser considerados uma preocupação transversal. Esperar relações contratuais perfeitas entre duas ou mais APIs nem sempre é realista. Essas preocupações têm o potencial de atormentar os desenvolvedores e fazer com que eles passem mais tempo trabalhando fora de seu domínio.

Isso levou a um certo cinismo em relação ao estado atual dos padrões de microsserviços. A promessa inicial da utopia de microsserviços de que uma equipe de tamanho razoável pode se concentrar em uma solução de escopo restrito, de que pode contar com contratos limpos e compatíveis com versões anteriores (APIs), parece quebrada. Quaisquer ganhos iniciais de economia de tempo e foco que a arquitetura de microsserviços proporcionou ao desenvolvedor foram extintos devido ao escopo não planejado. Uma coisa que parece ter sido convenientemente ignorada em muitos artigos e vídeos sobre “como fazer microsserviços” é como lidar com questões transversais.

Como chegamos aqui?

Um dos pontos-chave que levaram à adoção de microsserviços foi a promessa de separação de interesses. Contanto que cada microsserviço forneça um contrato limpo na forma de uma API compatível com versões anteriores, os desenvolvedores devem ser livres para se concentrar no serviço. Então, o que acontece?

Muitas ferramentas que afirmam eliminar preocupações transversais simplesmente transferem essas preocupações do desenvolvedor para outra pessoa – ou pior, substituem um conjunto de preocupações por outros inteiramente novos.

Por exemplo, as soluções de malha de serviço podem transferir preocupações como política de segurança, observabilidade, registro central e roteamento de tráfego do serviço para a infraestrutura. Embora isso signifique que o desenvolvedor do serviço não é mais responsável pela implementação desses tipos de políticas, as preocupações subjacentes não desapareceram. Essas preocupações agora são de responsabilidade da equipe que gerencia a malha de serviço.

Os desenvolvedores de serviços, que anteriormente eram solicitados a abordar essas preocupações por meios que pudessem racionalizar e testar, agora têm duas opções: 1) Levar seus serviços adiante e rezar para que tudo funcione bem no novo contexto da malha, ou 2) imaginar encontrar uma maneira de incorporar a nova política de malha ao fluxo de trabalho do desenvolvedor. A primeira opção provavelmente levará a muitas execuções de CI/CD com falha; este último representa apenas outro conjunto de preocupações transversais.

Como abordar preocupações transversais

Não existe um padrão mágico que possa fazer desaparecer as preocupações transversais. Os serviços precisam ser observados para garantir que estejam em bom estado. Os logs precisam estar acessíveis às partes interessadas responsáveis ​​pela solução de problemas dos serviços. Quando a solução consiste em muitos microsserviços, é necessário que haja uma forma de rastrear o ciclo de vida de uma solicitação, para que, se as coisas não estiverem funcionando corretamente, seja possível determinar quais serviços estão em jogo.

Além da observabilidade e do diagnóstico, devemos também considerar o sistema como um todo. Todos esses microsserviços estão trabalhando coletivamente para uma solução mais ampla. Assim como dois cantores com afinação perfeita ainda podem cantar fora de harmonia, dois ou mais microsserviços funcionando perfeitamente também podem atrapalhar os objetivos maiores do sistema.

Portanto, em vez de tentar eliminar preocupações transversais, deveríamos nos esforçar para reduzir o seu impacto na produtividade do desenvolvedor.

Exponha antecipadamente preocupações transversais

A melhor forma de reduzir o impacto destas preocupações transversais é expô-las o mais cedo possível no processo de desenvolvimento. Para abordar questões transversais ou qualquer outra forma de complexidade adicional, um desenvolvedor terá que executar muitas iterações. Essas iterações ficam mais caras em termos de tempo e pressão à medida que se aproximam da produção. Portanto, o momento melhor e menos dispendioso para abordar estas preocupações transversais seria no início do processo de desenvolvimento. Este é o momento em que o desenvolvedor tem mais controle e pode iterar rapidamente.

Infelizmente, estas preocupações transversais muitas vezes só são abordadas muito mais tarde no ciclo de vida do desenvolvimento. Isso equivale a um ciclo de feedback extremamente lento para o desenvolvedor enquanto ele tenta racionalizar como fazer com que seu código coexista em um ambiente sobre o qual ele tem visibilidade limitada e ainda menos controle.

Uma das principais razões para esta situação é a forte dependência de um gasoduto fixo para reunir todas estas preocupações. O desenvolvedor está à mercê do pipeline para obter feedback do ambiente de produção mais amplo. Quanto maior a complexidade, maior será o delta entre o que o desenvolvedor está testando e o que precisa ser aprovado para ser promovido para produção.

Crie pipelines portáteis

O que os desenvolvedores precisam é a capacidade de lidar com as complexidades de produção em seu ambiente de desenvolvimento, permitindo-lhes realizar a maioria das iterações da maneira mais rápida e menos dispendiosa possível.

Existem ferramentas, como o Garden, que enfrentam esses desafios, permitindo a criação de um pipeline portátil que define ações básicas como construir, implantar, executar e testar. Essas ações podem ser expressas tendo em mente a ordem de dependência e, por estar em formato gráfico, pode isolar e executar apenas as etapas necessárias para concluir uma determinada tarefa, tornando-a muito rápida e eficiente.

Esse formato portátil padrão não apenas descreve as etapas para implantar um aplicativo, mas também leva em conta outras preocupações transversais. Isso ocorre porque o Garden pode adquirir outros projetos do Garden, permitindo a separação de preocupações, como uma equipe separada que possui e gerencia políticas de malha de serviço.

Com o gráfico e as fontes externas definidas, o desenvolvedor pode executar um comando simples do Garden, como garden deploy ou garden test para obter feedback em segundos. Isso significa que um desenvolvedor pode racionalizar e testar preocupações que normalmente não seriam expostas até muito mais tarde no ciclo de vida de desenvolvimento de software, como após uma solicitação pull e a execução completa do CI/CD.

Isso cria um ciclo de feedback rápido que permite aos desenvolvedores descobrir rapidamente se o código em que estão trabalhando está em conflito com as políticas de outra equipe ou até mesmo com outros serviços. Colaborar com outra equipe para descobrir a melhor solução será muito mais fácil neste estágio inicial do que seria bater na porta da produção.

Ter um pipeline portátil significa que o mesmo gráfico que os desenvolvedores estão usando em seu ambiente também pode ser aproveitado em um pipeline de CI/CD. (Na verdade, usar o Garden pode simplificar o pipeline de CI/CD para alguns comandos.) Isso pode abrir um novo paradigma: em vez de trabalhar a partir do desenvolvimento local marchando em direção à produção, começamos a imaginar um mundo onde definimos nosso estado de produção em pipelines portáteis e simplesmente distribua o gráfico para os estágios subjacentes, sem deixar delta entre produção, CI/CD e os ambientes de desenvolvimento.

Para concluir

Apesar da dor que as preocupações transversais e outras complexidades causam à comunidade de desenvolvedores, deve-se notar que esta dor também afeta outras partes interessadas, como segurança, engenheiros de confiabilidade do site, gerentes e outros que não podem se dar ao luxo de ter essas preocupações ignoradas porque eles são muito difíceis ou opressores de gerenciar. Esperamos que quando essas diferentes equipes se encontrarem na próxima reunião, todos possam sair e desfrutar da companhia uns dos outros como verdadeiros colaboradores e talvez até amigos!

Confira Garden para ter uma visão mais aprofundada de como resolvemos alguns desses desafios e deixe-nos abraçar as complexidades com uma nova confiança.

A postagem Por que os microsserviços não estão funcionando para você apareceu pela primeira vez em The New Stack.