Entrevista com Tyler Treat sobre o livro Microservice Observability

Em seu artigo mais recente sobre observabilidade em microservices, Tyler Treat, sócio-gerente da Real Kinetic, tenta explicar os conceitos de observabilidade e monitoramento. No artigo, Treat demonstra como os sistemas estáticos tendem a existir em um dos dois estados: ativo ou inativo. Isso facilita o monitoramento, pois podemos configurar as ferramentas para relatar estes estado. No entanto, os sistemas complexos tendem a existir em vários potenciais estados e, portanto, exigem uma abordagem baseada em descobertas, que não pode se basear em dashboards e perguntas predefinidas.

Treat enfatiza que o post-hoc versus ad-hoc é uma das principais diferenças entre monitoramento e observabilidade. No monitoramento, a tendência é responder à perguntas predefinidas, normalmente as variáveis já são conhecidas e já sabemos onde procurá-las. Por definição, a observabilidade é necessária sempre que não tivermos o mesmo nível de dados disponível para formular perguntas pré definidas. Isso nos coloca em um estado em que as variáveis não são conhecidas e a descoberta é o principal método de abordagem.

O InfoQ conversou recentemente com Treat para discutir tópicos de observabilidade e monitoramento.

InfoQ: Em sua opinião, por que o monitoramento e a observabilidade estão em conflito nas discussões sobre este assunto?

Tyler Treat: Existem alguns fatores. Primeiro, monitoramento e observabilidade estão intimamente relacionados. Ambos são importantes e necessários para a operação de sistemas em grande escala. Dashboards e perguntas predefinidas ainda são parte essencial disso. O que mudou é que nossos sistemas se tornaram mais distribuídos, elásticos e complexos. Portanto, estas duas abordagens não são mais suficientes - daí vem o aumento da observabilidade. O segundo fator é simplesmente o fato de que a observabilidade é um conceito relativamente novo que tem se tornado importante.

Por fim, este ainda é um espaço inicial e em evolução ("espaço" sendo usado em um sentido muito amplo aqui em referência a sistemas nativos da nuvem, microservices, DevOps e outras ideias relacionadas). Ao contrário de muitas outras disciplinas de engenharia, não há nada científico nos conceitos de monitoramento e observabilidade, pois eles geralmente são aplicados na maioria dos sistemas de software. Estamos criando os conceitos à medida que evoluímos. Nas outras disciplinas existem teorias em que podemos nos apoiar, mas isso não tem acontecido de fato. Não é de se admirar que as ideias sejam confundidas. Em primeiro lugar, elas não são de fato definidas rigorosamente!

InfoQ: O livro aborda sobre Arquiteturas Monolíticas Estáticas e como é um problema bem compreendido com relação ao monitoramento, e como as soluções tradicionais não são suficientes para as Arquiteturas Elásticas de Microservices. A adição do monólito e do microservice é um componente necessário? Ao invés disso, aparentemente a mudança para a observabilidade é uma característica emergente de sistemas complexos que tende a surgir com arquiteturas mais elásticas e tolerantes a falhas.

Treat: Acredito que este é o cerne da questão. A mudança não é tanto uma questão de monolíticos estáticos contra microservices elásticos. Está muito mais relacionada na diferenciação dos níveis de complexidade. No entanto, podemos ter monólitos complexos, semelhantes as arquiteturas complexas dos microservices. Por que então os microservices complexos trouxeram essa mudança em direção à observabilidade? O motivo é que, embora os monólitos possam ter complexidade interna, os microservices trazem essa complexidade à superfície. A complexidade não estará somente no código, mas nas operações e na arquitetura, e esse é um tipo de desafio totalmente diferente.

InfoQ: Quais são os erros mais comuns que as empresas cometem quando começam a explorar a introdução de práticas de observabilidade em seus sistemas? Recomenda alguma abordagem para evitá-los?

Treat: Uma falha que vejo com bastante frequência nas empresas, é a busca por novas ferramentas que supostamente resolveriam todos os problemas. "Se tivermos mais uma ferramenta, as coisas vão melhorar." Da mesma forma, procuram um "painel unificado" que é uma tela, na qual as várias informações de diversos softwares podem observadas ao mesmo tempo, geralmente é uma tarefa sem chances de sucesso. Na realidade, o que as ferramentas fazem é fornecer diferentes lentes para visualizar o sistema. A composição do mesmo é o que realmente importa, e não existe uma única ferramenta que resolva todos os problemas. Embora as ferramentas sejam valiosas, elas não são o solucionador dos problemas.

Tudo começa com a cultura, é assim na maioria das coisas. Temos que promover uma cultura de observabilidade. Se as equipes não tratarem a instrumentação como uma prioridade nos sistemas, ferramenta nenhuma será capaz de ajudar. Pior ainda, se as equipes não estão realmente focadas exclusivamente nos sistemas que entregam à produção, não há incentivo para que façam a instrumentação. Isso leva a outro erro comum nas empresas, que é simplesmente renomear uma equipe de "operações" para uma equipe de "observabilidade". Isso é semelhante a renomear os engenheiros de operações para engenheiros de DevOps, achando que isso irá mudar alguma coisa. É preciso haver uma cultura de propriedade e responsabilidade, isso é o que realmente significa DevOps - mas mudar a cultura é difícil.

No entanto, essa cultura de propriedade e responsabilidade geralmente faz a balança pender mais para outra direção. Vi equipes que receberam acesso SSH a servidores de produção em nome dos DevOps. Afinal, se a equipe está em uma situação complicada, precisam ter acesso livre a tudo, certo? Essa é uma norma cultural perigosa por várias razões. Por um lado, as pessoas preocupadas com a segurança e com a conformidade se assustariam com razão. Mesmo o acesso SSH aos ambientes de teste pode ser perigoso no que se refere à observabilidade. Isso ocorre porque fornece aos desenvolvedores um atalho para depurar ou identificar um problema.

Se sempre pudermos usar o SSH para anexar um depurador ou consultar diretamente o banco de dados para rastrear um problema, seremos menos incentivados a instrumentar adequadamente o sistema ou criar ferramentas de suporte para o mesmo. Se estamos condicionados a resolver problemas dessa maneira na pré-produção, o que acontece quando algo dá errado na produção, no qual não é possível confiar nas mesmas técnicas? Os instintos de operações atrofiam porque dependemos de uma muleta. Esse é um fenômeno que chamo de "desenvolvimento induzido pela dor" e pode ser perigoso se não for controlado.

Como resultado, uma prática que incentivo é o teste do caos ou "gameday exercises". Este exercícios não são importantes apenas para avaliar como o sistema se comporta em uma situação ruim, mas também para identificar lacunas no monitoramento e na observabilidade, desenvolvendo assim um ambiente seguro, além de aprimorar os instintos de operação.

InfoQ: No modelo de espectro de observabilidade e monitoramento, foi destacado que o monitoramento está relacionado à hipóteses, enquanto a observabilidade está relacionada à descobertas. Como as outras duas categorias que definiu, premissas e fatos, se encaixam nisso?

Treat: Premissas e fatos são o que alimentam as práticas de monitoramento e observabilidade. Por exemplo, digamos que temos um runtime com uma limitação de memória de 512 MB. Este é um "fato" usando o modelo mental que descrevi. Esse fator conhecido informa como podemos monitorar a utilização da memória do sistema, como alertar quando estivermos em 90% da memória máxima. Da mesma forma, creio que é importante estar ciente das incógnitas desconhecidas ou "suposições", pois podem influenciar o pensamento, assim como podem impedir que exploremos uma certa possibilidade ao depurar um problema ou monitorar um comportamento específico.

InfoQ: A transição de uma arquitetura monolítica para uma arquitetura mais voltada à microservices é uma tarefa que muitas empresas estão realizando. Em que momento dessa transformação é recomendado que elas comecem a criar o próprio pipeline de observabilidade?

Treat: Desde o início. Isso requer alguma qualificação. Um pipeline de observabilidade deve ser um processo evolutivo ou iterativo. Não devemos perder tempo criando um pipeline sofisticado no início. Devemos nos concentrar em agregar valor aos clientes.

No início, dê pequenos passos com itens que agregam valor imediato à observabilidade dos sistemas. Algo que podemos começar a fazer hoje e agregar muito valor com o mínimo de custo, é adotar o logging estruturado. Outra coisa de alta alavancagem é passar um objeto de contexto em todas as chamadas de serviço para propagar os metadados da solicitação que podem ser desconectados e correlacionados. Em seguida, mova a coleção de logs fora de processo usando algo como Fluentd ou Logstash. Se ainda não estivermos preparados, podemos começar a usar um sistema de registro centralizado - Splunk, Elasticsearch, Sumo Logic, Graylog - há várias opções, de código aberto e comerciais, SaaS ou autogerenciadas. Com o coletor de out-of-process, podemos introduzir um pipeline de dados de streaming para separar os produtores de logs dos consumidores. Novamente, existem opções gerenciadas como Amazon Kinesis ou Google Cloud Pub/Sub e opções autogerenciadas como Apache Kafka. Com isso, podemos adicionar uma variedade de consumidores e coletores de log. Nesse ponto, podemos começar a unificar a coleção de outras instrumentações, como métricas e rastreios.

Estamos começando a ver a comercialização dessa ideia com produtos como Cribl, e acho que isso continuará apenas quando as pessoas começarem a atingir as limitações das ferramentas tradicionais de APM em um ambiente de microservice.

InfoQ: É mencionado que com uma arquitetura elástica de microservices, o sistema está potencialmente em "um dos estados n-fatoriais" e que "o teste de integração não pode atender a todas essas combinações". Qual seria o papel do teste de integração neste novo mundo?

Treat: As estratégias de teste começam a mudar. Os testes de integração ainda podem ter valor neste novo mundo, mas em capacidades mais limitadas, como o teste de sanidade. Trabalhei em sistemas grandes e complexos que tinham extensos testes de integração que levavam horas para serem executados e não eram nem um pouco confiáveis. O problema com os testes é que eles se acumulam com o tempo. A sequência típica de eventos é: algo ruim acontece, uma correção é introduzida e um novo teste é adicionado. Um ciclo vicioso. Esses testes se acumulam, mas, com o passar do tempo, se tornam cada vez menos relevantes. Curiosamente, o mesmo acontece com o monitoramento e com os dashboards. Os dashboards são cicatrizes operacionais. É importante reavaliar periodicamente o objetivo e o valor deles, o mesmo se aplica a testes e processos organizacionais!

Com os microservices, creio que o teste de contrato começa a se tornar mais importante e, em particular, o teste de contrato orientado ao consumidor. Isso tende a ser uma abordagem muito mais escalável e confiável para testar sistemas distribuídos em larga escala.

InfoQ: Em um artigo anterior, foi aconselhado que enquanto uma única equipe de operação possa não ter contexto suficiente para solucionar problemas de sistemas distribuídos, os demais grupos devem ser responsáveis por fornecer as ferramentas e os dados que as equipes precisam para operar os sistemas. Há um desafio para a equipe centralizada em relação a não ter o contexto correto ou a especialização neste sistema, para poder criar as ferramentas corretas ou saber quais dados podem ser necessários?

Treat: Esta é uma ótima pergunta, porque ela nos leva a uma noção importante: Qual é o futuro das operações? Hoje, as empresas que adotam as práticas de DevOps enfrentam o desafio de equilibrar a autonomia e o empoderamento dos desenvolvedores com o caos e a duplicação de esforços, entre várias outras preocupações. As operações centralizadas oferecem benefícios como especialização de funções e modelos padronizados em questões como confiabilidade, segurança e recuperação de desastres. Agora, os desenvolvedores têm a liberdade de resolver os assuntos por conta própria. Mas, para muitos deles, esses requisitos não funcionais são pouco importantes, são tarefas para o pessoal de operação ou de segurança, ou pior, nem sequer sabem da existência. Ao mesmo tempo, as operações centralizadas sem dúvida criam um gargalo de inovação e entrega, além de incentivos desalinhados em termos de operações de software. Então, como conciliamos os dois?

