Durante os anos em que Ben Sigelman trabalhou no Google, criaram o que hoje chamamos de arquitetura de microservices. Alguns erros foram cometidos durante a adoção, que ele acredita estarem sendo repetidos hoje pelo resto do setor. Em uma apresentação no QCon London 2019, Sigelman descreveu suas recomendações para evitar cometer esses erros ao iniciar com microservices.
Sigelman, CEO e cofundador da LightStep, começou com um breve resumo de suas experiências durante os anos em que trabalhou no Google, e observou que os projetos mais respeitados da época compartilhavam algumas características comuns:
- Identificação e alavancagem de pontos de escala horizontal;
- Infraestrutura bem desenvolvida na camada de aplicação, por exemplo, RPC, descoberta, balanceamento de carga, autorização;
- Atualizações contínuas e lançamentos semanais.
A primeira recomendação de Sigelman ao começar com microservices é que se entenda por que está usando microservices, e ele se refere a Vijay Gill, vice-presidente de engenharia da Databricks, que em uma apresentação recente argumentou que a única boa razão para usar microservices é porque inevitavelmente entregará seu organograma. Para Sigelman, o principal motivo para a adoção de microservices é a comunicação humana. Ainda não encontramos um meio para que mais de uma dúzia de engenheiros trabalhem efetivamente em uma parte do software, por isso precisamos da independência da equipe para manter a velocidade no desenvolvimento.
Para o Google, foram motivos técnicos que levaram a uma arquitetura de microservices, como por exemplo, seus requisitos técnicos em escala planetária. Mas isso também gerou problemas, pois o Google utilizava os requisitos técnicos e o desempenho como a principal razão para a adoção de microservices, e não a velocidade da equipe. Sigelman, portanto, enfatiza que devemos estar muito conscientes sobre por que adotamos microservices - as razões são independência e velocidade da equipe, ou aspectos técnicos?
A alta velocidade é importante, mas Sigelman não concorda com a suposição de que a melhor maneira de atingir velocidade é permitindo que cada equipe tenha total independência sobre a tecnologia que usam. Uma parte importante de uma arquitetura de microservices é o custo para preocupações comuns, como segurança e monitoramento, devem ser compartilhados por toda a organização. Ter todas as equipes construindo essas coisas por conta própria será muito caro. Sigelman, portanto, recomenda que deve haver uma ou algumas plataformas suportadas, a partir das quais cada equipe pode selecionar a mais adequada para seus serviços.
Serverless computing é para Sigelman a maneira como deveríamos estar fazendo computação, mas ele aponta que a função como um serviço (FaaS) é extremamente limitada, e que comumente estamos confundindo FaaS com a idéia de computação sem servidor. Um aspecto importante ao usar o serverless é a enorme diferença de latência entre chamar uma função dentro do mesmo processo em comparação a uma chamada de rede. Por exemplo, a latência de uma referência em memória é uma ordem de magnitude mais rápida do que o envio de um pacote pelo Oceano Atlântico. Ele se refere a um artigo de Hellerstein: Serverless Computing: One Step Forward, Two Steps Back, em que essas questões são descritas e quantificadas. Embora acredite que serverless faz total sentido em certas situações, como serverless na borda, Sigelman é cético em relação a usar serverless como o backbone para uma arquitetura de microservices. O uso do serverless deve ser tratado com cautela e com muitas considerações iniciais, pois na perspectiva de equipe, é uma abordagem diferente em comparação à adoção de microservices.
Os painéis gigantes que exibem muitos dados de séries temporais são uma ótima maneira de visualizar a variação ao longo do tempo, mas são ruins em identificar um problema real. A principal razão para adotar uma arquitetura de microservices é reduzir a comunicação entre as equipes, mas durante uma indisponibilidade isso funciona contra a descoberta da causa raiz. Para superar isso e ser capaz de encontrar a razão para uma indisponibilidade, devemos reduzir o espaço de busca e, na prática, Sigelman vê a observabilidade de um sistema como duas atividades:
- Detecção de Indicadores de Nível de Serviço (SLIs), como latência, taxa de erro e taxa de requisição. Este é um pequeno subconjunto de todos os dados de séries temporais, mas um subconjunto que realmente importa para um usuário;
- Explicando a variação encontrada, para microservices, especialmente a variação ao longo do tempo e a variação na distribuição de latência.
Ao fazer uma boa hipótese de onde essa variação se origina, você provavelmente chegou muito perto de resolver o problema. Ele aponta que visualizar tudo em um painel gigante é uma maneira terrível de explicar a variação e pode levar a mais confusão.
Sigelman descreve o rastreamento distribuído como um log de transações individuais à medida que elas passam por cada microservice, permitindo o acompanhamento do tempo de vida de uma transação por todo o sistema. Um dos maiores desafios no rastreamento é o enorme volume de dados em grandes sistemas. Deve-se usar a amostragem para reduzir a quantidade de dados criados, mas também enfrenta o risco de não reter as falhas intermitentes. Outro problema é que, embora seja necessário visualizar rastros individuais, os dados de rastreio distribuídos brutos são muito complicados para uma pessoa analisar. Para Sigelman, uma abordagem superior seria:
- Consumir 100% de dados de rastreio distribuídos brutos;
- Medir SLIs com alta precisão;
- Explicar a variação com amostragem projetada para um SLI específico e estatísticas reais.
Ele observa que o rastreamento como fonte de dados é extremamente valioso, mas que nós, como indústria, ainda somos primitivos. Ele o descreve como o mais jovem e imaturo dos três pilares da observabilidade.
Em uma palestra na conferência, Sigelman discutiu o rastreamento distribuído e a observabilidade em mais detalhes.
A maioria das apresentações da conferência foram gravadas e estarão disponíveis no InfoQ nos próximos meses. A apresentação de Sigelman da QCon São Francisco em novembro de 2018 já está disponível: Lições do nascimento de microservices. O QCon London 2020 está programado para 2 a 6 de março de 2020.