فيديو: بنتنا يا بنتنا (سبتمبر 2024)
وتناثر المشهد البرمجيات المؤسسة مع التقنيات الصاخبة. لقد كتبنا عن الكثير منها ، سواء كان ذلك بلوكشين ، أو تطوير كود منخفض ، أو اتجاهات ناشئة أخرى تغير طريقة عملنا. إحدى الكلمات الطنانة الجديدة التي ربما لم تسمع بها من قبل هي "الخدمات المصغرة".
هذا حسب التصميم. Microservices هي طريقة مختلفة لبرامج المهندسين على أساس مجموعة من المكونات المعيارية المتشابكة بدلاً من الفكرة التقليدية المتمثلة في "متراصة" - تطبيق يتكون من جبل واحد من الكود المتزايد باستمرار. لا تبدو التطبيقات المستندة إلى Microservices مختلفة عن جانب واجهة المستخدم (UI) ، سواء كان ذلك في تطبيق مركز بيانات معقد أو تطبيق ويب أو تطبيق جوال مستضاف على بنية تحتية سحابية قابلة للتطوير.
السبب الذي يجعل الشركات تهتم بالخدمات المصغرة هو أن البنية التحتية ، خلف الكواليس ، يمكن أن تساعد فرق التطوير وتكنولوجيا المعلومات لديك على العمل والابتكار بشكل أسرع وإدارة البنية التحتية وتقليل التكلفة والتعقيد المتمثل في إضافة ميزات ووظائف جديدة إلى التطبيق. أوضح الحلوة ، مدير برنامج أبحاث تطوير التطبيقات في مركز البيانات الدولي ، كيف سيقدم خدمات ميكروية لإحدى التنفيذيين مع مراعاة التحديات الثقافية والتقنية.
وقال حلوة: "عند بناء أنظمة جديدة ، ربما تكون النقطة الأساسية هي إدراك أنه ينبغي إنشاء خدمة مجهرية واحدة بواسطة فريق صغير". "ثانياً ، غالبًا ما يكون التسامح مع التنوع في لغات البرمجة وسير عمل المطورين ضمنيًا بسبب الطبيعة المستقلة لثقافة الخدمات الجزئية الشاملة. يتمثل الهدف الرئيسي لأي شركة تنفيذية في إنشاء برنامج تدريجيًا باستخدام فرق صغيرة ، مع بناء كل وحدة نمطية متماسكة مع منشور الميزة هي أن الوحدات المستقلة يمكن تطويرها بوتيرة أسرع بكثير بشكل مستقل طالما يتم إدارة واجهات برمجة التطبيقات المنشورة بطريقة منظمة."
ما هي Microservices ، حقا؟
قامت حلوة بتأليف تقرير IDC لعام 2015 بعنوان "ظهور خدمات Microservices كنهج معماري جديد لبناء أنظمة برمجيات جديدة". في التقرير ، يعرّف خدمات microservices بأنها بنية برامج محببة حيث يتم تصميم مكونات التطبيق وتطويرها بشكل مستقل لتلبية متطلبات التشغيل المتداخل المعرفة من قبل API (بمعنى ، يتم ربطها مرة أخرى بالتطبيق ككل). لا توجد خدمات Microservices في فراغ. تتطلب البنية الجديدة دعمًا تنظيميًا قويًا وتحولًا في ثقافة تقنية المعلومات.
لا يتم تعريف Microservices أيضًا بواسطة أي تقنية محددة ، ولكن كتطور المفهوم القديم للهندسة الموجهة للخدمة (SOA) الذي يعززه ظهور الحاويات وصعود الأتمتة من خلال مناهج التطوير مثل التسليم المستمر (CD) والتكامل المستمر (CI).
وقالت حلوة: "إن المنظمات التي تستخدم الخدمات الدقيقة اليوم تحركها عادة الرغبة في تسريع وتيرة تطور الخدمة". "وهكذا ، في معظم هذه الحالات ، تستخدم الخدمات المصغرة الأتمتة CI / CD إلى حد كبير. ومع ذلك ، قد تختلف وتيرة النشر الفعلي بين الخدمات. أعتقد أن المفتاح هو إلقاء نظرة جيدة على الثقافة الداخلية وتكون تأكد من أنك على استعداد لتحمل قدر أكبر من اللامركزية والتنوع في كومة التكنولوجيا."
يشير مصطلح "حلوة" إلى حد بعيد إلى "DevOps" ، وهي عبارة عن فلسفة تجمع بين تطوير البرمجيات وعمليات تكنولوجيا المعلومات وضمان الجودة (QA) في سير عمل واحد تعاوني. لطالما كانت HashiCorp وبدء مؤسسيها في برمجيات DevOps من المؤيدين للخدمات الميكروية. الشركة ، التي حصلت مؤخرًا على تمويل بقيمة 24 مليون دولار من السلسلة B ، تحسب شركات مثل Cisco و DigitalOcean و Mozilla و Stripe بين مستخدميها من المصادر المفتوحة والعملاء من المؤسسات.
تعد Microservices أساسية لكيفية تقارب HashiCorp مع تطوير DevOps للبنية التحتية وسير عمل التطبيق عبر أدواتها المفتوحة المصدر الشهيرة ومجموعة منتجات المؤسسة المتنامية. قام Armon Dadgar ، CTO والمؤسس المشارك لـ HashiCorp ، بتفكيك الفرق بين الخدمات المتجانسة والخدمات المصغرة باستخدام تشبيه بسيط: Amazon و eBay.
وقال دادجار: "فكر في Amazon و eBay كتطبيقات فردية. من منظور المستخدم النهائي ، يبدوان متشابهين ، لكن وراء الكواليس ، اتخذت الشركات مقاربات معاكسة في كيفية بناء تطبيقاتها وأرشفتها". "كانت Amazon من البداية عبارة عن حزمة من الخدمات المصغرة ؛ إنها بمثابة تطبيق واحد. ولكن إذا أجريت البحث ، وكتالوج المنتجات ، وعربة التسوق ، والفواتير ، وتدفقات الطلبات ، وتقسيم تلك الوظائف ، فإن التطبيقين يعملان على مختلف آلات ".
يمتد قياس الأمازون أيضًا إلى كيفية تنظيم أمازون نفسها. يشرح Dadgar الأساليب التكنولوجية مثل الخدمات الصغيرة كأدوات لدعم حركة العملية الأكبر نحو DevOps. يعمل جيف بيزوس في كتابه "Two Pizza Rule" على أن يكون هناك ما بين خمسة وثمانية أشخاص فقط في أي فريق من الأمازون. إذا كان الفريق أكبر ، فإنه ينقسم إلى قسمين.
يبدأ التسلسل الهرمي التنظيمي لـ Amazon في رسم الخرائط نحو ما وصفه Dadgar بأنه "تحلل للوظائف". منفصلًا عن كل من المستوى التنظيمي والمستوى المعياري للهندسة المعمارية ، يتمتع كل فريق بعد ذلك بالقدرة على التطوير والتجربة بحرية أكبر ، دون الحاجة إلى التنسيق في كل تغيير - كل الوقت ما زال يعمل كجزء من تطبيق واحد متماسك.
وقال دادجار: "لقد اتخذ eBay المقاربة المتجانسة ؛ لقد بنوا جميع eBay كتطبيق طويل مكون من 50 مليون سطر من الكود". "نهج الخدمات الميكروية هو أكثر إيلامًا في البداية لأن مشاكل النموذجية وقابلية التشغيل البيني هي مشاكل لا وجود لها في مجموعة متجانسة. لكن الأشياء تبدأ في الانهيار عندما يكبر التطبيق بشكل كبير. في متراصة ، لا يوجد أي تحلل.
"فكر في مئات أو الآلاف من المطورين الذين يتعاونون في قاعدة بيانات واحدة ويحاولون التنسيق. فريق ضمان الجودة الذي يضيف وظيفة على جانب واحد من التطبيق يمكن أن يكسر شيئًا ما على الجانب الآخر لأنه لا يوجد فصل واضح بين الأدوار والمسؤوليات. إنها تحتاج إلى المزيد والمزيد من التنسيق بين مديري المشروع وعملية ضمان الجودة التي قد تستغرق أسابيع وتطور عنق الزجاجة ، بغض النظر عن مدى سرعة عمل هذا الفريق. إنه عدد كبير جدًا من الطهاة في المطبخ."
الحاويات و Microservices في عالم DevOps
الطريقة التي ينفذ بها عملك بنية خدمات microservices سوف تقطع شوطًا طويلًا في تحديد ما إذا كان الاستثمار سيؤتي ثماره أم لا. خدمات Microservices كثيرًا من العمل ، خاصة في تكامل واجهة برمجة التطبيقات (API) الذي يتطلبه الأمر للتأكد من أن جميع الخدمات تتحدث مع بعضها البعض. أوضح حلوة أن الأمر أكثر تعقيدًا عند محاولة دمج الخدمات المصغرة في نظام قائم ؛ يوصي بأن تقوم المؤسسات ببناء أنظمة جديدة كلما كان ذلك ممكنًا بدلاً من إعادة تصميم تطبيق قديم مترابط للخدمات الصغيرة.
وقال حلوة: "عادة ما تنطوي أنظمة النظم التقليدية على أنظمة قاعدة بيانات كبيرة ومعقدة من السجلات ذات مخططات طبيعية معقدة". "إن تخصيص مثل هذه الأنظمة إلى مكونات أصغر مع أنظمتها المستقلة يتطلب الكثير من أعمال تصميم قواعد البيانات وإعادة كتابة معظم منطق التطبيق الأساسي بفعالية. وهذا عمومًا باهظ التكلفة والوقت في معظم الحالات."
إذا قمت بإعادة تصميم تطبيق قديم ، فإن حلوة تنصحك بذلك بشكل تدريجي. على الرغم من أنها أكثر أهمية من تكامل واجهة برمجة التطبيقات ، لا تعمل الخدمات المصغرة بدون ثقافة DevOps التي تقوم عليها. قال Dadgar من HashiCorp ، عندما يتعلق الأمر بالمظلة الأكبر لـ DevOps ، تصبح الخدمات الصغيرة أداة لتسهيل تحول عملية أكبر نحو تغيير مهام سير العمل بشكل أساسي من خلال تقديم التطبيقات. وأشار إلى Tao of HashiCorp عندما وضع هو والمؤسس المشارك ميتشل هاشيموتو الشركة: بسيطة ، وحدات ، وقابلة للتكوين.
وقال دادجار "DevOps من بعض النواحي هو مصطلح أكثر من طاقته أكثر من الخدمات الصغيرة". "لكن العمل يتكون من أشخاص ذوي تخصصات مختلفة من المعرفة: المطورين والمشغلين وضباط الأمن. ثم لديك العملية ، الطريقة التي تنظم بها هؤلاء الأشخاص. ثم لديك الأدوات لدعم تلك العملية ، حيث توجد خدمات ميكروية وحاويات ادخل."
إن الحاويات ، التي شاعها انفجار دوكر المفتوح المصدر ، بعيدة كل البعد عن كونها الأداة الوحيدة التي يمكن أن تستخدمها الشركات لتسهيل الخدمات المصغرة. قال حلوة من IDC إن الحاويات تستخدم في التطبيقات الحديثة كجزء من سير عمل CI / CD ، وفي بعض الحالات ، أثناء النشر للإنتاج. لكنه قال إن الخدمات الصغيرة يمكنها الاستفادة من الأجهزة الافتراضية (VMs) أيضًا ، دون الحاجة إلى حاويات.
ومع ذلك ، عندما يتعلق الأمر بالطرق التي تتطور بها سحب الأعمال ، فإن حاويات Docker والخدمات المصغرة هي مزيج قوي من الأدوات التي تتبناها الشركات من جميع الأشكال والأحجام - من الشركات الناشئة مثل HashiCorp إلى الشركات العملاقة مثل Oracle. قال Dashgar من HashiCorp إن الحاويات هي الوسيلة المناسبة التي تتواصل من خلالها Dev and Ops (وبالتعاون مع الفرق والخدمات المختلفة) مع بعضها البعض.
وقال دادجار "ما هي القطع الأثرية التي نمرها بين المطورين والمشغلين؟ ما الذي نتدفقه بشكل دقيق ونبني عليه؟ الحاويات هي وحدة ملائمة للتجول فيها". "فكر في منتج شحن عالمي للمؤسسة في جميع أنحاء العالم. سواء كانت سفينة شحن أو قطار شحن أو شاحنة ، فهي نفس الوحدة التي تتدفق عبر النظام بالكامل."
لا تزال خدمات DevOps و microservices بعيدة عن اعتماد المؤسسات على نطاق واسع ، لكن السوق ينمو فقط. وفقًا لتقرير IDC ، ستدخل هندسة الخدمات المصغرة في مرحلة النضج على مدار السنوات الخمس القادمة. سيحدث هذا النضج في أعقاب وصول ثقافة DevOps إلى 50 بالمائة من المؤسسات بحلول عام 2020 ، والتطور المستمر لأدوات أتمتة البرامج ، والسيطرة على البنية التحتية السحابية الرخيصة والقابلة للتطوير التي توفرها أمثال Amazon Web Services (AWS) و Microsoft Azure.
وقال دادجار إنه حتى مع وجود جزء صغير من الشركات التي تتبنى DevOps والخدمات المصغرة في الوقت الحالي ، فإن HashiCorp تم بالفعل زيادة الاكتتاب فيها بشكل كبير. حقق أول إيرادات من سبعة أرقام بعد تسعة أشهر فقط من مبيعات المؤسسات ، بالإضافة إلى مجتمع مفتوح المصدر على GitHub يضم عدة ملايين من المستخدمين النشطين شهريًا. لا تمثل Microservices سوى جزءًا من خط أنابيب أدوات تطبيق تدفق العمل في HashiCorp وخريطة طريق DevOps أكبر للبنية التحتية. لكن النظامية وقابلية التشغيل البيني تحت كل شيء تبنيه الشركة قد غذت صعودًا نيزكًا لواحدة من أكثر الشركات الناشئة برمجيات في وادي السيليكون.
وقال دادجار: "منذ أربعة أعوام عندما بدأنا ، كنا نذهب إلى الاجتماعات ونضع رؤيتنا حول كيفية إدارة البنية التحتية". "لم نكن نضحك تمامًا من الغرفة ؛ فقد علمنا أن الأمر بدأ مبكرًا. لكن أدواتنا مثل Terraform في طريقها الآن لتصبح معايير للصناعة. ما سنراه هو تأثير الدومينو للضغط التنافسي وفي على المدى الطويل ، سيكون دورنا العمل مع مدراء تقنية المعلومات والمديرين التنفيذيين لفهم تحول العملية الذي يحتاجون إليه.
"فكر في تويوتا مرة أخرى في اليوم ،" واصل دادجار. "كان لديك مجموعة من شركات صناعة السيارات ، لكن التكلفة كانت أعلى مما ينبغي. لم تقم شركة تويوتا بإعادة اختراع ما كانت عليه السيارة ؛ لقد كانت أكثر صرامة وتدريجية في هذه العملية ، وانتقلت من الضحك إلى القوة ، مما أجبر تبني بقية الصناعة نفس مجموعة الممارسات لتظل قادرة على المنافسة ، في الوقت الحالي ، لدينا قادة صناعيون يسألون كيف يمكنهم الحصول على ميزة تنافسية ، وإجابتهم هي تبني ممارسات Google و Amazons في السوق. نقطة ، وسوف تصل إلى كتلة حرجة ".
