.jpg)
בגוגל קלאוד, נהוג להשתמש במונח "ארכיטקטורת ענן מקומי" בתור מטרה סופית ורצויה עבור אפליקציות שנודדות או נבנות על פלטפורמת הענן של גוגל (GCP). אבל למה אנחנו מתכוונים במונח "ענן מקומי", ואיך אנחנו מעצבים מערכת כזו?
ברמה העילית, ארכיטקטורה של ענן מקומי היא הסתגלות אל מצבים חדשים – אך עם סט שונה של מגבלות ארכיטקטוניות הנמצאות בענן בהשוואה לתשתית פרטית. דרך טובה להסתכל על זה, היא דרך נקודת המבט של ארכיטקט תוכנה ששוקל את האלמנטים העיליים לפני ביצוע כל פעולה:
● הדרישות הפונקציונאליות של המערכת (מה היא צריכה לעשות, קרי 'התהליך עובד לפי הפורמט הבא...')
● הדרישות הלא פונקציונאליות של המערכת (איך היא צריכה לעבוד, קרי 'תהליך של לפחות 200 פקודות בדקה')
● מגבלות (על מה לא להתפקס, קרי 'פקודות חייבות להתעדכן בשלדת המערכת הקיימת שלנו')
בעוד האספקטים הפונקציונאליים כמעט ולא משתנים, הענן מציע ולעתים דורש דרכים שונות בכדי לעמוד בדרישות הלא פונקציונאליות. אם הארכיטקטים לא מצליחים להסתגל לתפיסה עבור המגבלות השונות, המערכות שהם בונים לרוב יהיו שבריריות, יקרות וקשות לתחזוק. מערכת ענן מקומי הבנויה הטוב, תהיה כזו ש"משקמת את עצמה", יעילה, חסכונית וניתנת לעדכון ותחזוק בקלות באמצעות תהליכי הטמעה ושילוח מתמשכים (CI/CD).
החדשות הטובות הן שהענן עשוי מאותו ההרכב של שרתים, דיסקים ורשתות שמייצגים את התשתית המסורתית. המשמעות היא, שכמעט כל העקרונות של עיצוב ארכיטקטוני טוב עדיין תקפים לגבי ארכיטקטורה של ענן מקומי. למרות זאת, חלק מההשערות הפונדמנטליות לגבי איך אותו מארג פועל, משתנות כאשר אתם נמצאים בענן. למשל, אספקה של שרת חליפי יכול לקחת שבועות בסביבות קלאסיות, בעוד בענן ניתן לעשות זאת תוך שניות – ארכיטקטורת האפליקציה שלכם צריכה לקחת זאת בחשבון.
במאמר זה, ריכזנו לכם חמישה עקרונות של ארכיטקטורת ענן מקומי שתעזור לכם לוודא שהעיצובים ינצלו את מלוא היתרונות של הענן בעוד אתם נמנעים מהכשלים של גישות ישנות שעלולים לבוא איתכם לפלטפורמה החדשה.
עקרונות עבור ארכיטקטורה של ענן מקומי
העקרון של ארכיטקטורה עבור הענן (קרי, ארכיטקטורת הענן המקומי) מתרכז על איך למטב את הארכיטקטורות של המערכות עבור היכולות הבלעדיות של הענן. ארכיטקטורות מסורתיות נוטות למטב עבור תשתיות יקרות ומוכנות מראש, שדורשות מאמץ ידני גדול בכדי לבצע שינויים. לכן, התשתית המסורתית מתרכזת בגמישות וביצועים של מספר קטן של רכיבים הנמצאים בה. לעומת זאת, השימוש בענן עולה כסף רק לפי שימוש (ובכך אתם חוסכים כסף כשאתם לא נמצאים בפעילות), ובכך קל הרבה יותר לקיצור תהליכים אוטומטיים (כך שהגדלה והפחתה של סקיילינג נהפכת להליך קל הרבה יותר). לכן, ארכיטקטורה של ענן מקומי מתרכזת בהשגה של גמישות וסקיילינג באמצעות סקיילינג רוחבי, הפצה של העיבוד הנצרך ואוטומציה של החלפת רכיבים שכשלו – בואו ונבחן אותם:
עקרון 1: עיצוב עבור אוטומציה
אוטומציה תמיד הייתה פרקטיקה עבור מערכות תוכנה, אבל הענן הופך את נושא אוטומציית התשתית והרכיבים שיושבים מעליה לקלים מתמיד. למרות שההשקעה הראשונית (לרוב) גבוהה יותר, העדפה של פתרון אוטומציה כמעט תמיד ישתלם בטווח הארוך במונחים של מאמץ, אך גם מבחינת גמישות וביצועים של המערכת שלכם. הליכים אוטומטיים יכולים לשפר, לבצע סקיילינג ולהפיץ את המערכת שלכם הרבה יותר מהר משאדם יכול לעשות בצורה ידנית. כמו שנדון בהמשך, ארכיטקטורה בענן היא לא דיל חד פעמי, ואוטומציה היא ממש לא הליך יוצא מן הכלל – אתם תמצאו מגוון דרכים בהם המערכת שלכם תצטרך לנקוט בפעולה מסוימת, וכך אתם תמצאו דברים חדשים שאתם יכולים להפוך לאוטומטיים.
ישנם מספר אזורים שמתאימים לביצוע אוטומציה במערכות ענן מקומי כגון:
תשתית: בצעו אוטומציה על היצירה של התשתית, ביחד עם עדכונים עבורה, באמצעות כלים כמו מנהל ההפצה של גוגל קלאוד או Terraform.
הטמעה מתמשכת/שילוח מתמשך: הכניסו את הבילד, בדיקה וההפצה להליכים אוטומטיים של החבילות שבונות את המערכת שלכם באמצעות כלים כמו בונה הענן של גוגל קלאוד, Jenkins ו-Spinnaker. לא רק שאתם תהפכו את ההפצה שלכם לאוטומטית, אתם גם תצליחו להפוך הליכים כמו canary testing ורולבאקים.
סקיילינג מוגבר וסקיילינג מופחת: אלא אם כן אתם נמצאים במערכת שכמעט ולא משתנה אף פעם, אתם צריכים לבצע אוטומציה עבור הסקיילינג של המערכת. במקרה ויש עליה בעומס, עליכם ללמד את המערכת לבצע סקיילינג גבוה, ולהפך כאשר יש ירידה בעומס בכדי לצמצם עלויות. בכך תוכלו להתמודד ביתר קלות עם אפליקציות הדורשות משאבים רבים כמו אתרים ציבוריים או אפליקציות קטנות עם טעינה כבדה מהרגיל. לדוגמא, אפליקציות פנימיות יכולות להיות עסוקות במיוחד בזמנים מסוימים, אך להיות חסכוניות במיוחד בשאר הזמן. עבור אפליקציה שלפעמים לא מקבלת טראפיק, או כאלו שאין לכם בעיה אם יהיה עיכוב קל, אתם יכולים אפילו לשקול ביצוע סקיילינג לאפס (הסרה של כל האינסטנסים הרצים, ואתחול של האפליקציה רק כאשר יש בה צורך)
בקרה ושחזור אוטומטי: אתם צריכים לפקח ולהתחבר למערכות הענן המקומי שלכם כבר מההתחלה. התחברות ופיקוח על מאגרי מידע יכול להיות בשימוש באופן טבעי עבור פיקוח על מצב המערכת שלכם, אבל ישנן עוד הרבה מאוד אופציות אחרות. למשל, הם יכולים לתת תובנות בעלות ערך עבור לגבי השימוש במערכת והתנהגות המשתמשים (כמה אנשים משתמשים במערכת, באיזה חלקים הם משתמשים, מה הדיליי הממוצע ועוד). שנית, ניתן להשתמש בהם בכדי לאגור מידע הקשור למצב המערכת (ההארדיסק התמלא שוב, אך האם הוא התמלא מהר יותר מהרגיל? מה היא המערכת בין השימוש בהארדדיסק לבין הניצול שלו בשירות? וכו'). שלישית, הם נקודת פתיחה מעולה עבור ציוות של אוטומציות. עכשיו, כאשר הדיסק מתמלא, במקום רק לתעד שגיאה, אתם גם יכולים לשנות את גודל האחסון בכדי לאפשר למערכת להמשיך לתפקד כרגיל.
עקרון 2: השתמשו בחוכמה ב'מצבים'
אחסון של 'מצבים', בין אם מדובר במידע של משתמש (קרי, החפצים שנמצאים בעגלת הקניות או מספר העובד שלהם) או מצבים של המערכת (קרי, כמה אינסטנסים רצים לכל סוג משימה, איזו גרסאת קוד רצה בפרודקשן ועוד) היא האספקט הקשה ביותר בכל הקשור לבניית ארכיטקטורה של ענן מקומי. לכן, אתם צריכים להנדס את המערכת שלהם להיות מכוונת לגבי מתי ואיך אתם מאחסנים מידע, ולעצב רכיבים 'חסרי מצב' בכל הזדמנות שעומדת בפניכם.
רכיבים חסרי 'מצב' מקלים עליכם במגוון דרכים:
סקיילינג: אם אתם רוצים להגדיל את הסקיילינג, פשוט הוסיפו עוד עותקים, בכדי להפחית את הסקיילינג, הדריכו את האינסטנסים להשמיד את עצמם ברגע שהם השלימו את המשימה הנוכחית.
תיקון: בכדי 'לתקן' אינסטנס שכשל בתוך רכיב, פשוט הפסיקו אותו בדרך הכי מתחשבת שיש ודאגו לתחלופה.
רולבאק: אם יש לכם הפצה רעה, רכיבים חסרי 'מצב' הם כאלו שהרבה קל לבצע בהם אחזור, מפני שאתם יכולים להפסיק אותם ולהפעיל אינסטנסים של הגרסא החדשה במקום.
איזון טעינה רוחבי: כאשר רכיבים הם חסרי 'מצב', איזון הטעינה הופך להרבה יותר פשוט מפני שכל אינסטנס יכול לטפל בכל בקשה. איזון טעינה על פני רכיבים עשירים ב'מצבים' היא קשה הרבה יותר, מפני שמצב הסשן של היוזר לרוב נמצא באינסטנס עצמו, ובכך אתם רק תכריחו את האינסטנסים להתמודד עם כל הבקשות של משתמש מסוים.
עקרון 3: העדיפו שירותים מנוהלים
הענן הוא הרבה יותר מתשתית – רוב ספקי הענן מציעים סט של שירותים מנוהלים, המציעים לכם כל מיני סוגים של פונקציונאליות שמקלים על כאב הראש שאתם מקבלים מניהול של תוכנות או תשתית בצד השרת. למרות זאת, ארגונים רבים נזהרים בכל הנוגע ליצירת יתרון באמצעות אותם שירותים, מפני שהם חוששים ממקרה שבו הם יהיו 'תלויים בספק'. אמנם מדובר בחשש מובן לחלוטין, אך שירותים מנוהלים לרוב יכולים לחסוך לארגונים זמן ומשאבים רבים, ולהקנות ראש שקט.
אם נדבר בצורה כללית, ההחלטה של האם כדאי לכם להשתמש בשירותים מנוהלים מסתכמת בניידות אל מול הוצאות עקיפות הקשורות לביצועים. במונחים של כסף וכישורים, השירותים המנוהלים (שכנראה) מעניינים אתכם מתחלקים ל-3 קטגוריות עיקריות:
ניהול של שירותים בקוד פתוח/מותאמים לקוד פתוח: שירותים שמנוהלים בקוד פתוח (כמו למשל CloudSQL), או מציעים ממשק מותאם לקוד פתוח (כמו למשל Cloud Bigtable), הם כמעט תמיד אופציה שעדיפה עבורכם, מפני שהם נותנים לכם הרבה במינימום סיכון.
שירותים מנוהלים עם חסכון גדול בביצועים: חלק מהשירותים לא תמיד יעבדו עם קוד פתוח, לחלקם לא תמצאו תחליפים בקוד פתוח, ולחלקם יהיו אלטרנטיבות, אך כאלו שפחות טובות משמעותית – והן עדיין שוות את הסיכון. למשל, BigQuery נמצא בשימוש בקרב ארגונים רבים, מפני שמאוד קל לתפעל אותו.
כל השאר: וגם כאן יש את המקרים הקשים, בהם אין דרך קלה לבצע נדידה למוצר אחר, ולא תמיד ישנם יתרונות ברורים הנראים לעין. אתם תצטרכו לבחון את המקרים האלו בנפרד, ולשקול דברים כמו החשיבות האסטרטגית של השירות עבורכם, את ההוצאות העקיפות של הביצועים הנדרשים בהרצה עצמית, ואת המאמץ הנדרש בכדי לנדוד לפתרון אחר.
למרות זאת, ניסיון פרקטי הוכיח שרוב הארכיטקטורות של הענן המקומי מעדיפות שירותים מנוהל: הסיכון של נדידה אליהן לרוב כמעט ולא גובר על החסכונות העצומים של זמן, מאמץ וסיכונים ביצועיים הקשורים לניהול על ידי ספק הענן.
עקרון 4: התאמנו כמו שצריך על ההגנה
ארכיטקטורות מסורתיות מסתמכות על הגנה היקפית, בעיקר לפי הערכה גסה של "דברים טובים בפנים, דברים רעים בחוץ", אך לרוע המזל, הגישה הזו תמיד הייתה פגיעה להתקפות פנימיות ואיומים חיצוניים כמו פישינג 'חנית'. בנוסף, הלחץ הגובר בנוגע לאספקה של עבודה גמישה וניידת רק החמיר את התפיסה השלילית לגבי רשת היקפית.
השורשים של הארכיטקטורות בענן המקומי בשירותים המשתמשים באינטרנט, ולכן הם תמיד נבנו במחשבה של הגנה מפני מתקפות חיצוניות. לכן, הם פיתחו גישה של הגנה מעמיקה על ידי הפעלה של הליכי זיהוי בין כל רכיב, ובכך צמצמו את האמון בין אותם רכיבים (אפילו אם הם 'פנימיים'), כתוצאה מכך, אין 'בפנים' ו'בחוץ'.
ארכיטקטורות ענן מקומי צריכות להרחיב את הרעיון מעבר לזיהוי בכדי לכלול דברים כמו הגבלת קצב והזרקת סקריפטים, וכל רכיב בעיצוב צריך לפעול בכדי להגן על עצמו מהרכיבים האחרים. כך, לא רק שהארכיטקטורה מאוד גמישה, אלא שהיא גם הופכת את השירותים החדשים לקלים להפצה בסביבת ענן, בה הם לא בהכרח תהיה תקשורת בין השירות למשתמשים שלו.
עקרון 5: תמיד תתכננו
אחד מעקרונות הבסיס של מערכת ענן מקומי היא שהיא תמיד מתפתחת, וזהו עקרון נכון עבור הארכיטקט עצמו. בתור ארכיטקט של ענן מקומי, אתם תמיד צריכים לחפש איפה אפשר לשפר, לפשט ולשפר את הארכיטקטורה של המערכת שלכם, ממש כמו שהצרכים של הארגון שלכם משתנים. למרות שאין ספק שמדובר בהשקעה מתמדת, השיעורים של העבר מלמדים מסקנות פשוטות – התפתחו, גדלו והגיבו. מערכות טכנולוגיות מידע צריכות לחיות, לנשום ולהשתנות. מערכות טכנולוגיות מידע מאובנות ומתות לרוב יביאו את הארגון לעצירה כללית, כזו שלא תיתן להם להגיב לסיכונים חדשים והזדמנויות.
המשתנה היחיד הוא שינוי
בממלכת החיות, הישרדות היא מנת חלקם של אלו שמסתגלים לסביבה שלהם. זהו לא מסע ליניארי מ'רע' ל'טוב' או מ'פרימטיבי' ל'מפותח', אלא מעין 'תרשים זרימה' מתמשך. ככל שהסביבה משתנה, לחץ מופעל על המינים בכדי להתפתח ולהסתגל למצב החדש. באופן דומה, ארכיטקטורות ענן מקומי לא מחליפות את אלו המסורתיות, אבל הן בהחלט מסתגלות למערכת השונה לחלוטין של הענן. הענן תופס לאט לאט את מקומו בתור הסביבה הטבעית של ארגונים רבים, וכשל בהתפתחות והסתגלות יכול להיות הרסני עבורכם (כמו שמינים רבים יוכלו להעיד), בטח שלא בטווח הארוך.
העקרונות שהוצגו במאמר הם לא נוסחת קסם שנועדה ליצור ארכיטקטורה של ענן מקומי, אבל הוא בהחלט אמור לספק לכם נהלים ברורים וטובים לגבי כיצד תוכלו לנצל את המקסימום מהענן. יתרון נוסף במעבר והסתגלות של הארכיטקטורות שלכם עבור הענן מקנה לכם את ההזדמנות להשתפר ולהסתגל אליהן בדרכים שונות, ובכך לגרום להן להסתגל לקראת המעבר הסביבתי הבא שלכם. שינוי יכול להיות לא קל, אבל כמו שהאבולוציה כבר לימדה אותנו – במהלך מיליארדי שנים, אתם לא חייבים להיות הכי טובים בכדי לשרוד – אתם רק צריכים להיות בעלי יכולת הסתגלות.
מאת: מערכת IsraelClouds
רוצים להתעדכן בתכנים נוספים בנושאי GCP? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
בגוגל קלאוד, נהוג להשתמש במונח "ארכיטקטורת ענן מקומי" בתור מטרה סופית ורצויה עבור אפליקציות שנודדות או נבנות על פלטפורמת הענן של גוגל (GCP). אבל למה אנחנו מתכוונים במונח "ענן מקומי", ואיך אנחנו מעצבים מערכת כזו?
ברמה העילית, ארכיטקטורה של ענן מקומי היא הסתגלות אל מצבים חדשים – אך עם סט שונה של מגבלות ארכיטקטוניות הנמצאות בענן בהשוואה לתשתית פרטית. דרך טובה להסתכל על זה, היא דרך נקודת המבט של ארכיטקט תוכנה ששוקל את האלמנטים העיליים לפני ביצוע כל פעולה:
● הדרישות הפונקציונאליות של המערכת (מה היא צריכה לעשות, קרי 'התהליך עובד לפי הפורמט הבא...')
● הדרישות הלא פונקציונאליות של המערכת (איך היא צריכה לעבוד, קרי 'תהליך של לפחות 200 פקודות בדקה')
● מגבלות (על מה לא להתפקס, קרי 'פקודות חייבות להתעדכן בשלדת המערכת הקיימת שלנו')
בעוד האספקטים הפונקציונאליים כמעט ולא משתנים, הענן מציע ולעתים דורש דרכים שונות בכדי לעמוד בדרישות הלא פונקציונאליות. אם הארכיטקטים לא מצליחים להסתגל לתפיסה עבור המגבלות השונות, המערכות שהם בונים לרוב יהיו שבריריות, יקרות וקשות לתחזוק. מערכת ענן מקומי הבנויה הטוב, תהיה כזו ש"משקמת את עצמה", יעילה, חסכונית וניתנת לעדכון ותחזוק בקלות באמצעות תהליכי הטמעה ושילוח מתמשכים (CI/CD).
החדשות הטובות הן שהענן עשוי מאותו ההרכב של שרתים, דיסקים ורשתות שמייצגים את התשתית המסורתית. המשמעות היא, שכמעט כל העקרונות של עיצוב ארכיטקטוני טוב עדיין תקפים לגבי ארכיטקטורה של ענן מקומי. למרות זאת, חלק מההשערות הפונדמנטליות לגבי איך אותו מארג פועל, משתנות כאשר אתם נמצאים בענן. למשל, אספקה של שרת חליפי יכול לקחת שבועות בסביבות קלאסיות, בעוד בענן ניתן לעשות זאת תוך שניות – ארכיטקטורת האפליקציה שלכם צריכה לקחת זאת בחשבון.
במאמר זה, ריכזנו לכם חמישה עקרונות של ארכיטקטורת ענן מקומי שתעזור לכם לוודא שהעיצובים ינצלו את מלוא היתרונות של הענן בעוד אתם נמנעים מהכשלים של גישות ישנות שעלולים לבוא איתכם לפלטפורמה החדשה.
עקרונות עבור ארכיטקטורה של ענן מקומי
העקרון של ארכיטקטורה עבור הענן (קרי, ארכיטקטורת הענן המקומי) מתרכז על איך למטב את הארכיטקטורות של המערכות עבור היכולות הבלעדיות של הענן. ארכיטקטורות מסורתיות נוטות למטב עבור תשתיות יקרות ומוכנות מראש, שדורשות מאמץ ידני גדול בכדי לבצע שינויים. לכן, התשתית המסורתית מתרכזת בגמישות וביצועים של מספר קטן של רכיבים הנמצאים בה. לעומת זאת, השימוש בענן עולה כסף רק לפי שימוש (ובכך אתם חוסכים כסף כשאתם לא נמצאים בפעילות), ובכך קל הרבה יותר לקיצור תהליכים אוטומטיים (כך שהגדלה והפחתה של סקיילינג נהפכת להליך קל הרבה יותר). לכן, ארכיטקטורה של ענן מקומי מתרכזת בהשגה של גמישות וסקיילינג באמצעות סקיילינג רוחבי, הפצה של העיבוד הנצרך ואוטומציה של החלפת רכיבים שכשלו – בואו ונבחן אותם:
עקרון 1: עיצוב עבור אוטומציה
אוטומציה תמיד הייתה פרקטיקה עבור מערכות תוכנה, אבל הענן הופך את נושא אוטומציית התשתית והרכיבים שיושבים מעליה לקלים מתמיד. למרות שההשקעה הראשונית (לרוב) גבוהה יותר, העדפה של פתרון אוטומציה כמעט תמיד ישתלם בטווח הארוך במונחים של מאמץ, אך גם מבחינת גמישות וביצועים של המערכת שלכם. הליכים אוטומטיים יכולים לשפר, לבצע סקיילינג ולהפיץ את המערכת שלכם הרבה יותר מהר משאדם יכול לעשות בצורה ידנית. כמו שנדון בהמשך, ארכיטקטורה בענן היא לא דיל חד פעמי, ואוטומציה היא ממש לא הליך יוצא מן הכלל – אתם תמצאו מגוון דרכים בהם המערכת שלכם תצטרך לנקוט בפעולה מסוימת, וכך אתם תמצאו דברים חדשים שאתם יכולים להפוך לאוטומטיים.
ישנם מספר אזורים שמתאימים לביצוע אוטומציה במערכות ענן מקומי כגון:
תשתית: בצעו אוטומציה על היצירה של התשתית, ביחד עם עדכונים עבורה, באמצעות כלים כמו מנהל ההפצה של גוגל קלאוד או Terraform.
הטמעה מתמשכת/שילוח מתמשך: הכניסו את הבילד, בדיקה וההפצה להליכים אוטומטיים של החבילות שבונות את המערכת שלכם באמצעות כלים כמו בונה הענן של גוגל קלאוד, Jenkins ו-Spinnaker. לא רק שאתם תהפכו את ההפצה שלכם לאוטומטית, אתם גם תצליחו להפוך הליכים כמו canary testing ורולבאקים.
סקיילינג מוגבר וסקיילינג מופחת: אלא אם כן אתם נמצאים במערכת שכמעט ולא משתנה אף פעם, אתם צריכים לבצע אוטומציה עבור הסקיילינג של המערכת. במקרה ויש עליה בעומס, עליכם ללמד את המערכת לבצע סקיילינג גבוה, ולהפך כאשר יש ירידה בעומס בכדי לצמצם עלויות. בכך תוכלו להתמודד ביתר קלות עם אפליקציות הדורשות משאבים רבים כמו אתרים ציבוריים או אפליקציות קטנות עם טעינה כבדה מהרגיל. לדוגמא, אפליקציות פנימיות יכולות להיות עסוקות במיוחד בזמנים מסוימים, אך להיות חסכוניות במיוחד בשאר הזמן. עבור אפליקציה שלפעמים לא מקבלת טראפיק, או כאלו שאין לכם בעיה אם יהיה עיכוב קל, אתם יכולים אפילו לשקול ביצוע סקיילינג לאפס (הסרה של כל האינסטנסים הרצים, ואתחול של האפליקציה רק כאשר יש בה צורך)
בקרה ושחזור אוטומטי: אתם צריכים לפקח ולהתחבר למערכות הענן המקומי שלכם כבר מההתחלה. התחברות ופיקוח על מאגרי מידע יכול להיות בשימוש באופן טבעי עבור פיקוח על מצב המערכת שלכם, אבל ישנן עוד הרבה מאוד אופציות אחרות. למשל, הם יכולים לתת תובנות בעלות ערך עבור לגבי השימוש במערכת והתנהגות המשתמשים (כמה אנשים משתמשים במערכת, באיזה חלקים הם משתמשים, מה הדיליי הממוצע ועוד). שנית, ניתן להשתמש בהם בכדי לאגור מידע הקשור למצב המערכת (ההארדיסק התמלא שוב, אך האם הוא התמלא מהר יותר מהרגיל? מה היא המערכת בין השימוש בהארדדיסק לבין הניצול שלו בשירות? וכו'). שלישית, הם נקודת פתיחה מעולה עבור ציוות של אוטומציות. עכשיו, כאשר הדיסק מתמלא, במקום רק לתעד שגיאה, אתם גם יכולים לשנות את גודל האחסון בכדי לאפשר למערכת להמשיך לתפקד כרגיל.
עקרון 2: השתמשו בחוכמה ב'מצבים'
אחסון של 'מצבים', בין אם מדובר במידע של משתמש (קרי, החפצים שנמצאים בעגלת הקניות או מספר העובד שלהם) או מצבים של המערכת (קרי, כמה אינסטנסים רצים לכל סוג משימה, איזו גרסאת קוד רצה בפרודקשן ועוד) היא האספקט הקשה ביותר בכל הקשור לבניית ארכיטקטורה של ענן מקומי. לכן, אתם צריכים להנדס את המערכת שלהם להיות מכוונת לגבי מתי ואיך אתם מאחסנים מידע, ולעצב רכיבים 'חסרי מצב' בכל הזדמנות שעומדת בפניכם.
רכיבים חסרי 'מצב' מקלים עליכם במגוון דרכים:
סקיילינג: אם אתם רוצים להגדיל את הסקיילינג, פשוט הוסיפו עוד עותקים, בכדי להפחית את הסקיילינג, הדריכו את האינסטנסים להשמיד את עצמם ברגע שהם השלימו את המשימה הנוכחית.
תיקון: בכדי 'לתקן' אינסטנס שכשל בתוך רכיב, פשוט הפסיקו אותו בדרך הכי מתחשבת שיש ודאגו לתחלופה.
רולבאק: אם יש לכם הפצה רעה, רכיבים חסרי 'מצב' הם כאלו שהרבה קל לבצע בהם אחזור, מפני שאתם יכולים להפסיק אותם ולהפעיל אינסטנסים של הגרסא החדשה במקום.
איזון טעינה רוחבי: כאשר רכיבים הם חסרי 'מצב', איזון הטעינה הופך להרבה יותר פשוט מפני שכל אינסטנס יכול לטפל בכל בקשה. איזון טעינה על פני רכיבים עשירים ב'מצבים' היא קשה הרבה יותר, מפני שמצב הסשן של היוזר לרוב נמצא באינסטנס עצמו, ובכך אתם רק תכריחו את האינסטנסים להתמודד עם כל הבקשות של משתמש מסוים.
עקרון 3: העדיפו שירותים מנוהלים
הענן הוא הרבה יותר מתשתית – רוב ספקי הענן מציעים סט של שירותים מנוהלים, המציעים לכם כל מיני סוגים של פונקציונאליות שמקלים על כאב הראש שאתם מקבלים מניהול של תוכנות או תשתית בצד השרת. למרות זאת, ארגונים רבים נזהרים בכל הנוגע ליצירת יתרון באמצעות אותם שירותים, מפני שהם חוששים ממקרה שבו הם יהיו 'תלויים בספק'. אמנם מדובר בחשש מובן לחלוטין, אך שירותים מנוהלים לרוב יכולים לחסוך לארגונים זמן ומשאבים רבים, ולהקנות ראש שקט.
אם נדבר בצורה כללית, ההחלטה של האם כדאי לכם להשתמש בשירותים מנוהלים מסתכמת בניידות אל מול הוצאות עקיפות הקשורות לביצועים. במונחים של כסף וכישורים, השירותים המנוהלים (שכנראה) מעניינים אתכם מתחלקים ל-3 קטגוריות עיקריות:
ניהול של שירותים בקוד פתוח/מותאמים לקוד פתוח: שירותים שמנוהלים בקוד פתוח (כמו למשל CloudSQL), או מציעים ממשק מותאם לקוד פתוח (כמו למשל Cloud Bigtable), הם כמעט תמיד אופציה שעדיפה עבורכם, מפני שהם נותנים לכם הרבה במינימום סיכון.
שירותים מנוהלים עם חסכון גדול בביצועים: חלק מהשירותים לא תמיד יעבדו עם קוד פתוח, לחלקם לא תמצאו תחליפים בקוד פתוח, ולחלקם יהיו אלטרנטיבות, אך כאלו שפחות טובות משמעותית – והן עדיין שוות את הסיכון. למשל, BigQuery נמצא בשימוש בקרב ארגונים רבים, מפני שמאוד קל לתפעל אותו.
כל השאר: וגם כאן יש את המקרים הקשים, בהם אין דרך קלה לבצע נדידה למוצר אחר, ולא תמיד ישנם יתרונות ברורים הנראים לעין. אתם תצטרכו לבחון את המקרים האלו בנפרד, ולשקול דברים כמו החשיבות האסטרטגית של השירות עבורכם, את ההוצאות העקיפות של הביצועים הנדרשים בהרצה עצמית, ואת המאמץ הנדרש בכדי לנדוד לפתרון אחר.
למרות זאת, ניסיון פרקטי הוכיח שרוב הארכיטקטורות של הענן המקומי מעדיפות שירותים מנוהל: הסיכון של נדידה אליהן לרוב כמעט ולא גובר על החסכונות העצומים של זמן, מאמץ וסיכונים ביצועיים הקשורים לניהול על ידי ספק הענן.
עקרון 4: התאמנו כמו שצריך על ההגנה
ארכיטקטורות מסורתיות מסתמכות על הגנה היקפית, בעיקר לפי הערכה גסה של "דברים טובים בפנים, דברים רעים בחוץ", אך לרוע המזל, הגישה הזו תמיד הייתה פגיעה להתקפות פנימיות ואיומים חיצוניים כמו פישינג 'חנית'. בנוסף, הלחץ הגובר בנוגע לאספקה של עבודה גמישה וניידת רק החמיר את התפיסה השלילית לגבי רשת היקפית.
השורשים של הארכיטקטורות בענן המקומי בשירותים המשתמשים באינטרנט, ולכן הם תמיד נבנו במחשבה של הגנה מפני מתקפות חיצוניות. לכן, הם פיתחו גישה של הגנה מעמיקה על ידי הפעלה של הליכי זיהוי בין כל רכיב, ובכך צמצמו את האמון בין אותם רכיבים (אפילו אם הם 'פנימיים'), כתוצאה מכך, אין 'בפנים' ו'בחוץ'.
ארכיטקטורות ענן מקומי צריכות להרחיב את הרעיון מעבר לזיהוי בכדי לכלול דברים כמו הגבלת קצב והזרקת סקריפטים, וכל רכיב בעיצוב צריך לפעול בכדי להגן על עצמו מהרכיבים האחרים. כך, לא רק שהארכיטקטורה מאוד גמישה, אלא שהיא גם הופכת את השירותים החדשים לקלים להפצה בסביבת ענן, בה הם לא בהכרח תהיה תקשורת בין השירות למשתמשים שלו.
עקרון 5: תמיד תתכננו
אחד מעקרונות הבסיס של מערכת ענן מקומי היא שהיא תמיד מתפתחת, וזהו עקרון נכון עבור הארכיטקט עצמו. בתור ארכיטקט של ענן מקומי, אתם תמיד צריכים לחפש איפה אפשר לשפר, לפשט ולשפר את הארכיטקטורה של המערכת שלכם, ממש כמו שהצרכים של הארגון שלכם משתנים. למרות שאין ספק שמדובר בהשקעה מתמדת, השיעורים של העבר מלמדים מסקנות פשוטות – התפתחו, גדלו והגיבו. מערכות טכנולוגיות מידע צריכות לחיות, לנשום ולהשתנות. מערכות טכנולוגיות מידע מאובנות ומתות לרוב יביאו את הארגון לעצירה כללית, כזו שלא תיתן להם להגיב לסיכונים חדשים והזדמנויות.
המשתנה היחיד הוא שינוי
בממלכת החיות, הישרדות היא מנת חלקם של אלו שמסתגלים לסביבה שלהם. זהו לא מסע ליניארי מ'רע' ל'טוב' או מ'פרימטיבי' ל'מפותח', אלא מעין 'תרשים זרימה' מתמשך. ככל שהסביבה משתנה, לחץ מופעל על המינים בכדי להתפתח ולהסתגל למצב החדש. באופן דומה, ארכיטקטורות ענן מקומי לא מחליפות את אלו המסורתיות, אבל הן בהחלט מסתגלות למערכת השונה לחלוטין של הענן. הענן תופס לאט לאט את מקומו בתור הסביבה הטבעית של ארגונים רבים, וכשל בהתפתחות והסתגלות יכול להיות הרסני עבורכם (כמו שמינים רבים יוכלו להעיד), בטח שלא בטווח הארוך.
העקרונות שהוצגו במאמר הם לא נוסחת קסם שנועדה ליצור ארכיטקטורה של ענן מקומי, אבל הוא בהחלט אמור לספק לכם נהלים ברורים וטובים לגבי כיצד תוכלו לנצל את המקסימום מהענן. יתרון נוסף במעבר והסתגלות של הארכיטקטורות שלכם עבור הענן מקנה לכם את ההזדמנות להשתפר ולהסתגל אליהן בדרכים שונות, ובכך לגרום להן להסתגל לקראת המעבר הסביבתי הבא שלכם. שינוי יכול להיות לא קל, אבל כמו שהאבולוציה כבר לימדה אותנו – במהלך מיליארדי שנים, אתם לא חייבים להיות הכי טובים בכדי לשרוד – אתם רק צריכים להיות בעלי יכולת הסתגלות.
מאת: מערכת IsraelClouds
רוצים להתעדכן בתכנים נוספים בנושאי GCP? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר