ruby on rails - لماذا يستخدم الأشخاص Heroku عندما يكون AWS موجودًا؟ ما الذي يميز Heroku من AWS؟




ruby-on-rails amazon-web-services (9)

أنا مبرمج RoR مبتدئ يخطط لنشر تطبيقي باستخدام Heroku. تقول كلمة من أصدقائي المستشارين الآخرين أن Heroku سهل جدًا وجيد الاستخدام. المشكلة الوحيدة هي أنه ليس لدي أي فكرة عما يفعله Heroku ...

لقد نظرت إلى موقعهم على website وباختصار ، ما يفعله Heroku هو المساعدة في التوسع ولكن ... لماذا يهم ذلك؟ كيف يساعد Heroku مع:

  1. السرعة - أشارت بحثي إلى أن نشر AWS على الساحل الشرقي للولايات المتحدة سيكون الأسرع إذا كنت أستهدف جمهورًا أمريكيًا / آسيا.

  2. الأمن - ما مدى أمانها؟

  3. التدريج - كيف يعمل بالفعل؟

  4. فعالية التكلفة - هناك شيء مثل الدينو يجعل من السهل توسيع نطاقه.

  5. كيف يتصرفون ضد منافسيهم؟ على سبيل المثال ، Engine Yard و bluebox ؟

الرجاء استخدام المصطلحات الانجليزية للشخص العادي لشرح ... أنا مبرمج المبتدئين.


AWS / Heroku على حد سواء مجانية لمشاريع هواية صغيرة (لتبدأ).

إذا كنت ترغب في بدء تطبيق على الفور ، دون الكثير من التخصيص للهندسة المعمارية ، ثم اختر Heroku .

إذا كنت ترغب في التركيز على البنية والقدرة على استخدام خوادم ويب مختلفة ، فاختر AWS . AWS هو أكثر استهلاكا للوقت بناء على الخدمة / المنتج الذي تختاره ، ولكن يمكن أن يكون يستحق ذلك. كما يأتي AWS مع العديد من الخدمات والمنتجات الإضافية.

Heroku

  • النظام الأساسي كخدمة (PAAS)
  • وثائق جيدة
  • لديها أدوات ومعمارية مدمجة.
  • تحكم محدود في الهندسة المعمارية أثناء تصميم التطبيق.
  • يتم الاهتمام بالنشر (من خلال أوامر git فقط).
  • لا تستغرق وقتا طويلا.

AWS

  • البنية التحتية كخدمة (IAAS)
  • متعددة الاستخدامات - لديها العديد من المنتجات مثل EC2 ، LAMBDA ، EMR ، إلخ.
  • يمكن استخدام مثيل مخصص لمزيد من التحكم في البنية ، مثل اختيار نظام التشغيل وإصدار البرنامج ، إلخ. هناك أكثر من طبقة خلفية واحدة.
  • Beanstalk مرنة هي ميزة مماثلة لهرم Heroku.
  • يمكنه استخدام النشر التلقائي ، أو يمكنك تشغيله بنفسك.

أول الأشياء أولا ، AWS و Heroku هي أشياء مختلفة. تقدم AWS البنية التحتية IaaS (IaaS) في حين يقدم Heroku منصة IaaS (PaaS).

ماهو الفرق؟ تقريبًا جدًا ، يمنحك IaaS المكونات التي تحتاج إليها لبناء أشياء فوقه ؛ يعطيك PaaS بيئة حيث يمكنك فقط دفع الكود وبعض التكوينات الأساسية والحصول على تطبيق قيد التشغيل. يمكن أن يمنحك IaaS المزيد من القوة والمرونة ، على حساب الاضطرار إلى بناء والحفاظ على المزيد من نفسك.

للحصول على شفرتك تعمل على AWS وتبحث قليلاً عن نشر Heroku ، ستحتاج إلى بعض حالات EC2 - سترغب في تحميل طبقة توازن / تحميل مؤقت مثبت عليها (مثل Varnish ) ، ستحتاج إلى تشغيل مثيلات مثل Passenger و nginx لخدمة الكود الخاص بك ، سترغب في نشر وتكوين نسخة قاعدة بيانات مجمعة لشيء مثل PostgreSQL . ستحتاج إلى نظام نشر يحتوي على شيء مثل Capistrano ، وشيء يفعل تجميع السجل.

هذا ليس كمية ضئيلة من العمل لإعداد وصيانة. مع Heroku ، فإن الجهد المطلوب للوصول إلى هذا النوع من المسرح ربما يكون بضعة أسطر من كود التطبيق و git push .

إذاً أنت بهذا الآن ، وترغب في الارتقاء. عظيم. أنت تستخدم Puppet في نشر EC2 ، أليس كذلك؟ حتى الآن قمت بتكوين ملفات Capistrano الخاص بك إلى الأعلى لأعلى / لأسفل مثيلات حسب الحاجة؛ يمكنك إعادة تحريك لعبة Puppet config الخاصة بك حتى يدرك الورنيش حالات مثيلات الويب وسيتجمع تلقائيًا بينها. أو كنت على heroku scale web:+5 .

نأمل أن يعطيك فكرة عن المقارنة بين الاثنين. الآن لمعالجة نقاطك المحددة:

سرعة

حاليا Heroku يعمل فقط على حالات AWS في us-east eu-west . بالنسبة لك ، يبدو هذا مثل ما تريد على أي حال. بالنسبة للآخرين ، فمن المحتمل أن يكون أكثر من النظر.

الأمان

لقد رأيت الكثير من خوادم الإنتاج التي يتم صيانتها داخليًا والتي تتخلف عن تحديثات الأمان ، أو بشكل عام ضعيفًا بشكل عام. مع Heroku ، لديك شخص آخر يدير هذا النوع من الأشياء ، وهو إما نعمة أو نقمة اعتمادا على كيفية النظر إليها!

عندما تقوم بالنشر ، فإنك تقوم بتسليم كودك بشكل مباشر إلى Heroku. قد يكون هذا مشكلة بالنسبة لك. يوضح مقالهم حول Dyno Isolation تفاصيل تقنيات عزلهم (يبدو كما لو أن هناك العديد من العمليات الديناميكية يتم تشغيلها على حالات EC2 الفردية). وقد عبّر العديد من الزملاء عن هذه التقنيات وعن قوة عزلتهم ؛ أنا للأسف ليس في موقف من المعرفة / الخبرة الكافية للتعليق ، ولكن عمليات نشر Heroku الحالية تعتبر "جيدة بما فيه الكفاية". قد تكون مشكلة بالنسبة لك ، أنا لا أعرف.

تدريج

لقد تطرقت إلى كيفية تنفيذ ذلك في مقارنة IaaS مقابل PaaS المذكورة أعلاه. يحتوي Procfile على Procfile ، والذي يحتوي على أسطر من النموذج dyno_type: command_to_run ، على سبيل المثال (cribbed from http://devcenter.heroku.com/articles/process-model ):

web:    bundle exec rails server
worker: bundle exec rake jobs:work

هذا ، مع:

heroku scale web:2 worker:10

سينتج عنك ديناميتين على web و 10 وحدات ديناميكية worker . لطيفة وبسيطة وسهلة. لاحظ أن web عبارة عن نوع دينو خاص ، يمكنه الوصول إلى العالم الخارجي ، ويكمن وراء جهاز تتبع حركة مرور الويب الجميل (ربما نوعًا ما من مجموعة الورنيش / nginx) التي ستوجه حركة المرور وفقًا لذلك. من المحتمل أن يتفاعل عمالك مع قائمة انتظار الرسائل لتوجيه مشابه ، سيحصلون منه على الموقع عبر عنوان URL في البيئة.

فعالية التكلفة

الكثير من الناس لديهم الكثير من الآراء المختلفة حول هذا الموضوع. يبلغ حاليًا 0.05 دولار في الساعة للساعة الواحدة ، مقارنةً بـ 0.025 دولار في الساعة لمثيل Micro AWS أو 0.09 دولار في الساعة لمثيل صغير من AWS.

تقول وثائق Dyno في Heroku أن لديك حوالي 512 ميغابايت من ذاكرة الوصول العشوائي ، لذا من غير المعقول على الأرجح أن ننظر إلى dyno على أنه مثل مثيل Micro EC2. هل يستحق مضاعفة الثمن؟ كم تقدر وقتك؟ إن مقدار الوقت والجهد المطلوبين للبناء على عرض IaaS للحصول على هذه المواصفة القياسية ليس بالتأكيد رخيصًا. لا أستطيع الإجابة عن هذا السؤال بالنسبة لك ، ولكن لا تقلل من شأن "التكاليف المخفية" للإعداد والصيانة.

(قليلا من جانبا ، ولكن إذا قمت بالاتصال heroku run bash من هنا ( heroku run bash ) ، فإن نظرة خاطفة تظهر 4 قلب في /proc/cpuinfo وذاكرة الوصول العشوائي 36GB - وهذا يقودني إلى الاعتقاد بأنني على " تقول المستندات الديناميكية لـ Heroku أن كل دينو يتلقى 512 ميغابايت من ذاكرة الوصول العشوائي ، لذا من المحتمل أن أشارك مع ما يصل إلى 71 وحدة ديناميكية أخرى (ليس لدي بيانات كافية حول تجانس حالات AWS في Heroku ، لذلك قد تختلف الأميال الخاص بك))

كيف يتصرفون ضد منافسيهم؟

هذا ، أخشى أنني لا أستطيع مساعدتك حقًا. المنافس الوحيد الذي سبق لي أن نظرت إليه هو Google App Engine - في الوقت الذي كنت أبحث فيه عن نشر تطبيقات Java ، وكان مقدار القيود على الأطر والتقنيات القابلة للاستخدام غير قابل للإفلاس بشكل لا يصدق. هذا أكثر من مجرد "شيء جافا" - يبدو أن مقدار القيود العامة والاعتبارات الضرورية (تلميحات الأسئلة الشائعة على عدة) أقل ملاءمة. في المقابل ، كان الانتشار في Heroku حلما.

استنتاج

آمل أن يجيب هذا عن أسئلتك (يرجى التعليق على ما إذا كانت هناك فجوات / مجالات أخرى ترغب في تناولها). أشعر أنني يجب أن أقدم موقفي الشخصي. أنا أحب Heroku "لعمليات النشر السريعة". عندما أقوم ببدء تطبيق ، وأريد بعض الاستضافة الرخيصة (طبقة Heroku المجانية رائعة - بشكل أساسي إذا كنت تحتاج فقط إلى dyno و 5MB من PostgreSQL ، فإنه مجاني لاستضافة تطبيق) ، Heroku هو موقع الانتقال . بالنسبة لـ "نشر الإنتاج الجاد" مع العديد من العملاء الذين يدفعون ، مع اتفاقية مستوى الخدمة ، مع تخصيص وقت للإنفاق على العمليات ، وما إلى ذلك ، لا أستطيع أن أحمل نفسي على تفريغ هذه السيطرة إلى Heroku ، ومن ثم إما AWS أو خوادمنا الخاصة كانت منصة الاستضافة المفضلة.

في النهاية ، الأمر يتعلق بما يناسبك. أنت تقول أنك "مبرمج مبتدئ" - قد يكون ذلك فقط باستخدام Heroku سيسمح لك بالتركيز على كتابة Ruby ، ​​ولن تضطر إلى قضاء بعض الوقت في الحصول على جميع البنية التحتية الأخرى حول التعليمة البرمجية الخاصة بك. كنت بالتأكيد محاولة إعطائها.

لاحظ أن AWS لديها بالفعل عرض PaaS ، Beanstalk Elastic ، الذي يدعم Ruby و Node.js و PHP و Python و .NET و Java. أعتقد بشكل عام أن معظم الناس ، عندما يرون "AWS" ، يقفزون إلى أشياء مثل EC2 و S3 و EBS ، والتي هي بالتأكيد عروض IaaS


تقدم خدمات Amazon Web Services (AWS) الكثير من الخدمات من IaaS إلى PaaS مع ضمان متانة 99.9999999٪ وتوفر البيانات والبنية التحتية. توفر AWS أتمتة البنية الأساسية إلى جانب العديد من الأدوات للمطورين لتوجيه عملية نشر التطبيقات الخاصة بهم.

من ناحية أخرى ، Heroku هو فقط PaaS الذي يقدم خدمات لإدارة النظام الأساسي الخاص بك على السحابة الخاصة بهم. لا يقف في أي مكان مع AWS سواء البنية التحتية أو الأمن.


حسنا .. ليس كل هذا وردية ..

بادئ ذي بدء: AWS ليست علم الصواريخ ، وإذا كنت تعرف طريقك حول نشر "الأشياء" في نهاية اليوم ، فمن الأفضل استخدام AWS ، وأرخص .. بدلا من أي PaaS الأخرى التي تميل إلى أن تكون دائما أكثر تكلفة في تبادل القيام "الأشياء" بالنسبة لك ... IMHO AWS أفضل بكثير ولديك الكثير من السيطرة الشاملة ،

خاصة الآن عندما يكون هناك مقياس صحيح ، bitnami ، الخ ... وكل تلك الصور التي تم إعدادها بواسطة EC2 للعديد من حزم البرامج المختلفة.


حسنا! أنا مراقب Heroku تشتهر في مطوري الناشئة والمولدين حديثا في حين AWS لديها شخصية متقدمة المطور. DigitalOcean هو أيضا لاعب رئيسي في هذه الأرض. جعلت Cloudways من السهل للغاية إنشاء كومة مصباح بنقرة واحدة على DigitalOcean و AWS. يعد إجراء جميع التحديثات المتعلقة بالخدمات والطرز بنقرة واحدة أفضل بكثير من إجراء كل شيء يدويًا.

يمكنك التحقق من هنا بالكامل: https://www.cloudways.com/blog/host-php-on-aws-cloud/


شيء مضحك هو Heroku يستخدم في الواقع AWS على الخلفية. فإنه يأخذ كل النفقات العامة وإدارة العمارة على EC2 بالنسبة لك. (حصلت على هذه المعرفة من مهندس كبير في شركة كبيرة خلال مقابلة)


كما قال كريستيان جلاس سعيد ، لا توجد مقارنة بين IaaS ( AWS ) و Heroku ( Heroku ، EngineYard ).

يساعد PaaS بشكل أساسي المطورين على تسريع تطوير التطبيق ، وبالتالي توفير المال وأهم من ذلك ، ابتكار تطبيقاتهم وأعمالهم بدلاً من إعداد التكوينات وإدارة الأشياء مثل الخوادم وقواعد البيانات. ميزات أخرى شراء لاستخدام PaaS هي عملية نشر التطبيق مثل خفة الحركة ، عالية الإتاحة ، المراقبة ، مقياس / Descale ، الحاجة المحدودة للخبرة ، النشر السهل ، والتكلفة المنخفضة ووقت التطوير.

ولكن لا يزال هناك جانب مظلم من PaaS الذي يؤدي إلى عرقلة تبني PaaS:

  • أقل السيطرة على الخادم وقواعد البيانات
  • ستكون التكاليف مرتفعة للغاية إذا لم يتم تنظيمها بشكل صحيح
  • من السابق لأوانه وشكوك في اليوم الحالي والعمر

بصرف النظر عن أعلى يجب أن يكون لديك مجموعة من المهارات الكافية لإدارة الجنة IaaS:

  • اكتساب الأجهزة
  • نظام التشغيل
  • برنامج الخادم
  • بيئة برمجة الخادم الجانبية
  • قاعدة بيانات للانترنت
  • نظام إدارة قواعد البيانات (Mysql ، Redis ، الخ)
  • تكوين خادم الإنتاج
  • أداة للاختبار والنشر
  • مراقبة التطبيق
  • توافر عالية
  • تحميل Blancing / المتشعب التوجيه
  • سياسات النسخ الاحتياطي للخدمة
  • فريق التعاون
  • إعادة بناء الإنتاج

إذا كان لديك نشاط تجاري صغير ، سيكون خيار PaaS الخيار الأفضل لك:

  • ادفع كما تذهب
  • انخفاض تكاليف البدء
  • ترك السباكة للخبير
  • يعالج PaaS القياس / إزالة الترقيم تلقائيًا ، وموازنة الأحمال ، واستعادة البيانات بعد الكوارث
  • يدير PaaS جميع متطلبات الأمان
  • يدير PaaS الموثوقية ، التوفر العالي
  • تدير Paas العديد من الإضافات الخاصة بطرف ثالث

سيكون اختيار فردي تمامًا بناءً على المتطلبات. يمكنك الحصول على تفاصيل حول تطبيقات PPT Hosting Rails الخاصة بي .



هناك الكثير من الطرق المختلفة للنظر إلى هذا القرار من أهداف التطوير وتكنولوجيا المعلومات والأعمال ، لذلك لا تشعر بالسوء إذا بدت ساحقة. ولكن أيضًا - لا تفرط في التوسع.

فكر في متطلباتك .

لقد قمت بتصميم مواقع الويب التي خدمت أكثر من 8 مليون قطعة في اليوم ، وقدمت تيرابايت من الفيديو أسبوعًا مبنيًا على بنية تحتية تبدأ من 250 ألف دولار في الأجهزة الرأسمالية unr من قِبل فريق عمل ضخم يبلغ تكلفته مليون دولار.

ولكن لدي أيضًا مواقع ويب أصغر حجمًا تم تصميمها لتوليد 10 إلى 20 ألف دولار سنويًا ، ولم يكن بها عدد كبير جدًا من الزيارات ، أو ديسيبل ، أو متطلبات المعالجة ، وقمت بتشغيل تلك الحسابات من حساب استضافة عام بقيمة 10 دولارات أمريكية دون التنازلات.

في المستقبل ، سيبدو النشر أكثر مثل Heroku من AWS ، فقط بسبب التقدم. هناك قيمة صفرية في تكنولوجيا المعلومات ، وهي تحريك البنية التحتية لتوسيع البنية التحتية للإنترنت والتي لا يمكن الاعتماد عليها بشكل آلي ، ولا شيء منها له علاقة بقيمة المنتج أو الخدمة التي تقدمها.

ضع في اعتبارك أيضًا موقعًا تجاريًا على الويب - القابلية للتوسعة هي ما نطلق عليه غالبًا "مشكلة جيدة" - على الرغم من أن مشكلات التدرجية مع مواقع مثل Facebook و Twitter كانت عالية المستوى ، إلا أنها لم تؤثر سلبًا على نجاحها - الأخبار ربما أسهمت في المزيد من الاشتراكات (كل الصحافة هي الصحافة الجيدة).

إذا كان لديك خدمة تقوم بتوليد 100k + uniques في اليوم وتواجه مشاكل في القياس ، فسأكون سعيدًا لإخراجها عنك بغض النظر عن اللغة ، أو db ، أو النظام الأساسي ، أو البنية التحتية التي تعمل عليها!

القابلية للتطوير هي مشكلة قابلة للتنفيذ قابلة للتنفيذ - عدم وجود عملاء يمثل مشكلة وجودية.





amazon-web-services