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