Q & A: Meet New Azure CTO، Mark Russinovich

في وقت سابق من هذا الشهر ، قامت Microsoft بتعيين مهندس برامج بهدوء مارك روسينوفيتش يشغل منصب كبير مسؤولي التقنية لمنصة الحوسبة السحابية Azure ، مما يضفي الطابع الرسمي على الدور الذي كان يقوم به خلال السنوات العديدة الماضية.

لقد كان موعدًا ذكيًا ليس أقلها لأنه قد يساعد في تخفيف أي مخاوف متبقية من مسؤولي النظام الذين يترددون في اتخاذها على منصة سحابة مايكروسوفت كجزء من واجبات وظيفتها. من بين المؤمنين من مايكروسوفت ، فإن روسينوفيتش لديه مصداقية خطيرة في المهوس. إذا كان Russinovich وراء التروس في Azure ، فيجب أن يكون O.K

منذ فترة طويلة Russinovich واحدة من أكثر المتكلمين شعبية في المؤتمرات الفنية Microsoft Build و TechEd ، وذلك بفضل تفسيرات واضحة ومقنعة لتقنيات الشركة. انضم روسينوفيتش إلى الشركة في عام 2006 ، بعد أن اشترت مايكروسوفت شركته للبرمجيات ، Winternals Software ، التي عرضت مجموعة من أدوات إصلاح Windows التي وجدها كثيرون متفوقة على أدوات مايكروسوفت الخاصة.

[المزيد من القراءة: أفضل خدمات البث التلفزيوني]

الانضمام لشركة مايكروسوفت أدى روسينوفيتش إلى تحويل تركيزه المتحمّس من نظام ويندوز إلى ممارسة السحاب التي أصبحت معروفة آنذاك ، أزور ، التي أصبحت الآن حجر الزاوية في استراتيجية أعمال الشركة. لقد عانى روسينوفيتش من آلام أزوري المتنامية بنفسه ، وتحدث عنها بصراحة ، وعمق.

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

كان هذا الحادث مفاجئًا للشركة. "مع الخدمات ، يتعلق الأمر بدورة الحياة بأكملها. قال روسينوفيتش خلال حديثه في مؤتمر بيلد الأخير في أبريل: "عليك أن تفكر في نهاية المطاف عندما تتعامل مع العمليات". > جلس خدمة IDG للأخبار مع روسينوفيتش لمعرفة المزيد عن كيفية إعادة تشكيل Azure الطريقة التي تعمل بها الشركة.

IDGNS

: لماذا يتم تشغيل خدمة سحابة مختلفة عن منتجات برامج الشحن؟ Russinovich

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

عندما تذهب إلى نموذج تقديم الخدمات ، يكون الأمر أكثر استمرارية. يقوم المطورون بتطوير البرنامج واختباره واختباره.

الاختلاف الرئيسي الآخر هو أننا أيضاً الذين يقومون بتشغيل البرنامج. نظرًا لأننا نعمل على نطاق واسع ، فإننا نمتلك فائدة ومسؤولية تطوير المراقبة العميقة للبرنامج ، لذلك يمكننا اكتشاف المشكلات.

تحتاج هذه المشكلات إلى حلها من قِبل مطوري البرامج نفسها ، بدلاً من الفريق الهندسي

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

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

IDGNS

: حتى devops ليس مجرد buzzphrase ، ولكن الطريقة الجديدة للقيام الأشياء. Russinovich

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

بمجرد الوصول إلى شيء بحجم Azure ، لا يمكنك فعله بهذه الطريقة. يجب أن يكون لديك نظام آلي.

بدأ تغيير الذهن مرة أخرى بينما كانت أجزاء من الشركة تعمل بهذه الطريقة بالفعل على خدماتنا الأولى ، مثل Bing أو Hotmail. لذلك كان هذا ينتشر من خلال الشركة بأكملها ويأخذ جهدا متضافرا ، ويأخذ التعلم ، وما الذي ينجح وما لا ينجح. يمكننا مشاركة أفضل الممارسات ، لكن كل فريق يمر بتحويل فريد. كان رائعا لمشاهدة.

وهناك مثال رائع هو ويندوز سيرفر. تعني السحابة أولاً أن الكثير من الأشياء التي يقومون بها هي لصالح Azure ، وعمليات نشر السحابة في البنية الأساسية للخادم بشكل عام. أحد الأشياء الواضحة هو أن لدى Windows Server ميزة نسخ احتياطي يمكنك الإشارة إليها في Azure ، بحيث يمكنك استخدام اشتراك Azure التخزين وإجراء نسخ احتياطي للخوادم إلى السحابة.

IDGNS

: كيف شاركت في Azure ؟ Russinovich

: لقد بدأت العمل في Microsoft في عام 2006 عندما تم شراء شركتي ، وعملت في النهاية الخلفية لنظام التشغيل Vista ، ونظام التشغيل Windows 7. حيث تم الانتهاء من Windows 7 ، وبدأنا العمل على Windows 8 ، كنت أبحث في جميع أنحاء للقيام بشيء مختلف. وقد حفز بعض من هذا على بعض الناس الذين بدأوا مشروع أزور ، بما في ذلك واحد من بلدي الأبطال ، ديف كوتلر ، الرجل الذي أنشأ نظام التشغيل Windows NT.

لقد بدأ مشروع Azure في الوقت الذي انضممت فيه إلى فريق Windows ، والذي كان مخيباً بالنسبة لي أنه بدأ العمل على هذا. كنت أبحث في مشروعه وأفكر "نعم ، دق نفسك هناك ، ما زلت أعمل على الأشياء الرائعة هنا في Windows."

بعد بضع سنوات ، تحدثت معه ، وتحدثت مع [ثم Microsoft كبير المهندسين المعماريين] راي أوزي ، وبدأت في اتخاذ خطوة إلى الوراء. رأيت التحول الذي تمر به الصناعة. كنت أساعد مايكروسوفت قبل الانتقال المحمول من الحوسبة الموجهة سطح المكتب. لكنني أدركت أن هناك جانباً آخر لهذا الاضطراب المتنقل ، والذي كان جزء السحابة منه. كل هذه الأجهزة تتواصل مع بعضها البعض وتخزن البيانات في موقع مركزي. هذا جعلني أدرك أن السحابة كانت على الأرجح أكبر وأكثر تعقيدا حتى من الهاتف المحمول.

البنية التحتية ، وأنظمة البرمجيات ، ونماذج التطبيقات الخاصة بالسحابة بالكاد كانت موجودة آنذاك. كيف نعمل على هذا النطاق؟ كيف يكتب الأشخاص التطبيقات التي تعمل على هذا النطاق؟ كيف يمكنك تطوير تطبيق من شأنه أن يعمل في جميع أنحاء العالم؟ هذا مثل نظام تشغيل جديد. أدركت أن Azure كانت الأساس لمستقبل Microsoft.

IDGNS

: كيف ستتغير المهمة لمسؤول النظام الذي ينتقل حمل العمل إلى السحابة؟ Russinovich

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

Shadow IT-I تسميها "إحضار الخاصة بك - تكنولوجيا المعلومات" - هي فقط الأعمال التجارية التي تدور حول تكنولوجيا المعلومات المركزية لأن السحابة هي أكثر مرونة بكثير.

حتى إذا كان رجال تكنولوجيا المعلومات المركزية لا يريدون أن تترك وراء إدارة الاشياء في المؤسسة ، لديهم لمعرفة كيفية الحصول على موقف لمساعدة أعمالهم على الوصول إلى السحابة. وهذا يعني فهم نموذج تكلفة السحابة ، والنموذج الأمني ​​للسحابة ، وكيفية وضع الحوكمة حتى يفعل الناس الشيء الصحيح ، وجعله بحيث يتم تحفيز إدارات الأعمال لمساعدتهم ، بدلاً من الالتفاف حولك كعائق.

IDGNS

: لقد كانت مايكروسوفت هادئة إلى حد كبير على واجهة OpenStack ، والتي كانت تولد الكثير من الدعاية كمنصة سحابة. ما هي القيمة المحتملة التي تراها مايكروسوفت في OpenStack؟ Russinovich

: من منظورنا ، OpenStack هو ، كشيء نتبناه لتشغيل السحابة الخاصة بنا ، وليس ناضجًا بما فيه الكفاية ، وقابلية للتوسع بما فيه الكفاية أو مستقرة بما فيه الكفاية. والطريقة التي ننظر بها لا تتمثل في كيفية استخدامنا لها ، ولكن ما يريده عملاؤنا منه. ما نجده هو أنه لا أحد تقريبا يستخدم واجهات برمجة تطبيقات OpenStack [واجهات برمجة التطبيقات] مباشرة. عندما نتحدث إليهم ، نسمع أن OpenStack صعب للغاية في الإعداد وأنه من الصعب للغاية الحفاظ عليه. عدد قليل من الناس يقومون بنشره واستخدامه بنجاح.

أولئك الذين يستخدمونه بنجاح لا يستخدمون واجهات برمجة التطبيقات. انهم يستخدمون طبقة التجريد على القمة. لذلك عندما نسأل ما إذا كان من المفيد تقديم دعم لواجهة برمجة التطبيقات ، فإن الإجابة هي لا. وفي الواقع ، سيكون من الصعب علينا القيام بذلك. إذا نظرت إلى مجموعة OpenStack API ، أو إلى واجهات برمجة تطبيقات Amazon ، أو واجهات برمجة التطبيقات الخاصة بنا ، فهناك عدم تطابق في المعاوقة بينهما. إنشاء طبقة تجريد ، سوف ينتهي بك الأمر مع أشياء تتصادم حيث لا يوجد تطابق تام من API إلى آخر. لذا ، سيكون من الصعب علينا أن نتخذ واجهة OpenStack API عالية الدقة على قمة Azure ، لأن OpenStack يتحرك في اتجاهات مختلفة وربما ليس بالضرورة بنفس السرعة.

IDGNS

: ما هي الدروس المستفادة من انقطاع 2013؟ Russinovich

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