O DevOps pode ser implementado de várias maneiras diferentes. Por exemplo, o Google faz SRE. Mas não existe uma implementação "certa", cada empresa é diferente. Precisamos ter ideias, entender o contexto e aplicá-las à nossa própria situação (ou descartá-las) conforme apropriado. Uma ideia que achei consistentemente eficaz, no entanto, é aplicar um mindset de produto às operações. É o que chamo de Developer Enablement. Como sugeri no post mencionado, esta é a ideia de permitir que as equipes agreguem valor aos negócios, fornecendo-lhes ferramentas, automação, padrões e APIs que codificam padrões comuns e práticas recomendadas. Como isso difere das operações centralizadas tradicionais e como construímos as ferramentas certas? É aqui que o mindset do produto entra em ação.

Primeiro, a criação de produtos visa capacitar os clientes, nesse caso, as equipes de desenvolvimento, para agregar valor com o mínimo de dependências externas e, ao mesmo tempo, permitir que a equipe de capacitação do desenvolvedor saia do caminho. As operações tradicionais, por outro lado, estão diretamente no caminho crítico na maior parte dos casos. Por exemplo, arquivamos um ticket de alguma pessoa da operação, sem identificação, realiza o trabalho em uma caixa preta. Isso se torna um gargalo e fonte de atrito.

Segundo, a experiência do cliente é um aspecto importante no mindset de produto. Isso significa criar produtos que os desenvolvedores não apenas desejam usar, mas sentiriam falta se não pudessem mais usá-los. Para tal, é necessário que haja um trabalho em conjunto com as equipes durante a descoberta e o desenvolvimento de produtos e o recebimento constante de feedback deles para entender o que está funcionando bem e identificar áreas que podem ser melhoradas. Isso resulta em melhorias na experiência geral do desenvolvedor. O processo deve ser iterativo e é muito semelhante ao modo como produtos normais voltados para o cliente são criados.

Por fim, saber o que construir - ou mais importante, o que não construir - é uma parte essencial do mindset de produto. Ao invés de tentar criar produtos para resolver o que pode ser percebido, como um problema geral ou tentar criar uma solução folheada a ouro, as equipes de Developer Enablement devem trabalhar com equipes de produtos que tenham uma necessidade específica e desenvolver ou aperfeiçoar ferramentas já existentes para atender às necessidades da equipe. Ao criar apenas produtos que resolvem uma necessidade específica e evoluí-los ao longo do tempo quando novas necessidades são identificadas, a equipe de Developer Enablement é capaz de se concentrar no que é essencial e útil para fornecer valor imediato às equipes. Lembre-se de que a solução também pode ser comprar ao invés de construir.

InfoQ: Quais as principais tendências em observabilidade para os próximos anos?

Treat: Acredito que veremos os grandes players de monitoramento tentando pivotar suas ofertas em direção à observabilidade. Inicialmente, isso veio na forma de rebranding e ajuste da linguagem de marketing, mas creio que existem recursos específicos necessários para implementar totalmente a observabilidade, como eventos estruturados de forma amplamente arbitrária, dimensões de alta cardinalidade sem a necessidade de índices ou esquemas, e contexto compartilhado propagado entre serviços no request path, para citar alguns. O Honeycomb tem sido verdadeiramente um líder neste espaço a medida que a observabilidade avança. Acho que os outros vão se aproximar quando as pessoas começarem a realmente entender o que a observabilidade significa, qual o seu valor e como é diferente do monitoramento.

InfoQ: Quando podemos esperar a parte dois? Algum spoiler sobre o que esperar?

Treat: Já iniciei a próxima parte, mas o desenvolvimento tem sido lento devido a compromissos de consultoria com a Real Kinetic. Esperemos que antes do final do ano esteja pronto. Teremos uma visão mais concreta da observabilidade, bem como um pipeline de observabilidade na prática. Fique ligado!

Sobre o entrevistado

Tyler Treat é sócio-gerente da Real Kinetic, onde ajuda as empresas a criar softwares em nuvem e entregar com confiança. Como engenheiro, se interessa por sistemas distribuídos, infraestrutura de mensagens e engenharia de resiliência. Como líder técnico, busca formar equipes e empresas de software eficazes. Treat também colabora frequentemente com soluções open-source e é blogueiro ávido no bravenewgeek.com.