Stack Overflow opera con 9 servidores on-prem

• Resumen de la entrevista a Roberta Arcoverde, directora de ingeniería de Stack Overflow, en el pódcast de Scott Hanselman
• Entró hace 8 años como ingeniera de software, luego se convirtió en staff engineer (tech lead) y a inicios de este año dio el giro hacia un rol de gestión

S: ¿Qué cambió al convertirte en directora de ingeniería?

• R: Ahora gestiono personas. Gestiono sus carreras y les ayudo a crecer. También tengo una visión estratégica de hacia dónde debemos ir
  Sigo de forma constante la arquitectura de software para ver cómo es y si avanza en una dirección que permita crecer, y si este PR nos mueve no solo en el corto plazo, sino hacia donde queremos estar en los próximos 3 años
• S: O sea que haces planes y actúas con una visión más de largo plazo. Para no sorprenderte con los cambios tecnológicos.
• R: Exactamente. Y también tengo muchas más reuniones 1-on-1.
• S: En Microsoft también estamos en temporada de evaluaciones, y paso varios días haciendo solo reuniones 1-on-1 y revisiones. Como estar en reuniones todo el tiempo no es muy divertido, ¿a veces miras código para despejarte?
• R: Sí, veo código. Creo firmemente que incluso los gerentes de primera línea como yo deberían escribir código todos los días. Pienso que eso ayuda personalmente a mantener el nivel técnico.
  También ayuda a mentorizar a ingenieros junior y a evaluar el impacto de los cambios propuestos por los ingenieros senior.
  Si sigues escribiendo código y viendo hacia dónde va el software, incluso cuando hay grandes rediseños puedes hacer las "preguntas correctas" para ayudarles a lograr el mejor resultado posible.

S: ¿Cómo es la arquitectura de Stack Overflow?

• R: Stack Overflow es algo particular. Especialmente si se compara con otros sitios grandes que empezaron en 2008.
  • Actualmente tenemos una base de código de 14 años,
  • operamos en nuestras propias máquinas on-prem dentro de nuestro propio datacenter.
  • Nunca nos hemos ido a la nube.
  • También es una aplicación monolítica. No la dividimos en servicios ni microservicios.
  • También tenemos una web app multi-tenant. Está basada en .NET y corre como una sola aplicación en 9 servidores web.
  • Opera sobre IIS, y un solo servidor maneja 6,000 requests por segundo. (2 mil millones de PV al mes)
• S: Muchas instalaciones de IIS desaparecieron con el auge de Apache, NGINX y Kubernetes. Podrían haberse ido por ese camino; ¿hubo cosas que decidieron ignorar a propósito? Y también, ¿qué cosas pensaron que sí necesitaban para SO?
• R: Ignoramos muchas de esas cosas. Lo más reciente ha sido todo lo relacionado con microservicios y Kubernetes.
  La razón principal para ignorarlas viene de una de las filosofías de desarrollo más fuertes de SO.
  Siempre empezamos con esta pregunta: "¿Qué problema estamos tratando de resolver?"
  Los problemas que esas herramientas intentan resolver no son los problemas que nosotros tenemos.
  Por ejemplo, migrar de un monolito a microservicios o servicios sirve para escalar dividiendo equipos.
  Permite que varios equipos trabajen sobre el mismo proyecto sin chocar entre sí, y desplegar rápido, etc.
  Pero desplegar rápido tampoco era un problema para nosotros. SO despliega varias veces al día, en 4 minutos, y si hay un problema también puede revertirse rápidamente en unos minutos
  Actualmente nuestro lead time y el tiempo que toma hacer merge son excelentes, y no es algo doloroso.
  Unos 50 ingenieros desarrollan la plataforma de Q&A
• R: En 2014 eran 10, y era fácil que todos entendieran toda la base de código.
  Ahora el onboarding de nuevos ingenieros sí se está volviendo más difícil.
  En algún momento quizá separemos ciertos módulos y haya equipos dedicados a revisarlos sin necesidad de entender todo el código.
  Pero todavía no hemos llegado a ese punto. Aún no tenemos ese problema y somos pragmáticos.

Otras partes de la arquitectura

• Caché de 2 capas (memoria y servidor web)
• También varios SQL Server: con 1.5 TB de RAM, 1/3 de toda la DB puede accederse rápidamente desde memoria
  → Parece una configuración muy costosa, de las que serían difíciles de usar barato en la nube
• La página de preguntas no se cachea. Aunque tiene la mayor tasa de aciertos, 80% del tráfico va allí...
  → Antes intentaron cachearla con Redis, pero la tasa de hit/miss no fue muy buena
• El tiempo actual de renderizado de página es de unos 20 ms
• StackExchange también opera como multi-tenant en los mismos servidores. Una sola aplicación atiende los 200 sitios
  → Es decir, con desplegar una sola aplicación se aplica a todo
• Hace rolling builds debajo de HAProxy

[galadbran]

Oh, vaya... Me impresionó la parte donde hacen rolling builds con haproxy; me da curiosidad cómo lo implementan.

[galadbran]

Leí la transcripción del pódcast y da la impresión de que la parte donde usan haproxy se menciona brevemente y se pasa de largo. Por cómo la conversación conecta con el tema de los health checks y con que hacen mucho monitoreo, parece que más o menos lo tienen bien armado internamente… ^^;

[roxie]

Tengo curiosidad por saber cómo hacen los despliegues en "4 minutos".

[ifmkl]

Yo también operé servidores de 4 TB de RAM y de 8 TB de RAM en una empresa anterior, y aunque el costo de implementación fue, por supuesto, enorme, realmente no me parecía que fuera posible reemplazar esas especificaciones con la nube.

[forteleaf]

Eso tiene sentido.

[nicewook]

Gracias por el resumen.
Hay muchas partes impresionantes.

• Usan IIS y no usan MSA ni K8s. Porque no lo necesitan.
• Una configuración de 1.5 TB de RAM es una ventaja que tiene on-prem frente a la nube.

[xguru]

Es una entrevista bastante larga, así que la resumí por partes. ¡Escúchenla completa mientras consultan la transcripción!
Transcripción: https://app.podscribe.ai/episode/83433649