اختيار قواعد البيانات المناسبة للخدمات المصغرة

إذا كان التطبيق الخاص بك مثل معظم التطبيقات التي نراها والتي بدأت في طريق إعادة هيكلتها إلى خدمات مصغرة، فيمكننا على الأرجح أن نفترض بأمان أنه يعمل مع قاعدة بيانات علائقية واحدة كبيرة. والأكثر من ذلك، هناك احتمال شبه متساو أن تكون قاعدة البيانات هذه قاعدة بيانات Oracle—فجميع قواعد البيانات العلائقية الأخرى (DB2، SQL Server، Informix، أو حتى قاعدة بيانات مفتوحة المصدر مثل MySQL أو Postgres) تتقاسم الحصة المتبقية. في الواقع، الابتعاد عن قاعدة البيانات العلائقية المؤسسية (التي عادة ما تكون مكلفة) هو أحد الفوائد التي يتم الترويج لها غالبا لإعادة الهيكلة إلى الخدمات المصغرة.

الآن، هناك أسباب وجيهة جدًا لاختيار أنواع أخرى من قواعد البيانات - إما NewSQL أو NoSQL للعديد من الخدمات المصغرة. ومع ذلك، فإن التخلي عن قاعدة بياناتك العلائقية الحالية دفعة واحدة غالبًا ما يكون قرارًا متهورًا. بدلاً من ذلك، قد ترغب في النظر إلى نهج تدريجي أكثر لتغيير قاعدة البيانات الخاصة بك، تمامًا كما ندعو إلى اتباع نهج تدريجي لإعادة هيكلة رمز Java البرمجي الحالي.

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

في الأساس، فإن المكان المناسب للبدء هو التمييز بين خادم قاعدة البيانات ومخطط قاعدة البيانات. بالنسبة لأولئك الذين يعرفون قواعد البيانات على مستوى المؤسسات مثل Oracle أو Db2، هذا أمر طبيعي لأن المؤسسات عادة ما يكون لديها خادم Oracle كبير واحد (أو RAC، وهو خادم كبير مكون من عدة خوادم أصغر) حيث تستضيف عدة فرق قواعد بيانات منفصلة (كل منها يمثّل بمخطط منفصل). والسبب في ذلك هو أن الترخيص يتم في الغالب عن طريق وحدة المعالجة المركزية، وأن الشركة تريد تعظيم الاستخدام الذي يمكن أن تحصل عليه مقابل أموالها. ويعد تجميع فرق متعددة معًا في خادم واحد كبير طريقة للقيام بذلك. لمن لديهم معرفة أكبر بقواعد البيانات مفتوحة المصدر مثل MySQL أو PostgreSQL، هذا أقل شيوعاً لأن التمييز أقل طلبًا في كثير من الأحيان.

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

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

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

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

في هذا المثال (الذي يهدف إلى إظهار عمل إعادة هيكلة قيد التنفيذ)، يمكنك رؤية كيف تم تقسيم قاعدة البيانات عن طريق فصل جداول تتوافق مع ثلاثة مخططات جديدة (A وB وC) تتوافق مع وحدات محددة في التطبيق المعاد هيكلته. بمجرد فصلها بهذه الطريقة، يمكن تقسيمها بسهولة إلى خدمات مصغرة منفصلة. ومع ذلك، لا تزال D و E قيد إعادة الهيكلة - لا يزالان مشتركان في مخطط واحد مع جداول مترابطة.

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

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

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

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

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

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

إذا كان التطبيق (أو، على الأرجح، مجموعة فرعية من التطبيق) يستخدم التخزين في قاعدة بيانات علائقية، فهذه بالفعل علامة جيدة جدًا على أنه قد يكون من الأفضل لك استخدام مخزن قيمة رئيسية مثل Memcached أو Redis. من ناحية أخرى، قد ترغب في التراجع خطوة إلى الوراء والتفكر قليلاً فيما تقوم بتخزينه. إذا اتضح أنه مجرد كائن Java منظم (ربما منظم بعمق، ولكن ليس ثنائيًا في الأصل) فقد يكون من الأفضل لك استخدام مخزن مستندات مثل Cloudant أو MongoDB. والأكثر من ذلك، مع القليل من الجهد المبذول في كيفية تخزين مستنداتك (على سبيل المثال، كلتا قاعدتي البيانات المذكورة أعلاه هي مخازن مستندات JSON، ومحللات JSON متاحة على نطاق واسع وسهلة التخصيص) يمكنك التعامل مع أي مشاكل تتعلق "بانحراف المخطط" بسهولة أكبر بكثير مما يمكنك التعامل معه مع نهج مخزن Blob، والذي يكون أكثر غموضًا في آلية التخزين الخاصة به.

