.
Aurich Lawson | Getty Images
Saudações, queridos leitores, e parabéns — chegamos ao fim de nossa série de quatro partes sobre como o Strong The One é hospedado na nuvem, e tem sido uma jornada. Passamos por nossa infraestrutura, nossa pilha de aplicativos e nossa estratégia de CI/CD (isso é “integração contínua e implantação contínua” — o processo pelo qual gerenciamos e mantemos o código de nosso site).
Agora, para encerrar as coisas, temos alguns tópicos para analisar. Nesta parte final, discutiremos alguns detalhes de configuração restantes que não tive a chance de abordar nas partes anteriores – incluindo como funciona nosso sistema de liveblogging testado em batalha (é surpreendentemente simples e, no entanto, resistiu a milhões de leitores martelando durante os eventos da Apple). Também veremos como lidamos com o DNS autoritativo.
Por fim, encerraremos algo que venho querendo examinar há algum tempo: as ofertas de serviços ARM de 64 bits baseados em nuvem da AWS. Quanto de nossa infraestrutura poderíamos transferir para sistemas baseados em ARM64, quanto trabalho isso daria e quais poderiam ser os benefícios a longo prazo, tanto em termos de desempenho quanto de custos?
Mas primeiro, porque sei que temos leitores que gostam de pular adiante, vamos reintroduzir nosso diagrama de blocos e garantir que todos saibam o que estamos fazendo hoje:
A recapitulação: o que temos
Então, recapitulando: o Ars é executado no WordPress para a página inicial, uma instância menor do WordPress/WooCommerce para a loja de produtos e XenForo para o OpenForum. Todos esses aplicativos vivem como contêineres em tarefas do ECS (onde “tarefa”, nesse caso, é funcionalmente equivalente a um host Docker, contendo vários serviços). Essas tarefas são invocadas e eliminadas conforme necessário para dimensionar o site para cima e para baixo em resposta à quantidade atual de tráfego de visitantes. Vários outros componentes da pilha contribuem para manter o site operacional (como Aurora, que fornece bancos de dados MySQL para o site, ou Lambda, que usamos para iniciar as tarefas agendadas do WordPress, entre outras coisas).
No lado esquerdo do diagrama, temos nossa pilha CI/CD. O código que faz o Ars funcionar – que para nós inclui coisas como nossos arquivos PHP do WordPress, tanto o núcleo quanto o plug-in – reside em um repositório privado do Github sob controle de versão. Quando precisamos alterar nosso código (como se houvesse uma atualização do WordPress), modificamos a fonte no repositório do Github e, usando todo um conjunto de ferramentas, enviamos essas alterações para o ambiente da Web de produção e novas tarefas são executadas contendo essas mudanças. (Assim como a pilha de software, é um pouco mais complicado do que isso — consulte a parte três para obter uma descrição mais granular do processo!)
Leitores atentos podem perceber que há algo diferente no diagrama acima: alguns dos serviços estão destacados em amarelo. Bem observado — esses são serviços que podemos alternar para executar na arquitetura ARM64, e examinaremos isso próximo ao final deste artigo.
Cores à parte, também faltam várias coisas nesse diagrama. Na tentativa de mantê-lo o mais alto possível e ainda ser útil, omiti toda uma confusão de componentes de infraestrutura mais básicos – e um desses componentes é o DNS. É uma daquelas coisas sem as quais não podemos operar, então vamos pular lá e falar sobre isso.
.
