Stack Overflow opera com 9 servidores on-premises

• Resumo da entrevista com Roberta Arcoverde, diretora de engenharia do Stack Overflow, no podcast de Scott Hanselman
• Entrou há 8 anos como engenheira de software, virou staff engineer (tech lead) e, no começo deste ano, migrou para gestão

S: O que mudou ao se tornar diretora de engenharia?

• R: Passei a gerenciar pessoas. Administrar carreiras e ajudar no crescimento. Também ter uma visão estratégica sobre para onde devemos ir
  Acompanho continuamente se a arquitetura de software está indo na direção do crescimento e se este PR está nos movendo para onde queremos estar nos próximos 3 anos, não apenas agora
• S: Então você planeja e age com uma visão mais de longo prazo. Para não ser pega de surpresa pelas mudanças na tecnologia.
• R: Exatamente. E também faço mais reuniões 1-on-1.
• S: Na Microsoft também estamos em época de avaliações, e por vários dias tudo o que faço são reuniões 1-on-1 e reviews. Fica chato só fazer reunião o tempo todo; você olha código para dar uma refrescada?
• R: Sim, olho código. Acredito fortemente que até gestores de linha de frente como eu deveriam escrever código todos os dias. Acho que isso ajuda pessoalmente a manter a bagagem técnica.
  Também ajuda a orientar engenheiros juniores e a avaliar o impacto das mudanças propostas por engenheiros seniores.
  Se você continua escrevendo código e acompanhando para onde o software está indo, consegue fazer as perguntas certas para ajudá-los a obter o melhor resultado quando há grandes redesenhos.

S: Como é a arquitetura do Stack Overflow?

• R: O Stack Overflow é um pouco peculiar. Especialmente comparado com outros grandes sites que começaram em 2008.
  • Temos hoje uma base de código com 14 anos
  • Rodamos em máquinas on-premises no nosso próprio datacenter
  • Nunca fomos para a nuvem
  • Também é uma aplicação monolítica. Não a dividimos em serviços ou microsserviços
  • Também temos uma web app multi-tenant. É baseada em .NET e roda como um único app em 9 servidores web
  • Opera em IIS, e um único servidor processa 6.000 requests por segundo. (2 bilhões de pageviews por mês)
• S: Muito do IIS desapareceu com a ascensão de Apache, NGINX, Kubernetes e outros. Vocês poderiam ter ido nessa direção; houve coisas que decidiram ignorar de propósito? E o que vocês pensaram: isso é algo de que o SO precisa?
• R: Ignoramos muitas dessas coisas. As mais recentes foram tudo relacionado a microsserviços e Kubernetes.
  O maior motivo para ignorá-las vem da filosofia de desenvolvimento mais forte do SO.
  Sempre começamos com esta pergunta: "Que problema estamos tentando resolver?"
  Os problemas que essas ferramentas tentam resolver não são os problemas que enfrentamos.
  Por exemplo, migrar de um monólito para microsserviços ou serviços serve para dividir e escalar times.
  Permite que vários times trabalhem no mesmo projeto sem conflitos, façam deploy mais rápido etc.
  Deploy rápido também nunca foi um problema para nós. O SO faz deploy várias vezes por dia, em 4 minutos, e mesmo se houver problema é possível reverter rapidamente em poucos minutos
  Hoje nosso lead time ou o tempo necessário para fazer merge é excelente, e não é algo doloroso.
  Cerca de 50 engenheiros estão desenvolvendo a plataforma de Q&A
• R: Em 2014 eram 10, e era fácil para todos entenderem toda a base de código.
  Agora o onboarding de novos engenheiros está ficando mais difícil.
  Em algum momento talvez separemos módulos específicos, com times dedicados olhando para eles sem precisar entender todo o código.
  Mas ainda não chegamos lá. Ainda não estamos enfrentando esse problema, e somos pragmáticos.

Outras partes da arquitetura

• Cache em 2 camadas (memória e servidor web)
• Também vários servidores SQL Server: com 1,5 TB de RAM, 1/3 do banco inteiro pode ser acessado rapidamente a partir da memória
  → Isso parece uma configuração muito cara, difícil de usar barato na nuvem
• As páginas de perguntas não são armazenadas em cache. Elas têm a maior taxa de acerto, então 80% do tráfego vai para lá, mas...
  → No passado tentaram usar Redis para cache, mas a taxa de hit/miss não era muito boa
• Hoje o tempo de renderização de página é de cerca de 20 ms
• O StackExchange também roda em multi-tenant nos mesmos servidores. Um único aplicativo atende todos os 200 sites
  → Ou seja, basta fazer deploy de uma única aplicação para aplicar a tudo
• Rolling builds sob o HAProxy

[galadbran]

Uau.... A parte de fazer rolling build com haproxy é impressionante, mas fiquei curioso sobre como isso é implementado.

[galadbran]

Li o roteiro do podcast, e parece que a parte sobre o uso do haproxy é mencionada rapidamente e deixada de lado. Pelo fato de a conversa seguir para a questão de health checks e de estarem fazendo bastante monitoramento, dá a impressão de que eles mesmos construíram isso bem e estão tocando assim... mais ou menos isso ^^;

[roxie]

Fico curioso sobre como eles fazem "deploy em 4 minutos".

[ifmkl]

Na minha empresa anterior, eu também já operei servidores com 4 TB de RAM e 8 TB de RAM. O custo de implantação era, claro, gigantesco, mas sinceramente nunca achei que seria possível substituir com folga essas especificações por cloud.

[forteleaf]

Faz sentido, né.

[nicewook]

Obrigado pelo resumo.
Há muitos pontos impressionantes.

• Usam IIS e não utilizam MSA nem K8s. Porque não precisam.
• A configuração com 1,5 TB de RAM é uma vantagem que o on-prem tem sobre a nuvem.

[xguru]

É uma entrevista bem longa, então resumi alguns trechos ao longo do caminho. Ouça o episódio completo enquanto consulta a transcrição! Transcrição: https://app.podscribe.ai/episode/83433649