قبل سنوات، عندما كان Martin Fowler يكتب "أنماط هياكل التطبيقات المؤسسية"، أجرينا مراسلات نشطة وعدة اجتماعات تقييم حيوية حول العديد من الأنماط. وواحد على وجه الخصوص يبرز دائمًا على أنه نمط البطة السوداء — نمط السجل النشط. لقد كان غريبًا لأننا لم نكن قد واجهتنا من قِبل مجتمع Java (على الرغم من أن Martin أكّد لنا أنه كان شائعًا في مجتمع برمجة Microsoft .NET). لكن ما لفت انتباهنا حقاً في ذلك—وخاصة عندما بدأنا نرى بعض تطبيقات Java باستخدام تقنيات مصدر مفتوح مثل iBatis—هو أنه بدا أن أفضل طريقة لاستخدامها هي عندما تكون الكائنات، مسطحة.

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

هناك نمط شائع آخر رأيناه في أنظمة إدارة المخاطر التشغيلية (ORM) وهو الجمع بين "البيانات المرجعية في الجدول الممتصة في ذاكرة التخزين المؤقت في الذاكرة". تتكون البيانات المرجعية من أشياء لا يتم تحديثها في كثير من الأحيان (أو لا يتم تحديثها مطلقًا)، ولكن يتم قراءتها باستمرار. من الأمثلة الجيدة على ذلك قائمة الولايات الأمريكية أو المقاطعات الكندية؛ وتشمل الأمثلة الأخرى الرموز الطبية أو قوائم الأجزاء القياسية. غالبًا ما يُستخدم هذا النوع من البيانات لملء القوائم المنسدلة في الواجهات الرسومية.

يتمثل النمط الشائع في البدء بقراءة القائمة من جدول (عادةً ما يكون جدولاً من عمودين مستويين أو على الأكثر من ثلاثة أعمدة) في كل مرة يتم فيها استخدامها. ومع ذلك، ستجد بعد ذلك أن أداء القيام بذلك في كل مرة يكون باهظًا، لذا بدلاً من ذلك، يقوم التطبيق بقراءته في ذاكرة تخزين مؤقت في الذاكرة مثل EhCache عند بدء التشغيل.

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

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

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

وهنا يأتي دور الحلول مثل Apache Tinkerpop أو Neo4J والتي قد تكون نهجًا جيدًا. من خلال نمذجة الحل مباشرةً كرسوم بيانية، كان بإمكاننا تجنب الكثير من أكواد Java و SQL المعقدة، وفي الوقت نفسه، ربما كان بإمكاننا تحسين أداء وقت التشغيل بشكل كبير.

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

للتعمق أكثر في المقارنة بين NoSQL وSQL انظر "SQL مقابل NoSQL: ما الفرق بينهما؟

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

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

في هذه الحالة، كانوا بحاجة إلى جميع سمات وضع ACID، لكنهم لم يكونوا بحاجة إلى التجزئة (على سبيل المثال، التقسيم)؛ فقد عمل نظامهم الحالي لسنوات بمستوى أداء مقبول تمامًا على نموذج علائقي، ولم يكونوا يتوقعون نموًا هائلاً. ولكن على الرغم من أن جوهر النظام يحتاج إلى معاملات ACID ولا يحتاج إلى تجزئة، إلا أن هذا لم يكن صحيحًا بالضرورة لجميع الأجزاء المختلفة من النظام. هناك بعض الأشياء التي تتميز بها قواعد بيانات SQL، وإن معاملات ACID هي واحدة منها. في أنظمة الخدمات المصغرة، عادةً ما يكون تجميع معاملات ACID معًا حول أصغر مجموعة من البيانات التي تعمل عليها هو النهج الصحيح.

