גישות SaaS/PaaS והגישה ההיברידית

כמעט בכל חברה יתקיים מצב בו החברה תחפש תוכנה שתבצע שרות X או שתתן שרותי פלטפורמה Y במקום “להמציא את הגלגל” מחדש בכל פעם. אם לדוגמא העסק מעוניין לשלוח איחולי חג שמח לכל הלקוחות, ניתן יכול לשכור שרותי Saas של חברה כמו Mailchimp לדוגמא ובתמורה תקבלו ממשק קל לשימוש וסיכוי מאוד גדול שכל לקוחות העסק יקבלו את המייל. מצד שני אפשר בעזרת מעט סקריפטולוגיה ושימוש באמזון SES לבצע את אותו דבר אך במחיר זול בהרבה (יכול לחסוך לא מעט אם לחברה יש מאות אלפי או מיליוני לקוחות לדוגמא). אפשר כמובן לקחת גם את האופציה החינמית ולהקים שרת מייל או להשתמש בשרת מייל מקומי כדי לשלוח את הררי האימיילים, אבל במקרים כאלו הסיכוי שהמייל יתקבל אצל כל הלקוחות הוא די קלוש – אם לא משקיעים בכל עניין של Whitelist, RBL, דבר שלוקח לא מעט זמן ומשאבים.

יותר ויותר חברות תוכנה מקצצות בהשקעה של כתיבת תוכנות והפצת כ-Stand alone המיועדות לרוץ על שרתים בתשתית מקומית של הלקוח, וזאת ממספר סיבות, הנה 2 העיקריות:

  1. עלויות תמיכה – ככל שתוכנה נמכרת כ-Stand Alone, עלות התמיכה ליצרן התוכנה תהיה גבוהה, מכיוון שיש לא מעט סיכוי שהתוכנה לא תעבוד בסביבות או מכונות שונות, הרשאות שגויות, חוסר ידע טכני של הלקוח ועוד. ככל שהתומכים הטכניים יהיו עסוקים יותר ויותר שעות בפתרון בעיות של לקוח ספציפי זה או אחר, הרווח של יצרן התוכנה ירד. אחרי הכל, אף אחד לא משלם ליצרן התוכנה אם מחלקת התמיכה השקיעה 10 שעות בפתרון בעיה אצל לקוח יחיד לדוגמא.
  2. פיראטיות – בהרבה מאוד חברות הצוות מוריד אפליקציה או פלטפורמות מסויימות למטרת Trial ומיד לאחר מכן הם מחפשים כל מיני כלים ודרכים כדי לפרוץ את ה-Trial. הרווח של יצרן התוכנה ממקרים כאלו – אפס.

מהרגע שיצרן התוכנה מציע את מוצריו כ-PaaS או SaaS, הדברים נהיים יותר קלים עבורו:

  1. אין פיראטיות
  2. עלויות התמיכה מצטמצמות משמעותית הואיל והכל רץ בתשתית וירטואלית של יצרן התוכנה בעננים שונים ומקרי התמיכה נהיים יותר ויותר פשוטים כי ניתן לשחזר את התקלות במחלקת התמיכה של יצרן התוכנה.
  3. תזרים הכנסות חודשי/שנתי רציף מהלקוחות.
  4. קצב הפיתוח מואץ יותר, באגים ופונקציונאליות חדשה נכנסת ל-Life Cycle של השרות במהירות גבוהה יותר ובכך דרישות לדברים חדשים שלקוחות מבקשים – נענים במהירות גבוהה יותר.
  5. אין צורך בתמיכת Legacy הואיל וכולם עובדים על גירסה אחת או שתי גרסאות.

אך יש גם חסרונות:

  1. עלויות תשתית הרבה יותר גבוהות בענן ציבורי. בניגוד למכירת תוכנת Stand Alone שלא מתחברת החוצה, כאן פתרון ה-Saas/PaaS יצטרך חיבור קבוע למשאבים שונים של יצרן התוכנה.
  2. אבטחת המידע צריכה להיות הרבה יותר רצינית בהשוואה למקרים של תשתית סגורה החוצה. מהרגע שמתגלה אצל יצרן כזה דליפת מידע, יש סיכוי לא רע שחלק מהלקוחות יעדיפו לנטוש ולחפש פתרון מתחרה.

אלו, פחות או יותר הסיבות שבגללן חברות תוכנה יעדיפו להציע שרותי PaaS/SaaS.

אחת הנקודות שבמקרים רבים אינני רואה התייחסות מצד אותן חברות – היא למקרים שהלקוח אינו מוכן “לעבור All In”, כלומר הלקוח לא מוכן שכל ה-DATA שלו ישב בתשתית של יצרנית תוכנה ולו (ללקוח) לא תהיה שליטה על הנתונים מבחינת אבטחת מידע או בכלל מהבחינה העקרונית שזה ישב בתשתית של חברה אחרת שאין לו מושג ירוק לגביה. זו לדוגמא אחת הסיבות שחברות יעדיפו לוותר על פתרון SaaS/PaaS שמוצע רק על ענן ובמקומו הם יעדיפו פתרון שרץ מההתחלה ועד הסוף על תשתית מקומית (On Prem).

מה שלעניות דעתי אותן יצרניות תוכנה PaaS/SaaS צריכות להציע – הן את האפשרויות הבאות (אחת או יותר), משהו שהוא יותר מעין “Hybrid”:

  1. ה-DATA של הלקוח יכול להיות מאוחסן On Prem עם Agent שמתחבר לענן. לשרות תהיה גישה עם הרשאות מאוד מוגבלות
  2. אם ללקוח יש חשבון בענן ציבורי כלשהו, הלקוח יוכל להגדיר אחסון אובייקטים כלשהו (S3 לדוגמא) עם הרשאות מוגבלות שינתנו בעת הפעלה ראשונית של שרות ה-SaaS/PaaS והרשאות אלו יהיו תחומים למשאבים מסויימים בלבד (נניח Bucket כלשהו)
  3. הלקוח יצטרך לבחור כבר בהתחלת שימוש ה-PaaS/SaaS את ה-Passphrase שלו (ובלבד שיהיה מורכב) ועם אותו Passphrase (ואולי יחד עם עוד מספר נתונים) יוצפן ה-DATA של הלקוח כך שגם ליצרן התוכנה לא תהיה גישה לנתונים. (אפשר כמובן במקום Passphrase יהיה אפשר להשתמש במפתחות פרטי/ציבורי יחד עם Passphrase)

לסיכום: מצד אחד יותר ויותר חברות תוכנה עוברות להציע את מרכולתן בתצורות של PaaS/SaaS, אולם במקרים רבים לחברות וארגונים גדולים לא קל לעבור מבחינה פסיכולוגית למצב שכל הנתונים הקנייניים/פרטיים ישבו באיזה DB/אחסון ענני של יצרן תוכנה כלשהי מבלי שללקוח יש מושג מה יצרן התוכנה עושה/יעשה עם הנתונים, שלא לדבר על סיטואציה שלא מעט ארגונים לא רוצים/לא יכולים לבחור בפתרונות כאלו עקב רגולציה או אבטחת מידע. אותן חברות צריכות להציע משהו שהוא “באמצע” – התשתית תרוץ בענן, אבל המידע ישב מקומית בתשתית של הלקוח או שהוא ישב בענן בצורה כזו שללקוח תהיה שליטה מי יכול לצפות/לגשת לנתונים (גם אם מדובר בחסימת הנתונים מפני חברת התוכנה).

למי מתאים OpenStack?

היי חץ, אנחנו שוקלים מעבר מפלטפורמת VMWare למשהו אחר, עדיף יותר זול. האם OpenStack יכול להתאים לנו?

עבדכם הנאמן מקבל אימיילים בנוסח כזה או אחר אחת לכמה זמן כשמגיעות ישיבות תקציב ל-IT (או שמגיע זמן חידוש רשיונות ואף אחד לא שם לב לכך בישיבות תקציב השנתיות. גם את זה ראיתי בעבר. לא כולם מסודרים). אני בהחלט יכול להבין את הרצון לעבור למשהו אחר בגלל חסכון (ברוב המקרים זו הסיבה היחידה, אגב. לא מצאתי הרבה אנשים שאינם מרוצים מהפתרונות של VMWare מבחינת ביצועים, קלות שימוש וכו’).

אז כ-שרות לקוראי בלוג זה אתאר מספר נקודות פשוטות, ואת ההצעה שלי בסוף.

נניח ויש לכם מערכת VMWare ואתם צריכים לבצע את אחד (או יותר) מהדברים הבאים:

  • הקמת והגדרת Cluster
  • ביצוע Live Migration למספר מכונות VM בין Clusters
  • ביצוע Live Migration בין 2 Datastores
  • הגדרות Fault Tolerance

איך אתם תבצעו את הדברים?

  • דרך ה-Vcenter web client (הממשק הוובי) או ה-vcenter client שרץ על מכונת Windows
  • דרך PowerShell או דרך סקריפטים שכתבתם בפייתון או בשפה אחרת

התוצאות:

  • אם אתם משתמשים אך ורק בכלי ה-GUI/WEB ש-VMWare מספקת – תרדו מהמחשבה על מעבר ל-OpenStack.
  • אם אתם “פוחדים”/מתעצלים/לא מעוניינים להשתמש ב-API או לכתוב סקריפטים לאוטומציה או שימוש On Demand במקרה הצורך – רדו מ-OpenStack.

בקיצור – אם אתם הטיפוסים של “קליק קליק קליק” – OpenStack לחלוטין אינו מתאים לכם.

ברכותיי, חסכתם כמה מאות שקלים של דמי יעוץ 🙂

אחד הדברים שבגינם אני כותב את הפוסט הזה, זו המחשבה המוטעית ש-OpenStack הוא איזה פתרון CSN (כלומר Compute, Storage, Network) שמהווה תחליף ל-VMware. מבחינה טכנית “על הנייר” – הוא מסוגל בהחלט לתת שרותי CSN, אבל לא בשביל זה קונים ומטמיעים את OpenStack, כמו שלא מקימים מערכת Kubernetes בשביל להריץ 2-3 קונטיינרים.

הדברים שצריך להבין לגבי ה-OpenStack ומדוע הוא ה”דארלינג” של כל עסק HyperScale (כלומר עסק גדול שנותן שרותי ענן – כמו רוב חברות התקשורת הגדולות בחו”ל – AT&T, Verizon, SK-Telecom ועוד רבים אחרים) הם דברים מהותיים כמו:

  • OpenStack מאפשר לך להקים שרותים כמו Object ו-Block storage מצד אחד, אבל מצד שני, OpenStack יכול להתחבר בקלות לסטורג’ שלך ולקבל את השרותים מהסטורג’, וכל יצרני הסטורג’ הגדולים (והיקרים) תומכים ב-OpenStack. שלח מייל ליצרן הסטורג’ שרכשתם ותקבל בחזרה קובץ PDF או קישור איך לחבר ביניהם, כך ש-OpenStack לא מנסה להתחרות ביצרניות האחרות, אבל מצד שני אם אין לך את המשאבים/תקציב – הוא מאפשר לך להקים פתרון.
    אותו דבר מבחינת שרותי וירטואליזציה – אתה יכול להשתמש בשרותי ה-KVM של OpenStack או לחבר את ה-vSphere אל ה-OpenStack כך שמערכות ESXI יריצו את המכונות הוירטואליות. הנה התיעוד.
  • מבחינת רשתות (סיבה עיקרית שחברות הטלקום אוהבות אותו) ה-NFV (כלומר Network Functions Virtualized) של OpenStack מאפשר להתרחב למימדים מפלצתיים! גם כאן, אפשר או להקים או פשוט לפנות ליצרן ציוד התקשורת שלך שכבר תומך מספר שנים ב-OpenStack (כן, כל הגדולים תומכים).
  • שרותים, שרותים, שרותים: OpenStack התחילה את חייה כמערכת IAAS קלאסית, אבל כיום OpenStack מציעה מאות שרותים שאתה יכול לשלב ל-OpenStack ולתת/למכור את השרותים הללו ללקוחות. הלקוח רוצה שרותי ניהול DNS? אולי DB? להריץ קונטיינרים ב-Kubernetes או OpenShift? ניהול, הקמת והגדרות ברזלים (Provisioning)? שרותי Identity? שרותי Telemetry ועוד? יש, רק תגדיר במערכת ותתחיל להשתמש ולהציע ללקוחות – ולמנמר”ים שכמובן חושבים על תקציבים ותשלומים בראש ובראשונה – אני רוצה להכיר לכם את … CloudKitty.

