המסמך הזה הוא השני מתוך שלושה מסמכים בקבוצה. המאמר מתאר תבניות נפוצות של ארכיטקטורות היברידיות ומרובות עננים. בנוסף, מופיע תיאור של התרחישים שהדפוסים האלה הכי מתאימים להם. בסוף המאמר מפורטות שיטות מומלצות לשימוש כשפורסים ארכיטקטורות כאלה ב- Google Cloud.
סדרת המסמכים בנושא דפוסי ארכיטקטורה היברידית ומרובת עננים (multi-cloud) מורכבת מהחלקים הבאים:
- יצירת ארכיטקטורות היברידיות ומרובות עננים (multi-cloud): במאמר הזה מוסבר איך לתכנן אסטרטגיה ליצירת הגדרה היברידית ומרובת עננים באמצעות Google Cloud.
- תבניות ארכיטקטורה היברידיות ומרובות עננים: מאמר שבו מוסבר על תבניות ארכיטקטורה נפוצות שכדאי לאמץ כחלק מאסטרטגיה היברידית ומרובת עננים (המסמך הזה).
- דפוסי ארכיטקטורה של רשתות מאובטחות בסביבות היברידיות ומרובות עננים (multi-cloud): מאמר שדן בדפוסי ארכיטקטורה של רשתות ��יברידיות ומרובות עננים מנקודת מבט של רשתות.
לכל ארגון יש פורטפוליו ייחודי של עומסי עבודה של אפליקציות, שמציב דרישות ומגבלות על הארכיטקטורה של הגדרה היברידית או מרובת עננים. למרות שאתם צריכים לתכנן את הארכיטקטורה ולהתאים אותה למגבלות ולדרישות האלה, אתם יכולים להסתמך ��ל כמה דפוסים נפוצים כדי להגדיר את הארכיטקטורה הבסיסית.
דפוס ארכיטקטורה הוא דרך שניתן לחזור עליה כדי לבנות מבנה של כמה רכיבים פונקציונליים של פתרון טכנולוגי, אפליקציה או שירות, כדי ליצור פתרון לשימוש חוזר שעונה על דרישות מסוימות או על תרחישי שימוש מסוימים. פתרון טכנולוגי מבוסס-ענן מורכב לרוב מכמה שירותי ענן נפרדים ומבוזרים. השירותים האלה פועלים יחד כדי לספק את הפונקציונליות הנדרשת. בהקשר הזה, כל שירות נחשב לרכיב פונקציונלי של הפתרון הטכנולוגי. באופן דומה, אפליקציה יכולה לכלול כמה רמות פונקציונליות, מודולים או שירותים, וכל אחד מהם יכול לייצג רכיב פונקציונלי בארכיטקטורת האפליקציה. אפשר ליצור סטנדרטיזציה של ארכיטקטורה כזו כדי לתת מענה לתרחישי שימוש עסקיים ספציפיים, והיא יכולה לשמש כדפוס בסיסי שניתן לשימוש חוזר.
כדי להגדיר באופן כללי תבנית ארכיטקטורה לאפליקציה או לפתרון, צריך לזהות ולהגדיר את הפרטים הבאים:
- הרכיבים של הפתרון או האפליקציה.
- הפונקציות הצפויות לכל רכיב – לדוגמה, פונקציות של קצה קדמי שמספקות ממשק משתמש גרפי או פונקציות של בק-אנד שמספקות גישה לנתונים.
- איך הרכיבים מתקשרים ביניהם ועם מערכות או משתמשים חיצוניים. באפליקציות מודרניות, הרכיבים האלה מתקשרים באמצעות ממשקים או ממשקי API מוגדרים היטב. יש מגוון רחב של מודלים לתקשורת, כמו תקשורת אסינכרונית וסינכרונית, בקשה-תגובה או תקשורת מבוססת-תור.
אלה שתי הקטגוריות העיקריות של דפוסי ארכיטקטורה היברידית ומרובת עננים:
- דפוסי ארכיטקטורה מבוזרת: הדפוסים האלה מסתמכים על פריסה מבוזרת של עומסי עבודה או רכיבי אפליקציה. כלומר, הם מריצים אפליקציה (או רכיבים ספציפיים של האפליקציה) בסביבת המחשוב שהכי מתאימה לדפוס. כך התבנית יכולה לנצל את המאפיינים השונים של סביבות מחשוב מבוזרות ומקושרות.
- תבניות ארכיטקטורה מיותרות: התבניות האלה מבוססות על פריסות מיותרות של עומסי עבודה. בדפוסים האלה, אתם פורסים את אותן אפליקציות ואת הרכיבים שלהן בסביבות מחשוב שונות. המטרה היא לשפר את יכולת הביצועים או את העמידות של אפליקציה, או לשכפל סביבה קיימת לצורך פיתוח ובדיקה.
כשמטמיעים את דפוס הארכיטקטורה שבוחרים, צריך להשתמש בארכיטיפ פריסה מתאים. ארכיטיפים של פריסה הם אזוריים, במספר אזורים או גלובליים. הבחירה הזו מהווה את הבסיס לבניית ארכיטקטורות פריסה ספציפיות לאפליקציות. כל ארכיטיפ פריסה מגדיר שילוב של תחומים שבהם יכולה לפעול אפליקציה. תחומי הכשל האלה יכולים לכלול אזורים או אזורי זמינות, ואפשר להרחיב אותם כך שיכללו את מרכזי הנתונים בארגון או תחומי כשל אצל ספקי ענן אחרים.Google Cloud
הסדרה הזו כוללת את הדפים הבאים:
דפוסי ארכיטקטורה מיותרים
שותפים ביצירת התוכן
הכותב: Marwan Al Shawi | Partner Customer Engineer
תורמי תוכן אחרים:
- סעוד אלבזאי | Customer Engineer, Application Modernization
- Anna Berenberg | Engineering Fellow
- Marco Ferrari | Cloud Solutions Architect
- Victor Moreno | Product Manager, Cloud Networking
- Johannes Passing | Cloud Solutions Architect
- מארק שלגנהוף | כותב טכני, רשתות
- Daniel Strebel | EMEA Solution Lead, Application Modernization
- אמט וויליאמס | מהנדס קשרי מפתחים