גישות 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/אחסון ענני של יצרן תוכנה כלשהי מבלי שללקוח יש מושג מה יצרן התוכנה עושה/יעשה עם הנתונים, שלא לדבר על סיטואציה שלא מעט ארגונים לא רוצים/לא יכולים לבחור בפתרונות כאלו עקב רגולציה או אבטחת מידע. אותן חברות צריכות להציע משהו שהוא "באמצע" – התשתית תרוץ בענן, אבל המידע ישב מקומית בתשתית של הלקוח או שהוא ישב בענן בצורה כזו שללקוח תהיה שליטה מי יכול לצפות/לגשת לנתונים (גם אם מדובר בחסימת הנתונים מפני חברת התוכנה).

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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