Ricardo Ferreira é Principal Developer Advocate da Elastic nos Estados Unidos, onde trabalha com comunidades “fazendo os desenvolvedores se apaixonarem pela tecnologia”. Ele próprio um apaixonado pela profissão, percorreu um vasto caminho como programador e arquiteto de soluções ao longo das últimas duas décadas, até conquistar a posição que ocupa atualmente na empresa por trás da famosa ELK Stack.
Nosso CEO Bruno Pereira conduziu um papo bem informal – e técnico – com Ricardo, sobre questões envolvendo: Engenharia de Confiabilidade do Site (SRE), Observabilidade, sistemas distribuídos, sistemas de streaming e também um pouquinho sobre a carreira e os desafios dos desenvolvedores para os próximos desafios que se seguirão daqui pra frente no mundo da computação em nuvem.
Neste post, destacamos os principais tópicos dessa conversa, com muitos insights para quem está iniciando a jornada tendo todos esses desafios em mente para resolver – e, principalmente, no backlog.
Como é o seu trabalho no dia a dia atuando como Developer Advocate?
Ricardo Ferreira: Eu vejo como sendo um trabalho de duas partes. O meu primeiro trabalho é ser uma espécie de “advogado” da comunidade. Toda vez que alguém sente que está patinando em um projeto, seja porque a documentação está ruim, ou porque eventualmente encontrou um bug, daí abre um chamado no GitHub, e o chamado fica lá por duas semanas e ninguém responde; ou de repente você deseja incluir algo totalmente novo no software, ou eu mesmo escrevo uma coisa nova e gostaria que ela fosse incluída no software, então é meu papel ajudar as pessoas a fazerem tudo isso. Ou seja: desamarrar todos os problemas e levar para outro nível.
Além disso, também gosto de dizer que um bom developer advocate tem que funcionar como um “roteador humano”. E o que seria isso? Ele tem que conectar as pessoas com conhecimento. Por exemplo, muita gente chega para mim e diz que quer se aprofundar no Kafka, ou no ElasticSearch, e me pergunta: qual o caminho das pedras? Por onde devo começar? Então, mais do que entregar a documentação, recomendar um artigo ou um blog, mais do que simplesmente jogar esses recursos no colo da pessoa, é encontrar um formato que possa fazer sentido para aquela pessoa.
Então, por exemplo, qual é a grande diferença entre um “evangelista” e um “developer advocate”? O evangelista vai fazer isso: toma aqui a documentação e… se vira! Já o developer advocate busca criar uma conexão mais pessoal: eu vou primeiro entender o nível de conhecimento daquela pessoa com quem estou me comunicando, para depois sugerir qual tipo de material melhor se adequa àquela pessoa. E, se esse material não existir, eu vou criar. Essa é a primeira parte. A segunda parte é ser um “advogado” da empresa. E o que isso significa, na prática? É levar para a comunidade algumas decisões sobre coisas que a empresa pensa em fazer, ou mesmo já fez. Então é meu papel também dar aquela “amaciada” na comunidade, coletar feedbacks, conversar mais informalmente com todo mundo: “galera, se a gente fizer isso, vai quebrar tudo aí, ou não, vai mudar para melhor?” Então é esse tipo de feedback que eu levo para dentro da organização. É mais ou menos como ser um lobista, e buscar sempre construir pontes, não muros.
O ElasticSearch surgiu inicialmente como uma solução de busca, em 2010. Na época existia o Solr, e opções do tipo pré-cloud, ou seja, que não eram nativamente pensadas para se comportarem como uma arquitetura distribuída. A ElasticSearch começa como uma solução de busca, que ao mesmo tempo era também uma tecnologia de banco orientada a documento. Cerca de nove anos depois a empresa passa a oferecer toda uma solução conectada à gestão de logs, Observabilidade etc; então se puder contar um pouquinho como é a Elastic atualmente, e seu portfólio de produtos. Uma empresa aberta e que com menos de 10 anos chega a valer US$ 15 bilhões de dólares, como você enxerga isso?
RF: A gente gosta de explicar a Elastic sob o ponto de vista do produto de busca. Tem até um slogan inicial onde o próprio criador do ElasticSearch, o Shay Banon, diz: se parar para pensar, tudo o que a gente faz hoje em dia como tecnologia e desenvolvedor, é uma busca. Só muda o formato e a forma como você está pensando, mas em última análise é uma busca. Então todo o portfólio que a Elastic criou até hoje gira em torno desse conceito de busca; obviamente, estamos falando do ElasticSearch. O ElasticSearch está para a Elastic assim como o banco de dados Oracle está para a Oracle. Para a Elastic, o ElasticSearch também é isso, é o coração de tudo o que a Elastic faz.
No entanto, a Elastic criou uma estratégia que é a seguinte: a de criar (ou adquirir) tecnologias que irão se tornar tão padrão na vida do desenvolvedor, que daqui 7 anos – que é o momento em que nos encontramos hoje – a gente possa começar a criar soluções e produtos em cima de uma plataforma sem ter o problema (que a maioria das empresas têm), que é: onde eu encontro mão de obra? Então quando você me pergunta o que é a Elastic hoje, ela continua sendo uma empresa por trás da Elastic Stack.
Ou seja, Logstash, Kibana e Elasticsearch continuam sendo tecnologias-chave para a organização, porém hoje ela está diversificando o portfólio. Por exemplo, nós temos 3 soluções que foram criadas em cima da stack da Elastic: a solução de segurança, a solução de Enterprise Search (que é um nicho mais específico para pesquisa, meio que concorrente do Google) e a de Observabilidade, que é o tema que vamos discutir mais a fundo daqui a pouco.
O ponto onde eu quero chegar é que, em termos de estratégia, a Elastic diversificou de uma forma bem pensada seu portfólio de produtos. E porque eu digo isso? Porque ela passou cerca de 10 anos criando uma fundação onde, por exemplo, a solução de segurança da Elastic, que é em cima da Elastic stack, se “der pau”, onde é que eu encontro um profissional que entende de Logstash? Não vai ser tão difícil hoje em dia. Não é tão difícil encontrar e nem mesmo formar mão de obra. E isso é uma coisa que é bem legal. Eu fiz a comparação com a Oracle porque eu já trabalhei lá, mas se pararmos para pensar foi isso mesmo que a própria Oracle fez: ela criou o banco de dados, e em seguida passou a investir no Oracle Fusion Middleware, e começou a criar aplicações em cima da plataforma. Então esse é um modelo de negócio que é bem interessante. E é o que a Elastic está fazendo hoje. É uma empresa de segurança, de Observabilidade, e de Enterprise Search, mas que no fundo está sempre amarrada pelo velho e bom Elastic Stack.
O Elasticsearch surgiu em uma época de maior tração das empresas na migração para a nuvem, saindo daquela arquitetura on-premises; mas, quando chegam na nuvem, tem Serverless, tem containers, enfim, uma série de tipos de processamentos que podemos fazer. O monitoramento ficou muito difícil, porque já não é mais aquele alvo parado, é preciso observar bem as arquiteturas, o que está sendo feito em produção de “n” formas. E até brinco que a Observabilidade é o monitoramento da era da nuvem, porque não é mais possível monitorar como se fazia antes.
Então se puder comentar o que você considera uma arquitetura recomendada para alguém que deseja monitorar seus sistemas como as melhores empresas monitoram, sob a ótica da Observabilidade e Confiabilidade (SRE). Por exemplo, é necessário hoje em dia pensar em uma jornada de produto acompanhada, então o que uma empresa que não tem tanta maturidade precisa fazer para começar? O que deve estar no radar desta empresa com relação a componentes de Observabilidade para que o Produto possa ser bem acompanhado e não apresentar surpresas em produção, com métricas e com dados que suportem um entendimento claro de tudo o que está acontecendo nos sistemas?
RF: Você comentou essa questão da mudança, de como a tecnologia evolui, principalmente com o advento da nuvem, e eu estava me lembrando de uma coisa que você falou que não me esqueci até hoje, que é aquela analogia entre o animal de estimação e o gado. Antigamente, a gente olhava para a arquitetura e sabia cada um dos “animais” que tínhamos em casa, mas hoje estamos lidando com gado, ou seja, é uma quantidade tão espantosa de “bois” pastando junto que a gente já não consegue mais dar um nome para isso. Então o primeiro ponto que eu percebo, falando como usuário e também como fornecedor da tecnologia, é que a maioria das pessoas enxerga Observabilidade como aquela “caixinha mágica”.
Ou seja, a partir do momento que os dados estão ali, tudo é bonito – como de fato é – os dados já estão ali armazenados em banco de dados, e aí começamos a falar de coisas como machine learning, detecção e aprendizado de anomalia, é maravilhoso, só que o problema é que ninguém fala do que antecede aquilo ali; que é a jornada de identificação de quais dados de telemetria é preciso coletar, como é que se coleta isso, qual é o overhead gerado para fazer essa coleta, e o mais importante de tudo: como é que você vai normalizar tudo isso.
Então deixa eu explicar melhor onde eu quero chegar. É legal discutir o que ninguém quer discutir. Esse é o primeiro ponto. Não evite uma discussão que você precisa ter só porque você sabe que vai doer. Então o ponto que eu quero chegar é o seguinte: todo mundo fala que Observabilidade são os 3 pilares, que é métrica, log e tracing. E é, não tou dizendo que não é. O problema é que eles não são pilares distintos, nem isolados, e acho que o primeiro ponto que vejo por aí é que as pessoas tendem a tratar esses pilares como coisas isoladas. Por exemplo, o que acontece muito é algo como: “a gente vai consolidar nosso projeto de telemetria, e na parte de métricas vamos usar um Prometheus, e aí teremos um time responsável só pelo Prometheus; para essa parte do tracing, a gente vai adotar um Jaeger, ou Zipkin, e vai colocar tudo aqui (outro silo); e para log a gente vai usar ElasticSearch, Splunk ou algo do tipo.
Então, instintivamente, as pessoas continuam pensando em silos. E eu acho que fazem isso porque é fácil e cômodo. Mas acredito que para quem deseja estruturar uma iniciativa de Observabilidade séria de verdade, a primeira coisa que precisa fazer é justamente evitar a criação desses silos, embora isso possa “doer” e levar a um conflito de interesses, por exemplo. Mas mesmo esse conflito é normal e parte da dinâmica para criar uma estratégia unificada. Então promover essas discussões o quanto antes, acho que é bem interessante.
Esse conceito de criar times dedicados a alguma coisa é o que está no DNA dos profissionais hoje em dia, novos ou velhos. E é isso que precisa mudar. Não estou entrando no mérito do certo ou errado. Mas acho que se você quer que a Observabilidade funcione, você tem que integrar, unificar. E aí entra a segunda parte do que eu sugeriria: pensar que se você vai unificar e quer ter uma visão integrada de logs, traces e métricas; se você tá vendo o tracing de uma transação, precisa ser capaz de ver os logs que são inerentes daquela transação; você está vendo a métrica de um host, ou de um container, e tem que dali derivar quais são todas as transações que estão sustentando aquela métrica; erros por segundo, por exemplo.
Quais foram todas as transações que geraram aqueles erros? Então para que tudo esteja integrado, você tem que normalizar. Tem que haver esse processo de normalização (a gente chama de dados de telemetria, para não ficar repetindo log, métrica e tracing). Precisa criar uma versão unificada da telemetria para ter uma visão integrada de tudo. Então são essas discussões que eu acho que precisam acontecer. E são mais discussões do que coisas técnicas que decidiremos usar. E essa discussão tem que começar no desenho.
Essa é outra coisa que eu tento trabalhar quando estou ajudando alguém com essa parte da Observabilidade dos sistemas. Parece que tem 3 escolas diferentes: a escola que acha que Observabilidade é uma responsabilidade de Ops; a escola que acha Observabilidade é Ops e também o desenvolvedor, que tem que instrumentar a aplicação, tem que entrar no mérito do que “loga” e “não loga”. E é verdade, é preciso fazer isso também. Mas tem uma terceira classe que é meio invisível, que é justamente pensar a Observabilidade como uma discussão de desenho, antes de tudo.
Você é um analista de requisito funcional, na hora que está idealizando seu produto, precisa pensar quais são as transações mais importantes, pelo menos para a transação de finalizar a compra, você tem que identificar como vai coletar métricas disso, quais são pertinentes, como vai correlacionar as métricas com as transações… e, a meu ver, essa não é uma discussão que deve ficar apenas com as equipes de Desenvolvimento e Produto. Não, todo mundo tem que fazer isso! Sabe porquê? Porque na hora que aparece o problema, as pessoas que vão estar realmente interessadas em saber disso são as que desenharam o Produto.
Um cenário que acontece com frequência é que qualquer produto quando traciona muito, que possui muitos acessos e muitas transações acontecendo, naturalmente vai produzir muitos logs, e não é tão trivial para quem está começando a trabalhar com isso possuir uma arquitetura capaz de suportar tudo de uma forma fácil. Então, se a gente pega uma Black Friday, tem um pico de acesso durante o dia que é muito maior do que o volume gerado de madrugada, quando as pessoas estão dormindo, por exemplo.
As arquiteturas de nuvem suportam isso bem, a questão da sazonalidade, uma volatilidade grande, e um dos pontos-chave disso é como que eu consigo ter uma estrutura de logs capaz de receber um volume muito grande em períodos curtos, em um momento de pico e que não custe um absurdo. E que também não fique super dimensionada para aqueles 99% do tempo que não tem tanto acesso. Tendo em vista esse contexto, quais modelos você tem acompanhado em que seja possível trabalhar com picos de tráfego sem ficar caro demais e com uma estrutura difícil de manter?
RF: Eu vou te responder isso usando minha experiência com Elasticsearch. Não sei como outras soluções de log funcionam, mas no caso do Elasticsearch, é uma combinação de práticas, implementações e cultura que você tem que fazer. Em primeiro lugar, o Elasticsearch é extremamente rápido, mesmo com volumes e leitura gigantescos de dados. Essa é a principal característica dele. Tem casos de uso de petabytes de dados e ainda assim o Elasticsearch te entrega uma consulta de um dado que foi indexado há meio milissegundo atrás e acontecendo em tempo (quase) real. Porém ele não foi feito para escrita de dados massiva. Então quando você o expõe para as aplicações ou agentes escreverem nele diretamente, está correndo um sério risco, embora eu já tenha visto o Elasticsearch suportar 100 mil documentos por segundo – devidamente dimensionado, mas ele suporta isso.
Mas você falou um ponto importante, que é a sazonalidade. Uma Black Friday, por exemplo. Então quando a gente tem situações como essa, o que é recomendável: colocar um buffer na frente do ElasticSearch. O que eu chamo de buffer é um componente que foi escrito para lidar com escrita massiva, tipo um Apache Kafka, um Apache Pulsar, um Kinesis da AWS, um Pub/Sub do Google Cloud, ou Event Hubs do Azure – isso é o que eu chamo de buffer. Porque esses sistemas são desenhados para escrita massiva, então se houver uma sazonalidade, a gente consegue segurar, e eles são persistentes. É diferente de um sistema de mensageria, por isso que a gente tem essa diferença de chamar de streaming ou mensageria. A principal diferença é que um streaming é persistente, e por ele ser persistente, você consegue voltar no tempo e reprocessar coisas, então essas características são muito interessantes de ter em uma arquitetura que precisa suportar sazonalidade. Esse é o primeiro ponto.
O segundo ponto, e ainda falando de Elasticsearch, é que a arquitetura mudou bastante nos últimos releases, a começar desde o release 7.9 mais ou menos (hoje ele está no 7.14). E de lá para cá, ocorreu um monte de mudança, mas acho que a principal delas é que o Elasticsearch sempre suportou o conceito de data tiers. O que são data tiers? Antigamente a gente tinha, por exemplo, todos os meus dados que são “hot”, eu podia elencar um conjunto de nós no meu cluster que ele vai colocar nesses nós aqui, aí eu incluo um disco SSD, que é um block storage mais bacana, e para dados que são “warm” uso um disco magnético, rotacional, que é um pouco mais barato, e tem uma durabilidade semelhante mas não é tão performático; então fica economicamente viável. Isso sempre aconteceu. Agora o que houve nos últimos releases, que tem a ver com isso que a gente tá falando, é a introdução de dois tiers diferentes, que é o frozen data tier, e o searchable snapshots; eles conseguem fazer um offload de todo o dataset do ElasticSearch para que toda a parte de escrita vá para um ObjectStorage, que a gente sabe que é durável e infinitamente mais barato se comparado com o BlockStorage, e mais resiliente também, com distribuição geográfica maior, e redundância em availability zones.
Mas, trazendo para o mundo do Elasticsearch, essa era a grande dor de cabeça: como manter o Elasticsearch economicamente viável quando você pensa em sazonalidade e escala? Essa é a grande dor. Antigamente, você tinha que crescer um cluster Elasticsearch colocando Storage e Compute junto, cada nó era uma combinação de Storage e Compute, memória RAM, CPU e Storage. Agora, não: você pode crescer seu Storage, que é o ObjectStorage, e ter um conjunto finito de compute nodes efetivamente que vão cuidar só da parte do protocolo distribuído do Elasticsearch. Aí temos uma economia absurda de poder acomodar anos de dados e ainda assim tornando transparente, porque a API é a mesma.
Mas a performance vai ser a mesma? Não. Se você fizer uma consulta a um documento que está armazenado lá no snapshot que salvo, binário, lá no S3, o Elasticsearch vai transparentemente pegar aquele documento, rematerializar para dentro do cluster, colocar no cache e servir aquele documento. É óbvio que isso não vai ter a mesma performance que você teria, por exemplo, se fosse um disco SSD. Mas qual é a vantagem? A vantagem é que, quando já está em cache, a segunda requisição vai bem mais rápido, isso é outra coisa que o Elasticsearch colocou também, tem uma camada de cache agora.
Em um cenário onde alguém deseja adicionar um novo cluster do Elasticsearch, uma stack de Observabilidade dessa em produção, e a pessoa não sabe bem como fazer, qual deve ser o ponto de atenção? Por exemplo, o Elasticsearch até pouco tempo atrás tinha aquela questão da segurança pelo perímetro, se deixasse ele com a API aberta publicamente, você estava arriscado a ter os dados apagados – o MongoDB tinha o mesmo problema. Então alguém que deseja colocar um produto como esse em produção, que é um cluster que possui vários componentes e tal, quais devem ser os pontos principais de atenção? Como se preparar para colocar no ar de uma forma segura, resiliente, que não vai dar problema? Quais seriam as dicas para evitar “erros de principiante” para quem está começando com a tecnologia agora?
RF: Por conta do meu trabalho como developer advocate, lidando com fóruns, eventos e coisas do tipo, toda vez que alguém vem comentar de algum problema, 99% das vezes tem a ver com mapping. Deixa eu explicar o que isso significa, na prática. Como já comentamos, o que o Elasticsearch faz de melhor é servir documentos em tempo real. Mas para que ele possa fazer isso, ele usa uma estrutura de dados chamado índice invertido. Ou seja, quando ele cataloga, ou indexa um documento, ele tem que popular esse índice invertido para que quando você faça uma pesquisa, ela seja extremamente rápida. É mais ou menos como o índice de palavras no final de um livro, por exemplo, que localiza a página a partir de uma dada palavra. O Elasticsearch faz exatamente isso, por isso que ele é tão rápido.
Mas o ponto é: se você não cria um mapping, ele vai fazer uma varredura no documento e tentar supor uma estrutura de dados que vai ser o seu schema, e vai popular aquele índice invertido baseado no que ele supôs. Ele não é mágico, mas vai fazer o melhor possível. Se você criar um documento e começar a indexar, indexar, indexar, fatalmente você terá problemas do tipo: “o charge está muito lento, em menos de 10 dias de produção eu começava uma agregação que rodava em 1 segundo e agora demora 1 hora para executar”; na maioria das vezes, isso ocorre é porque o mapping não foi desenhado da forma correta.
O Elasticsearch tem um poder de expressar o mapping que é fantástico, até entrar no mérito de pesquisa por emoji, acredita nisso? Colocar um emoji e ele encontrar o documento? Você pode, no mapping, associar um analyzer por campo e fazer isso. Mas, qual o ponto que eu quero chegar aqui? Isso você precisa fazer explicitamente, não é automático. É necessário usar o mapping, e garantir no seu checklist que todo índice tenha um mapping associado. Esse é o primeiro ponto. O segundo ponto, tem uma feature nova chamada data streams, que quase ninguém usa. O que ela faz? Fazendo uma analogia com banco relacional, é como se fosse uma fill. É algo que não existe na prática, mas por baixo tem um monte de tabelinhas que estão sendo trabalhadas. O data streams é isso: ele trata aquele documento como uma série de documentos que você diz qual é a periodicidade (mês, ano, tamanho etc) mas para quem está escrevendo naquele índice, é transparente.
Então usar o data streams é uma coisa que elimina grande parte dos problemas de manutenção de índice. Porque muitas vezes a pessoa que não conhece bem o Elasticsearch roda um comando qualquer e sai quebrando todos os documentos que foram indexados. Eu já ouvi coisas como: “o Elasticsearch não é confiável porque perde documento”, quando não é bem assim. Na verdade, ele é bem resiliente, mas dependendo do comando que você roda nele, pode perder documento, mas aí entra na seara de que você está rodando o comando sem saber direito o que tá fazendo.
Outra coisa que é bem comum também, é que o Elasticsearch tem um limite teórico: todo mundo quando desenha uma solução com Elasticsearch pensa assim: vou testar com 10 mil, 100 mil documentos, para ver se funciona. É o “hello world” para ver se funciona, antes de colocar para produção. Mas todo índice, quando você joga uma query nele, irá te retornar por padrão até 10 mil documentos. Para quem fez essa experiência, já deve ter visto esse ponto. Se tentar recuperar mais do que isso, ele vai dar pau. Daí você tem duas alternativas: ou pode ir na configuração do índice, e aumentar aquilo ali, se precisar, por exemplo, lidar com algo que possa retornar 100 mil documentos em uma consulta só. Tem um parâmetro que faz isso. Mas ninguém mexe nesse parâmetro. E aí todo mundo fala: “mandei uma consulta lá e nunca passei de 10 mil, porquê?” Bem, é por isso. Então ao invés de ficar aumentando esse parâmetro de 10 mil para 20 mil, 30 mil, 40 mil, não aumenta, nem mexe em nada: usa uma API chamada cursor.
O que é essa API: ao invés de mandar uma consulta direta, você manda uma consulta que vai usar um cursor e ele vai paginar tudo bonitinho. Então ele vai te retornar os primeiros 10 mil, aí o código do cursor muda para os próximos 10 mil, você pagina para ele. Então isso faz com que não só você não tenha que mudar nada na aplicação, como também vai dar uma boa descarregada no shards, porque quando você manda uma consulta de 100 mil documentos de um shard só, o que o Elasticsearch vai ter que fazer: ele vai ter que sair coletando de todos os shards no cluster, vai pegar aquele buffer pra entregar para quem mandou. E isso demanda um tempo, sendo que a API de cursor é mais otimizada para esse fim.
E tem uma outra feature que é pouco explorada também. Na maioria das vezes, a pessoa está querendo montar um relatório dos logs dela no Kibana. E tem lá, por exemplo, os logs de determinados clusters de servidores da última semana. Aquilo ali, em última análise, é uma consulta sendo rodada no ElasticSearch. Então a maioria das pessoas, instintivamente, e porque é mais fácil, vai criar aquele relatório no Kibana, mandando aquela consulta para o Elasticsearch. Funciona? Funciona que é uma maravilha! Mas quando você tem escala e sazonalidade, começa a ficar infinitamente lento. Então como resolver esse problema? Com uma coisa chamada transforms. O que é isso?
Pensa em um ETL, só que ele nunca para. Então o que ele faz: você indexou 10 documentos, o transforms vai pegar aquele documento, e vai rodar aquela consulta, agregação, seja lá o que for, você pode usar o que quiser no Elasticsearch, e ele vai materializar aquele resultado em um índice de saída. Que é finito, estático e nunca vai mudar. E aí, por exemplo, chegaram mais 5 documentos. O que o transforms vai fazer? Ele sabe que não tem que reprocessar os 15. Ele vai pegar os 10 que já tinham e vai colocar 5. Ele contempla um conceito de snapshots e pontos de parada e guarda isso em um estado do cluster do Elasticsearch. Então até mesmo em caso de falha de hardware e de software, ele consegue continuar do ponto em que estava, porque tem um snapshot envolvido. E o que isso vai garantir? O relatório do Kibana sempre vai servir os dados que são atualizados, sem necessariamente ficar rodando a mesma consulta no cluster Elasticsearch toda vez. Porque para pra pensar: você pode já pré-computar aquilo ali. Você só precisa atualizar a diferença. Então o transforms é um recurso que é interessante se aprofundar e explorar. Porque qual é o outro problema número 1 que as pessoas reclamam do Elasticsearch: quando o volume de dados aumenta, ele começa a ficar lento, e aí volta o problema para o time de infraestrutura. E aí como se resolve? Tem que “marretar” na força bruta, que é colocar mais hardware, ou… pensar em uma arquitetura mais elaborada, que nem usar transforms.
Eu conheci o ElasticSearch primeiro, e depois como solução de logs também, com o ELK stack. E um tempo atrás surgiu o (agora famoso) Observability Stack. Você comentou que é uma confusão comum as pessoas conhecerem muito o ELK, e ficaram só nessa stack, quando na verdade já tem uma outra stack criada por cima da anterior. Então se você puder comentar até onde vai uma coisa, e quando começa outra, o que na prática é essa visão de soluções que a Elastic possui hoje, acho que ajudaria a entender melhor qual é o ElasticSearch que eu preciso usar, ou qual é a stack que eu de fato preciso para desenvolver o meu produto.
RF: Essa é uma pergunta interessante, porque eu vejo mesmo muita confusão. Que eu chamo de síndrome da Nike ou Apple. E o que seria isso? Essas são duas marcas muito populares, essa é a parte boa. Mas para quem trabalha na Apple e na Nike, para quem cria seus produtos, acaba sofrendo de um problema muito grande que é como criar uma identidade para aquele produto. Porque, em última análise, por conta do branding da empresa ser tão forte, o pessoal fala assim: “ah, não interessa qual é o produto, ele tá usando Nike…. ah, não importa qual o produto, ele tá usando Apple” e acaba que o produto ali não tem mais identidade, o que importa é o branding. E eu vejo que isso acontece muito com a Elastic. Por exemplo: quando as pessoas falam: “a Elastic”; elas estão se referindo a quê exatamente? Ao Elasticsearch? O ELK? A Elasticstack? Ao Enterprise Search? A Observabilidade? Então a Elastic virou sinônimo para tudo. Por isso que eu disse, isso é bom e ruim ao mesmo tempo.
Acho que é bom porque a marca fica forte, mas isso também cria um problema de identidade das soluções. Por exemplo: eu vejo muita gente confundindo Elastic Observability com Elasticstack. “Ah, usa Elastic para Observabilidade”… e o que isso significa, na prática? Eu vou colocar o ELK? Não, na verdade, muito pelo contrário: olha que interessante, para você usar Observabilidade da Elastic, você não precisa do ELK. Não precisa nem do Logstash. Então Observabilidade, Segurança, Enterprise Search, essas são na verdade soluções, ou, digamos, produtos, que a Elastic construiu em cima do Elasticstack.
Portanto, do ponto de vista de arquitetura e topologia, para quem usa o Elastic Observability, ele está usando, pelo menos, o Elasticsearch e o Kibana. Agora o que é importante de notar disso tudo: você está e não está usado. O que eu quero dizer com isso? Que você não vê o Elasticsearch, você não vê o Kibana. Você para de olhar as tecnologias individuais e passa a olhar a solução que foi criada em cima delas. Esse é o ponto principal da diferença entre as soluções. Então quando a gente fala assim: “Elastic Observability”, estamos nos referindo à solução, que integra traces, logs, e métricas em uma visão unificada. Isso vai dar ao usuário a possibilidade de trabalhar a questão da Observabilidade usando as features de machine learning, que por sua vez vai oferecer o suporte a open-telemetry, por exemplo, daí você já começa a ver: realmente, estou indo por um caminho que já não tem nada a ver com o bom e velho Elasticsearch, ou o velho Kibana. Já é uma discussão diferente. Mas no fundo, o Elasticstack são essas peças comuns que estão por baixo da solução: abriu o capô tá lá o Elasticsearch, Kibana, todas as tecnologias. Ou seja, entregamos uma abstração diferente, com o trabalho de integração e junção percorrido. Então são soluções em que o intuito não é ver o motor, mas sim o carro pronto.
Bruno Pereira: A plataforma 1P faz algo que é muito parecido: nessa jornada SRE e DevOps, existem vários pequenos silos de dados, algo que até o mercado norte-americano chegou a estimular por um tempo. Ou seja, determinada solução vai responder por um pedacinho da jornada, vai entregar tudo muito bem, e vai valer 10 milhões fazendo só esse pedacinho; para um investidor esse argumento era muito interessante, para o time talvez, porque quando chegava no momento de operar tudo aquilo, o desenvolvedor pensava: bom, tenho que entregar monitoramento com controle de versão, com CI/CD, e assim chegava-se a 8 ou 10 ferramentas. E o que a gente percebia, é que era muito difícil para um time novo, que não fosse muito experiente, saber escolher o que ele vai usar, como que vai integrar depois e tal, então juntar essa proposta de valor em numa única solução que simplifica, é uma forma de se fazer algumas escolhas até pelo cliente.
A gente tem feito isso no que diz respeito à Confiabilidade, juntando a jornada de Produto também, porque uma das coisas que a gente acredita é: você tem log, você tem tracing e tem um monte de outras coisas que vão te ajudar a entender tudo o que está acontecendo, mas quase sempre um produto cai em produção não é porque a AWS está fora do ar, não é porque o Google falhou, na verdade é muito raro a plataforma de nuvem falhar; o que acontece é que é muito mais provável o desenvolvedor ter cometido algum engano, algum teste falho no desenvolvimento e isso estourar em produção, do que o problema ter sido pela nuvem em si. Então essas questões de unir silos de dados que eram totalmente apartados, e englobar uma visão geral das aplicações, e do que elas dependem, ajuda de fato a tirar um pouquinho dessa complexidade de ser tudo distribuído.
Na sua jornada em tecnologia, você comentou que começou desenvolvendo software, resolvendo problemas de código, sem ter essa visão tão ampla, e só depois começou a trabalhar com arquitetura de solução, e problemas mais complexos e de produto. Hoje, que você já conhece todo esse mercado, e pensando em como era 20 anos atrás e como é agora, se puder comentar o que você acredita que pode contribuir na carreira de um desenvolvedor, para alguém que está começando agora. Por exemplo, o quanto pode fazer diferença ter essa visão de Observabilidade, e o quanto pensar no Produto rodando em produção pode ajudar a carreira da pessoa ser melhor sucedida… como na sua experiência isso se tornou tangível?
RF: Realmente, quando você entende, adota e implementa Observabilidade vai ajudar hoje em dia a ter uma carreira com um pouco mais de sucesso. E porque eu acho isso? Se olharmos por exemplo há 15 anos ou mesmo 20 anos atrás, a gente não tinha essa preocupação frenética com disponibilidade, qualidade e excelência de entrega de software que temos agora. Eu acho que culturalmente a gente não era assim, e acho que a cloud trouxe um pouco disso para a realidade atual. Se você pega a maioria das pessoas que desenvolve produtos hoje em dia, e aí até deixando a questão mais técnica de lado, é fato que todo mundo precisa entregar um produto que tenha disponibilidade, porque a experiência do usuário (UX) é a moeda de troca hoje em dia.
Porque sabemos que um software, se é lento ou que quase nunca está disponível hoje, não vai entregar valor e todo mundo já vai odiar logo de cara. Eu acho que essa é a diferença, porque antigamente a gente tolerava por completo esse tipo de coisa. Eu lembro que a gente tinha, por exemplo, o programa para entrega do imposto de renda, que naquela época era em Delphi, não era nem a versão Java ainda, e na hora de emitir a declaração dava pau, porque o sistema ficava sobrecarregado e a gente meio que incorporava o problema. Então, antigamente, as pessoas toleravam mais isso. Hoje em dia, a gente já parte de cara para as redes sociais reclamar quando algo não vai bem, então começou a se tornar tão intolerável indisponibilidade e lentidão, que eu diria que é imprescindível você criar produtos sem isso.
E como é que você garante esse tipo de coisa? Como vocês na Elvenworks estão trabalhando já há algum tempo, ou seja, criando Confiabilidade nos sistemas. Isso é uma prática que não tem como fugir. Isso não tem só a ver com produto de tecnologia, mas é cultura, é coisa que ou você faz ou não faz. Além disso, que é meio que uma perna de Confiabilidade, temos a Observabilidade. Como diz o ditado, você não consegue controlar o que você não consegue medir. Então se você não pensar em Observabilidade logo no primeiro momento, na hora que acontecer o problema você não vai ser capaz de garantir disponibilidade porque não vai conseguir nem fazer as perguntas certas, porque o sistema não foi projetado para responder àquelas perguntas.
Por outro lado, quando se adota a Observabilidade, ficamos expostos a coisas como: o que são os 4 sinais de ouro tradicionais? Zero de tráfego, número de erros, latência, e saturação. E uma coisa que percebo bastante nesse trabalho que eu faço com comunidades é que eu vejo que as pessoas (a maioria) não entram mais naquele mérito de tentar entender o que é uma arquitetura CPU bound, network-bound, disk-bound, ou memory bound. Ou pelo menos antigamente a gente tinha essa preocupação. Essa tecnologia é o que? Elasticsearch por exemplo, ela é uma tecnologia que pega mais disco, CPU, memória ou rede? Não precisa pensar muito, a resposta é: disco e rede. E onde isso é relevante, pensando na questão da saturação? Porque quando a gente fala: “tenho que monitorar a saturação”, como fazer isso em uma arquitetura que é distribuída e tem um microserviço por exemplo que tá fazendo um cálculo, que é CPU bound, enquanto outro é network-disk-bound e já tem mais a ver com armazenamento e propagação de streamings?
É preciso olhar o sistema como um todo, e como é que você calcula a saturação disso entrando no mérito de saturação de cada um deles sem entender o que é disk, I/O, network? Esse é um pequeno detalhe, mas que se você parar para pensar faz toda a diferença em quanto está levando a sério monitorar a saturação por exemplo. O que é um sistema saturado? É um sistema em que o banco de dados passou do high-water mark de 80%? É porque o load-balancer passou de 1000 requisições por segundo? Esse é o seu critério de saturação? Acho que tem que ir muito mais a fundo principalmente por conta daquilo que a gente discutiu lá no início da nossa conversa. Estamos vivendo em um mundo em que as tecnologias estão muito distribuídas e complicadas, não é mais aquele servidor Apache que você “dava um tail no log” e estava tudo certo. Agora é tudo muito mais complexo.
Assista ao vídeo com a íntegra do bate-papo:
