أمازون MSK Serverless هو نوع من الكتلة Amazon Managed Streaming لأباتشي كافكا (Amazon MSK) الذي يسهل عليك تشغيل Apache Kafka دون الحاجة إلى إدارة سعة المجموعة وتوسيع نطاقها. يعمل MSK Serverless تلقائيًا على توفير موارد الحوسبة والتخزين وتوسيع نطاقها. باستخدام MSK Serverless، يمكنك استخدام Apache Kafka عند الطلب والدفع مقابل البيانات التي تقوم بدفقها والاحتفاظ بها على أساس الاستخدام.
يعتبر نشر البنية التحتية عبر VPCs المتعددة والحسابات المتعددة من أفضل الممارسات، مما يسهل قابلية التوسع مع الحفاظ على حدود العزل. في بيئة متعددة الحسابات، يمكن أن يتواجد منتجو ومستهلكو Kafka داخل نفس VPC - ومع ذلك، غالبًا ما يكونون موجودين في VPC مختلفة، وأحيانًا داخل نفس الحساب، أو في حساب مختلف، أو حتى في عدة حسابات مختلفة. هناك حاجة إلى حل يمكنه توسيع الوصول إلى مجموعات MSK Serverless للمنتجين والمستهلكين من VPCs المتعددة داخل حساب AWS نفسه وعبر حسابات AWS المتعددة. يجب أن يكون الحل قابلاً للتطوير ومباشرًا للمحافظة عليه.
في هذا المنشور، نوجهك عبر أساليب الحلول المتعددة التي تعالج خيارات الاتصال عبر VPC والوصول عبر الحسابات من MSK Serverless، ونناقش مزايا وقيود كل نهج.
الاتصال والمصادقة بدون خادم MSK
عند إنشاء مجموعة MSK Serverless، تقوم AWS بإدارة البنية التحتية للكتلة نيابةً عنك وتوسع الاتصال الخاص مرة أخرى إلى VPCs الخاصة بك من خلال نقاط نهاية VPC المدعومة بواسطة AWS الرابط الخاص. يمكنك تمهيد اتصالك بالمجموعة من خلال خادم التمهيد الذي يحتفظ بسجل بجميع الوسطاء الأساسيين لديك.
عند الإنشاء، يتم تعيين اسم المجال المؤهل بالكامل (FQDN) لخادم تمهيد المجموعة الخاص بك. يحتوي خادم التمهيد FQDN على التنسيق العام لـ boot-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com، ويتبع وسطاء المجموعة تنسيق bxxxx-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, أين ClusterUniqueID.xx فريدة من نوعها لمجموعتك و bxxxx هو نطاق وسيط ديناميكي (b0001 وb0037 وb0523 يمكن أن يكون بعض الوسطاء المعينين لديك في وقت ما). تجدر الإشارة إلى أن الوسطاء المعينين لمجموعتك ديناميكيون ويتغيرون بمرور الوقت، لكن عنوان التمهيد الخاص بك يظل كما هو بالنسبة للمجموعة. تبدأ جميع اتصالاتك مع المجموعة بخادم التمهيد الذي يمكنه الاستجابة بقائمة الوسطاء النشطين عند الحاجة. من أجل التواصل الصحيح مع كافكا، يجب أن يكون عميل MSK قادرًا على حل أسماء النطاقات الخاصة بخادم التمهيد الخاص بك بالإضافة إلى جميع الوسطاء لديك.
عند إنشاء المجموعة، يمكنك تحديد VPCs التي تريد أن تتواصل معها المجموعة (ما يصل إلى خمسة VPCs في نفس الحساب مثل مجموعتك). بالنسبة لكل VPC محدد أثناء إنشاء المجموعة، يتم إنشاء نقاط نهاية VPC للمجموعة جنبًا إلى جنب مع منطقة مستضافة خاصة تتضمن قائمة بخادم التمهيد الخاص بك وجميع الوسطاء الديناميكيين محدثين. تسهل المناطق المستضافة الخاصة حل FQDNs لخادم التمهيد والوسطاء، من داخل VPCs المرتبطة المحددة أثناء إنشاء المجموعة، إلى نقاط نهاية VPC المعنية لكل منها.
الوصول عبر الحسابات
لتتمكن من توسيع الاتصال الخاص لمنتجي ومستهلكي Kafka لديك بمجموعة MSK Serverless، يتعين عليك مراعاة ثلاثة جوانب رئيسية: الاتصال الخاص، والمصادقة والترخيص، وحل DNS.
يسلط الرسم البياني التالي الضوء على خيارات الاتصال الممكنة. على الرغم من أن الرسم البياني يوضح كل هذه الخيارات هنا لأغراض العرض التوضيحي، إلا أنه في معظم الحالات، يمكنك استخدام واحد أو أكثر من هذه الخيارات اعتمادًا على البنية الخاصة بك، وليس من الضروري أن تكون جميعها في نفس الإعداد.
في هذا القسم، نناقش خيارات الاتصال المختلفة بالإضافة إلى إيجابياتها وسلبياتها. نحن نغطي أيضًا جوانب المصادقة وحل DNS المرتبطة بخيارات الاتصال ذات الصلة.
طبقة الاتصال الخاصة
هذا هو الاتصال الأساسي بالشبكة الخاصة. يمكنك تحقيق هذا الاتصال باستخدام نظير VPC، بوابة عبور AWSأو PrivateLink، كما هو موضح في الرسم التخطيطي السابق. التناظر VPC يبسط الإعداد، لكنه يفتقر إلى دعم التوجيه المتعدي. في معظم الحالات، يتم استخدام النظير عندما يكون لديك عدد محدود من VPCs أو إذا كانت VPCs الخاصة بك تتواصل عمومًا مع عدد محدود من VPCs للخدمات الأساسية دون الحاجة إلى اتصال جانبي أو توجيه متعدٍ. من ناحية أخرى، تعمل AWS Transit Gateway على تسهيل التوجيه الانتقالي ويمكنها تبسيط البنية عندما يكون لديك عدد كبير من VPCs، وخاصة عندما يكون الاتصال الجانبي مطلوبًا. يعد PrivateLink أكثر ملاءمة لتوسيع الاتصال بمورد معين بشكل أحادي الاتجاه عبر VPCs أو الحسابات دون الكشف عن اتصال VPC إلى VPC الكامل، وبالتالي إضافة طبقة من العزل. يعد PrivateLink مفيدًا إذا كان لديك CIDRs متداخلة، وهي حالة غير مدعومة من Transit Gateway أو VPC Peering. يعد PrivateLink مفيدًا أيضًا عندما تتم إدارة الأطراف المتصلة بشكل منفصل، وعندما يكون الاتصال والعزل في اتجاه واحد مطلوبين.
إذا اخترت PrivateLink كخيار اتصال، فستحتاج إلى استخدام ملف موازن تحميل الشبكة (NLB) مع مجموعة مستهدفة من نوع IP مع تعيين أهدافها المسجلة كعناوين IP لنقاط النهاية المنطقية لمجموعة MSK Serverless الخاصة بك.
مصادقة المجموعة والترخيص
بالإضافة إلى التمتع باتصال خاص والقدرة على حل أسماء نطاقات خادم التمهيد والوسطاء، لكي يتمكن المنتجون والمستهلكون من الوصول إلى مجموعتك، تحتاج إلى تكوين عملائك باستخدام بيانات الاعتماد المناسبة. يدعم MSK Serverless إدارة الهوية والوصول AWS (IAM) المصادقة والترخيص. للوصول عبر الحسابات، يحتاج عميل MSK الخاص بك إلى تولي دور يحتوي على بيانات اعتماد مناسبة للوصول إلى المجموعة. يركز هذا المنشور بشكل أساسي على جوانب الاتصال عبر الحسابات وحل الأسماء. لمزيد من التفاصيل حول المصادقة والترخيص عبر الحسابات، راجع ما يلي جيثب ريبو.
قرار DNS
لكي يتمكن منتجو ومستهلكو Kafka الموجودون في الحسابات عبر المؤسسة من الإنتاج والاستهلاك من وإلى مجموعة MSK Serverless المركزية، يجب أن يكونوا قادرين على حل FQDNs لخادم تمهيد المجموعة وكذلك كل من وسطاء المجموعة. ومن خلال فهم الطبيعة الديناميكية لتخصيص الوسيط، يجب أن يلبي الحل مثل هذا المطلب. وفي القسم التالي، سنتناول كيف يمكننا تلبية هذا الجزء من المتطلبات.
حل DNS عبر الحسابات الجماعية
الآن بعد أن ناقشنا كيفية عمل MSK Serverless، وكيفية توسيع الاتصال الخاص، ومتطلبات المصادقة والتفويض، فلنناقش كيفية عمل تحليل DNS لمجموعتك.
بالنسبة لكل VPC مرتبط بمجموعتك أثناء إنشاء المجموعة، يتم إنشاء نقطة نهاية VPC جنبًا إلى جنب مع منطقة مستضافة خاصة. تعمل المناطق المستضافة الخاصة على تمكين تحليل أسماء FQDNs لخادم تمهيد المجموعة والوسطاء المخصصين ديناميكيًا، من داخل كل VPC المعنية. يعمل هذا بشكل جيد عندما تأتي الطلبات من داخل أي من VPCs التي تمت إضافتها أثناء إنشاء المجموعة لأنها تحتوي بالفعل على نقاط نهاية VPC المطلوبة والمناطق المستضافة الخاصة ذات الصلة.
دعنا نناقش كيف يمكنك توسيع نطاق تحليل الاسم ليشمل VPCs الأخرى داخل نفس الحساب والتي لم يتم تضمينها أثناء إنشاء المجموعة، وإلى الأجهزة الأخرى التي قد تكون موجودة في حسابات أخرى.
لقد حددت بالفعل خيار الاتصال الخاص الذي يناسب متطلبات البنية الخاصة بك على أفضل وجه، سواء كان ذلك من خلال نظير VPC أو PrivateLink أو Transit Gateway. بافتراض أنك قمت أيضًا بتكوين عملاء MSK لتولي الأدوار التي تحتوي على بيانات اعتماد IAM الصحيحة لتسهيل الوصول إلى المجموعة، فأنت بحاجة الآن إلى معالجة جانب تحليل الاسم للاتصال. تجدر الإشارة إلى أنه على الرغم من قيامنا بإدراج خيارات اتصال مختلفة باستخدام VPC Peering وTransit Gateway وPrivateLink، إلا أنه في معظم الحالات لا يوجد سوى خيار واحد أو اثنين فقط من خيارات الاتصال هذه. لا تحتاج بالضرورة إلى الحصول عليها جميعًا؛ لقد تم إدراجها هنا لتوضيح خياراتك، ولك الحرية في اختيار الخيارات التي تناسب بنيتك ومتطلباتك.
في الأقسام التالية، سنصف طريقتين مختلفتين لمعالجة تحليل DNS. ولكل طريقة، هناك مزايا وقيود.
المناطق المستضافة الخاصة
يسلط الرسم البياني التالي الضوء على بنية الحل ومكوناته. لاحظ أنه لتبسيط المخطط وإفساح المجال لمزيد من التفاصيل ذات الصلة المطلوبة في هذا القسم، قمنا بإلغاء بعض خيارات الاتصال.
يبدأ الحل بإنشاء منطقة مستضافة خاصة، يليها إنشاء اقتران VPC.
إنشاء منطقة مستضافة خاصة
نبدأ بإنشاء منطقة مستضافة خاصة لتحليل الاسم. لجعل الحل قابلاً للتطوير وسهل الصيانة، يمكنك اختيار إنشاء هذه المنطقة المستضافة الخاصة في نفس حساب مجموعة MSK Serverless؛ في بعض الحالات، يفضل إنشاء منطقة مستضافة خاصة في حساب شبكة مركزي. إن إنشاء المنطقة المستضافة الخاصة في حساب مجموعة MSK Serverless يسهل الإدارة المركزية للمنطقة المستضافة الخاصة إلى جانب مجموعة MSK. يمكننا بعد ذلك ربط المنطقة المستضافة الخاصة المركزية بخوادم VPC داخل الحساب نفسه، أو في حسابات أخرى مختلفة. يمكن أيضًا أن يكون اختيار مركزة المناطق المستضافة الخاصة بك في حساب الشبكة حلاً قابلاً للتطبيق يجب مراعاته.
الغرض من المنطقة المستضافة الخاصة هو أن تكون قادرًا على حل FQDNs لخادم التمهيد بالإضافة إلى جميع الوسطاء المرتبطين بالمجموعة المعينين ديناميكيًا. كما تمت مناقشته سابقًا، فإن تنسيق FQDN لخادم التمهيد هو boot-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com، ويستخدم وسطاء المجموعة التنسيق bxxxx-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com، مع bxxxx كونه معرف الوسيط. تحتاج إلى إنشاء المنطقة المستضافة الخاصة الجديدة مع تعيين النطاق الأساسي على أنه kafka-serverless.Region.amazonaws.com، مع سجل A-Alias يسمى *.kafka-serverless.Region.amazonaws.com يشير إلى نقطة نهاية VPC الإقليمية لمجموعة MSK Serverless في مجموعة MSK VPC. يجب أن يكون هذا كافيًا لتوجيه كل حركة المرور التي تستهدف مجموعتك إلى نقاط نهاية VPC للمجموعة الأساسية التي حددتها في المنطقة المستضافة الخاصة بك.
الآن بعد أن قمت بإنشاء المنطقة المستضافة الخاصة، لكي يعمل تحليل الاسم، تحتاج إلى ربط المنطقة المستضافة الخاصة بكل VPC حيث لديك عملاء لمجموعة MSK (المنتج أو المستهلك).
ربط منطقة مستضافة خاصة مع VPCs في نفس الحساب
بالنسبة إلى VPCs الموجودة في نفس الحساب مثل مجموعة MSK ولم يتم تضمينها في التكوين أثناء إنشاء المجموعة، يمكنك ربطها بالمنطقة المستضافة الخاصة التي تم إنشاؤها باستخدام وحدة تحكم إدارة AWS عن طريق تحرير إعدادات المنطقة المستضافة الخاصة وإضافة VPCs المعنية. لمزيد من المعلومات، راجع ربط المزيد من VPCs بمنطقة مستضافة خاصة.
ربط منطقة مستضافة خاصة في VPCs عبر الحسابات
بالنسبة لأجهزة VPC الموجودة في حساب مختلف غير حساب مجموعة MSK، راجع ربط Amazon VPC ومنطقة مستضافة خاصة قمت بإنشائها باستخدام حسابات AWS مختلفة. الخطوات الرئيسية هي كما يلي:
- قم بإنشاء ترخيص اقتران VPC في الحساب الذي تم إنشاء المنطقة المستضافة الخاصة به (في هذه الحالة، هو نفس الحساب مثل حساب مجموعة MSK Serverless) لتخويل VPCs البعيدة بالارتباط بالمنطقة المستضافة:
- قم بربط VPC بالمنطقة المستضافة الخاصة في الحساب الذي لديك فيه VPCs مع عملاء MSK (الحساب البعيد)، مع الإشارة إلى ترخيص الارتباط الذي قمت بإنشائه مسبقًا:
- احذف ترخيص VPC لربط VPC بالمنطقة المستضافة:
لا يؤثر حذف التفويض على الاقتران، بل يمنعك فقط من إعادة ربط VPC بالمنطقة المستضافة في المستقبل. إذا كنت تريد إعادة ربط VPC بالمنطقة المستضافة، فستحتاج إلى تكرار الخطوتين 1 و2 من هذا الإجراء.
لاحظ أن VPC الخاص بك يحتاج إلى enableDnsSupport و enableDnsHostnames تم تمكين سمات DNS لهذا العمل. يمكن تكوين هذين الإعدادين ضمن إعدادات VPC DNS. لمزيد من المعلومات، راجع سمات DNS في VPC الخاص بك.
تعمل هذه الإجراءات بشكل جيد مع جميع الحسابات البعيدة عندما يتم توسيع الاتصال باستخدام نظير VPC أو Transit Gateway. إذا كان خيار الاتصال الخاص بك يستخدم PrivateLink، فيجب إنشاء المنطقة المستضافة الخاصة في الحساب البعيد بدلاً من ذلك (الحساب الذي توجد به نقاط نهاية PrivateLink VPC). بالإضافة إلى ذلك، يجب إنشاء سجل A-Alias الذي يتحول إلى نقطة نهاية PrivateLink بدلاً من نقطة نهاية مجموعة MSK كما هو موضح في الرسم التخطيطي السابق. سيؤدي هذا إلى تسهيل تحليل الاسم إلى نقطة نهاية PrivateLink. إذا كانت VPCs الأخرى بحاجة إلى الوصول إلى المجموعة من خلال نفس إعداد PrivateLink، فستحتاج إلى اتباع نفس إجراء اقتران المنطقة المستضافة الخاصة كما هو موضح سابقًا وربط VPCs الأخرى الخاصة بك بالمنطقة المستضافة الخاصة التي تم إنشاؤها لـ PrivateLink VPC الخاص بك.
القيود
يحتوي حل المناطق المستضافة الخاصة على بعض القيود الأساسية.
أولاً، لأنك تستخدم kafka-serverless.Region.amazonaws.com باعتباره النطاق الأساسي لمنطقتنا المستضافة الخاصة، ويستخدم سجل A-Alias الخاص بك *.kafka-serverless.Region.amazonaws.com، سيتم توجيه كل حركة المرور إلى خدمة MSK Serverless التي تنشأ من أي VPC مرتبطة بهذه المنطقة المستضافة الخاصة إلى نقطة النهاية الإقليمية لمجموعة VPC المحددة التي حددتها في سجل الاسم المستعار للمنطقة المستضافة.
يكون هذا الحل صالحًا إذا كان لديك مجموعة MSK Serverless واحدة في VPC الخاصة بالخدمة المركزية. إذا كنت بحاجة إلى توفير الوصول إلى مجموعات MSK Serverless متعددة، فيمكنك استخدام نفس الحل ولكن مع تكييف نهج المنطقة المستضافة الخاصة الموزعة بدلاً من النهج المركزي. في نهج المنطقة المستضافة الخاصة الموزعة، يمكن لكل منطقة مستضافة خاصة أن تشير إلى مجموعة محددة. ستتواصل وحدات VPC المرتبطة بهذه المنطقة المستضافة الخاصة المحددة فقط مع المجموعة المعنية المدرجة ضمن المنطقة المستضافة الخاصة المحددة.
بالإضافة إلى ذلك، بعد إنشاء ارتباط VPC بمنطقة مستضافة خاصة لحل *.kafka-serverless.Region.amazonaws.com، لن تتمكن VPC المعنية إلا من الاتصال بالمجموعة المحددة في تلك المنطقة المستضافة الخاصة المحددة وليس أي مجموعة أخرى . الاستثناء لهذه القاعدة هو إذا تم إنشاء مجموعة محلية داخل نفس العميل VPC، وفي هذه الحالة لن يتمكن العملاء داخل VPC إلا من الاتصال بالمجموعة المحلية فقط.
يمكنك أيضًا استخدام PrivateLink لاستيعاب مجموعات متعددة عن طريق إنشاء PrivateLink بالإضافة إلى منطقة مستضافة خاصة لكل مجموعة، وتكرار خطوات التكوين الموضحة مسبقًا.
لا يزال كلا الحلين، باستخدام المناطق المستضافة الخاصة الموزعة أو PrivateLink، خاضعين للقيود التي تنص على أنه بالنسبة لكل عميل VPC، يمكنك فقط الاتصال بمجموعة MSK Serverless واحدة التي تم تكوين المنطقة المستضافة الخاصة المقترنة لها.
في القسم التالي، نناقش حلًا محتملاً آخر.
قواعد المحلل وAWS Resource Access Manager
يوضح الرسم البياني التالي نظرة عامة عالية المستوى على الحل المستخدم الأمازون الطريق 53 قواعد الحل و مدير الوصول إلى موارد AWS.
الحل يبدأ بالإنشاء الطريق 53 نقاط نهاية الحل الواردة والصادرة، المرتبطة بمجموعة MSK VPC. ثم تقوم بإنشاء قاعدة إعادة توجيه محلل في حساب MSK غير المرتبط بأي VPC. بعد ذلك، يمكنك مشاركة قاعدة المحلل عبر الحسابات باستخدام Resource Access Manager. في الحساب البعيد الذي تحتاج إلى توسيع نطاق تحليل الاسم إليه، يتعين عليك قبول مشاركة المورد وربط قواعد المحلل بوحدات VPC المستهدفة الموجودة في الحساب البعيد (الحساب الذي يوجد به عملاء MSK).
لمزيد من المعلومات حول هذا الأسلوب، راجع حالة الاستخدام الثالثة في قم بتبسيط إدارة DNS في بيئة متعددة الحسابات باستخدام Route 53 Resolver.
يستوعب هذا الحل العديد من مجموعات MSK المركزية بدون خادم بطريقة أكثر مرونة وقابلية للتوسع. لذلك، يعتمد الحل على توجيه طلبات DNS ليتم حلها بواسطة VPC حيث توجد مجموعات MSK. يمكن أن تتعايش مجموعات MSK Serverless المتعددة، حيث يمكن للعملاء في VPC معين التواصل مع واحد أو أكثر منهم في نفس الوقت. هذا الخيار غير مدعوم مع أسلوب حل المنطقة المستضافة الخاصة.
القيود
على الرغم من أن هذا الحل له مزاياه، إلا أن له أيضًا بعض القيود.
أولاً، بالنسبة لحساب مستهلك أو منتج مستهدف معين، يجب أن تكون جميع مجموعات MSK Serverless الخاصة بك في نفس VPC للخدمة الأساسية في حساب MSK. ويرجع ذلك إلى حقيقة أنه تم تعيين قاعدة المحلل على مستوى الحساب وتستخدم.kafka-serverless.Region.amazonaws.com كمجال أساسي، وتوجيه حلها إلى زوج محدد من نقطة نهاية محلل VPC الوارد/الصادر داخل خدمة VPC تلك . إذا كنت بحاجة إلى مجموعات منفصلة في VPCs مختلفة، ففكر في إنشاء حسابات منفصلة.
القيد الثاني هو أن جميع وحدات VPC الخاصة بعملائك يجب أن تكون في نفس المنطقة التي يوجد بها MSK Serverless VPC الأساسي. السبب وراء هذا القيد هو أن قواعد المحلل التي تشير إلى زوج نقطة نهاية المحلل (في الواقع، تشير إلى نقطة النهاية الصادرة التي تتكرر في نقاط النهاية الواردة) يجب أن تكون في نفس المنطقة مثل قواعد المحلل، وسيقوم مدير الوصول إلى الموارد بتوسيع المشاركة فقط داخل نفس المنطقة. ومع ذلك، يعد هذا الحل جيدًا عندما يكون لديك مجموعات MSK متعددة في نفس VPC الأساسية، وعلى الرغم من أن عملائك البعيدين موجودون في VPCs وحسابات مختلفة، إلا أنهم لا يزالون داخل نفس المنطقة. يتمثل الحل البديل لهذا القيد في تكرار إنشاء قواعد المحلل ونقطة نهاية المحلل الصادر في منطقة ثانية، حيث تتكرر نقطة النهاية الصادرة مرة أخرى عبر نقطة نهاية المحلل الوارد الأصلية للمنطقة الأولى المرتبطة بمجموعة MSK Serverless VPC (بافتراض تسهيل اتصال IP) . ويمكن بعد ذلك مشاركة قاعدة محلل المنطقة الثانية هذه باستخدام مدير الوصول إلى الموارد داخل المنطقة الثانية.
وفي الختام
يمكنك تكوين MSK Serverless عبر VPC والوصول عبر الحسابات في بيئات متعددة الحسابات باستخدام مناطق مستضافة خاصة أو قواعد محلل Route 53. يتيح لك الحل الذي تمت مناقشته في هذا المنشور مركزية التكوين الخاص بك مع توسيع الوصول عبر الحسابات، مما يجعله حلاً قابلاً للتطوير وسهل الصيانة. أنت تستطيع قم بإنشاء مجموعات MSK Serverless الخاصة بك من خلال الوصول عبر الحسابات للمنتجين والمستهلكين، واصل تركيزك على نتائج أعمالك واكتسب رؤى من مصادر البيانات عبر مؤسستك دون الحاجة إلى تحديد الحجم الصحيح وإدارة البنية الأساسية لـ Kafka.
عن المؤلف
تامر سليمان هو مهندس حلول أول في AWS. إنه يساعد عملاء بائعي البرامج المستقلين (ISV) على الابتكار والبناء والتوسع على AWS. يتمتع بخبرة تزيد عن عقدين من الزمن في الصناعة، وهو مخترع حصل على ثلاث براءات اختراع. تمتد خبرته إلى مجالات تقنية متعددة بما في ذلك الاتصالات والشبكات وتكامل التطبيقات وتحليلات البيانات والذكاء الاصطناعي/تعلم الآلة والنشر السحابي. وهو متخصص في شبكات AWS ولديه شغف عميق بالاعتماد على الآلة والذكاء الاصطناعي والذكاء الاصطناعي التوليدي.
- محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
- PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
- أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
- أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
- أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
- المصدر https://aws.amazon.com/blogs/big-data/secure-connectivity-patterns-for-amazon-msk-serverless-cross-account-access/
