Em março passado, seu CTO e co-fundador Tyler Love tweetou que a empresa havia adotado totalmente a arquitetura sem servidor. “Atendemos mais de um bilhão de solicitações a 80 milhões de pessoas usando...

O Bustle Digital Group é a maior editora premium alcançando mulheres da geração do milênio, atraindo mais de 80 milhões de leitores por mês para propriedades como Bustle.com e Elite Daily . Em março passado, seu CTO e co-fundador Tyler Love tweetou que a empresa havia adotado totalmente a arquitetura sem servidor . “Atendemos a mais de um bilhão de solicitações para 80 milhões de pessoas usando SSR pré-agem e reagem por mês” , escreveu ele . “Somos um exemplo de sucesso de JavaScript moderno em grande escala.”

Nossa gerente de engenharia Sara Chipps conversou com Love como parte de uma série de perguntas e respostas sobre como as equipes de engenharia de todos os setores e indústrias trabalham e colaboram. Eles mergulharam mais fundo em sua experiência em Serverless e por que foi a decisão certa para Bustle adotá-lo totalmente.

Sara Chipps: Quais benefícios você acha que o Serverless adicionou à pilha de tecnologia e cultura do Bustle?

Tyler Love: Vou começar pelo lado técnico. Eu construí infraestrutura automatizada em alguns lugares no passado. Naquela época, construímos tudo e empurramos para fora no Chef. Isso foi antes que o Docker fosse uma solução viável e parecia realmente doloroso.

Mas toda vez que queríamos fazer uma mudança nisso, ou queríamos um novo tipo de pilha, repetíamos muito trabalho. Portanto, acho que o que foi adicionado à pilha foi a capacidade de tirar o código de infraestrutura da equação e não ter que construir a mesma coisa indefinidamente. Conseguimos nos concentrar um pouco mais em outros desafios.

Do lado da cultura, acho que é uma resposta um pouco mais nebulosa. Eu diria que acabamos de ser engenheiros com um conjunto de habilidades mais focado. A parte da cultura é um pouco separada de qualquer uma das coisas sem servidor. Mas encontramos engenheiros que estão bem em tentar algo novo. Não existe uma maneira conhecida e estabelecida de fazer as coisas que você não questione ou que as pessoas estejam menos dispostas a mudar. Portanto, é útil no lado cultural.

Então você não precisa de uma equipe DevOps?

Não temos uma equipe DevOps. Acho que são duas coisas. Há menos DevOps e menos manutenção de sobrecarga. Mas também significa que todos nós assumimos um pouco disso. Ainda temos um código que lida com tudo, desde a implantação e o monitoramento, e você ainda precisa saber como essas coisas funcionam. Estamos apenas usando ferramentas de nuvem para fazer mais, mas ainda temos que configurá-lo e controlar onde nossos logs vão parar e esse tipo de coisa.

Então eu vi um espectro de estratégias de contratação, e o que você está dizendo me faz pensar se você precisa de pessoas full stack que sejam ainda mais full stack. Ou você contrata com especialidades em mente e apenas incentiva as pessoas a estarem mais atentas a essa parte do meio ambiente?

Isso é algo que parece um pouco diferente de engenheiro para engenheiro. Acho que a parte mais interessante é que alguns engenheiros tendem a gostar de se concentrar nos microproblemas e desenvolver soluções realmente sucintas para eles. E alguns engenheiros gostam de fazer mudanças mais abrangentes.

Tenho pensado um pouco menos nas diferenças entre os engenheiros full stack front-end e back-end. Mas eu meio que me identifico com os dois. É muito divertido escrever a solução mais simples para algo que parece básico e também diminuir o zoom para que você possa descobrir como configurar algo de nível super alto.

As propriedades do Bustle Media Group atraem mais de 80 milhões de visitantes. Quando se trata de empresas sem servidor, aposto que seu tráfego está no lado superior. Você diria que isso é correto?

Sim, eu faria. Até onde eu sei, somos o site sem servidor voltado para o usuário com maior tráfego. Tenho certeza de que isso ainda é verdade. Mas tenho certeza de que há pessoas que estão fazendo coisas internas e usando o Serverless que está muito além da escala em que estamos.

Você já se deparou com algum desafio por causa disso, ou está apenas surpreso que mais pessoas não estão fazendo isso porque você não?

Certamente foi desafiador descobrir o lado voltado para o usuário no início. Tanto que corremos alguns riscos, mas descobrimos que não era possível fazer algumas coisas. Felizmente, tudo isso parece ter sido resolvido agora.

Mas não acho que a Amazon pretendia que sites voltados para o usuário fossem lançados com API Gateway e Lambda antecipadamente. Então acabamos esperando que eles adicionassem alguns recursos e cruzando os dedos para que viessem. Era algo básico, como lidar com códigos de resposta sob certas condições, e era mais simples do que você pode imaginar. Era como fazer um redirecionamento, onde você poderia conectar redirecionamentos quando eles o iniciassem, mas não poderia passar a URL para a qual ele deveria redirecionar a partir de sua função. Então, tivemos que hackear coisas realmente selvagens como essa.

Uau, isso é selvagem.

Eu comparo muito de nossa experiência com a forma como mudou o DevOps. Isso é o que realmente mudou. Ainda estamos escrevendo lógica de negócios em JavaScript. A outra ponta era o monitoramento e registro, então não sabíamos o que íamos fazer lá. Não havia convenções, práticas recomendadas ou ferramentas plug-and-play. Mas todos os registros estão aparecendo em algum lugar, então nós mesmos assumimos muitos deles.

Isso acabou sendo uma solução muito boa. Todos os nossos logs por padrão na Amazon vão para CloudWatch. Temos apenas uma função que está completamente isolada de nosso aplicativo, que se espalha para qualquer serviço que escolhermos. Portanto, é apenas uma questão de darmos uma olhada no SDK, ou qualquer que seja a API para a qual desejamos enviar os logs. Descobrimos se queremos amostrar ou enviar todos para lá, e apenas escrevemos o que acaba sendo uma função para adotar qualquer ferramenta de monitoramento.

Quando começamos, essa solução era assustadora e desafiadora. Pensamos: “Como vemos os rastreamentos de pilha?” E acabamos com algo um pouco melhor do que começamos.

Isso é legal. Você armazena seus logs nos mesmos lugares?

Nós meio que construímos tudo do zero conforme mudamos para o Serverless. Temos o CloudWatch que analisa e desenhamos os gráficos básicos que você gostaria de ver, que substituem coisas como CPU e utilização de memória.

Agora, estamos interessados ​​no tempo de execução, no monitoramento das partidas a frio e no impacto que elas têm. Adotamos coisas como o Scalyr, para onde vai a maior parte de nossos logs se realmente precisarmos de uma pesquisa de tecnologia completa. Existem um milhão de produtos de monitoramento.

Não ouvi falar de Scalyr.

Foi fácil adotar. Também temos o Sentry, que é outro para travamentos de aplicativos. É aí que nossos rastreamentos de pilha resultam em um erro 500. Portanto, entre essas duas ferramentas, podemos obter tudo o que sempre desejamos de registro e monitoramento. Somos capazes de reproduzir bugs e problemas que estão acontecendo na produção e no desenvolvimento facilmente para que possamos corrigi-los. Também podemos dizer: “Se eu escrever esta declaração de log e o aplicativo aqui, sei como construir um gráfico a partir dela, ou ver o volume, ou apenas ver o que está acontecendo na produção”.

Você vê um fim à vista? Há algo na sua frente onde você diz: “Não seremos mais capazes de funcionar assim?” Ou você está em um lugar que está satisfeito com a forma como a infraestrutura está configurada?

Estou muito feliz com a configuração. Acho que as próximas preocupações de dimensionamento que temos são particionar nosso armazenamento de dados em algum momento dos próximos um ou dois anos, e isso desvenda um novo conjunto de problemas. O Serverless meio que tirou isso da equação.

Eu vou ser honesto, no entanto. Para nossa carga de trabalho específica, somos um site com muitas leituras. Ainda fazemos muitas gravações de dados, mas não precisamos dimensionar essas coisas entre si.

Isso faz sentido.

Agora nosso conjunto de dados está ficando maior, portanto, nossos problemas de dimensionamento nunca foram particularmente desafiadores quando se trata de apenas atender às solicitações HTTP geradas pelo usuário. Acho engraçado dizer, no entanto. Uma década atrás, pensar sobre a quantidade de tráfego que tínhamos seria assustador para a maioria das pessoas. Agora, eu não acho que nenhum grupo relativamente competente de engenheiros poderia provavelmente descobrir isso com todos os tipos de técnicos diferentes.

Isso faz uma boa transição para uma questão remanescente. O que o estressa e o mantém acordado à noite?

Essa é a parte divertida do que faço. O que me mantém acordado à noite é sempre garantir que haja projetos envolventes e divertidos para os engenheiros trabalharem. Portanto, sabendo do que precisamos como negócio e contextualizando isso em desafios e problemas de engenharia que realmente envolverão os engenheiros. E acho que você precisa entender o contexto do problema e que conjunto de habilidades de engenharia realmente será necessário para resolvê-lo.

Acho que é uma parte importante da cultura que estou tentando construir na equipe aqui. Somos uma equipe de engenharia relativamente pequena, portanto, é muito difícil manter de 15 a 20 pessoas ocupadas, sentindo que estão aprendendo algo e também causando um impacto nos negócios.

Acho que, devido à tecnologia que escolhemos, você tem a liberdade de experimentar. Então, as coisas que são servis ou repetitivas, meio que resolvemos com a pilha de tecnologia que escolhemos. Acho que o GraphQL e o Serverless fizeram com que você não configurasse um servidor web para fazer algo diferente de alguma forma. Isso nos manteve focados na lógica de negócios e no código real que você escreve para vender algo, o que é divertido.

Descubra como os conteúdos do Avance Network pode ajudar equipes de cientistas e engenheiros de todos os tamanhos a melhorar a produtividade.