Nos bastidores: como apresentamos o Ars Technica, parte 1

Há pouco mais de três anos, pouco antes do surgimento do COVID, publicamos um longo artigo sobre as ferramentas e truques que fazem o Ars funcionar sem um escritório físico. Ars passou décadas aperfeiçoando como fazer as coisas como uma força de trabalho remota distribuída e, ao que parece, tivemos ainda mais sorte do que imaginávamos porque essa natureza distribuída tornou o trabalho durante a pandemia mais ou menos um não-evento para nós. Enquanto outras empresas se esforçavam para organizar o trabalho em casa para seus funcionários, continuamos transportando caminhões sem precisar fazer nada diferente.

No entanto, lá era uma mudança significativa pela qual Ars passou na época em que o artigo foi publicado. Janeiro de 2020 marcou nossa transição da infraestrutura física para um ambiente de hospedagem totalmente baseado em nuvem. Depois de anos de grande serviço do pessoal da Server Central (agora Deft), chegou a hora de dar um salto para as nuvens – e pulamos.

Havia alguns grandes motivos para fazer a mudança, mas os que mais importavam eram relacionados a recursos e custos. A Ars acredita firmemente em executar sua própria pilha de tecnologia, principalmente porque podemos iterar novos recursos mais rapidamente dessa maneira, e nossa plataforma de comunidade é única entre outras marcas da Condé Nast. Assim, quando o restante da empresa estava migrando para ou já no Amazon Web Services (AWS), pudemos entrar na onda e aproveitar os preços corporativos da Condé. Isso, combinado com não ter mais que manter a infraestrutura de reserva física para absorver grandes picos de tráfego e poder contar com o dimensionamento, mudou fundamentalmente a equação para nós.

Além do custo, também aproveitamos a chance de reprojetar como o site da Strong The One e seus componentes foram estruturados e servidos. Estávamos usando uma configuração de “nuvem privada virtual” em nossa hospedagem anterior – era uma pilha de servidores físicos dedicados executando o VMWare vSphere – mas colocar tudo na AWS nos deu a oportunidade de reavaliar o site e adotar uma arquitetura de referência sólida.

Nublado com possibilidade de infraestrutura

E agora, com esse redesenho funcional e estável por alguns anos e alguns bilhões de visualizações de página (sério!), Queremos convidar todos vocês para trás da cortina para espiar como mantemos um site importante como o Ars online e funcional. Este artigo será o primeiro de uma série de quatro partes sobre como o Strong The One funciona – examinaremos as opções básicas de tecnologia que alimentam o Ars e o software com o qual conectamos tudo.

Esta primeira peça, na qual estamos embarcando agora, examinará a configuração de um alto nível e, em seguida, focará nos componentes de tecnologia reais – mostraremos os blocos de construção e como esses blocos são organizados. Em outra semana, daremos seguimento com uma visão mais detalhada dos aplicativos que executam o Ars e como esses aplicativos se encaixam na infraestrutura; depois disso, vamos nos aprofundar no ambiente de desenvolvimento e ver como o diretor de tecnologia da Ars, Jason Marlin, cria e implementa alterações no site.

Finalmente, na parte quatro, daremos uma espiada no futuro. Estamos pensando em fazer algumas mudanças — a atração (e o preço!) das ofertas de ARM de 64 bits é uma coisa poderosa — e veremos essas coisas e falaremos sobre nossos planos futuros de migração para ela.

Strong The One: O que estamos fazendo

Mas antes de olharmos para o que queremos fazer amanhã, vamos ver o que estamos fazendo hoje. Preparem-se, queridos leitores, e vamos mergulhar.

Para começar, aqui está um diagrama de blocos dos serviços específicos da AWS que o Ars usa. É uma maneira relativamente simples de representar uma estrutura interligada complexa:

Ars se apóia em várias partes da pilha de tecnologia da AWS. Dependemos de um Application Load Balancer (ALB) para primeiro rotear o tráfego de entrada do visitante para o serviço de back-end Ars apropriado (mais sobre esses serviços na parte dois). Downstream do ALB, usamos dois serviços chamados Elastic Container Services (ECS) e Fargate em conjunto para ativar contêineres do tipo Docker para fazer o trabalho. Outro serviço, o Lambda, é usado para executar cron jobs para o aplicativo WordPress que forma o núcleo do site Ars (sim, o Ars executa o WordPress — abordaremos isso na parte dois).