Aurich Lawson | imágenes falsas
Hace poco más de tres abriles, amoldonado antaño de que llegara el COVID, realizamos un espacioso trabajo sobre las herramientas y los trucos que hacen que Ars funcione sin una oficina física. Ars ha pasado décadas perfeccionando cómo hacer las cosas como una fuerza de trabajo remota distribuida, y resultó que tuvimos aún más suerte de lo que creíamos porque la naturaleza distribuida hizo que trabajar durante la pandemia fuera más o menos un evento obvio para nosotros. Mientras que otras empresas luchaban por organizar el trabajo desde casa para sus empleados, nosotros continuamos conduciendo camiones sin tener que hacer cero diferente.
Pero hay era un cambio significativo que sufrió Ars amoldonado en el momento en que se publicó el artículo. Enero de 2020 marcó nuestra transición de la infraestructura física a un entorno de alojamiento totalmente basado en la estrato. Luego de muchos abriles de buen servicio por parte de la parentela de Server Central (ahora Deft), había llegado el momento de dar un brinco a las nubes, y lo hicimos.
Hubo algunas razones importantes para hacer el cambio, pero las más importantes estaban relacionadas con la función y el costo. Ars cree firmemente en ejecutar su propia pila de tecnología, principalmente porque podemos iterar en nuevas funciones más rápido de esa modo, y nuestra plataforma comunitaria es única entre otras marcas de Condé Nast. Entonces, cuando el resto de la empresa se mudó o ya estaba en Amazon Web Services (AWS), pudimos subirnos al carro y disfrutar los precios empresariales de Condé. Eso, combinado con no tener que nutrir una infraestructura física de respaldo para absorber grandes picos de tráfico y poder dejarlo en Dios en la escalabilidad, cambió fundamentalmente la ecuación para nosotros.
Por otra parte del costo, incluso aprovechamos la oportunidad de rediseñar cómo se estructuraron y operaron el sitio de Ars Technica y sus componentes. Usamos una configuración de «estrato privada posible» en nuestro alojamiento antedicho, era un corro de servidores físicos dedicados que ejecutaban VMWare vSphere, pero trasladar todo a AWS nos dio la oportunidad de retornar a evaluar el sitio y adoptar una cimentación de relato sólida.
Nublado con posibilidad de infraestructura
Y ahora que ese rediseño ha sido cómodo y estable durante algunos abriles y unos miles de millones de páginas vistas (¡en serio!), nos gustaría invitarlos a todos detrás de la cortina para ver cómo mantenemos un gran sitio como Ars en bisectriz. y cómodo. Este artículo será el primero de una serie de cuatro partes sobre cómo funciona Ars Technica: examinaremos las opciones tecnológicas fundamentales que impulsan a Ars y el software con el que conectamos todo.
Esta primera alcoba, en la que nos estamos embarcando ahora, analizará la configuración desde un stop nivel y luego se centrará en los componentes tecnológicos reales: mostraremos los componentes básicos y cómo se organizan esos bloques. Seguiremos otra semana con una observación más detallada a las aplicaciones que ejecutan Ars y cómo esas aplicaciones encajan juntas en la infraestructura; luego profundizaremos en el entorno de explicación y veremos cómo el director técnico de Ars, Jason Marlin, crea e implementa cambios en el sitio.
Finalmente, en la Parte 4, echamos un pequeño vistazo al futuro. Hay algunos cambios que estamos considerando hacer: el atractivo (¡y el precio!) de las ofertas de ARM de 64 bits es cachas, y en la Parte 4 lo analizaremos y hablaremos sobre nuestros próximos planes para portar a él.
Ars Technica: Qué hacemos
Pero antaño de mirar lo que queremos hacer mañana, veamos lo que estamos haciendo Hoy. Cíñanse los lomos, queridos lectores, y sumerjámonos.
Para comenzar, aquí hay un diagrama de bloques de los servicios específicos de AWS que usa Ars. Es una forma relativamente simple de representar una estructura enlazada compleja:
Lee Hutchinson
Ars se basamento en varias partes de la pila de tecnología de AWS. Confiamos en un Balanceador de carga de aplicaciones (ALB) para dirigir primero el tráfico de visitantes entrantes al servicio de back-end de Ars apropiado (más información sobre estos servicios en la Parte 2). Aguas debajo de ALB, usamos dos servicios llamados Elastic Container Services (ECS) y Fargate en conjunto para construir contenedores tipo Docker para hacer el trabajo. Otro servicio, Lambda, se usa para ejecutar trabajos cron para la aplicación de WordPress que forma el núcleo del sitio web de Ars (sí, Ars ejecuta WordPress; hablaremos de eso en la Parte 2).