10 התכונות של שירותי ענן (Cloud Computing)

מבולבלים מכל הדיבורים על מחשוב ענן? מרגישים שאתם זקוקים לקצת יותר הבנה כדי להיות בעניינים?

זהו פוסט המשך לפוסט המבוא בו תיארתי את ההבדל בין PaaS, SaaS ו IaaS.

אפליקציות ענן הן שונות ומשונות. לעתים אלו אפליקציות עסקיות שלמות (כמו NetSuite) ו Salesforce, לעתים זהו שירות ממוקד (כגון Geo Location). ישנם עננים ציבוריים (Amazon), שיתופיים (למשל – ממשל) ועננים פרטיים (פנים-ארגוניים), ישנם ספקי תשתית (Amazon) וספקי Hosting שאינם בהכרח ספקי-ענן. מה הופך אפליקציה להיות אפליקצית ענן או שירות להיות שירות ענן?
התשובה כמובן היא לא מוחלטת ויש וריאציות שונות ומשונות של ספקים ושירותים. בכל זאת אספתי את עשרת המאפיינים העקריים של אפליקציות ושירותים בענן.

קודם כל כמה הגדרות שאשתמש בהן בפוסט זה:

ספק שירותי הענן – Amazon, Salesforce, Microsoft או Google. החברה אשר מבצעת Hosting ומספקת לי תשתיות ושירותים עליהם אבנה את אפליקציית הענן שלי.
שירות ענן – תשתיות כגון EC2 של Amazon או Azure של מייקרוסופט בעזרתם אני אבנה את האפליקציה שלי.
אפליקציית ענן – האפליקציה הסופית למשתמש הקצה אותה אני מפתח, תוך כדי שימוש בשירותי ענן המסופקים על ידי ספקי שירותי ענן.

1.Hosting או Off-Premises – בניגוד לשירותים On-Premises שמנוהלות בחוות השרתים של הארגון, אפליקציות ענן לרוב יותקנו על מחשבים של ספק שירות הענן ומחוץ לגבולות הארגון. לעובדה זו יש שתי השלכות חשובות: אחת – המידע בין משתמש הקצה לשירות מועבר על גבי האינטרנט (ולא ברשת הפנימית של הארגון או VPN). שנייה – המידע נשמר ומעובד מחוץ ל Firewall של הארגון. התקשורת בין המשתמש לשירות חוצה גם את הגבולות הפיסיים וגם גבולות האבטחה של הארגון.

2. אלסטיות לגדול ולהצטמצם ע"פ הצורך. עקרון שהולך יד-ביד עם שירותי הענן הוא עיקרון של On-Demand: שימוש על פי הצורך. לדוגמה: אנו אתר מכירות ויש לנו Sale מטורף? אנו צופים תעבורה כפולה מהרגיל בשבוע הקרוב? ספקי Hosting יאפשרו לנו להכפיל את מספר השרתים בשימוש תוך דקות ולהפסיק להשתמש אחרי שבוע. באתרי מכירות מקוונים לקהל האמריקאי, שבהן חלק נכבד מהמכירות השנתיות מתבצע בתקופת חג-המולד, זהו ההבדל בין החזקת חומרה כפולה ומשולשת כל השנה (מי יודע כמה תעבורה תהיה בסוף השנה? – פספוס מכירות הוא דבר בלתי נסבל) על מנת להשתמש בה למשך חודש בודד בשנה [1].

3. Virtualization – אפליקציות ענן לרוב אינן מותקנות ישירות על מערכת ההפעלה. על מנת לספק אלסטיות גבוהה, קרי – להגדיל ולהקטין את נפח השירות בצורה מהירה, ספק השירות חייב להיות מסוגל להקצות עוד מכונות (חומרה) ללקוח בזמן קצר ביותר. אם על כל ביקוש לעוד כח חישוב / אחסון לשירות מסוים היה צורך באיש Operations שמבצע התקנה פיסית של שרת – התגובה תהיה איטית למדי.

הפתרון בעולם ה IaaS הוא להתקין מערכת הפעלה (Host OS) עליה תוכנת וירטואליזציה (Hypervisor). ה Hypervisor יריץ (ע"פ דרישה) מערכת הפעלה (אחת או יותר), הנקראות Guest OS, שעליה יותקן ה Image של הלקוח. ה Image הוא העתק של מערכת הפעלה המותקנת עם התוכנה שלכם ומקונפגת בהתאם – מוכנה לפעולה. בסביבות שונות (לדוגמה, Amazon) ספק השירות מציע מבחר של Images מוכנים של מערכות הפעלה והסדרי רישיונות עם היצרן (מייקרוסופט) על מנת להקל את התהליך למשתמש. פשוט בקשו "מכונה גדולה עם Windows Server 2008 64bit" ותוך חצי דקה יש לכם שרת online מוכן לפעולה.

מצד הספק, על מנת לספק את השירות הנ"ל, הוא פשוט בוחר שרת פיסי שאינו בשימוש (או שבדיוק הוחזר ל pool ע"י לקוח אחר), סוגר את התהליך של Guest OS אחד ומפעיל Guest OS אחר על סמך ה Image שסיפקתם לו (שלרוב שמור ברשת, אמאזון משתמשת ב S3 – שירות האחסון המבוזר שלה לשמור גם את ה Images). לא צריך לגשת פיסית למחשב, לא צריך מעורבות של איש Operations ואפילו לא צריך Restart. נהדר!

בתחום הוירטואליזציה יש 4 שחקניות מרכזיות:

VMWare (שנרכשה ע"י EMC) – מסחרית, ותיקה ובעלת סט עשיר של יכולות. [עדכון 2014: למרבה ההפתעה, היא עדיין פתרון הוירטואליזציה הנפוץ ביותר].
KVM (קיצור של Kernel-Based-Virtual Machine) – פתרון חינמי, ופופולארי, ללינוקס.
XEN – במקור חינמית, אך נפוצים שימושים בגרסאות מסחריות, כמו XenServer של Citrix.
VirtualBox של אורקל (במקור: של Sun), דומה בהיבטים רבים ל VMWare.

ישנה גישה לוירטואליזציה הנקראת Full Virtualization (למשל VMWare) – שזו הגישה הנפוצה ובעלת תאימות טובה למערכות ישנות, וגישה אחרת בשם Paravirtualization (המספקת שכבה דומה יותר לחומרה המקורית וכך חוסכת עבודה מה Guest OS) – אשר בכדי להשתמש בה יש צורך בתמיכה ספציפית ממערכת ההפעלה. דוגמה נפוצה ל Paravirtualization בימנו היא XEN. עוד גישה נפוצה מאוד לאחרונה, אותה מאמצים ענקי המחשוב (כמו גוגל, או נטפליקס) היא גישת ה Containers. כתבתי פוסט העוסק בוירטואליזציה.

4. חיוב ע"פ שימוש בפועל – כפי שהוזכר בנקודה מס' 2, השאיפה היא לחייב ע"פ שימוש בפועל. מכיוון ויתכן שעל אותו המחשב רצים כמה שירותים של לקוחות שונים (בעקבות וירטואליזציה בעיקר), לכל ספק שירותי ענן שיטה משלו לחייב ע"פ כמות שימוש: כמות שימוש ב CPU, דיסק, רשת וכו' [2]. לעיתים הספק מעודד שימוש בשעות המתות ע"י מתן תעריפים נמוכים יותר, כך שהוא יכול לנצל את החומרה שברשותו בצורה עדיפה. התשלום לספק הענן לרוב אפשרי בעזרת כרטיס אשראי, עובדה שהופכת את ההצטרפות לפשוטה.

5. חומרה זולה (Commodity hardware) אחת הסיבות העקריות לשימוש במחשוב ענן הוא הפחתת עלויות. ברוב סביבות הענן איננו יכולים לדעת על אילו חומרה בדיוק תרוץ האפליקציה שלנו בפועל, ולרוב האפליקציה שלנו תכתב מראש בצורה Scalabale כך שהיא יכולה לגדול אם מוסיפים לה עוד שרתים (חומרה). ניתן לנצל עובדה זו ולהשתמש בחומרה זולה למדי – בעלת מקסימום CPU Cycles ליחידת תצרוכת חשמל. תצרוכת החשמל מכתיבה לא רק את מחיר החשמל (מחיר ישיר), אלא גם את מחיר הקירור / מיזוג (מחיר עקיף) וכיוון שיש מגבלה של יכולת קרור לנפח נתון – את עלות הנדל"ן בו יושב ב Data Center. הכל בכדי להפחית בעלויות.

6. (SLA (Service Level Agreement – ספקי שירות ענן מוכרים לא רק את הזכות להשתמש בחומרה ושירותים, אלא גם מחויבות לזמינות החומרה והשירותים שאותם הם מספקים, זמני תגובה ועוד. סט התחייבויות אלו נקרא (SLA (Service Level Agreement והוא חלק מכל שירות. יש ספקי ענן שמתחייבים רק לזמינות נמוכה, ויש כאלו שמתחייבים לזמינות גבוהה יותר. זמינות מקובלת היא 99.95% up-time (מה שנקרא three and a half nines). זמינות של five nines (כלומר 99.999%) – היא נדירה וגבוהה במיוחד. המבקרים יאמרו שלא משנות ההבטחות – ספקי הענן עד היום לא עמדו בהן ולא פיצו את הלקוחות. מצד שני נראה שהספקים משקיעים מאמצים אמיתיים לעמוד ב SLAs.
בכל מקרה, פיתוח נכון של אפליקציות לענן מניח שיהיו תקלות וכולל את המנגנונים להתמודד איתן.

7. High Availability – רוב שירותי הענן מסופקים במספר אתרים בעולם המפוזרים גיאוגרפית. לעיתים אתר מחולק לכמה יחידות (מה שנקרא באמאזון Availability Zones) שאמורות להיות בלתי תלויות – גנרטורים אחרים, רשת נפרדת וכו' על מנת לאפשר המשך פעילות כאשר יחידה מסויימת נפגעת (שריפה, ניתוק ברשת האינטרנט וכו'). אם האיזור בו שרתים שהוקצו לכם נפגעו – תוכלו להתאושש ללא פגיעה חמורה בזמינות – בהנחה שחילקתם את השרתים שלכם לכמה יחידות זמינות. אני אומר לא-חמורה מכיוון שבכל זאת, ייקח קצת זמן להבין שהייתה תקלה, להקצות שרתים חדשים לפצות על היחידה שנפגעה, לטעון עליהם את ה images – וכנראה שאם הייתה שריפה ביחידת זמינות – אתם לא היחידים שמבצעים פעולות התאוששות באותו הרגע [3].
ספקי Infrastructure מניחים שעל מפתח האפליקציה לנהל את הנוכחות שלו באיזורים שונים בעצמו, בעוד ספקי Platform נוטים יותר לבצע את הפיזור עבור הלקוח. עוד שירות נפוץ הוא [4]CDN המאפשר למשתמש-קצה של האפליקציה אשר הוא מרוחק גיאוגרפית מספק הענן לקבל שירות דומה ללקוח שקרוב גיאוגרפית אליו.

8. Mutli-tenancy – זוהי נקודה שמטעה לא מעט כותבי אפליקציות ענן. Multi-tenancy היא היכולת של שירות לספק לקוחות שונים באופן בלתי תלוי. Multi-Tenancy מתייחס לאחד או יותר מהבאים:

חציצה בנתונים ובקונפיגורציה (לקוח אחר לא יכול בשום אופן לגשת לנתונים שלי)
אי-תלות גירסה (אני יכול לבחור בגרסת התוכנה, ללא תלות בלקוח אחר שרץ איתי על אותו השרת).
אי-תלות של תוספים Plug-ins (אני יכול להריץ תוספים שלי או של ספק אחר, ללא תלות בלקוח אחר שרץ איתי על אותו השרת).

כמה שניות לחשוב… מה המשמעות…

כן. Multi-tenancy הוא לא דבר פשוט. הוא מהדברים שאם לא תכננתם מראש – יהיה מאוד קשה להוסיף בהמשך.

כשאנחנו חושבים על ענן אנו חושבים על שירותים בעל תצרוכת משאבים אדירה, כמו כלי ניתוח נתונים בענן שמשרת לקוחות ענק, תוך כדי שינוי בכמות השרתים ע"פ הצורך: לפעמים שלושה ולפעמים שלושים. אני מאחל לכם שכל הלקוחות שלכם יהיו כאלו.

בפועל יותר סביר שיהיו לכם המון לקוחות קטנים שלא יצליחו לנצל אפילו שרת אחד פשוט. כל לקוח גם יצפה שהנתונים, הקונפיגורציה והתוספים (Plug-ins) בהם הוא משתמש יהיו פרטיים לחלוטין. אם תקצו לכל לקוח קטן שרת פיסי משלו (על מנת לספק את ההפרדה) – קרוב לוודאי שהתפעול יהיה יקר ואולי אפילו תפסידו על חלק גדול מהלקוחות כסף. אפילו אם הלקוחות שלכן הן חברות ענק, נוסח חברות Fortune 500, תגלו שלהם יש משרדים, מחלקות, שותפים וסניפים שונים שעלולים לדרוש אוטונומיה. אם לא תתכננו את המערכת שלכם בהתאם ומהתחלה, התפעול שלכם יהיה יקר במיוחד ותאלצו לעבוד שנים על מנת להוסיף יכולת Multi-tenancy למערכת קיימת [5].

9. הפעלה ב API – למרות שיש לרוב גם UI חלקי להפעלת שירותי הענן, רוב התקשורת והעבודה מול ספק שירות הענן יתבצע ב API. זאת על מנת שנוכל לתפעל את כל הפעולות מול ספק הענן (שינוי הקצאת החומרה לשירות שלנו, עדכון תוכנה וכו') בצורה אוטמטית ועם מינימום התערבות ידנית.

10. ארכיטקטורה מבוססת שירותים (SOA)
זוהי נקודה פחות מפורשת ומדוברת מהנקודות האחרות, אך ארכיטקטורה מבוססת שירותים (Service Oriented Architecture), או לאחרונה Micro-Services Architecture (בקיצור: MSA) – נפוצות מאוד בענן. אני מתכוון לחלוקת המערכת לשירותים בלתי-תלויים ועצמאיים, לא לשימוש ב Web Services או ESB – Enterprise Service Bus (השם ירחם). אם נבחן את SOA – נראה שהיא מתאימה לענן: היא מאפשרת ביזור, חוסר תלות, Scalability ואולי הכי חשוב: בנייה של מערכת מודולרית משירותים (services) שונים. מצב נפוץ הוא שמערכת בענן מתבססת ומשתמשת בשירותי ענן אחרים, יש לכך 2 סיבות משמעותיות:

חסם נמוך יותר לשימוש בשירותים אחרים: אם רציתם להשתמש בשירות חיצוני במערכת On-Premises הייתם צריכים לדרוש גישה לאינטרנט, לנהל מעקב אחר השימוש של הלקוחות על מנת לחייב אותם – או לדרוש מהם לרכוש את השירות בעצמם, להתלות במערכת אחרת שפחות יציבה משלכם (בשל המרחק הגדול ברשת ו (Commodity Hardware) ועוד. כאשר אתם מפתחים אפליקציית ענן – קרוב לוודאי שהתמודדתם כבר עם רוב הקשיים האלו, ולכן אימוץ של שירות ענן אחר הופך לטבעי וקל הרבה יותר.
כיום, ישנה תחרות גדולה מי יציע בתחום שירותי ענן מוקדם יותר, ושימוש חוזר בשירותים היא דרך טובה להאיץ את הפיתוח ולצאת מוקדם יותר עם פתרון מתפקד.

לסיכום: הענן הוא נושא מתפתח בעל מורכבויות שונות, אך ישנם כמה מאפיינים "ענניים". אני מקווה שפוסט זה עזר לעשות קצת סדר בראש ולהבין את הגבולות (הלא מדויקים) של עולם שירותי הענן (Cloud Computing). בפוסטי המשך אנסה לצלול עוד קצת פנימה על דילמות וגישות לפתור בעיות בענן.

—

[1] נשאלת השאלה מדוע אמזון (ספקית IaaS מובילה) אינה נתקלת באותה בעיה: דרישה אדירה לשרתים בחג-המולד ו"תקופה מתה" בשאר השנה (או לסרוגין צריכה אדירה בשעות היום בארה"ב מול שעות מתות בשעות הלילה)? אמזון מסבירה שהיא מאזנת את מגמת השימוש הנוצרית / אמריקאית עם שאר העולם (בעיקר המזרח הרחוק) וגופי מחקר – שישמחו לשכור כח מחשוב במחיר מוזל בשעות המתות. בכל זאת, כנראה שזו בעיה קיימת שאמזון ממעיטה בערכה בפומבי. עובדה שהיא מציעה השכרה של שרתים "בתנאי חוסר-שימוש" – שרתים במחיר זול במיוחד, שברגע שלקוח שמשלם מחיר מלא מבקש אותם – אתם נזרקים מהם ללא התראה (והחיוב בהתאם, כמובן). מעניין עד כמה הענות יש לסידור הזה.

[2] Google Apps לדוגמא חייבה בצורה בה היה משתלם יותר להתפרש על מכונות פיסיות רבות, וברגע ששינתה את שיטת החיוב יצרה מהומה לא קטנה. לינק נוסף.

[3] למרות שבכמה מקרים נפל Availability Zone יחיד של אמזון, השמועות שרצו הם שכולם נפלו. מייד אחרי הנפילה נוצר עומס גדול כ"כ על היחידות השכנות כך שזה נראה כמו חוסר זמינות שלהן.
לזכותם של אמאזון יאמר שהם מפרסמים תחקירי אירוע כנים ויסודיים – כזה שאינו ברור מאליו שכל ארגון היה מפיק לעצמו. אין מה לעשות: אמון הצרכנים בענן הוא נכס (או נטל) בעל משמעות אדירה לעסקים – ולא נראה שלאמזון יש ברירה אחרת.

[4] Content Delivery Network.

[5] חברת SAP השקיעה מיליארד דולר בפיתוח אפליקציה עסקית בענן ללא יכולת multi-tenancy, רק כדי לגלות שלקוחות הענק שלה רוצים הרבה חבילות קטנות של רישיונות (לכל משרד, מחלקה, שותף וכו') ולא חבילה אחת גדולה. SAP עיכבה את שחרור המוצר ונדרשו 3 שנים עד ש SAP הצליחה לספק פתרון Multi-tenant.

על הדרך הנכונה לחלק מערכת לשירותים מבוזרים

המערכת שלכם, הרצה על שרת יחיד (או ב cluster שבו כל ה nodes זהים), גדלה והחלטתם להרחיב אותה ל 2 או יותר שירותים (services) עצמאיים על שרתים נפרדים. במאמר זה אסקור כמה שיקולים חשובים במהלך שכזה.

איך נוצרת מערכת מבוזרת?
מכיוון שנתקלתי בחיי בכמה וכמה החלטות לפצל שרת למספר שירותים מבוזרים שלא הצדיקו את עצמן ורק מעט שכן הצדיקו את עצמן, הייתי ממליץ לשקול היטב את ההחלטה. זו החלטה שבה נוטים לטעות.באופן טבעי אנו נוטים לפצל מערכות בקלות – זו חלוקה פונקציונלית שעושה סדר ולכן מרגישה הגיונית. אם היה מדובר בקוד – אין ספק: חלוקה לפונקציות היא צעד חיובי כמעט ותמיד.

חלוקה של מערכת (process או service) למספר תהליכים או שירותים – הוא גם צעד שלא טומן בחובו Tradeoffs משמעותיים. לרוב – ה tradeoff בין צריכת זיכרון ל isolation – שבמקרים רבים עושה שכל.

חלוקה של מערכת למספר שירותים היושבים על שרתים פיסיים שונים (או בהקבלה פיזור השירותים הנפרדים הקיימים בין שרתים שונים) היא החלטה שבה יש שיקולים שונים מהותית. מערכת כזו נקראת מערכת מבוזרת (Distributed System), שם קצת מפחיד – ובצדק.

אפשרויות הביזור
הפיצול לשירותים לעיתים מבטא שיקוף של המבנה הארגוני: שירות אחד של צוות X על שרת A, ושירות אחר של צוות Y על שרת B. בתאוריה של מערכות מבוזרות, מערכת כזו נקראת מערכת מבוזרת הטרוגנית.

מערכת מבוזרת הטרוגנית

אפשרות פעולה אחרת היא שגם שירות X וגם שירות Y נמצאים על שרתים A וגם B כך שתכולת שרתים אלו היא זהה. אפשרות זו נקראת מערכת מבוזרת הומוגנית

מערכת מבוזרת הומוגנית

מתי לבחור פרדיגמה הומוגנית?

שתי הגישות אפשריות ושתיהן יכולות לעבוד עבור כמעט כל מערכת. האם יש כללי אצבע שיעזרו לנו לבחור? – בהחלט כן!הכלל העקרוני הוא די פשוט: אם אפשר – בחרו בחלוקה הומוגנית (כל השרתים זהים וכוללים את כל השירותים).

יתרונות:

זמינות (high availability) גבוהה יותר, מכיוון ששני השרתים זהים. שרת A נפל – שרת B יוכל לספק את כל השירותים. בפרדיגמה ההטרוגנית כל שרת הוא single point of failure.
ניהול עומס (load balancing) מיטבי – כל שרת יכול לטפל בכל בקשה וכך ניתן לחלק את העומס בצורה מיטבית בין השרתים. בגישה ההטרוגנית ייתכן ששרת A עמוס לחלוטין, ולשרת B יש משאבים פנויים. קרי – לא ניצלתם את החומרה לתומה. חישבו על פיזור העומס לא רק ב load מרבי, אלא גם על השעות מהם יש עומס קטן יותר על המערכת.
יעילות תקשורת – אם שירות X ו Y זקוקים אחד לשני – הם יכולים לבצע קריאות לוקאליות בזכרון, שהן יעילות ובעלת latency קטן משמעותית מקריאה ברשת. אפילו אם בוחרים לתקשר על גבי http – הביצועים יהיו עדיפים במחשב מקומי.
תחזוקה קלה יותר (Maintainability). שיקול Operations. אנו יכולים להחזיק אותה חומרה ולנהל מלאי אחד של חלפים. אנו יכולים לנהל image יחיד, להתמודד עם בעיות של updates ו upgrade בצורה אחידה וכו'.

איך ממשים שני שירותים על אותו שרת? לרוב הפתרון פשוט כמו שהוא נשמע: אם מדובר על Servlet Engine – פשוט מתקינים את שני השירותים על אותו Container כשני קבצי war או ear נפרדים (שכל צוות בארגון יכול לפתח עצמאית).
אם השירותים הם בשפות תכנות שונות (נאמר Ruby ו Scala כמו ב [1]Twitter או C ו Java כפי שנפוץ במוצרים רבים) – פשוט מתקינים שני containers או אפליקציות על אותו השרת הפיסי. הרי ב Windows או Linux יש עשרות שירותים מותקנים, אז מונע מאיתנו להריץ עוד כמה?

עד כמה שנתקלתי המחסום העיקרי לאימוץ גישה זו – הוא פסיכולוגי. אולי התבנית מזכירה תבנית של שכפול קוד "The Mother of All Evil", אשר מעבירה בנו צמרמורת רק עם הזכרת שמה.

מתי לבחור בפרדיגמה הטרוגנית?

השיקולים העיקריים לפרדיגמה הטרוגנית הם:

שימוש במשאבים מיוחדים: חומרה מיוחדת ויקרה שזקוקים לה עבור שירות Y ולא עבור X וכך אפשר לחסוך בעלויות.
- מקרה נפוץ יותר – צורך בזיכרון רב. לדוגמא: שירות Y משתמש ב in-memory Database וזקוק לכמה עשרות GB של זכרון כדי לפעול בצורה מיטבית. דוגמא נפוצה היא חוות זיכרון נוסח memcached או [terracotta[2.
השירות רלווני במיקום גיאוגרפי מסוים / מיקום מסוים ברשת. למשל: השירות מבצע sniffing על הרשת או חייב להיות מותקן במיקום מסוים כדי לגשת לשירותים שהוא זקוק להם.

במקרים אלו אנו סובלים מרשימת החסרונות שתוארו בפרדיגמה ההומוגנית – אך ייתכן וזו הברירה העדיפה.

כמה טיעונים נפוצים לשימוש בפרדיגמה ההטרוגנית

"זיכרון, מכיוון ששירות Y דורש כ 2GB זכרון נוסף בכדי לרוץ".
מכיוון שזיכרון הוא זול כ"כ ועלות פיתוח של High Availability היא גבוהה כ"כ + ניצול מרבי של חומרה מחזיר מהר מאוד עלות של מעט זיכרון נוסף – טיעון זה לא נראה לי רציני.

הלקוחות שלנו רוצים לקנות שירות לראות את הקופסא שהם קנו.
שמעתי גם את זה. לפי דעתי זהו פידבק של אנשי מכירות או Professional Services ולא באמת לקוחות. לקוחות שאני מכיר מוטרדים מעלות התחזוקה הכוללת (TCO) שמושפעת יותר מ High Availability או אחידות החומרה. כשעבדתי בנייס, הפסדנו עסקאות כי השרת שלנו היה 3U (ר [3]) והשרת של המתחרה היה חלש קצת יותר אבל נכנס ב 2U (כלומר – קצת מקום איכסון היה מספיק משמעותי לעסקה). במידה וטיעון זה עלה – שווה לבקש לשוחח עם כמה לקוחות ולהבין במה מדובר.

"זיכרון, מכיוון ששירות Y דורש כ 20GB זכרון נוסף כדי לרוץ"
זהו אכן כלל-האצבע המצביע מתי הפרדיגמה ההטרוגנית עדיפה, אבל לפי דעתי כדאי לחשוב מעט ולא להחליט מייד. כמה עולה 20GB (ר [4]) זיכרון ומה מחיר חוסר-הזמינות?תזכורת: אלא אם מדובר בשרתי Unix עתיקים (שם הזיכרון יקר להחריד) – 20GB זיכרון הם לא דבר מאוד יקר. שווה לעשות את השיקול הכלכלי. לעיתים יהיה שווה לשים שרתים עם זכרון רב ולהשאר עם פרדיגמה הומוגנית (בעיקר ב cluster קטן). לעיתים באמת שווה לעשות את ההפרדה. במערכת עם מספר רב של שרתים (לרוב מערכת on-demand) ניתן לבחור בגישה מעורבת ולהנות מ-2 העולמות. לדוגמא: אם יש לי 12 שרתים אני יכול להקצות 8 לשירות X ו 4 לשירות Y (גישה הטרוגנית), אך כל קבוצה של שרתים תנוהל ב cluster שיספק לי high availability, load balancing וכו'.

ניהול משאבים הוגן או Resource Consumption Capping
זהו שיקול הגיוני: מספר שירותים במערכת שלנו עלולים לצרוך יותר משאבים ממה שאנו רוצים להקצות להם ולכן אנו רוצים להגביל את את השימוש בהם. גישה אחת לבצע את אכיפת שימוש המשאבים היא פריסה הטרוגנית של שירותים על מחשבים, למשל: יש לי 8 שרתים, 3 יוקצו לשירות X הבעייתי ו 5 לשירות Y. אכיפה כזו היא הקלה ביותר למימוש אך הגמישות לשנות את החלוקה ל 4:4 או 2:6 היא קטנה וייתכן שאותם 3 שרתים של שירות X לא יוקצו בצורה יעילה. פיתרון של Capping בתוכנה הוא פחות מדויק ודורש השקעה נוספת, אך יותר גמיש.
גישה מקובלת אחרת היא ליצור cluster הומוגני בו מספר קטן של שרתים להם רוצים לעשות Capping – מופרד ל cluster לוגי נפרד (כלומר: ה Load Balancer מתבקש לא להעביר להם תעבורה ע"פ כללים מסוימים). גישה מקובלת עבור ה crawler במערכות SharePoint או Batch Operations במערכות SAP.

"כי א' או ב' או ג'" או בקיצור "כי בא לי"
לעיתים השיקולים בארגון בו אנו עובדים הם רגשיים ולא ענייניים. דוגמא קלאסית הוא אפקט איקאה [5] – מישהו חשב ותכנון את פירוק השירותים ופתאום אתם באים עם רעיון דמיוני לשמור על פרדיגמה הומוגנית – והורסים הכל. ובכן, התמודדות עם מצב כזה הוא כבר דיון אחר, אבל בקיצור שווה לבדוק עד כמה רעה הגזרה ולעיתים גם לוותר. להיות צודקים יותר לא תמיד יביא אתכם למקום טוב יותר.

לסיכום: למרות שהגישה ההומוגנית היא מעט Counter Intuitive – היא טומנת בחובה עוצמה רבה שכדאי לעשות מאמץ ולנצל.

[1] סיפור מעניין בפני עצמו על Scalability.[2] החבר'ה מ Terracotta, חברה ישראלית, אוהבים לקרוא לחוות זיכרון אלו NAM – Network Attached Memory, על משקל NAS.

[3] חדרי שרתים בנויים מארונות הנקראים Rack מהם כל slot נספר כ U (אולי קיצור של Unit?). יחידות של 1U הן לרוב ציוד תקשורת כגון Router או Hub בעוד שרתים הם לרוב 2U. שרתים גדולים יותר יתפסו 3U או יותר.

[4] "איך לעזאזל מגיעים לצריכה של 20GB זיכרון?" אתם עשויים לתהות? לרוב כשיש Caches גדולים של מספר שירותים או In-Memory-Database.

[5] אפקט איקאה הוא המצב בו אדם שהשקיע עבודה מסויימת במוצר מתאהב בו ורואה תמונה מוטה של הדברים. במקור, האפקט מתואר כך שאדם יאהב יותר את הרהיט הפשוט מאיקאה שהרכיב בעצמו, על פני רהיט איכותי יותר שבהרכבתו לא היה מעורב. הנקודה המפתיעה היא שאדם השקיע חלק מהעבודה (איקאה) יתאהב במוצר בצורה חזקה יותר מזה שבנה את המוצר לבד מ Scratch.