בדפוס הארכיטקטורה סביבה היברידית, סביבת הייצור של עומס עבודה נשארת במרכז הנתונים הקיים. לאחר מכן משתמשים בענן הציבורי עבור סביבות הפיתוח והבדיקה או סביבות אחרות. הדפוס הזה מסתמך על פריסה יתירה של אותן אפליקציות במספר סביבות מחשוב. מטרת הפריסה היא לעזור להגדיל את הקיבולת, הגמישות והחוסן.
כשמעריכים אילו עומסי עבודה כדאי להעביר, יכול להיות שתיתקלו במקרים שבהם הפעלת אפליקציה ספציפית בענן ציבורי מציבה אתגרים:
- יכול להיות שתידרשו לשמור נתונים במדינה מסוימת בגלל מגבלות משפטיות או רגולטוריות.
- יכול להיות שתנאי הרישוי של צד שלישי ימנעו מכם להפעיל תוכנות מסוימות בסביבת ענן.
- יכול להיות שאפליקציה תדרוש גישה למכשירי חומרה שזמינים רק באופן מקומי.
במקרים כאלה, צריך להתייחס לא רק לסביבת הייצור אלא לכל הסביבות שקשורות למחזור החיים של האפליקציה, כולל מערכות פיתוח, בדיקה והעברה לבמה. ההגבלות האלה חלות בדרך כלל על סביבת הייצור והנתונים שלה, אבל יכול להיות שהן לא יחולו על סביבות אחרות שלא נעשה בהן שימוש בנתונים בפועל. כדאי לבדוק את זה מול מחלקת התאימות של הארגון או צוות מקביל.
התרשים הבא מציג דפוס אופייני של ארכיטקטורת סביבה היברידית:
הפעלת מערכות פיתוח ובדיקה בסביבות שונות ממערכות הייצור עשויה להיראות מסוכנת, ויכול להיות שהיא תהיה שונה מהשיטות המומלצות הקיימות או מהניסיונות שלכם לצמצם את ההבדלים בין הסביבות. החששות האלה מוצדקים, אבל הם לא רלוונטיים אם מבחינים בין השלבים בתהליכי הפיתוח והבדיקה:
תהליכי הפיתוח, הבדיקה והפריסה שונים לכל אפליקציה, אבל בדרך כלל הם כוללים וריאציות של השלבים הבאים:
- פיתוח: יצירת גרסה מועמדת להפצה.
- בדיקות פונקציונליות או בדיקות קבלה של משתמשים: בדיקה של גרסה מועמדת להפצה כדי לוודא שהיא עומדת בדרישות הפונקציונליות.
- בדיקות ביצועים ואמינות: בדיקה שהמועמד להפצה עומד בדרישות לא פונקציונליות. נקרא גם בדיקת עומס.
- בדיקות של שלבי ביניים או פריסה: בדיקה שהליך הפריסה פועל.
- ייצור: פרסום אפליקציות חדשות או מעודכנות.
בדרך כלל לא כדאי לבצע יותר משלב אחד בסביבה אחת, ולכן כל שלב דורש בדרך כלל סביבה ייעודית אחת או יותר.
המטרה העיקרית של סביבת בדיקה היא להריץ בדיקות פונקציונליות. המטרה העיקרית של סביבת Staging היא לבדוק אם תהליכי הפריסה של האפליקציה פועלים כמצופה. עד שגרסה מגיעה לסביבת ביניים, הבדיקות הפונקציונליות צריכות להסתיים. העברה לבמה היא השלב האחרון לפני פריסת התוכנה לפריסת הייצור.
כדי לוודא שתוצאות הבדיקה משמעותיות ושהן רלוונטיות לפריסת הייצור, קבוצת הסביבות שבהן אתם משתמשים במהלך מחזור החיים של האפליקציה צריכה לעמוד בכללים הבאים, ככל האפשר:
- כל הסביבות שקולות מבחינת הפונקציונליות. כלומר, הארכיטקטורה, ממשקי ה-API והגרסאות של מערכות ההפעלה והספריות זהים, והמערכות מתנהגות באופן זהה בכל הסביבות. השוויון הזה מונע מצבים שבהם אפליקציות פועלות בסביבה אחת אבל לא פועלות בסביבה אחרת, או מצבים שבהם אי אפשר לשחזר פגמים.
- סביבות שמשמשות לבדיקת ביצועים ואמינות, סביבות הכנה וסביבות ייצור הן שקולות מבחינה לא פונקציונלית. כלומר, הביצועים, קנה המידה וההגדרה שלהן, והאופן שבו הן מופעלות ומתוחזקות, זהים או שונים רק בדרכים לא משמעותיות. אחרת, בדיקות הביצועים וההכנה הופכות לחסרות משמעות.
באופן כללי, אין בעיה אם הסביבות שמשמשות לפיתוח ולבדיקות פונקציונליות שונות מהסביבות האחרות מבחינה לא פונקציונלית.
כפי שמוצג בתרשים הבא, סביבות הבדיקה והפיתוח מבוססות על Google Cloud. אפשר להשתמש במסד נתונים מנוהל, כמו Cloud SQL, כאפשרות לפיתוח ולבדיקה ב- Google Cloud. בסביבה המקומית, פיתוח ובדיקה יכולים להשתמש באותו המנוע של מסד הנתונים ובאותה גרסה, בגרסה ששקולה מבחינה פונקציונלית, או בגרסה חדשה שמופצת לסביבת הייצור אחרי שלב הבדיקה. אבל מכיוון שהתשתית הבסיסית של שתי הסביבות לא זהה, הגישה הזו לבדיקת עומס ביצועים לא תקפה.
התרחישים הבאים מתאימים במיוחד לדפוס של סביבה היברידית:
- להשיג שוויון פונקציונלי בכל הסביבות על ידי הסתמכות על Kubernetes כשכבת זמן ריצה משותפת, במקרים שבהם זה רלוונטי ואפשרי.
Google Kubernetes Engine (GKE) יכול להיות טכנולוגיה חשובה שתאפשר את הגישה הזו.
- לוודא שניתן להעביר עומסי עבודה (workloads) ולבצע הפשטה של ההבדלים בין סביבות מחשוב. עם Service mesh של מודל אבטחה של אפס אמון, אתם יכולים לשלוט בהפרדה הנדרשת בין הסביבות השונות ולשמור עליה.
- הפעלת סביבות פיתוח ובדיקות פונקציונליות בענן ציבורי. יכול להיות שהסביבות האלה יהיו שוות ערך מבחינת פונקציונלית לסביבות הנותרות, אבל יכול להיות שיהיו הבדלים בהיבטים לא פונקציונליים, כמו ביצועים. התרשים שלמעלה ממחיש את הרעיון הזה.
- הפעלת סביבות לייצור, לבדיקות ולביצועים (בדיקות עומס) ובדיקות אמינות בסביבת מחשוב פרטית, כדי להבטיח שוויון פונקציונלי ולא פונקציונלי.
שיקולים בתכנון
- צרכים עסקיים: לכל אסטרטגיית פריסה ושחרור של אפליקציות יש יתרונות וחסרונות משלה. כדי לוודא שהגישה שתבחרו תתאים לדרישות הספציפיות שלכם, כדאי לבסס את הבחירות על הערכה יסודית של הצרכים והמגבלות העסקיים שלכם.
- הבדלים בסביבות: במסגרת הדפוס הזה, המטרה העיקרית של השימוש בסביבת הענן היא פיתוח ובדיקה. המצב הסופי הוא אירוח האפליקציה שנבדקה בסביבה הפרטית המקומית (ייצור). כדי להימנע מפיתוח ובדיקה של יכולת שעשויה לפעול כצפוי בסביבת הענן ולהיכשל בסביבת הייצור (במקום), הצוות הטכני צריך להכיר ולהבין את הארכיטקטורות והיכולות של שתי הסביבות. זה כולל תלות באפליקציות אחרות ובמבנה החומרה – לדוגמה, מערכות אבטחה שמבצעות בדיקה של התנועה.
- ניהול: כדי לקבוע מה מותר לחברה לפתח בענן ובאילו נתונים מותר לה להשתמש לבדיקות, צריך להשתמש בתהליך אישור וניהול. התהליך הזה יכול גם לעזור לחברה שלכם לוודא שהיא לא משתמשת בתכונות של הענן בסביבות הפיתוח והבדיקה שלא קיימות בסביבת הייצור המקומית.
- קריטריונים להצלחה: צריכים להיות קריטריונים ברורים, מוגדרים מראש וברי מדידה להצלחת הבדיקה, שתואמים לתקני בקרת האיכות של התוכנה בארגון שלכם. צריך להחיל את התקנים האלה על כל אפליקציה שאתם מפתחים ובודקים.
- יתירות: יכול להיות שסביבות פיתוח ובדיקה לא ידרשו אמינות גבוהה כמו סביבת הייצור, אבל הן עדיין צריכות יכולות יתירות ואפשרות לבדוק תרחישי כשל שונים. הדרישות שלכם לגבי תרחישי כשל עשויות להוביל אתכם לכלול יתירות כחלק מסביבת הפיתוח והבדיקה.
יתרונות
להרצת עומסי עבודה של פיתוח ובדיקות פונקציונליות בענן ציבורי יש כמה יתרונות:
- אתם יכולים להפעיל ולהפסיק סביבות באופן אוטומטי לפי הצורך.
לדוגמה, אתם יכולים להקצות סביבה שלמה לכל פעולת commit או בקשת משיכה, לאפשר הפעלה של בדיקות ואז להשבית אותה שוב. הגישה הזו מציעה גם את היתרונות הבאים:
- כדי לצמצם עלויות, אפשר להפסיק את השימוש במכונות וירטואליות (VM) כשהן לא פעילות, או להקצות סביבות רק לפי דרישה.
- כדי לזרז את הפיתוח והבדיקות, אפשר להפעיל סביבות זמניות לכל בקשת משיכה. בנוסף, כך מצמצמים את עלויות התחזוקה ואת חוסר העקביות בסביבת build.
- הפעלת הסביבות האלה בענן הציבורי עוזרת להכיר את הענן ואת הכלים שקשורים אליו, ונותנת ביטחון בשימוש בהם. זה יכול לעזור במיגרציה של עומסי עבודה אחרים. הגישה הזו שימושית במיוחד אם אתם רוצים לבדוק את ניידות עומסי העבודה באמצעות קונטיינרים ו-Kubernetes – לדוגמה, באמצעות GKE בסביבות שונות.
שיטות מומלצות
כדי להטמיע בהצלחה את דפוס הארכיטקטורה ההיברידית של הסביבה, מומלץ לפעול לפי ההמלצות הבאות:
- מגדירים את דרישות התקשורת של האפליקציה, כולל הרשת האופטימלית ועיצוב האבטחה. לאחר מכן, משתמשים בתבנית של רשת משוכפלת כדי לעצב את ארכיטקטורת הרשת ולמנוע תקשורת ישירה בין מערכות מסביבות שונות. אם נדרשת תקשורת בין סביבות, היא צריכה להתבצע בצורה מבוקרת.
האסטרטגיה שבוחרים לפריסה ולבדיקה של האפליקציה צריכה להתאים ליעדים ולדרישות העסקיות. יכול להיות שזה יכלול הטמעה של שינויים ללא זמן השבתה או הטמעה הדרגתית של תכונות בסביבה ספציפית או בקבוצת משתמשים מסוימת לפני הפצה רחבה יותר.
כדי להפוך עומסי עבודה לניידים ולבצע הפשטה של ההבדלים בין סביבות, אפשר להשתמש בקונטיינרים עם Kubernetes. מידע נוסף זמין במאמר תרשים עזר לארכיטקטורה של סביבה היברידית ב-GKE.
הקמת שרשרת כלים משותפת שפועלת בסביבות מחשוב שונות לצורך פריסה, הגדרה והפעלה של עומסי עבודה. השימוש ב-Kubernetes מאפשר לכם לשמור על העקביות הזו.
מוודאים שצינורות ה-CI/CD עקביים בסביבות המחשוב, ושאותה קבוצה בדיוק של קבצים בינאריים, חבילות או קונטיינרים נפרסת בכל הסביבות האלה.
כשמשתמשים ב-Kubernetes, כדאי להשתמש במערכת CI כמו Tekton כדי להטמיע צינור פריסה שפורס לאשכולות ופועל בסביבות שונות. מידע נוסף זמין במאמר בנושא פתרונות DevOps ב- Google Cloud.
כדי לעזור לכם להשיק באופן רציף אפליקציות מאובטחות ואמינות, מומלץ לשלב אבטחה כחלק בלתי נפרד מתהליך DevOps (DevSecOps). מידע נוסף זמין במאמר השקה והגנה על אפליקציה שפונה לאינטרנט תוך פחות משעה באמצעות ערכת הכלים Dev(Sec)Ops.
שימוש באותם כלים לרישום ביומן ולמעקב בסביבות ענן קיימות וב- Google Cloud. כדאי להשתמש במערכות ניטור קוד פתוח. מידע נוסף זמין במאמר בנושא תבניות של מעקב ורישום ביומן בענן היברידי ובענן מרובה עננים (multi-cloud).
אם צוותים שונים מנהלים את עומסי העבודה של הבדיקות והייצור, יכול להיות שיהיה מקובל להשתמש בכלים נפרדים. עם זאת, שימוש באותם כלים עם הרשאות צפייה שונות יכול לעזור לכם לצמצם את המאמץ והמורכבות של ההדרכה.
כשבוחרים שירותי מסדי נתונים, אחסון והודעות לבדיקות פונקציונליות, כדאי להשתמש במוצרים שיש להם מקבילה מנוהלת ב- Google Cloud. הסתמכות על שירותים מנוהלים עוזרת לצמצם את המאמץ האדמיניסטרטיבי שנדרש לתחזוקת סביבות פיתוח ובדיקה.
כדי להגן על מידע רגיש, מומלץ להצפין את כל התקשורת בזמן ההעברה. אם נדרשת הצפנה בשכבת הקישוריות, יש אפשרויות שונות שמבוססות על פתרון הקישוריות ההיברידי שנבחר. האפשרויות האלה כוללות מנהרות VPN, HA VPN דרך Cloud Interconnect ו-MACsec ל-Cloud Interconnect.
בטבלה הבאה אפשר לראות אילו Google Cloud מוצרים תואמים למוצרי OSS נפוצים.
| מוצר OSS | תואם למוצר Google Cloud |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| CDAP | Cloud Data Fusion |
| Apache Hadoop | Managed Service for Apache Spark |
| MySQL, PostgreSQL | Cloud SQL |
| Redis Cluster, Redis, Memcached | Memorystore |
| Network File System (NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE |