أوريك لوسون | GettyImages
منذ أكثر من ثلاث سنوات بقليل ، قبل إصابة COVID مباشرة ، قمنا بتشغيل قطعة طويلة على الأدوات والحيل التي تجعل Ars يعمل بدون مكتب فعلي. أمضى آرس عقودًا في إتقان كيفية إنجاز الأمور كقوى عاملة موزعة عن بُعد ، وكما اتضح ، كنا محظوظين أكثر مما أدركنا لأن الطبيعة الموزعة جعلت العمل من خلال الوباء شيئًا غير مناسب لنا بشكل أو بآخر. بينما كانت الشركات الأخرى تتدافع للحصول على ترتيبات العمل من المنزل لموظفيها ، واصلنا النقل بالشاحنات دون الحاجة إلى القيام بأي شيء مختلف.
مهما يكن هنا كان تغيير كبير مر به آرس في وقت قريب من نشر تلك المقالة. شهد يناير 2020 انتقالنا بعيدًا عن البنية التحتية المادية إلى بيئة استضافة قائمة على السحابة بالكامل. بعد سنوات من الخدمة الرائعة من الأشخاص في Server Central (الآن Deft) ، حان الوقت للقفزة في السحاب – والقفز الذي فعلناه.
كان هناك عدد قليل من الأسباب الكبيرة لإجراء التغيير ، ولكن أكثرها أهمية كانت متعلقة بالميزة والتكلفة. يؤمن Ars بشدة بإدارة مجموعة التكنولوجيا الخاصة به ، ويرجع ذلك أساسًا إلى أنه يمكننا تكرار الميزات الجديدة بشكل أسرع بهذه الطريقة ، ومنصة المجتمع الخاصة بنا فريدة من نوعها بين العلامات التجارية الأخرى لـ Condé Nast. لذلك عندما كانت بقية الشركة إما تنتقل إلى Amazon Web Services (AWS) أو تستخدمها بالفعل ، كان بإمكاننا القفز على العربة والاستفادة من أسعار شركة Condé. هذا – جنبًا إلى جنب مع عدم الاضطرار إلى الحفاظ على البنية التحتية الاحتياطية المادية لامتصاص الزيادات الكبيرة في حركة المرور والقدرة على الاعتماد على التوسع – أدى إلى تغيير المعادلة بشكل أساسي بالنسبة لنا.
بالإضافة إلى التكلفة ، انتهزنا أيضًا فرصة فحص كيفية تنظيم موقع ويب Ars Technica ومكوناته وتقديمها. كنا نستخدم إعداد “سحابة خاصة افتراضية” في استضافتنا السابقة – كانت عبارة عن كومة من الخوادم المادية المخصصة التي تشغل VMWare vSphere – ولكن طرح كل شيء في AWS منحنا الفرصة لإعادة تقييم الموقع واعتماد بنية مرجعية قوية.
غائم مع فرصة للبنية التحتية
والآن ، مع إعادة التصميم هذه التي كانت عملية ومستقرة لبضع سنوات وبضعة مليارات مشاهدة للصفحة (حقًا!) ، نريد أن ندعوكم جميعًا خلف الستار لإلقاء نظرة خاطفة على كيفية الحفاظ على موقع رئيسي مثل Ars على الإنترنت وعملي. . . ستكون هذه المقالة هي الأولى في سلسلة من أربعة أجزاء حول كيفية عمل Ars Technica – سنقوم بفحص كل من الخيارات التقنية الأساسية التي تدعم Ars والبرامج التي نربط بها كل شيء معًا.
هذه القطعة الأولى ، التي سنشرع فيها الآن ، ستنظر في الإعداد من مستوى عالٍ ثم تركز على مكونات التكنولوجيا الفعلية – سنعرض اللبنات الأساسية وكيف يتم ترتيب تلك الكتل. أسبوع آخر ، سنتابع بإلقاء نظرة أكثر تفصيلاً على التطبيقات التي تشغل Ars وكيف تتلاءم هذه التطبيقات مع بعضها البعض في البنية التحتية ؛ بعد ذلك ، سنبحث في بيئة التطوير وننظر في كيفية قيام المدير التقني في Ars Jason Marlin بإنشاء ونشر التغييرات في الموقع.
أخيرًا ، في الجزء 4 ، سنلقي نظرة خاطفة على المستقبل. هناك بعض التغييرات التي نفكر في إجرائها – يُعد إغراء (وسعر) عروض ARM 64 بت أمرًا قويًا – وفي الجزء 4 ، سنلقي نظرة على هذه الأشياء ونتحدث عن خططنا القادمة للهجرة إليها.
آرس تكنيكا: ما نقوم به
لكن قبل أن ننظر إلى ما نريد القيام به غداً، دعونا نلقي نظرة على ما نفعله اليوم. اربط حقويه ، أيها القراء الأعزاء ، ودعنا نتعمق.
للبدء ، إليك مخطط كتلة لخدمات AWS المحددة التي يستخدمها Ars. إنها طريقة بسيطة نسبيًا لتمثيل بنية معقدة مترابطة:
لي هاتشينسون
يعتمد Ars على أجزاء متعددة من مكدس تقنيات AWS. نحن نعتمد على Application Load Balancer (ALB) لتوجيه حركة مرور الزائرين الوافدين أولاً إلى خدمة Ars الخلفية المناسبة (المزيد عن تلك الخدمات في الجزء 2). في اتجاه مصب ALB ، نستخدم خدمتين تسمى Elastic Container Services (ECS) و Fargate جنبًا إلى جنب مع بعضهما البعض لتدوير حاويات تشبه Docker للقيام بالعمل. تُستخدم خدمة أخرى ، Lambda ، لتشغيل وظائف cron لتطبيق WordPress الذي يشكل جوهر موقع Ars على الويب (نعم ، يدير Ars WordPress – سنتطرق إلى ذلك في الجزء 2).
اكتشاف المزيد من عرب نيوز للتقنية
اشترك للحصول على أحدث التدوينات المرسلة إلى بريدك الإلكتروني.
