המסמך הזה הוא השני מתוך שלושה מסמכים בקבוצה. המאמר מתאר תבניות נפוצות של ארכיטקטורות היברידיות ומרובות עננים (multi-cloud). בנוסף, מופיע תיאור של התרחישים שהדפוסים האלה הכי מתאימים להם. בסוף המאמר מפורטות שיטות מומלצות לשימוש בארכיטקטורות כאלה ב- Google Cloud.
סדרת המסמכים בנושא דפוסי ארכיטקטורה היברידית ומרובת עננים (multi-cloud) כוללת את החלקים הבאים:
- יצירת ארכיטקטורות היברידיות ומרובות עננים (multi-cloud): במאמר הזה מוסבר איך לתכנן אסטרטגיה ליצירת הגדרה היברידית ומרובת עננים באמצעות Google Cloud.
- תבניות של ארכיטקטורות היברידיות ומרובות עננים (multi-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
- Ammett Williams | Developer Relations Engineer