Sarah Wells definiu microservices em sua palestra no QCon Londres 2019 como uma abordagem arquitetônica que mantém os sistemas desacoplados, a fim de possibilitar a liberação de várias versões por dia. Para se construir sistemas resilientes e de fácil manutenção, são necessárias técnicas como balanceamento de carga em nós saudáveis, repetição com retirada (backoff), além de persistência ou dispersão de solicitações por meio de filas. "A melhor maneira de saber se seu sistema é resiliente é testá-lo", disse.
O Financial Times adotou os microservices pois queriam experimentar novos recursos e produtos de forma rápida e com baixo custo. Para atender a estes requisitos, era necessário liberar novas versões várias vezes por dia. Isso só é possível se as alterações individuais forem pequenas e independentes, argumentou Wells.
Wells salienta que os microservices são mais difíceis de manter e operar do que um monolito. A complexidade está entre os serviços e não nos próprios serviços (os serviços em si são simples de entender). Entretanto, qualquer pedido que passe pelo sistema provavelmente afetará vários serviços diferentes, talvez até filas e bases de dados. Os logs e as métricas serão gerados em várias VMs diferentes, e o caminho da solicitação muda diversas vezes, conforme as equipes criam novas funcionalidades e combinam serviços
De acordo com Wells, ao se trabalhar com microservices é necessário aceitar que são sistemas complexos e distribuídos, ou seja, que geralmente se está em um estado de falha parcial: alguma coisa não está funcionando perfeitamente, mas isso provavelmente não importa, desde que se tenha resiliência suficiente para que a funcionalidade retorne o resultado esperado.
A engenharia do caos se concentra em mudar o estado do sistema, por exemplo derrubando nós ou aumentando a latência das respostas de um sistema não crítico, para testar se o restante dos serviços continuam funcionando como esperado. Essas mudanças devem ser feitas em produção, mas sem afetar os usuários, explica Wells. O objetivo é ter uma hipótese de como seu sistema vai reagir, e então verificar se essa hipótese está correta.
O InfoQ entrevistou Sarah Wells, que é diretora técnica de operações e confiabilidade do Financial Times, sobre os desafios que surgem com os microservices e como podemos lidar com eles.
InfoQ: No QCon Londres, você apresentou um problema envolvendo redirecionamentos no site do Financial Times (FT). O que aconteceu e o que fez com que fosse tão difícil de resolver?
Sarah Wells: Muitas vezes, configuramos os redirecionamentos para o domínio ft.com, para poder compartilhar URLs legíveis como "https://www.ft.com/companies", em vez de nossas URLs exclusivas, como "https://www.ft.com/stream/c47f4dfc-6879-4e95-accf-ca8cbe6a1f69". A URL amigável redireciona para as nossas URLs únicas. O problema, neste caso, era um redirecionamento mal configurado: o destino não existia e as pessoas recebiam um 404 . Não conseguimos reverter o problema por meio da ferramenta de gerenciamento de URLs.
O problema é que a ferramenta de gerenciamento de URLs é apenas uma das centenas em operação no FT. Por conta dessa quantidade de serviços, ninguém realmente tinha muita experiência em fazer mudanças neste serviço específico. Pensamos em restaurar os dados a partir de um backup, porém ninguém estava realmente certo de onde iríamos fazer o backup ou quais eram as etapas para fazer a restauração: arquiteturas poliglotas, com vários tipos de base de dados diferentes são excelentes, mas é necessário documentar como cada base faz o backup e a restauração. Descobrimos que a documentação não era detalhada o suficiente.
Conseguimos resolver o problema no final, mas não atuamos com a confiança desejada, mesmo contando com um time de desenvolvedores experientes. Para um serviço individual, é fácil tomar medidas após o incidente: fazer uma restauração a partir do backup, atualizar a documentação. Mas isso é uma solução pontual: precisamos também nos preparar para que todos os serviços tenham esse nível de atenção.
InfoQ: O que vocês aprenderam sobre a operação de microservices?
Wells: Se os microservices lhe dão a chance de liberar várias versões diariamente, então essa complexidade adicional vale a pena. É possível facilitar a vida criando mecanismos que permitam observar - agregação de logs, métricas, monitoramento focado nos negócios: coisas que permitem que se entenda o que está acontecendo no sistema em produção. Em particular é necessário que sejamos capazes de localizar todos os logs relacionados a um determinado evento - marcando-os com um ID de transação. E também pode-se melhorar as coisas mudando a maneira como se testa para fazer mais testes em produção usando monitoramento para manter a qualidade.
Quando pessoas e equipes começam a passar para novos desafios, precisa-se ter certeza de que ainda há um dono dos sistemas - pessoas que sabem como restaurar o backup, que conseguem consertar falhas, liberar novos códigos, encontrar logs relevantes, etc. Temos um depósito de informações do sistema (chamamos de BizOps) que contém informações relevantes de cada serviço e queremos que isso vincule todos os serviços a uma equipe responsável. Também estamos começando a introduzir algumas pontuações automáticas de qualidade dos dados para encontrar os locais com maior risco de que não saberíamos o que fazer no caso de um incidente.
InfoQ: Como são os experimentos no Financial Times?
Wells: Para o ft.com, temos testes A/B incorporados e gerenciados por meio de flags. Realizamos muitos experimentos e fazemos análise estatística em cada um deles para ver se o resultado do impacto é o mesmo que estávamos procurando.
Como é barato e fácil de experimentar, e porque pedimos às pessoas que prevejam o "sucesso" com antecedência, muitas vezes temos experiências que provam que estávamos melhor anteriormente. Então, não lançamos esse recurso. Isso só é possível porque não há muito esforço e custo investidos no novo recurso. As pessoas são muito relutantes em abandonar uma ideia quando investiram muito tempo e esforço, mesmo que não funcione!
InfoQ: Quais são suas sugestões para documentar sistemas baseados em microservices?
Wells: Acho que é necessário documentar o mais próximo do código possível - mesmo que alguém escreva um bom histórico nos versionamentos, muita vezes o histórico não mudará quando houver uma mudança de código, a menos que os desenvolvedores consigam ver facilmente as coisas que não estão corretas. Estamos procurando atualizar as documentações automaticamente, no lançamento do código, com base nas informações do repositório.
Acredito que a documentação deveria ser sobre como entender o que está acontecendo com o serviço, em vez de tentar identificar os prováveis cenários de falha no futuro. Com microservices, a maioria dos problemas são inesperados e sempre envolve alguém pesquisando os detalhes, usando logs, métricas etc.
Também é necessário entender que muitas informações que viviam em uma documentação tradicional são compartilhadas em muitos microservices. É necessário encontrar uma maneira de permitir esse contexto compartilhado - ninguém deve ficar escrevendo as mesmas informações para dezenas de serviços!