لوقت طويل، كان سؤال البنية التحتية يبدأ من نفس المكان:
Cloud أم On-Premise؟
الـ Cloud تقدم سرعة في التوسع، وسهولة في اطلاق الخدمات الجديدة، وقدرة على الوصول الى موارد متقدمة دون الحاجة الى امتلاك كل شيء وادارته داخليا. وفي المقابل، تمنح On-Premise الشركة مستوى عاليا من التحكم، وقربا من العمليات المحلية، واداء يمكن التنبؤ به بشكل اكبر في بعض السيناريوهات، الى جانب سيطرة اوسع على بعض البيانات والانظمة الحساسة.
المشكل ليس في ان احدى الاجابتين صحيحة والاخرى خاطئة.
المشكل ان السؤال نفسه يفترض ان الشركة تحتاج الى اجابة واحدة.
في الواقع، الشركة لا تعمل بـ Workload واحد. لديها نظام مبيعات، وقاعدة بيانات مالية، وبيئة BI، وتطبيقات عملاء، وعمليات داخل الفروع، وربما AI Services، وكل واحد منها يحتاج شيئا مختلفا من البنية التحتية المحيطة به.
هذا ظهر امامي بوضوح في تجربة مع احد عملاء قطاع التجزئة الذي كان يدير عدة فروع.
برنامج الولاء كشف المشكلة الحقيقية
كان لكل فرع نقطة بيع يجب ان تستمر في العمل حتى لو انقطع الاتصال بالبيئة المركزية.
من منظور العمل، هذا امر اساسي. انقطاع الانترنت لساعة لا يمكن ان يعني ان المتجر يتوقف عن البيع، ولذلك كان من الضروري ان يمتلك الفرع قدرة محلية تسمح له بالاستمرار في تنفيذ العمليات الاساسية.
لكن برنامج الولاء وضعنا امام احتياج مختلف تماما.
العميل لا ينتمي الى فرع واحد. قد يشتري اليوم من فرع، وبعد اسبوع من فرع اخر، بينما نقاط الولاء والعروض والبيانات المتعلقة به يجب ان تعكس علاقة واحدة مع الشركة كلها.
اذا احتفظ كل فرع بكل شيء داخله، سنحصل على استمرارية ممتازة محليا، لكننا سنقسم علاقة العميل بين عدة انظمة منفصلة. واذا جعلنا كل شيء مركزيا، سنحصل على رؤية موحدة، لكننا سنجعل عمليات الفرع اليومية تعتمد اكثر مما ينبغي على الاتصال بالشبكة.
لم يكن الحل الحقيقي ان نختار جانبا ونفرضه على كامل العمل.
الحل كان ان نفصل المسؤوليات.
الفرع يحتاج الى ما يكفيه ليواصل العمل محليا، بينما تحتاج الشركة الى تنسيق مركزي يجمع نشاط العميل ونقاط الولاء والقواعد المشتركة والتقارير في صورة واحدة.
وهنا يصبح سؤال Cloud أم On-Premise اقل اهمية بكثير من سؤال اخر:
ما الذي يجب ان يعمل في كل مكان، ولماذا؟
التنفيذ المحلي لا يتعارض مع التنسيق المركزي
في مثال التجزئة، بعض الوظائف مرتبطة مباشرة باستمرارية العمل داخل الفرع. اذا توقف الـ Checkout، فالاثر يظهر فورا على المبيعات وعلى العميل الموجود امام الموظف.
لهذا من المنطقي ان تبقى هناك قدرة محلية كافية لاستمرار هذه العمليات.
لكن بيانات العميل مختلفة. قيمتها الحقيقية تظهر عندما تكون موحدة على مستوى المؤسسة، لان العميل نفسه قد يتعامل مع عدة فروع، ولان العروض ونقاط الولاء والتقارير تحتاج الى رؤية اشمل من حدود متجر واحد.
النتيجة الطبيعية هي توزيع المسؤوليات.
الفرع يستطيع مواصلة البيع اثناء انقطاع الاتصال، وتستمر بعض عمليات الولاء محليا، ثم تتم المزامنة عندما يعود الاتصال. وفي الوقت نفسه، تبقى هوية العميل ورصيده وصورته الكاملة والتقارير العامة منسقة مركزيا.
هذا ليس Hybrid Architecture لاننا قررنا مسبقا ان Hybrid هو الخيار الافضل.
اصبح Hybrid لان طبيعة العمل نفسها فرضت اكثر من مكان مناسب للتنفيذ.
وهذا فرق مهم جدا.
ابدأ بالـ Workload وليس بالمنصة
عندما ننظر الى البنية التحتية بهذه الطريقة، يصبح اختيار التكنولوجيا الخطوة الثانية وليس الاولى.
قبل ان اقرر اين سيعمل اي نظام، اريد اولا ان افهم ما الذي يحتاجه العمل منه.
خذ الاستمرارية مثلا. ماذا يحدث لو اختفى الاتصال لمدة ساعة؟ تأخر تقرير اداري قد يكون مقبولا، لكن توقف نقطة البيع في فرع ليس مقبولا بنفس الدرجة.
بعد ذلك يأتي سؤال المشاركة. هل هذا النظام يخدم موقعا واحدا، ام ان المعلومات التي ينتجها يجب ان تكون موحدة بين عدة فروع او اقسام؟ بيانات الولاء مثال واضح، لان العملية تحدث محليا لكن العلاقة مع العميل مركزية بطبيعتها.
ثم تأتي مسألة التحكم والامن. بعض الانظمة تحتوي على معلومات حساسة او تخضع لمتطلبات تنظيمية خاصة، بينما يمكن لخدمات اخرى ان تعمل بشكل طبيعي داخل Managed Cloud Services. السؤال المفيد هنا ليس هل Cloud اكثر امانا من On-Premise او العكس، بل ما الضوابط التي يحتاجها هذا Workload، واين يمكن تطبيقها بشكل افضل.
الاداء يضيف زاوية اخرى. بعض الانظمة تستفيد من وجودها بالقرب من المستخدم او الاجهزة او العمليات المحلية، بينما تستفيد اخرى من القدرة المركزية او من موارد يمكن زيادتها وخفضها حسب الاستخدام.
واخيرا هناك طبيعة التغير. نظام تشغيلي مستقر يعمل منذ سنوات لا يشبه AI Service جديدة قد يتغير استهلاكها ونماذجها وقدراتها بسرعة.
عندما تتضح هذه الاسئلة، يصبح قرار مكان التشغيل اسهل بكثير.
Hybrid نتيجة، وليس استراتيجية بحد ذاته
هناك فرق بين ان تكون الشركة لديها بيئة Hybrid، وبين ان يكون لديها Hybrid Strategy.
كثير من الشركات تعمل اليوم على اكثر من بيئة. بعض الانظمة بقيت On-Premise لانها موجودة منذ سنوات، وبعضها انتقل الى Cloud ضمن مشروع معين، بينما تم بناء تطبيقات جديدة في بيئة ثالثة.
من الناحية التقنية، هذا Hybrid.
لكن من الناحية الاستراتيجية، قد لا يكون اكثر من تراكم لقرارات حدثت في اوقات مختلفة.
الـ Hybrid الحقيقي يجب ان يكون من الممكن تفسيره.
لماذا بقي هذا النظام محليا؟ لماذا هذا النظام مركزي؟ ماذا يحدث عند انقطاع الاتصال؟ من يمتلك النسخة المعتمدة من البيانات؟ كيف تتم المزامنة؟ اين تطبق قواعد الامن؟ ومتى نعيد النظر في مكان تشغيل النظام؟
اذا كانت لهذه الاسئلة اجابات واضحة، فهناك قرار معماري حقيقي.
اما اذا كانت الاجابة هي "لانه موجود هنا منذ البداية"، فنحن قد نكون امام ترتيب استضافة، لا امام استراتيجية بنية تحتية.
التكلفة لا تختصر في فاتورة الخادم
نفس المشكلة تظهر عندما نختصر القرار كله في التكلفة.
قد تبدو Cloud ارخص لان الشركة لا تحتاج الى شراء وتجهيز Infrastructure كبيرة مقدما، بينما قد تبدو On-Premise اكثر توفيرا عندما يكون الـ Workload مستقرا ويمكن تشغيله لسنوات على موارد مملوكة بالفعل.
كلا الامرين قد يكون صحيحا.
لكن التكلفة الحقيقية لا تتوقف عند Compute وStorage.
هناك تكلفة التشغيل والدعم، والـ Integration، والحماية، وحركة البيانات، والتوقف، والنسخ الاحتياطي، والتوسع، والموظفين الذين يديرون البيئة، وحتى صعوبة تغيير التصميم لاحقا.
في مثال الفروع، توقف فرع عن البيع له تكلفة حقيقية. وفي المقابل، وجود بيانات عميل مجزأة بين عدة مواقع له تكلفة ايضا، حتى لو لم تظهر اي منهما كبند واضح في فاتورة Server.
لهذا لا ارى ان الهدف يجب ان يكون العثور على ارخص منصة لكل نظام.
الهدف الافضل هو وضع كل Workload في المكان الذي يجعل العمل ككل اكثر استقرارا وكفاءة وقدرة على التغير.
فكر في البنية التحتية كمحفظة من الـ Workloads
عندما نصل الى هذه النقطة، تبدأ Infrastructure Strategy بالاقتراب من فكرة Portfolio Management.
ليس من المنطقي ان نعطي كل Workload نفس المعاملة، لان كل واحد منها يخدم العمل بطريقة مختلفة.
قد يبقى نظام الفرع محليا لان الاستمرارية هي الاولوية. وقد تعمل منصة العملاء مركزيا لان العلاقة مع العميل تتجاوز حدود الموقع الواحد. وقد تستفيد Analytics من البيانات المجمعة ومن موارد معالجة قابلة للتوسع.
اما AI Workloads فلها طبيعة اخرى، لان استهلاكها قد يرتفع او ينخفض بشكل كبير، وقد تعتمد على Models وخدمات جاهزة وموارد متخصصة يصعب تبرير بنائها داخليا اذا كان الاستخدام غير منتظم.
ونفس المنطق يمكن تطبيقه على الانظمة المالية، وBackups، وArchives، وIntegrations، وقواعد البيانات التشغيلية، وتطبيقات العملاء.
ليس الهدف ان نصنع Architecture معقدة.
الهدف ان نعترف بان العمل نفسه يحتوي على احتياجات مختلفة، وبالتالي ليس من المنطقي اجبار كل شيء على نفس قرار الاستضافة.
AI يجعل هذا التفكير اكثر اهمية
دخول AI الى الشركات يجعل قرار مكان تشغيل الـ Workload اكثر اهمية، لا اقل.
AI Workload قد تحتاج الى قدرة توسع سريعة، وقد تعتمد على External Models او APIs او Vector Databases او خدمات متخصصة لا يوجد سبب اقتصادي لبنائها كلها داخليا.
لكن البيانات التي يحتاجها AI قد تكون ما زالت موجودة داخل SQL Server او ERP يعمل On-Premise، وربما يجب ان تبقى هناك لاسباب تتعلق بالامن او التنظيم او قربها من العمليات.
وجود AI لا يعني ان ننقل كل شيء الى Cloud.
المنطقي اكثر هو ان نربط الـ Workloads بطريقة مدروسة.
قد تبقى البيانات في المكان المناسب لها، بينما يتم تمرير الجزء المطلوب منها من خلال APIs او Integration Layer محكومة، ويعمل AI في بيئة توفر له المرونة والموارد التي يحتاجها.
الفكرة نفسها لا تتغير:
لا تنقل كل شيء بسبب تقنية جديدة. ضع كل مسؤولية في المكان الذي يخدم العمل بشكل افضل.
والمكان المناسب اليوم قد لا يكون المناسب غدا
قرار تشغيل Workload في مكان معين لا يجب ان يتحول الى قرار ابدي.
قد يكون نظام ما مناسبا تماما لـ On-Premise قبل خمس سنوات، ثم تتغير طريقة استخدامه ويصبح Cloud اكثر منطقية اليوم.
وقد يحدث العكس. Workload انتقلت الى Cloud اثناء مرحلة نمو سريع قد تصبح مستقرة لاحقا لدرجة تجعل نموذجا مختلفا اكثر كفاءة من ناحية التكلفة او التحكم.
كما يمكن ان تتغير الاجابة بسبب قانون جديد، او توسع الشركة، او افتتاح فروع، او استحواذ، او تحسن الاتصال، او دخول AI، او تغير نمط الاستخدام نفسه.
لذلك لا يجب ان تنتهي Infrastructure Strategy بعد Migration.
من المفيد اعادة النظر من وقت لآخر في اهم الـ Workloads ومقارنة مكانها الحالي بما يحتاجه العمل اليوم، لا بما كان يحتاجه عندما تم اتخاذ القرار قبل سنوات.
السؤال الذي يستحق ان نبدأ به
لو دخلت اليوم في نقاش حول Cloud وOn-Premise، لن ابدأ بالسؤال عن ايهما افضل.
سأبدأ برسم صورة للـ Workloads المهمة في الشركة.
ما الوظائف التي لا تستطيع التوقف اذا انقطع الاتصال؟ ما البيانات التي يجب ان تكون موحدة على مستوى المؤسسة؟ اين نحتاج الى تحكم اكبر؟ ما الذي يستفيد من Elasticity؟ ما الذي يحتاج الى Low Latency؟ ما الانظمة التي تتغير بسرعة؟ وما الـ Workloads التي اصبح تشغيلها في مكانها الحالي مكلفا او معقدا دون سبب كاف؟
عميل التجزئة الذي تحدثت عنه لم يكن لديه مشكلة Cloud او مشكلة On-Premise.
كانت لديه فروع تحتاج الى الاستمرار في العمل محليا، وفي الوقت نفسه علاقة مع العميل يجب ان تبقى موحدة ومركزية.
عندما فهمنا هاتين المسؤوليتين، اصبح قرار البنية التحتية اسهل بكثير.
وهنا بالنسبة لي تكمن الفكرة كلها:
لا تبدأ بالسؤال اين يجب ان تعمل الشركة. ابدأ بالسؤال اين يستطيع كل Workload ان يخدم العمل بشكل افضل.
