في 25 أبريل ، عقدنا في Mail.ru Group مؤتمرا حول السحب وحولها -
mailto: CLOUD . بعض النقاط البارزة:
- اجتمع المزوّدون الروس الرئيسيون على مرحلة واحدة - Mail.ru Cloud Solutions و #CloudMTS و SberCloud و Selectel و Rostelecom Data Center و Yandex.Cloud تحدثوا عن تفاصيل سوقنا السحابية وخدماتها ؛
- أخبر الزملاء من Bitrix24 كيف وصلوا إلى أصوات متعددة .
- قدمت Leroy Merlin و Otkrytie و Burger King و Schneider Electric رؤية مثيرة للاهتمام من جانب المستهلكين السحابيين - ما هي المهام التي تحددها مجموعات أعمالهم لتكنولوجيا المعلومات والتكنولوجيات ، بما في ذلك التقنيات السحابية ، التي يعتبرونها الأكثر وعدًا.
جميع مقاطع الفيديو من mailto: يمكن الاطلاع على مؤتمر CLOUD
هنا ، ولكن هنا يمكنك قراءة كيفية سير المناقشة حول الخدمات الصغيرة. تبادل ألكساندر ديولين ، رئيس مركز أبحاث وتطوير أنظمة MegaFon للأعمال ، وسيرجي سيرغييف ، مدير تكنولوجيا المعلومات في مجموعة إم. إم. فيديو إلدورادو ، حالاتهما الناجحة للتخلص من المتجانسات. كما ناقشوا القضايا المتعلقة باستراتيجية تكنولوجيا المعلومات والعمليات وحتى الموارد البشرية.
المتحدثون
- سيرجي سيرجيف ، مدير تقنية المعلومات في مجموعة M.Video-Eldorado ؛
- ألكساندر ديولين ، رئيس مركز أبحاث وتطوير أنظمة MegaFon التجارية ؛
- رئيس الجلسة - ديمتري لازارينكو ، رئيس حلول PaaS -direction Mail.ru Cloud Solutions .
بعد خطاب ألقاه ألكساندر ديولين
"كيف توسع MegaFon
أعمالها من خلال منصة Microservice" ، ينضم إليها سيرجي سيرجيف من M.Video-Eldorado للمناقشة ومدير المناقشة Dmitry Lazarenko ، Mail.ru Cloud Solutions.
أدناه قمنا بإعداد نسخة من المناقشة لك ، ولكن يمكنك أيضًا مشاهدة الفيديو:
التحول إلى خدمات microservices - استجابة لاحتياجات السوق
ديمتري:هل كان لديك أي تجربة ناجحة في التحول إلى خدمات microservices؟ وبوجه عام: أين ترى أكبر فائدة في الأعمال التجارية من استخدام الخدمات المصغرة أو الانتقال من الخدمات المتجانسة إلى الخدمات الصغيرة؟
سيرجي:لقد وصلنا بالفعل إلى حد ما للانتقال إلى خدمات micros وقد استخدمنا هذا النهج لأكثر من ثلاث سنوات. كانت الحاجة الأولى التي بررت الحاجة إلى الخدمات المصغرة هي التكامل اللامتناهي لمختلف منتجات الخطوط الأمامية مع المكتب الخلفي. وفي كل مرة كان علينا القيام بتكامل إضافي وتطوير وتنفيذ قواعدنا لتشغيل الخدمة.
في مرحلة ما ، أدركنا أننا نحتاج إلى تسريع أنظمتنا ووظائف المخرجات. في تلك اللحظة ، كانت هناك بالفعل مفاهيم مثل: خدمات microservices ، ونهج microservice في السوق ، وقررنا تجربتها. بدأت في عام 2016. ثم تم وضع المنصة وتنفيذ أول 10 خدمات من قبل فريق منفصل.
كانت إحدى الخدمات الأولى ، الأكثر تحميلًا ، خدمة حساب الأسعار. في كل مرة تأتي إلى أي قناة ، إلى مجموعة شركات M.Video-Eldorado ، سواء كان موقعًا إلكترونيًا أو متجرًا للبيع بالتجزئة ، يمكنك التقاط البضائع هناك ، أو الاطلاع على السعر على الموقع الإلكتروني أو في "السلة" ، تقوم خدمة واحدة تلقائيًا بحساب السعر. لماذا هناك حاجة لذلك: قبل ذلك ، كان لكل نظام مبادئه الخاصة بالعمل مع الخصومات الترويجية وما إلى ذلك. يتمثل المكتب الخلفي في التسعير ، ويتم تنفيذ وظيفة الخصم في نظام آخر. كان من الضروري مركزية وإنشاء مثل هذه الخدمة الفريدة القابلة للانفصال في شكل عملية تجارية تسمح لنا بتنفيذ ذلك. هكذا بدأنا.
كانت قيمة النتائج الأولى كبيرة جدا. أولاً ، تمكنا من إنشاء كيانات قابلة للفصل تتيح لنا العمل بشكل منفصل ومجمع. ثانياً ، قمنا بتقليل تكلفة الملكية من حيث التكامل مع عدد كبير من الأنظمة.
خلال السنوات الثلاث الماضية ، أضفنا ثلاثة أنظمة للخطوط الأمامية. كان من الصعب الاحتفاظ بها بنفس القدر من الموارد التي تستطيع الشركة تحملها. لذلك ، نشأت المهمة عن البحث عن مخارج جديدة ، والاستجابة للسوق من حيث السرعة ، من حيث التكاليف الداخلية والكفاءة.
كيفية تقييم نجاح الانتقال إلى خدمات microservices
ديمتري:كيف يتم النجاح في التحول إلى الخدمات المصغرة؟ ما هو "قبل" في كل شركة؟ ما المقياس الذي استخدمته لتحديد نجاح الانتقال ، من الذي حدده بالفعل؟
سيرجي:بادئ ذي بدء ، وُلد داخل تكنولوجيا المعلومات كعامل تمكين - "فتح" ميزات جديدة. كان علينا أن نفعل كل شيء بشكل أسرع مقابل نفس المال نسبيا ، استجابة لتحديات السوق. الآن ، يتم التعبير عن النجاح في عدد الخدمات التي تستخدمها أنظمة مختلفة ، وتوحيد العمليات فيما بينها. الآن كان الأمر كذلك ، وفي تلك اللحظة كانت فرصة لإنشاء منصة وتأكيد الفرضية القائلة بأنه يمكننا القيام بذلك ، وهذا سيعطي تأثير وحساب حالة العمل.
الكسندر:النجاح هو بالأحرى إحساس داخلي. الأعمال دائمًا ما تريد أكثر ، وعمق تراكمنا هو تأكيد النجاح. أعتقد ذلك.
سيرجي:نعم اوافق لمدة ثلاث سنوات لدينا بالفعل أكثر من مائتي خدمات وتراكم. ينمو الطلب على الموارد داخل الفريق فقط - سنويًا بنسبة 30٪. هذا لأن الناس شعروا: إنه أسرع ، بشكل مختلف ، التقنيات الأخرى ، كل هذا يتطور.
سوف تأتي Microservices ، ولكن سيبقى الأساسية
ديمتري:هذا يشبه عملية لا نهاية لها حيث تستثمر في التنمية. هل انتهى بالفعل الانتقال إلى الخدمات المصغرة للأعمال نفسها أم لا؟
سيرجي:من السهل جدا للرد. ما رأيك: استبدال الهواتف عملية لا نهاية لها؟ نحن أنفسنا نشتري الهواتف كل عام. وهنا هو: في حين أن هناك حاجة للسرعة ، في التكيف مع السوق ، ستكون هناك حاجة لبعض التغييرات. هذا لا يعني أننا نرفض الأشياء القياسية.
لكن لا يمكننا أن نعتنق ونعيد كل شيء على الفور. لدينا خدمات تكامل معيارية قديمة كانت قبل ذلك: حافلات الشركات وما إلى ذلك. ولكن هناك تراكم ، وهناك حاجة أيضا. يتزايد عدد تطبيقات الهاتف المحمول ووظائفها. في الوقت نفسه ، لا يقول أحد أنهم سوف يمنحك 30٪ من المال. وهذا هو ، هناك دائما احتياجات من ناحية ، ومن ناحية أخرى ، البحث عن الكفاءة.
ديمتري:الحياة في حالة جيدة.
(يضحك)الكسندر:بشكل عام ، نعم. ليس لدينا طرق ثورية لإزالة الأجزاء الأساسية من المشهد الطبيعي. يجري العمل المنهجي لتحليل الأنظمة بحيث تكون أكثر اتساقًا مع بنية الخدمات الميكروية ، لتقليل تأثير الأنظمة على بعضها البعض.
لكننا نخطط للحفاظ على الجزء الأساسي ، كما هو الحال في المشهد للمشغل سيكون هناك دائما بعض المنصات التي نشتريها. مرة أخرى ، تحتاج إلى توازن صحي: يجب ألا نتسرع في قلب "القطع". لقد وضعنا الأنظمة جنبًا إلى جنب ، والآن ، اتضح أن ذلك بالفعل عبر العديد من الأجزاء الأساسية. علاوة على ذلك ، عند تطوير الوظيفة ، نقوم بعمل التمثيلات اللازمة لجميع القنوات التي تعمل مع خدمات الاتصال الخاصة بنا.
كيفية بيع خدمات microservices لرجال الأعمال
ديمتري:ما زلت مهتمًا - بالنسبة لأولئك الذين لم يتحولوا ، لكنهم سيقومون بما يلي: ما مدى سهولة بيع هذه الفكرة إلى الأعمال وهل كان مقامرة ، أو مشروع استثمار؟ أو كانت استراتيجية متعمدة: الآن نذهب إلى الخدمات الصغيرة وهذا كل شيء ، لن يمنعنا شيء. كيف كان معك؟
سيرجي:نحن لم نبيع النهج ، ولكن الربح التجاري. كانت هناك مشكلة في العمل ، وحاولنا إزالته. في تلك اللحظة ، تم التعبير عن حقيقة أنه في قنوات مختلفة ، تم استخدام مبادئ تسعير مختلفة - بشكل منفصل للترقيات ، للأسهم وما إلى ذلك. كان من الصعب الحفاظ عليها ، نشأت أخطاء ، استمعنا إلى شكاوى العملاء. هذا هو ، لقد بعنا التخلص من المشكلة ، ولكن جاء مع حقيقة أننا بحاجة إلى المال لإنشاء منصة. وأظهروا حالة عمل على سبيل المثال من المرحلة الأولى من الاستثمار: كيف سنستمر في دفع ثمنها وماذا سيسمح لنا القيام به.
ديمتري:هل حددت بطريقة ما وقت المرحلة الأولى؟
سيرجي:نعم بالطبع. لقد استغرقنا 6 أشهر لإنشاء أساس كمنصة واختبار تجريبي. خلال هذا الوقت ، حاولنا إنشاء منصة كان عليها الطيار. وأكدوا كذلك الفرضية ، وحيث إنها تعمل ، يمكننا الاستمرار. بدأوا في تكرار وتعزيز الفريق - لقد أحضروه إلى وحدة منفصلة ، تعمل فقط في هذا.
التالي هو العمل المنهجي الناتج عن احتياجات العمل والفرص وتوافر الموارد وكل ما هو في العمل الآن.
ديمتري:حسنا. ألكساندر ، ماذا تقول؟
الكسندر:وُلدت خدماتنا المصغرة من "رغوة البحر" - بسبب توفير الموارد ، بسبب بعض الأرصدة في شكل قدرات الخادم وإعادة توزيع القوات داخل الفريق. في البداية ، لم نبيع هذا المشروع للأعمال. كان مشروعا حيث قمنا بالبحث والتطوير على حد سواء. بدأنا في بداية عام 2018 وقمنا بتطوير هذا الاتجاه بحماس. بدأت المبيعات للتو ، ونحن في هذه العملية.
ديمتري:ولكن يحدث أن يسمح لك النشاط التجاري بعمل مثل هذه الأشياء وفقًا لمبدأ Google - في يوم واحد مجاني في الأسبوع؟ هل لديك مثل هذا الاتجاه؟
الكسندر:في نفس الوقت الذي بحثنا فيه ، شاركنا في مهام العمل ، لأن جميع خدماتنا المصغرة هي حلول لمشاكل العمل. في البداية فقط ، قمنا ببناء خدمات ميكروية تغطي جزءًا صغيرًا من قاعدة المشتركين ، والآن نحن في جميع المنتجات الرئيسية تقريبًا.
والأثر المادي واضح بالفعل - يمكن بالفعل حسابنا ، يمكننا تقدير سرعة إنتاج المنتج والإيرادات المفقودة إذا أردنا السير في الطريق القديم. هذا هو المكان الذي نبني فيه القضية.
Microservices: الضجيج أو الحاجة؟
ديمتري:الأرقام هي أرقام. والإيرادات أو الأموال التي تم توفيرها مهمة للغاية. وإذا نظرتم إلى الجانب الآخر؟ يبدو أن microservices هي الاتجاه ، الضجيج والعديد من الشركات يسيئون استخدامه؟ ما مدى وضوح التمييز بين ما تقوم بترجمته وعدم ترجمته إلى خدمات ميكروية؟ إذا كان الإرث الآن ، هل ستظل لديك إرث في 5 سنوات؟ ماذا سيكون عصر أنظمة المعلومات التي تعمل في M. Video-Eldorado و MegaFon في 5 سنوات؟ هل سيكون هناك نظم معلومات مدتها عشر سنوات أو خمس عشرة سنة أم ستكون جيلًا جديدًا؟ كيف ترى ذلك؟
سيرجي:يبدو لي أنه يصعب القيام به بعيدًا جدًا. إذا نظرت إلى الوراء ، من الذي اقترح أن هذا من شأنه أن يطور سوق التكنولوجيا وتعلم الآلة نفسه ، وتحديد المستخدم وجهًا؟ لكن إذا نظرت في السنوات القادمة ، يبدو لي أن الأنظمة الأساسية ، وأنظمة المؤسسات لفئة تخطيط موارد المؤسسات في الشركات - كانت تعمل لفترة طويلة.
تعمل شركاتنا معًا منذ 25 عامًا ، حيث يوجد ERP الكلاسيكي في عمق النظام. من الواضح أننا نخرج بعض القطع من هناك ونحاول أن نجمعها في خدمات ميكروية ، لكن جوهرها سيبقى. من الصعب بالنسبة لي الآن أن أتخيل أننا سوف نستبدل جميع الأنظمة الأساسية هناك وسنعبر بسرعة إلى الجانب الآخر الأكثر إشراقًا من الأنظمة الجديدة.
أنا مؤيد لأن كل شيء أقرب إلى العميل والمستهلك ، حيث توجد أكبر مزايا وقيمة العمل ، حيث القدرة على التكيف والتركيز على السرعة ، على التغييرات ، على "محاولة ، إلغاء ، إعادة استخدام ، القيام بشيء آخر "- هناك المشهد سوف يتغير. ومنتجات الصناديق ليست مبنية بشكل جيد هناك. على الأقل نحن لا نرى هذا. إنها تتطلب أكثر الحلول بسيطة وخفيفة الوزن.
نرى مثل هذا التطور:
- نظم المعلومات الأساسية (معظمها المكتب الخلفي) ؛
- تقوم الطبقات الوسطى في شكل خدمات ميكروية بتوصيل النواة ، التجميع ، إنشاء ذاكرة تخزين مؤقت وما إلى ذلك ؛
- تهدف أنظمة الخطوط الأمامية إلى المستهلك ؛
- طبقة التكامل ، والتي يتم دمجها بشكل عام في الأسواق والأنظمة والنظم الإيكولوجية الأخرى. هذه الطبقة خفيفة قدر الإمكان ، بسيطة ، مع الحد الأدنى من منطق العمل فيها.
لكن في الوقت نفسه ، أنا مؤيد لمواصلة استخدام المبادئ القديمة ، إذا كانت معتادة على المكان.
دعنا نقول أن لديك نظام المؤسسات الكلاسيكية. يقع في منظر طبيعي لأحد البائعين ، ويتكون من وحدتين تعملان مع بعضهما البعض. هناك أيضا واجهة التكامل القياسية. لماذا إعادته وجلب microservice هناك؟
ولكن عندما يكون هناك 5 وحدات في المكتب الخلفي ، والتي يتم من خلالها تجميع أجزاء من المعلومات في عملية الأعمال ، والتي يتم استخدامها بعد ذلك من قبل 8-10 أنظمة للواجهة الأمامية ، تكون الفوائد ملحوظة على الفور. أنت تستخرج من أنظمة المكاتب الخلفية الخمسة ، تنشئ خدمة ، علاوة على ذلك ، معزولة ، والتي تركز على العملية التجارية. أنت تجعل خدمة تقنية - بحيث تخزن المعلومات وتتحمل الأخطاء ، وتعمل أيضًا مع المستندات أو كيانات الأعمال. ودمجها على مبدأ واحد مع جميع منتجات الخطوط الأمامية. لقد ألغوا المنتج في الخطوط الأمامية - لقد أوقفوا التكامل. غدًا تحتاج إلى كتابة تطبيق محمول أو إنشاء موقع صغير وجزء واحد فقط للهبوط في الوظيفة - إنه أمر بسيط: يمكنك وضعه معًا كمنشئ. أرى التطور في هذا الاتجاه أكثر - على الأقل في بلدنا.
الكسندر:وصف سيرجي تماما نهجنا ، شكرا. سأقول فقط أين سنذهب بالتأكيد - إلى الجزء الأساسي ، إلى موضوع الشحن عبر الإنترنت. وهذا يعني أن التصنيف والتحصيل سيبقيان في الواقع دراسًا "دراسيًا" سوف يشطب الأموال بطريقة موثوقة. وسيستمر اعتماد هذا النظام من قبل سلطاتنا التنظيمية. كل شيء آخر يتطلع إلى العملاء ، بالطبع ، هو خدمات ميكروية.
ديمتري:هنا شهادة ليست سوى قصة واحدة. ربما المزيد من الدعم. إذا كنت تنفق قليلاً على الدعم أو لا يحتاج النظام إلى الدعم والتحسين ، فمن الأفضل عدم لمسه. حل وسط معقول.
كيفية تطوير خدمات micros موثوقة
ديمتري:حسنا. لكن ما زلت مهتمة. أنت الآن تروي قصة نجاح: كل شيء على ما يرام ، لقد تحولنا إلى الخدمات الصغيرة ، ودافعنا عن الفكرة أمام العمل ، وكل شيء تم تنفيذه. لكنني سمعت قصص أخرى.
قبل عامين ، قامت شركة سويسرية ، استثمرت عامين في تطوير منصة جديدة لخدمات الميكروسكوب للبنوك ، بإغلاق هذا المشروع في النهاية. مطوية تماما. لقد تم إنفاق ملايين الفرنكات السويسرية ، لكن في النهاية قاموا بتفريق الفريق - لم يحدث ذلك.
هل كان لديك قصص مماثلة؟ هل كانت هناك أي صعوبات؟ على سبيل المثال ، صيانة microservice ، نفس المراقبة هي أيضا صداع في عمليات الشركة. بعد كل شيء ، يزيد عدد المكونات عشرات المرات. كيف ترى هذا ، هل كان هناك أي أمثلة غير ناجحة للاستثمارات هنا؟ وما الذي يمكن أن ينصح به الناس حتى لا يواجهوا مشكلات مماثلة؟
الكسندر:ومن الأمثلة غير الناجحة أن الأعمال غيرت الأولويات وألغت المشروعات. عندما تكون الشركة في مرحلة جيدة من الاستعداد (MVP جاهزة فعليًا) ، قالت الشركة: "لدينا أولويات جديدة ، سنذهب إلى مشروع آخر ، ونغلق هذا المشروع".
لم يكن لدينا ملفات عمومية مع خدمات microservices. نحن ننام بسلام ، لدينا نوبة عمل 24/7 تخدم نظام دعم الأعمال بأكمله BSS.
وحتى الآن - نحن نستأجر خدمات micros وفقًا للقواعد التي يتم بموجبها استئجار المنتجات المعبأة. مفتاح النجاح هو ، أولاً ، أنك بحاجة إلى تجميع فريق يقوم بإعداد الخدمة الميكروية للإنتاج بالكامل. التنمية نفسها ، مشروطة ، 40 ٪. الباقي هو التحليلات ، ومنهجية DevSecOps ، والتكاملات الصحيحة والبنية الصحيحة. نحن نولي اهتماما خاصا لمبادئ بناء تطبيقات آمنة. في كل مشروع ، يشارك ممثلو أمن المعلومات في مرحلة التخطيط للعمارة وفي عملية التنفيذ. كما أنها تدير أنظمة تحليل الكود الخاصة بمواطن الضعف.
لنفترض أننا ننشر خدماتنا عديمي الجنسية - لدينا في Kubernetes. هذا يسمح للجميع بالنوم بسلام بسبب التوسع التلقائي وخدمات رفع السيارات ، والتحول في الخدمة التقاط الحوادث.
طوال فترة وجود خدماتنا المصغرة ، كان هناك حادث واحد أو حادثان فقط وصلنا إلى خطنا. الآن لا توجد مشاكل التشغيل. بالطبع ، ليس لدينا 200 ، ولكن حوالي 50 خدمة microservices ، لكنها تستخدم في المنتجات الرائدة. إذا فشلوا ، فسنكون أول من يعلم بها.
Microservices والموارد البشرية
سيرجي:وأنا أتفق مع زميلي حول النقل في الدعم - أنك تحتاج إلى تنظيم العمل بشكل صحيح. لكنني سأقول عن المشاكل التي ، بالطبع ، هي.
أولاً ، التكنولوجيا جديدة. هذا هو الضجيج بطريقة جيدة ، والعثور على أخصائي من شأنه أن يفهم ويكون قادرا على إنشاء هذا يشكل تحديا كبيرا. المنافسة على الموارد مجنونة ، على التوالي ، يستحق الخبراء وزنها بالذهب.
ثانياً ، عند إنشاء مناظر طبيعية معينة وعدد متزايد من الخدمات ، يجب حل مشكلة إعادة الاستخدام باستمرار. كما يحب المطورون القيام بذلك: "دعنا نكتب هنا الكثير من الأشياء المثيرة للاهتمام هنا ..." ولهذا السبب ، فإن النظام ينمو ويفقد فعاليته من حيث المال وتكلفة الملكية ، وما إلى ذلك. أي أنك تحتاج إلى إعادة استخدام بنية النظم ، وأن تدرج في خريطة الطريق تقديم الخدمات ونقل التراث القديم إلى الهيكل الجديد.
هناك مشكلة أخرى - على الرغم من أنها جيدة بطريقتها الخاصة - وهي المنافسة الداخلية. "أوه ، لقد ظهر رجال موضة جدد هنا ، يتحدثون لغة جديدة." الناس ، بالطبع ، مختلفون. هناك أولئك الذين اعتادوا على الكتابة في جافا ، وأولئك الذين يكتبون ويستخدمون Docker و Kubernetes. هؤلاء أشخاص مختلفون تمامًا ، يتحدثون بطريقة مختلفة ، ويستخدمون مصطلحات مختلفة وأحيانًا لا يفهمون بعضهم بعضًا. القدرة أو عدم القدرة على تبادل الممارسة ، وتبادل المعرفة ، بهذا المعنى هي أيضًا مشكلة.
حسنا ، تحجيم الموارد. "رائع ، دعنا نذهب! والآن نريد أسرع وأكثر. أليس كذلك؟ هل من المستحيل تقديم مرتين في السنة؟ لماذا؟ تعتبر مشكلات النمو هذه قياسية ، وربما بالنسبة للعديد من الأشياء ، العديد من الأساليب ، وشعروا بها.
فيما يتعلق بالرصد. يبدو لي أن الخدمات أو أدوات المراقبة الصناعية تتعلم بالفعل أو قادرة على العمل مع Docker و Kubernetes في وضع مختلف وغير قياسي. بحيث لا تمتلك ، على سبيل المثال ، 500 جهاز Java تعمل تحتها بكل هذا ، أي المجاميع. ولكن هذه المنتجات لا تزال تفتقر إلى النضج ، وعليها أن تمر بهذا. الموضوع جديد حقًا ، سيظل مطورًا.
ديمتري:نعم مشوق جدا وهذا ينطبق على الموارد البشرية. ربما تغيرت عملية الموارد البشرية والعلامة التجارية للموارد البشرية قليلاً خلال هذه السنوات الثلاث. لقد بدأت في تجنيد أشخاص آخرين يتمتعون بكفاءة مختلفة. وربما هناك إيجابيات وسلبيات. في السابق ، كانت علوم البيانات والكتل ذات تقنية عالية ، وكان المتخصصون فيها يستحقون ملايين فقط. الآن السعر ينخفض ، والسوق مشبع ، وهناك اتجاه مشابه في الخدمات الصغيرة.
سيرجي:نعم بالتأكيد.
الكسندر:يسأل مدير الموارد البشرية السؤال التالي: "أين يقع وحيد القرن الوردي بين الواجهة الخلفية والواجهة الأمامية؟" الموارد البشرية لا تفهم ما هي خدمة microservice. كشفنا لهم سرا وقلنا أن هذه الخلفية فعلت كل شيء ، وليس هناك وحيد القرن. لكن الموارد البشرية تتغير ، وتعلم بسرعة وتوظيف الأشخاص الذين لديهم المعرفة الأساسية لتكنولوجيا المعلومات.
تطور الخدمات الصغيرة
ديمتري:إذا نظرت إلى البنية المستهدفة ، تبدو الخدمات المصغرة مثل هذا الوحش. استغرقت رحلتك عدة سنوات. البعض الآخر لديهم سنة ، والبعض الآخر لديهم ثلاث سنوات. لقد توقعت كل المشكلات ، أي بنية الهدف ، هل تغير شيء ما؟ على سبيل المثال ، في حالة الخدمات المصغرة ، العبارات ، شبكات الخدمة الآن تظهر مرة أخرى. هل استخدمتها في البداية أم قمت بتغيير العمارة نفسها؟ هل لديك أي من هذه التحديات؟
سيرجي:لقد أعدنا بالفعل كتابة العديد من بروتوكولات التفاعل. في البداية ، بروتوكول واحد ، تحولت الآن إلى آخر. نحن زيادة السلامة والموثوقية. لقد بدأنا بتكنولوجيا المؤسسات - Oracle و Web Logic. الآن نحن نبتعد عن منتجات المؤسسات التكنولوجية في مجال الخدمات المصغرة وننتقل إلى المصادر المفتوحة أو إلى التقنيات المفتوحة بالكامل. نحن نتخلى عن قواعد البيانات ، وننتقل إلى ما هو أكثر فعالية بالنسبة لنا في هذا النموذج. لم نعد بحاجة إلى تقنيات Oracle.
, , , , , , . . , , -, - , . , — - , — , . , API.
. , , , , . , . , , CI/CD.
— , : , . , , . : , , .
- , - — backlog' . . 20% , 80% — -. , , , , . .
:. «»?
:— . , «» — . , . .
: « ?». : « ?». service mesh. Istio, . . — , , - . , .
:! . GDPR chief data protection officers, . .
. — . , , .
, !
(1):, IT- ? , , — . IT- , ?
:, . , . , . . , CI/CD.
, , -, — . . -, — -. : « ?».
, , , : , -. , , , , .
(2):, . , - . ? .
:, .
, , 5-7 . , -. : BSS, .
. QA-. , 5-7 , 2-3 . , , , Mail.ru Group R&D «». , . QA- , .
. , , . , API-. - , front . , - , — , API- v2. , .
:. — . , , . : . , unit-. , . push , unit-.
, . , , .
end-to-end , , . , , . — , , . .
:, unit- . , unit- . , , . — . , . .
(3):, . ?
: . , . , , , .
, , . ?
:« » — . -, . , «», . , . — , — .
:, . , . : . - , , . -.
, , , , . , , . , . , . , .
, , , unit- — , . , .
:, , ? Backlog ? ?
:: . backlog, , — . backlog, , backlog . . IT-, . .
backlog' — backlog' — . , — IT. , — . , backlog' , .
, : « , — ». : «, ». : « : ?». , , . ? : « legacy-, , , ». : «: backlog — . ». , capacity, .
,
تمت استضافة مؤتمر mailto: CLOUD بواسطة Mail.ru Cloud Solutions .نقوم أيضًا بأحداث أخرى - على سبيل المثال ، Kubernetes Meetup ، حيث نبحث دائمًا عن مكبرات صوت رائعة: