Lantern موقع ويب لفعاليات المجتمع. ينشر المنظّمون الفعاليات، ويؤكّد الناس حضورهم، ولكل فعالية صورة ملصق. يعمل الموقع اليوم على خادم واحد مستأجَر: تطبيق Node.js، وقاعدة بيانات PostgreSQL، ومجلّد للملصقات المرفوعة، وكلها على القرص نفسه. وهناك مهمة cron ليلية تنسخ تفريغ قاعدة البيانات إلى… نعم، القرص نفسه.
\nظل الموقع يعمل ثلاث سنوات. ثم انتشر مهرجان لطعام الشارع على نطاق واسع، فقفزت الزيارات عشرين ضعفًا في أمسية واحدة، ونفدت ذاكرة الخادم، وسقط الموقع في اللحظة التي كان مهمًا فيها تمامًا. وبعد أسبوعين امتلأ القرص بالملصقات المرفوعة ورفضت قاعدة البيانات أي عملية كتابة. يريد القائمون على Lantern الانتقال إلى AWS، وهذه الدورة هي ذلك الانتقال، منفّذًا كما يجب.
\nيبيع مزوّد السحابة سعةً وخدماتٍ تنشئها وتعدّلها وتحذفها عبر API، وتدفع ثمنها بحسب الاستخدام. خلف كل زر في الـ console (وحدة التحكم) يوجد استدعاء API، ولهذا فكل ما تنقر عليه في هذه الدورة يمكنك أيضًا كتابته في سكربت.
\nتأتي هذه السعة بمستويات مختلفة من “كم تدير بنفسك”:
\n| ما تحصل عليه | \nمثال من AWS | \nما تبقى تديره أنت | \n
|---|---|---|
| آلة افتراضية | \nAmazon EC2 | \nتحديثات نظام التشغيل، بيئة التشغيل، التطبيق، التوسّع | \n
| قاعدة بيانات مُدارة | \nAmazon RDS | \nالمخطّط (schema)، الاستعلامات، من يمكنه الاتصال | \n
| دالة تعمل عند الطلب | \nAWS Lambda | \nالكود الخاص بك وصلاحياته | \n
| تخزين الكائنات | \nAmazon S3 | \nما تخزّنه ومن يمكنه قراءته | \n
كلما نزلت في الجدول، قلّ العمل الروتيني الذي لا يميّزك عن غيرك، وزاد تأثّرك بطريقة عمل تلك الخدمة.
\nليست موثوقة تلقائيًا. إذا نسخت خادم Lantern الوحيد إلى instance واحدة في EC2، فسيتعطّل تمامًا كما كان: آلة واحدة، وقرص واحد، ومكان واحد. تجعل AWS بناء التصميم الأفضل رخيصًا، لكنها لا تبنيه نيابة عنك.
\nوليست أرخص تلقائيًا. أنت تدفع مقابل ما تحجزه من موارد، لا مقابل ما تحسن استخدامه. قاعدة بيانات اختبار منسيّة تعمل طوال الشهر. والبيانات المرسلة إلى الإنترنت تُقاس وتُحسب. كثير من الفرق الصغيرة تنتقل إلى AWS ثم تتلقّى فاتورة مفاجئة في الشهر الثاني لأن أحدًا لم يضبط ميزانية.
\nوليست آمنة تلقائيًا. تؤمّن AWS المباني والعتاد والبرمجيات التي تشغّل خدماتها. أما أنت فتقرّر من يستطيع تسجيل الدخول، وما الذي يحق لكل قطعة من الكود أن تلمسه، وهل الـ bucket خاص أم لا. الدرس الثالث يحدّد هذا التقسيم بدقّة.
\n\nستتابع Lantern من حساب فارغ إلى إعداد جاهز للإنتاج. يغطّي القسم الأول أين تشغّل AWS مواردك، ومن المسؤول عن ماذا، وكيف تؤمّن الحساب بإحكام وتديره من الطرفية. القسم الثاني عن الهوية: من وما الذي يحق له تنفيذ أيّ إجراءات. القسم الثالث يختار القطع المناسبة من الحوسبة والتخزين وقواعد البيانات والشبكات. والقسم الرابع يبني Lantern الجديد وينشره، ثم يقيس أداءه.
\nعادتان ترافقانك في كل درس. قبل أن تنشئ أي شيء، اسأل: “كم سيكلّف هذا وهو قابع هناك؟” و"من يستطيع الوصول إليه؟" إذا استطعت الإجابة عن السؤالين، فأنت تفهم التصميم. في الدرس التالي: أين تعمل كل هذه الأشياء فعليًا على أرض الواقع.
\n","toc":[{"id":"sec-1","text":"ما الذي تستأجره فعلًا","level":2},{"id":"sec-2","text":"ما ليست السحابة","level":2},{"id":"sec-3","text":"كيف تسير هذه الدورة","level":2}],"takeaways":["السحابة سعة حوسبة مستأجَرة وخدمات مُدارة تنشئها وتعدّلها وتحذفها عبر API، وتدفع ثمنها بحسب الاستخدام.","الانتقال إلى AWS يزيل أعباء العتاد لكنه لا يزيل عمل التصميم؛ فالخادم الواحد في AWS يتعطّل بالطرق نفسها تمامًا التي يتعطّل بها أي خادم واحد في أي مكان آخر.","تحاسبك AWS بالثانية أو الساعة أو الغيغابايت أو الطلب، لذا فكل ما تتركه يعمل يظل يكلّفك مالًا حتى تحذفه.","الأمان في السحابة مسؤولية مشتركة؛ تؤمّن AWS مراكز البيانات، وتؤمّن أنت ما تضبطه وما ترفعه."],"further":[{"title":"What is cloud computing?","url":"https://aws.amazon.com/what-is-cloud-computing/"},{"title":"Overview of Amazon Web Services – Six advantages of cloud computing","url":"https://docs.aws.amazon.com/whitepapers/latest/aws-overview/six-advantages-of-cloud-computing.html"}],"quiz":[{"q":"تعطّل خادم Lantern الوحيد عندما انتشرت إحدى الفعاليات بشكل واسع. أيّ عبارة عن نقله إلى instance واحدة من Amazon EC2 صحيحة؟
","options":[{"text":"سيصمد أمام الذروة القادمة، لأن AWS توسّع كل instance تلقائيًا.","why":"الـ instance في EC2 آلة افتراضية بحجم ثابت. لا شيء يتوسّع ما لم تصمّم لذلك، مثلًا باستخدام Auto Scaling أو شبكة CDN."},{"text":"سيتعطّل بالطريقة نفسها، لأن الخادم الواحد يبقى خادمًا واحدًا أينما عمل.","why":"صحيح. السحابة تجعل بناء التصاميم الأفضل رخيصًا وسريعًا، لكن نقل صندوق واحد كما هو (lift-and-shift) يحتفظ بنقاط ضعف الصندوق الواحد."},{"text":"لا يمكن أن يتعطّل، لأن AWS تضمن توافرًا بنسبة 100% لـ EC2.","why":"لا توجد خدمة في AWS تعِد بـ 100%. اتفاقيات مستوى الخدمة (SLA) تمنح أرصدة تعويضية عندما ينخفض التوافر عن نسبة منشورة."}],"answer":1},{"q":"أيّ فكرة تسعير تصف معظم خدمات AWS بشكل أفضل؟
","options":[{"text":"رسوم شهرية ثابتة لكل حساب تغطي كل الاستخدام.","why":"هكذا تعمل كثير من خدمات الاستضافة المشتركة، لا AWS. فـ AWS تقيس كل مورد على حدة."},{"text":"شراء العتاد مرة واحدة لتستضيفه AWS نيابة عنك.","why":"أنت لا تشتري العتاد أبدًا. حتى الالتزامات طويلة الأمد مثل Savings Plans هي خصومات على الاستخدام، لا عمليات شراء."},{"text":"استخدام مُقاس، مثل ثواني تشغيل الـ instance والغيغابايتات المخزّنة والطلبات المنفّذة والبيانات المرسلة إلى الإنترنت.","why":"صحيح. لهذا تكلّف الموارد الخاملة مالًا، ولهذا يكون تنبيه الميزانية من أول ما تضبطه."}],"answer":2},{"q":"بعد الانتقال، من المسؤول عن أن يكون الـ bucket في S3 الذي تُخزَّن فيه ملصقات Lantern خاصًّا؟
","options":[{"text":"فريق Lantern، لأن إعدادات الوصول هي ضبطٌ يتحكّم فيه العميل.","why":"صحيح. تمنحك AWS إعدادات افتراضية آمنة وأدوات، لكن من تمنحه حق الوصول هو دائمًا قرارك ومسؤوليتك."},{"text":"AWS، لأن S3 خدمة مُدارة.","why":"كلمة «مُدارة» تعني أن AWS تشغّل الخوادم والبرمجيات. ولا تعني أنها تقرّر من يجب أن يقرأ بياناتك."},{"text":"لا أحد، لأنه لا يمكن جعل الـ buckets في S3 عامّة.","why":"الـ buckets الجديدة تحجب الوصول العام افتراضيًا، لكن المالك يستطيع إيقاف ذلك ونشر الكائنات."}],"answer":0}],"exercise":{"kind":"choice","multiple":true,"options":["spike","disk","backups","bugs","costs"],"correct":["disk","backups"],"title":"ما الذي يصلحه الانتقال فعلًا؟","prompt":"يعدّد القائمون على Lantern خمس مشكلات في خادمهم الوحيد. افترض أنهم انتقلوا إلى AWS بتصميم أفضل: الملصقات في Amazon S3، وقاعدة البيانات على خدمة مُدارة مع نسخ احتياطية تلقائية، لكن التطبيق ما زال على instance واحدة في EC2. اختر كل مشكلة يحلّها هذا الانتقال فعلًا.
\n","hints":["اسأل عن كل مشكلة: هل سببها توزيع العتاد، أم التصميم والكود؟","الخدمة المُدارة تغيّر من يشغّل التخزين والنسخ الاحتياطية. ولا تغيّر شيئًا في عدد خوادم التطبيق لديك.","مشكلتان تختفيان لأن البيانات لم تعد تعيش على قرص واحد. أما البقية فتحتاج إلى تصميم مختلف أو عادات مختلفة."],"explanation":"نقل الملصقات إلى S3 يزيل مشكلة امتلاء القرص، لأن S3 يتّسع دون أن تحجز مساحة مسبقًا. والنسخ الاحتياطية التلقائية لقاعدة البيانات المُدارة تُخزَّن بعيدًا عن خادم قاعدة البيانات، فلم يعد تلف القرص يأخذ النسخ الاحتياطية معه. أما ذروة الزيارات فتبقى مشكلة instance واحدة حتى تضيف CDN أو مزيدًا من الـ instances أو قطعًا من نوع serverless. وأخطاء كود Node.js تنتقل مع الكود. والتكاليف لا تنخفض إلا إذا راقبها أحد؛ فالسحابة تجعل الإنفاق الزائد أسهل، لا أصعب.
\n","checkLabels":{},"optionText":{"spike":{"text":"يسقط الموقع عندما تنتشر فعالية واحدة بشكل واسع.","why":"لم تُحَلّ. ما زال التطبيق يعمل على instance واحدة بحجم ثابت. تصلح هذا بالتخزين المؤقت عند الحافة، أو بسعة أكبر، أو بقطع serverless، وهو ما يبنيه القسم الرابع."},"disk":{"text":"رفع الملصقات يملأ قرص الخادم.","why":"حُلَّت. لا يوجد في Amazon S3 قرص يمتلئ؛ تدفع مقابل كل غيغابايت مخزّن بدلًا من حجز المساحة مسبقًا."},"backups":{"text":"النسخ الاحتياطية لقاعدة البيانات موجودة على القرص نفسه الذي عليه قاعدة البيانات.","why":"حُلَّت. النسخ الاحتياطية التلقائية لقاعدة البيانات المُدارة تُحفظ بمعزل عن الـ instance، فخسارة الخادم لا تعني خسارة النسخ الاحتياطية."},"bugs":{"text":"تسرّب في الذاكرة داخل تطبيق Node.js يستدعي إعادة تشغيله كل بضعة أيام.","why":"لم تُحَلّ. الكود الخاص بك ينتقل معك. قد تعيد السحابة تشغيل الأشياء تلقائيًا، لكن إصلاح التسرّب يبقى مسؤوليتك."},"costs":{"text":"لا أحد يعرف كم تكلّف الاستضافة كل شهر.","why":"الانتقال وحده لا يحلّها. فواتير AWS مفصّلة، لكنها لا تفيد إلا إذا ضبطت ميزانيات ونظرت فيها، وهو ما يضبطه الدرس الثالث."}}},"words":499,"readMinutes":3}