لكن SQL لا يعني بالضرورة قواعد بيانات SQL التقليدية. يمكن ذلك، وهناك بالتأكيد مكان لذلك في العديد من بنيات الخدمات المصغرة، ولكن يتم تنفيذ SQL أيضًا في نوعين آخرين على الأقل من قواعد البيانات التي يمكن أن تكون خيارات مفيدة للعديد من الفرق التي تنفذ الخدمات المصغرة. الأول هو "SQL الصغيرة"، وهو مجال قواعد البيانات مفتوحة المصدر مثل MySQL وPostgres. بالنسبة للعديد من الفرق التي تنفذ الخدمات المصغرة، تعتبر قواعد البيانات هذه خياراً معقولاً تماما لأسباب عديدة:

1. الفرق التي تعيد هيكلة التطبيقات الحالية إلى الخدمات المصغرة عادة ما تمتلك تجربة مع كل من SQL وأُطر عمل تعيين الكائنات العلائقية مثل Hibernate أو Spring Persistence. إن الاستفادة من هذه المعرفة مع البقاء ضمن حدود نهج الخدمات المصغرة أمر معقول بالتأكيد.
2. تحظى قواعد البيانات هذه بدعم جيد للغاية، سواء من قبل مجتمع المصدر المفتوح أو من قبل العديد من البائعين الذين يقدمون الدعم لها. من السهل نسبيًا العثور على الوثائق وبرامج تعليمية لها والعثور على مطورين ماهرين فيها.
3. قواعد البيانات هذه صغيرة وخفيفة الوزن بما يكفي لوضعها في حاويات بسهولة ونشرها وتحديثها من خلال آليات GitOps نفسها التي تستخدمها للرمز البرمجي لتطبيقك.
4. قواعد البيانات هذه مدعومة في إصدارات SaaS من معظم أو كل خدمات السحابة العامة فائقة التدرج.

العيب الرئيسي لاستخدام قواعد بيانات SQL الصغيرة هذه هو أنها غالبًا لا تدعم نفس مستوى المقياس (خاصةً فيما يتعلق بالتجزئة) الذي تدعمه قواعد بيانات المؤسسة. ومع ذلك، تم معالجة هذا بشكل رائع من قبل مجموعة جديدة من بائعي قواعد البيانات والمشاريع مفتوحة المصدر التي تجمع بين أفضل خصائص قاعدة بيانات SQL وقابلية التوسع لقواعد بيانات NoSQL. وغالبًا ما تسمى قواعد بيانات "NewSQL"، وتشمل قواعد بيانات CockroachDB، وApache Trofidion، وClustrix.

كلما احتجت إلى جميع معاملات ACID، ومحرك SQL يدعم النموذج العلائقي بالكامل، وأيضًا قدرات التوسع والتجزئة الواسعة، يمكن أن تكون قواعد بيانات NewSQL خيارًا جيدًا لفرق العمل. ومع ذلك ، يأتي هذا الاختيار بتكلفة – غالبًا ما تكون قواعد البيانات هذه أكثر تعقيدًا في الإعداد والإدارة من حلول "SQL الصغيرة" القديمة. ومن الصعب أيضًا العثور على أشخاص ذوي مهارات في قواعد البيانات هذه. وبغض النظر عن ذلك، لا تزال هناك حاجة إلى النظر فيها بعناية عند العمل على خياراتك.

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

أخيرًا، كن مدركًا لحقيقة أن نهج الخدمات المصغرة بأكمله يعتمد على فكرة أن الفِرَق التي تبني كل خدمة مصغرة يمكنها اتخاذ قراراتها الخاصة بشأن مخزن البيانات المناسب لها. أكبر مشكلة واحدة واجهتنا (كما ألمحت العديد من هذه القصص) هي محاولة جعل نهج واحد لتمثيل البيانات وتخزينها يعمل في جميع الحالات. 

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

تم تصميم IBM Garage للتحرك بسرعة أكبر، والعمل بذكاء أكبر، والابتكار بطريقة تتيح لك إحداث تغيير جذري.