מכאן נעבור למקום קלאסי שבו OpenStack מתאים כמו כפפה ליד (כן, חוץ מחברות טלקום שעדיין תקועות על VMware בלבד כ”פתרון ענן”.. לא מזכיר שמות..) – בנקים.

אני חושב שכמעט בכל בנק בישראל על הלוח של פרויקטים עתידיים מופיעה המילה “OpenStack” למימוש אי-שם-בעתיד, והם אינם מודעים לכך ש-כן, דווקא מימוש OpenStack תוך חיבור המערכות הקיימות (כן, גם מערכות וירטואליזציה של אורקל ניתן לחבר, לתשומת לב בנק מסוים..) יאפשר מתן שרותים קיימים וחדשים תוך זמן קצר, כולל הטמעה של פתרונות קונטיינרים שרוב הבנקים מכניסים כיום. (הנה תיעוד להרצת OpenShift ב-OpenStack).

ה”חסרון” של OpenStack – הוא שמדובר במערכת שאינה “קליק קליק קליק”. כן, יש ממשק Web אך הוא יחסית די בסיסי (במיוחד אם מנסים להשוות אותו לממשקים כמו של VMWare) ורוב העבודה נעשית מול API או binding עם שפות כמו Python. זו מערכת מסובכת, מורכבת, אבל לאחרונה (בגירסת Stein) קיימת תת-מערכת חדשה, AirShip שמאפשרת הקמה והגדרת דברים בצורה קצת יותר קלה – עם YAML (אגב, למי שרוצה לשחק עם Airship על מכונת לינוקס, אפשר להריץ את הפקודות כאן ולהתרשם בעצמכם).

לסיכום: מערכת OpenStack היא אינה מערכת “מתחרה” ב-VMWare והיא לא פתרון חלופי, במיוחד שההשקעה מבחינת הטמעה והגדרות ראשוניות – היא גבוהה. זו מערכת שנועדה להשלים ולתת שרותים רבים נוספים תוך שימוש בתשתיות הקיימות שלכם. היא פחות מתאימה למקומות בהם כמות הברזלים היא קטנה והיא מצריכה תחזוקה רצינית ע”י אנשים שמכירים טוב שפות כמו Python ומוכנים לצלול ולהכיר API על מנת להגדיר דברים. היא יעילה במיוחד בכל מה שקשור למתן שרותים שונים, שרותי רשת וכמובן Billing בין המחלקות או בין מוסד גדול ללקוחותיו וכו’. אם יש לכם את המשאבים ואתם רוצים להקים ענן גדול ורציני – תסתכלו על OpenStack (המסחרי, גירסת הקוד הפתוח משתנה תדיר).

קליפים על הקמה/שימוש ב-OpenStack – בקרוב.