OpenStack – ענן בקוד פתוח

בפוסט זה אדבר על פרויקט OpenStack, פרויקט ה IaaS (קיצור של Infrastructure as a Service) הפופולרי.
(אם אין לכם מושג מה זה PaaS או IaaS – הנה הפוסט בשבילכם)

בעולם ה IaaS, אמזון נמצאת עם AWS בערך במקום בו הייתה מייקרוסופט לפני 20 שנה עם Windows NT 4.0: במיקום אסטרטגי לכיבוש השוק. אין לה מתחרים ביכולות, בפריסה או במידת שביעות הרצון של לקוחותיה.

OpenStack (בקיצור: OSK) מנסה להיות \"הלינוקס של ה IaaS\": חינמי, חופשי, פתוח, ומפותח ע\"י קהילה. האם יקח גם לו כ 10 שנים לסגור את הפער? (אנשי לינוקס – אל תתרגזו. זו דעתי האישית).

ל OpenStack בהקשר זה יש גם אתגרים: הפרויקט כנראה נולד כצעד הגנתי של חברות IT שעיקר הרווח שלהן הוא בעולם ה On-Premises (קרי: לא בענן) כנגד AWS, גוגל (GAE) או Azure. קבלת החלטות שיטיבו עם OSK אבל יפגעו ברווחים של השותפות המרכזיות – הוא בעייתי. כמו כן, החברות ב OSK מצד אחד אמורות לתרום לפרויקט, מצד שני רבות מהן מוכרות שירותי OSK, ולכן רוצות לשמור יכולות מסוימות שפותחו – רק לעצמן.
אולי בגלל כל צפיפות האינטרסים האלו, קשה למצוא דיונים ביקורתיים ב OSK שנובעים מתוך הקהילה: רוב מה שתשמעו מהחברות הללו הוא PR שבא להאדיר את OSK. חסך בדיונים שכאלו עשוי לפגוע בפרויקט בטווח הארוך.

בהקשר זה כדאי להזכיר גם את פרויקט CloudFoundry (בקיצור: CF), שמנסה להיות ה\"לינוקס של ה PaaS\" (שכבת ה Platform as a Service). אין עדיין שחקן בולט במיוחד בעולם ה PaaS, אם כי BeanStalk של אמזון מתקדם לשם בצעדי-ענק, וגם MS Azure ו Google AppEngine (בקיצור: GAE) נראים כשחקנים משמעותיים [א].
ל CF יש עדיין מתחרה משמעותית בעולם הקוד הפתוח: OpenShift של Red Hat.אמנם CF זכתה להרבה מומנטום בחודשים האחרונים בצורת חברות שהתייצבו מאחוריה – אולם הקרב עדיין לא הוכרע.

הפוסט מניח שאתם יודעים קצת על:

  • טכנולוגיות ענן (עסקתי בהם גם בפוסט2, פוסט3). כדאי גם להכיר מעט על וירטואליזציה.
  • מושג כללי אודות שירותי middleware – כגון Authentication & Authorization או Message Queuing.

מקורות 

OSK הוקם ע\"י שיתוף פעולה של נאס\"א ו Rackspace (חברת server hosting גדולה): שתיהן פתחו תשתיות ענן שנראו דומות – וב 2010 החליטו לשלב כוחות. OSK, כמעט כולו, כתוב בשפת פייטון (Python).

ב 2011 אובונטו (הפצת לינוקס) החליטה לשלב את OSK באסטרטגיה שלה להפוך להפצת הלינוקס הבולטת בענן.

ב 2012 הוקם ל OSK ארגון ניהול ללא מטרת רווח בשם \"The Open Stack Foundation\" שנועד לקדם את הפלטפורמה, תוך כדי שמירה על עקרונות של פלטפורמה פתוחה המפותחת ע\"י שתוף פעולה של קהילה רחבה.
הארגון מורכב מ:

  • קהילת מומחים (technical committee) מצומצמת שמתווה את הכיוון הטכנולוגי.
  • מועצת מנהלים (24 נציגים, 8 עצמאיים ועוד 16 מחברות תומכות).
  • קהילת משתמשים פעילה, הכוללת אלפי תורמי קוד ותיעוד.
ניתן למצוא בוויקיפדיה את רשימת החברים ב2 הפורומים הראשונים.

מאז הצטרפו לפרויקט כ 200 חברות. אפשר לציין את AT&T, AMD, EMC, IBM, HP, Intel ו SAP (החברה בה אני עובד). פרויקט OSK גבר על כמה מתחרים – וכיום הוא פרויקט הקוד הפתוח הבולט ביותר בעולם ה IaaS, ואחד מפתרונות ה IaaS היחידים בעלי הסיכוי להתחרות ב AWS של אמזון.

OpenStack, תומך ב API \"תואם אמזון\" – כך שבתיאוריה ניתן להריץ אפליקציה שנכתבה עבור AWS (בפועל: בהתבסס על שירותים מאוד מסוימים) על OSK – עם שינויים קלים בלבד.

הגרסאות של OpenStack ששוחררו עד היום. שמותיהן על שמות ערים בעולם – בסדר עולה של ה ABC.

מבנה הפרויקט

OSK בנוי בצורה מודולרית, ומחולקת לשירותים (Services) עצמאיים, סוג של macro-services. רבים מהשירותים ניתנים להחלפה ע\"י שירותים חיצוניים – מה שמוכיח את טענת המודולריות.
כל שירות של OSK מנוהל כפרויקט (כמעט) עצמאי, והוא מורכב בד\"כ מכמה תתי פרויקטים משלו.
בדומה לפרויקטי קוד פתוח אחרים, פיצ\'רים גדולים חדשים מתחילים ב Incubation projects ורק כאשר צוברים תאוצה – מצטרפים כפרויקטים מהמניין. מייד נעבור על השירותים / פרויקטים של OpenStack.

הארכיטקטורה של OpenStack. הסברים בהמשך. מקור: OpenStack documentation

התקנה:

בכדי להתקין OpenStack צריך:

  • host OS (בד\"כ לינוקס).
  • בסיס נתונים (בד\"כ משתמשים ב MySQL. אפשר גם PostgreSQL או אפילו SQLLite3 – אך לא בסביבת production)
  • Message Queuing Service, בד\"כ מתקינים RabbitMQ.
אפשר להתקין את OSK גם על VM ולא ישירות \"על הברזלים\".
שירותים:

כפי שציינתי, ל OpenStack יש 5 שירותי ליבה, שנדרשים ל(כמעט) כל תצורה:

  • Identity Services (שם קוד: KeyStone)
  • Compute Services – מה שמריץ את ה VMs. (שם קוד: Nova)
  • Image Services – כלומר Images של VMs. (שם קוד: Glance)
  • Networking Services – (שם קוד: Nova Networking או Neutron)
  • Dashboard (שם קוד: Horizon)
בנוסף יש עוד כמה שירותים שהם extended / אופציונליים – ומותקנים רק במידה והשירותים שלהם מתבקשים. אותם אכסה בחלק השני של הפוסט.
כנראה אחד הדברים שמעניינים הם הקבלה ל Amazon Web Services, שלא יכלו שלא לשמש השראה ל OpenStack:
  • Nova דומה מאוד ל EC2, וכפי שציינתי יש לו API תואם EC2 בו ניתן להשתמש.
  • Glance דומה מאוד ל AMI Catalog של אמזון
  • Cinder (עליו נדבר בהמשך) דומה ל EBS (כלומר: Elastic Block Store) של אמזון.
  • Swift (עליו נדבר בהמשך) דומה ל S3, וגם הוא מממש חלקים מה S3 APIs.
אחוזי ההשתפות ב OpenStack, מתוך האתר הרשמי.

שירותי הליבה של OpenStack









Keystone 
זהו שירות ה Authentication & Authorization של OpenStack.
השירות נקרא Keystone מכיוון שהוא חיוני לכל פעילות של OpenStack. הוא מנהל הרשאות של:
  • משתמשי-קצה
  • שירותים
  • Endpoints של שירותים (כלומר: יישות שדרכה צורכים את השירות)
לאחר שמשתמש מבצע login / עובר authentication ראשוני, הוא מקבל מהשירות token שיזהה אותו ולא ידרוש זיהוי מחדש לאורך ה login session הנוכחי.
Keystone תומך במודל של Role-Based Authorization, אותו הסברתי בפוסט הזה.
ניתן לחבר את Keystone לשירותי LDAP חיצוניים ולשירותי Federated Identity כמו SAML (עליהם כתבתי בפוסט הזה). OAuth, עד כמה שידוע לי, עדיין לא נתמך – אך התמיכה בו היא כרגע בפיתוח.


Nova 
נובה היא שירות ה compute של OSK, המנהל את מחזור חיי המכונות (הפעלה / השבתה / התאוששות) בענן של OpenStack. נובה הוא השירות הגדול והמורכב ביותר ב OSK.
שירות נובה לא כולל יכולות Virtualization עצמאיות (כלומר: hypervisor או container[ב]), אלא רק ניהול שירותי VM של צד-שלישי: KVM, Xen VSphere, Hyper-V וכו\'.

במערכת OSK, ניתן להשתמש ביותר ממוצר hypervisor אחד במקביל – אולם כרגע, בשל מגבלה טכנית, תאלצו להרים שירות נובה לכל אחד בנפרד.

בנובה מגדירים:
  • Region (אזור גאוגרפי): התקנה מלאה של OSK, המכילה כמה Availability Zones.
  • Availability Zone:  מיקומים שונים שנבנו ברמת ה data center כך שכשל של אחד (שריפה, ניתוק התקשורת, וכו\') לא ישפיע על האחר.
  • Host) Aggregates): קבוצות לוגיות של מכונות מרוכזות ע\"י תכונות, למשל: כמות מסוימת של זכרון (נאמר 128GB), רשת 10G, חומרה מיוחדת, וכו\'. קבוצות אלו משמשות ל Queries ולניהול הפריטים בקבוצה יחדיו.
Availability Zones שונים באותו ה Region משתפים את שירותי ה keystone וה Horizon שלהם – לצורך פשטות העבודה של שירותים אלו. 

Nova-Networking

Nova-Networking הוא תת שירות של נובה, המספק (בצורה וירטואלית) שירותי רשת ל VMs שרצים בנובה:

  • VLANs (\"שכבה 2\")
  • הגדרת רשתות IP למחשבים (\"שכבה 3\") – בכמה אסטרטגיות שונות.

VLAN

דבר שעשוי להיות לא ברור הוא הצורך / משמעות ה VLAN:
\"אני מכיר VPN, או הפשטות שונות של רשת, אבל מה ההיגיון ב LAN וירטואלי? האם LAN הוא לא הרכיב הבסיסי ביותר עליו עושים את וירטואוליזציית הרשת?!\" – אתם עשויים לשאול

בארגונים נהוג לחלק את הרשת הפיסית לתתי רשתות, משיקולי ביצועים (או בעצם SLA של תתי רשתות ספציפיות) ושיקולי אבטחה. למרות שבאוניברסיטה מלמדים עליהם, כבר לא משתמשים היום ב Hubs, Bridges או Repeaters (תרגיל: נסו לקנות bridge של Cisco או HP) – בעצם משתמשים רק ב Switches (\"שכבה 2\") או Routers (\"שכבה 3\") שהם חכמים יותר ויודעים למלא תפקידים של Bridge, Hub או Repeater (ע\"י Switch) או Proxy ותפקידים אחרים (ה Router). בעוד ש switch ביתי הוא דבר זול מאוד (בערך 100 שקל?), הסוויצ\'ים בהם משתמשים בארגונים יכולים לעלות אלפי שקלים. מדוע? בגלל אמינות, ביצועים, ויכולות שליטה ובקרה מתקדמות (SNMP, קנפוג מרחוק, וכו\'). תוספת עלות נוספת לארגונים הוא התפעול / תחזוקה של ה swtiches הללו ע\"י אנשי IT.

הרעיון של VLAN הוא פשוט מאוד: מחברים את כל המחשבים ברשת הארגונית ל switch יחיד (או מערך משורשר של switches – כשיש יותר מ~50 מחשבים, אולי מחזיקים עותק נוסף עבור redundancy) ואת כל תת-הרשתות מגדירים ע\"י קונפיגורציה של ה switch ולא ע\"י חיווט ידני. יש לכך תקן – תקן 802.1Q (נקרא בע\"פ: \"דוט וואן קיו\") המוסיף ל header של Ethernet frame שדה חדש בשם VLAN: ערך מספרי בין 0-4095. לכל פורט (חיבור פיסי לכבל) של ה switch – כזה שמחובר למחשב כלשהו, מוגדר VLAN אליו הוא שייך. המחשב עצמו לא אמור לדעת שהוא נמצא ב VLAN – רק ציוד התקשורת (שאלו בעצם ה switches) מודע לשדה זה. כל הודעת Ethernet שנכנסת מהמחשב ל switch דרך הפורט תסומן בתגית עם מספר ה VLAN שהוגדר (נאמר VLAN מס\' 3). כל הודעה שיוצאת מה siwtch דרך הפורט למחשב כלשהו – תוסר ממנה תגית ה VLAN (כי המחשב לא אמור להכיר אותה). תגיות אלו משמשות רק בתוך ה switch ובין switches שמחוברים זה לזה דרך \"Trunk Ports\".

היתרונות: פחות חומרה (\"כל הפורטים ב switch מנוצלים\"), פחות חיווט פיסי, יותר שליטה בתוכנה.
נושא זה הופך לחשוב אפילו יותר – בענן.

ממשק ניהול של Enterprise Switch, לא גן ילדים

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

לגבי הגדרות IP למחשבים (\"שכבה 3\"), nova-networking תומכת בכמה מודלים:

  • Flat Networking – המחשבים מקבלים IP בזמן ה boot. ייתכן ש tenents שונים יקבלו כתובות IP עוקבות, זה לא אמור לשנות.
  • Flat DHCP – המחשבים מקבלים כתובות IP ע\"י שירות ה DHCP של OPK (הדרך הנפוצה יותר). 
  • VLAN Manager – ה Tenant הוא זה שמספק למחשב את ה VLAN וכתובת ה IP המתאימה ביחד.
  • Flat and Private: המחשב מקבל כתובת בתוך הענן במודל Flat Networking ועוד כתובת לרשת פנימית שייחודית רק עבור ה Tenant אליו הוא שייך.
  • גישה אחרת הנקראת \"Provider Router\" מגדירה לכל tenant \"רשת-על\" משלו, שהיא מחוברת לתת-רשתות פנימיות שה tenant הגדיר. וכו\'.
הרבה פעמים מחברים כל מחשב בענן ל2 רשתות: רשת פנימית לצריכת שירותי ענן / תקשורת עם nodes אחרים, ורשת נפרדת לתקשורת עם האינטרנט. יש כמה וכמה גישות, וכמה trade-offs שיש לשקול בכל גישה. אלו עניינים ברמת תכנון ה landscape וה Operations.

Project Neutron (לשעבר Quantum).
שירות נובה של OpenStack הלך ונהיה מורכב, ולאורך הגרסאות התחילו להתפצל ממנו שירותים נפרדים. למשל: nova-volume שדאג להקצות שטח דיסק (וירטואלי כמובן, בפועל האכסון נעשה על NAS או פתרון דומה) לכל מחשב, השתכלל לשירות Cinder עליו נדבר בהמשך. ה APIs של nova-volume עדיין עובדים – הם פשוט קוראים היום ל Cinder.

גם שירות ה nova-network נהיה מורכב, מצד אחד, ולא מספיק גמיש – מצד שני.
Open Stack Foundation החליט להקים את פרוייקט Quantum (שהיו בעיות על זכויות השם, ולכן שמו שונה ל Neutron) שיהיה שירות ה Next-Generation של הגדרת וניהול רשתות ב OpenStack. הוא מאפשר:

  • להתמודד עם scales ש nova-networking התקשה להתמודד איתם. כנראה זה אזור של יותר מכמה מאות nodes במערכת.
  • Software Define Networking – הגדרת רשתות ו SLAs מעשיים, בצורה כמעט וגמישה לחלוטין. (SDN הוא באזז בימנו. שווה פוסט).
  • תמיכה בתקנים משופרים (יותר מ 4095 VLANS, תמיכה ב IPv6, וכו\')
  • תמיכה במודלים נוספים (למשך GRE או VXLAN)
  • מבנה מודולרי יותר, המאפשר הרחבה ב plugins. רשתות הוא נושא מורכב, וכמעט תמיד יהיה צורך לפלח שוק מסוים בפנוקציונליות נוספת: או תמיכה בחומרה ייעודית (למשל: Cisco) או תוכנה ייעודית (למשל VMWare) ייעודית בצורה טובה יותר, או תמיכה בפרדיגמות שונות לניהול הרשת. 

ניוטרון שוחרר בגרסת Felson, אולם לא זכה לאימוץ מהיר: הוא מורכב יותר, אינו תומך לאחור ל nova-networking (כלומר: מי שכתב קוד מול OSK צריך לעדכן את הקוד), וגם לא נדרש עבור הרבה משתמשים של OSK שעובדים ב scale קטן יותר.
למרות שניוטרון הוא במפת הדרכים של OpenStack כשירות הרשת היחיד שיוותר, nova-networking עדיין בשימוש נרחב, מתוחזק (אם כי בצורה פחות מבעבר) ומהווה את הבחירה של רבים שנגשים לעבוד עם OpenStack לראשונה.
נראה שיעברו עוד כמה שנים עד ש nova-networking יעלם כליל.

Glance
Glance (\"מבט חטוף\") הוא שירות שמאחסן images (תמונת-כונן) של VMs.

Glance מאכסן תמונות-כונן ברמת ה Tenant או ברמה הגלובאלית (זמינות לכולם) + מאפשר שליטה נוספת בהרשאות כמו: מי יכול לעדכן תמונת-כונן, מי יכול להשתמש בה וכו\'.

תמונות-הכונן עצמן יכולות להשמר בכמה מקורות אחסון שונים:

  • Cinder או Swift – שירותי האכסון של OSK עליהם נדבר בהמשך.
  • מערכת הקבצים המקומית (לא מומלץ)
  • כל שירות חיצוני שמאפשר לקרוא אותם אח\"כ דרך HTTP, למשל: S3 של אמזון.
תת שירות של glance הוא glance-registry המאכסן metadata כל תמונות-הכונן השונות. ה metadata מאוכסן בנפרד מתמונות-הכונן, מה שמאפשר לבצע עליו חיפושים וחיתוכים שונים ביעילות.

כפי שהזכרנו קודם לכן, OSK אינו כולל את טכנולוגיות ה VM – הוא משתמש לשם כך בפתרונות צד-שלישי. בהתאמה: תמונות-הכונן שהוא שומר יכולות להיות בפורמטים שונים, ע\"פ ה VMs השונים שבשימוש. ניתן להשתמש ב OSK במקביל בכמה סוגי VM (למשל: VMWare ו Virtual Box).

Horizon

Horizon הוא ה Dashboard של OpenStack אליו מתנקזים נתונים מכל השירותים השונים.
חשוב להבין ש Horizon הוא קודם כל שירות שאוסף ומארגן את הנתונים, ורק אח\"כ – שכבת ה Presentation שהיא ה Dashboard הויזואלי שכולם רואים.

ל Dashboard (\"לוח הזינוק\"?) של OSK יש בעצם 2 גרסאות עקריות:

  • Dashboard ל Admin – מנהל המערכת, נקרא System Dashboard
  • Dashboard למתשמש – לאו דווקא משתמש קצה, אלא בעל האפליקציה, נקרא User Dashboard. בעיקרון, Dashboard זה הוא subset של ה Dashboard של ה Admin.
ה Dashboard עצמו (נקרא גם \"OpenStack Dashboard\") הוא אפליקציית Django (ספריית פייטון מאוד פופולרית ל Web UI), שבנויה בצורה מודולרית (ניתן להרחיב) ו Brandable (ניתן לשנות צבעים ולוגו בכדי לשקף את זהות מיישם ה OpenStack הנוכחי באותו הרגע).
את כל הפעולות שניתן לעשות ב Dashboard ניתן לעשות גם בצורה פרוגרמטית, בעזרת APIs.
System Dashboard עם מיתוג של OpenStack

User Dashboard עם מיתוג של Redhat

סיכום

עברנו על שירותי הליבה של OpenStack, שמעבר עליהם אמור לתת מושג טוב מה OpenStack עושה.
שירותים מרכזיים חשובים הם שירותי האכסון (Cinder, Swift ולאחרונה גם Trove) – ויש עוד שירותים נוספים משמעותיים שמרחיבים את הפונקציונליות של OpenStack אפילו מעבר לכך.

[א] הנה סקירה מעניינת (ומעט מוטה לטובת CF), של השחקנים בעולם ה PaaS.

[ב] מן מכונות וירטואליות רזות שמשתפות בניהן תהליכים של מערכת ההפעלה – וכך צורכות הרבה פחות זכרון או דיסק, ומאפשרות אתחול מהיר במיוחד => MTTR נמוך מאוד. נושא ה Linux Containers מצדיק פוסט בפני עצמו.

עננים ציבוריים ועננים פרטיים (Cloud Computing)

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

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

דמיינו שאתם משתמשים באפליקציית-ענן לניהול לקוחות ופרטיהם הרצה על הענן של אמזון. מידע רגיש וקריטי לארגון שלכם יושב באתר המנוהל ע\"י ארגון אחר. אין לכם שום ידיעה מי נכנס ומתחבר פיסית למחשבים שהוקצו לכם – ויכול לגשת ולהעתיק / לשנות את הנתונים.

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

גם מבחינת חומרה, אם אפליקציה או מידע מסוים חשוב לכם יותר אתם יכולים לרכוש חומרה ייחודית, מנהל ה IT יוכל להורות על תחזוקה תכופה יותר. אם וירוסים משתוללים הוא יכול להורות על סריקת כל המחשבים ב Data Center. שליטה זאת בדרך כלל לא-אפשרית בענן. אמנם יש ספקי ענן, כמו Racksapce, שיתנו לכם להתקין חומרה ע\"פ דרישה, אך זה רק צעד אחד והם לא ימלאו חוסרים אחרים – שאותם כן הייתם יכולים למלא אם ה\"ענן\" היה יושב ומנוהל אצלכם בארגון.

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

אינטרנט פרטי?
באופן דומה להפליא, ארגונים רבים התקנאו בעבר באינטרנט וכל היכולות שהוא הציע. בתחילת שנות התשעים רוב הארגונים עוד עבדו עם רשתות של נובל או מייקרוסופט שתוכננו במקור לקנה מידה קטו בהרבה: עשרות עד מאות מחשבים. טכנולוגיות כמו Token Ring ו NetBIOS (או גרסה יותר מתקדמת שנקראה NBF) איפשרו יכולות די בסיסיות והיוו את הסטנדרט הארגוני. \"רשת\" לא הייתה יכולת מובנית במערכת ההפעלה. על המשתמש היה להתקין מערכת הפעלה, \"חומרה יעודית לרשתות\" (כרטיס רשת) ותוכנה (נובל או מייקורוספט) להרצת הרשת. לנובל, אם אני זוכר נכון, היה נדרש שרת ש\"ינהל את הרשת\". חשבו באיזה קלות אתם מתחברים היום עם ה iPad לרשת הביתית.
האינטרנט נחשב לאיטי (הגישה לרוב הייתה דרך קווי טלפון), חסר תמיכה בצרכים ארגוניים (לדוגמא הדפסה) ובלתי-ניתן לשליטה. בכלל – הוא תוכנן כאילו יש בעולם רק אינטרנט אחד(!). למרות זאת, טכנולוגיות האינטרנט היו יעילות בהרבה וככל שלארגונים נוספו עוד ועוד מחשבים, \"הרשתות הארגוניות\" התקשו לעמוד במשימה.

בתחילת שנות ה-90 אוניברסיטאות, וכמה שנים אח\"כ גם ארגונים עסקיים, התחילו להטמיע \"טכנולוגיות אינטרנט\" ברשת הארגונית. על מגבלת המחסור ברשתות התמודדו עם subnet masking ואת שירותי ההדפסה העבירו על גבי TCP. בהדרגה, פחת החלק של הטכנולוגיות של מייקרוסופט ונובל והוחלף ע\"י טכנולוגיות אינטרנט סטנדרטיות: HTTP, אתרי אינטרנט (\"פורטל ארגוני\"), Firewalls, דואר אלקטרוני ועוד.
הסיפור אינו אמור להפליא, הוא מתרחש שוב ושוב במהלך ההיסטוריה: טכנולוגיה עם ייתרון מובנה (scale במקרה שלנו) מתחילה בעמדת נחיתות, המתחרים מזלזלים וצוחקים עליה אך הבעיות בה נפתרות אחת אחת עד שהיא הופכת להיות מתמודדת ראויה. בשלב זה הייתרון המובנה של הטכנולוגיה החדשה אינו ניתן לחיקוי ע\"י המתחרים המסורתיים – והמערכה מוכרעת לטובתה. כך היה עם הטלפון שבגרסאות הראשונות היה מוגבל לטווח של 10 ק\"מ ודרש חיווט ידני. מנהלי המוצר של חברות הטלגרף, חברות בעלות אמצעים אדירים, צחקו על הטלפון והסבירו ש\"בשביל 10 ק\'\'מ תלך ותפגש עם האדם פנים-מול-פנים. כל הבלאגן כדי לדבר איתו בטלפון הוא פשוט use-case מגוחך\". בל ניסה למכור ל Western Union את הפטנט ב 100,000 דולר – אך הם ויתרו. התוצאה כיום ידועה. הרכבים הראשונים היו ללא בלמים, על הנהג היה ללחוץ על הקלאץ\' כל הדרך לעצירה. חברות הרכבת, תאגידים עצומי-מימדים, גיחכו והתעלמו. התוצאה ידועה. כך גם עם המחשב הפרטי (PC) ועוד ועוד… [3]

ע\"פ סקר עכשיווי (מקור, עמ\' 5) שתי הדאגות העקריות של ארגונים מאפליקציות ענן הן אבטחה וביצועים (זמני תגובה, איכות הרשת וזמינות). את שתי הבעיות הללו ניתן לפתור ע\"י הטמעת \"טכנולוגיות ענן\" בתשתית הארגונית: להתקין כמה עשרות שרתים עם טכנולוגיות Virtualization, אלסטיות וניהול אוטומטי – ולהריץ ענן קטן.

שלושה סוגים של עננים \"פרטיים\"
בשונה מ\"עננים ציבוריים\" המתאורים בפוסט 10 תכונות של שירותי ענן, יש כמה סוגים של \"עננים פרטיים\" אשר שונים בכמה תכונות עקריות. נחלק אותם ל:

  • ענן פרטי (Private Cloud)
  • ענן מנוהל (Hosted Cloud)
  • ענן משותף (Community Cloud)

ענן פרטי
מגמה שתופסת תאוצה היא ארגונים שרוצים להריץ את אפליקציות הענן – In House. \"שלחו לנו את ה Appliances\" הם מבקשים מאיש המכירות של אפליקציית ה SaaS – \"ה IT שלנו יתקין ויתחזק אותם, מקסימום עם קצת תמיכה מכם\". ספקי הענן לרוב מופתעים בהתחלה – אך יש כסף בצד השני והמעבר הוא לא כ\"כ קשה:

  • אפליקצית הענן לרוב נכתבה עבור חומרה לא ידועה. ניתן לבחון שרתים סטנדרטיים של חברות כמו IBM או HP ולמכור אותם כ \"Appliance\".
  • נוהלים וכלי אוטומציה לניהול הענן – כבר יש. לבנות גוף תמיכה על בסיס ידע קיים – לא כ\"כ קשה.
  • \"טכנולוגיות הענן\" אינן נחלתן הבלעדית של אמזון או מייקרוסופט, ישנן ספריות קוד-פתוח כגון OpenStack או vCloud שמספקות יכולות דומות.

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

שאלה לגיטימית היא למה פתרון שכזה הוא \"ענן פרטי\" ולא \"Data Center מנוהל מרכזית\"?
השוני הוא, במידה רבה, בשימוש בוירטואליציה. וירטואליזציה שמאפשרת לאפליקציות לרוץ על מספר שונה של שרתים – ע\"פ הצורך. אמנם הארגון צריך להחזיק מספיק מכונות לתמוך ברגעי שיא של צריכה, אך הוא יכול לווסת בין האפליקציות השונות שרצות על אותה חומרה. הסבירות ל Peak בשימוש בכל האפליקציות בו-זמנית הוא קטן[4]. עוד יכולת מעניינת היא היכולת של ה IT לחייב את היחידות הארגוניות השונות ע\"פ שימוש בשירותי המחשוב בפועל.
לרוב הענן הפרטי יהיה קצת יותר יקר מענן ציבורי – יש פחות ייתרון לגודל והנצילות של החומרה נמוכה יותר, אך יתרונות האבטחה והרשת המהירה מצדיקים את מחיר הפרמיום עבור ארגונים רבים.

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

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

ענן מנוהל
זהו שלב-ביניים בין ענן פרטי לציבורי: ארגון הרוצה אבטחה גבוהה ורשת יציבה ממה שמספקים ספקי ענן ציבוריים, אך לא רוצה לנהל את הענן בעצמו. חברות כמו HP, GoGrid ו IBM ישמחו לעשות זאת עבורו עבור תשלום (לא-)צנוע. חברות אלה מספקות שירותים של Hosting ל Data Centers של ארגונים כבר במשך שנים והן צברו מיומנות לא מבוטלת. אמנם ספק ה Hosting יושב באתר מרוחק (עם כל המגבלות שבכך), אך עבור התשלום המתאים הוא ישמח לפתוח VPN על גבי קו אינטרנט מהיר שישפר בהרבה את ביצועי הרשת והאבטחה שלכם.

ענן משותף
סוג ענן זה הוא עדיין בחיתוליו – אך נראה שיש לו הרבה פוטנציאל. חשבו על הענן הפרטי שמקימה רשת בתי חולים גדולה, למשל (Hospital Corporation of America (HCA – רשת אמריקאית של 150 בתי חולים ב 270 אתרים. HCA הוא ארגון-העל המשרת בתי-חולים רבים. כאשר ארגון מנהל מידע רפואי של חולים, יש עליו דרישות מחמירות בתחום אבטחת הפרטיות של של חולה. רופא שיחשוף פרטים חסויים של מטופל – עלול להשלל רשיונו. מה יקרה לאיש-IT רשלן? לצורך כך הגדירו בארה\"ב תקן מחמיר בשם HIPPA המחייב ארגונים המחזיקים במידע רפואי של חולים לנהוג ע\"פ סדרה מסוימת של נוהלים. אני לא מקנא בקבוצת הפיתוח שתאלץ להתמודד עם התקן בפיתוח תוכנה בענן,  אך לאחר שתאימות ה-HIPPA הושגה, תוכל HCA להציע את השירות לכל בתי-החולים ברשת.
ומה עם שותפי-מחקר? אוניברסיטאות, חברות תרופות ועוד? גם הם מחזיקים במידע רגיש הנכלל בתקן ה HIPPA. מלבד הייתרון של \"לא להמציא את הגלגל מחדש\", יש עוד ייתרון לאותו שותף עסקי שיצטרף לענן של HCA: הוא יוכל להציע את השירותים שלו לבתי-החולים השונים עם Latency נמוך (הרי השירותים יושבים באותו Data Center) ואבטחה גבוהה (התקשורת לא עוברת באינטרנט הפתוח)!

אם אתם זוכרים את הפוסטים הקודמים, ציינו שאחת המגמות הפחות מפורשות של שימוש בענן הוא אימוץ SOA ובניית המערכת בעזרת שירותים אחרים בענן. מצד אחד – זהו שיפור משמעותי ביכולת לפתח אפליקציה בקלות. מצד שני – לא ברור היכן השירותים הללו יושבים. אולי הם מפוזרים אצל ספקי IaaS/PaaS ברחבי העולים? ה Latency לפעולה הדורשת קריאה למספר שירותים, הקוראים לשירותים אחרים יכולה להצטבר לזמן משמעותי.
עוד אלמנט מורגש, למי שפיתח מערכת התלויה בשירותים שונים בפיזור גאוגרפי, היא בעיית הזמינות. ככל שהמערכת שלי תלויה ביותר שירותים חיצוניים כך גדל הסבירות שאחד מהם לא זמין ברגע מסוים. האם זו בעייה של ספק השירות, ספק הענן הציבורי או בעיית תקשורת – זה לא משנה בכלל. השירות לא זמין והפונקציונליות (או יותר גרוע – הזמינות) של האפליקציה שלי – נפגעת.

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

סיכום
כמובן שהחלוקה שלי כאן היא אחת וניתן לחלק את סוגי העננים בצורות שונות. בכל זאת, רציתי לתאר כמה היבטים פחות מוכרים של טכנולוגיות הענן. רבים בתעשיית התוכנה מאמינים שענן הוא המהפכה המשמעותית הבאה, ומכיוון שכולם (כמעט) עשו MBA ומכירים את ה-Case-Studies שתוארו לעיל (או דומים), הם לא ממתינים בחיבוק ידיים. הענן הוא לא רק אמזון, למרות ההצלחה המרשימה. יש מקום לעוד הרבה שחקנים, יצירתיות ואתגרים טכנולוגיים ועסקיים.

בהצלחה.

הערות שוליים

[1]  מערך ההגנה של חומת ברלין הוא סיפור מעניין בפני עצמו:

  • 302 מגדלי שמירה עם שומרים חמושים.
  • קיר בטון חלק בגובה 4 מטר עם גדרות תייל בראשו
  • שדה של ברזנטים מחודדים (שנקרא \"העשב של סטאלין\") שמקשה מאוד על ריצה והופך נפילה למסוכנת.
  • 20 בונקרים עם שומרים בקו ההיקף של השדה
  • מאות שומרים חמושים מלווים בכלבים תוקפניים
  • שביל גישוש ברוחב 6 עד 15 מ\' עם פטרול לגילוי חדירות למרחב
  • תעלה למניעת מעבר של רכבים
  • גדר חשמלית וגלאי תנועה
  • מרחב גדול שהושטח על מנת להסיר מקומות מחבוא אפשריים (שנקרא \"רצועת המוות\")
בודדים הצליחו לברוח דרך קו הגנה זה, רובם שומרים. רוב הבורחים מגרמניה המזרחית פשוט ברחו ממקום אחר (מה שמזכיר את הסינים שבנו במערב המדינה חומה אדירה באורך 5000 ק\"מ בכדי למנוע מג\'ינגיס חאן לפלוש, אך הוא פשוט עשה מעקף ופלש מצפון).

[2] מנכל אינטל, אנדי גרוב, ניסה ללמוד את הלקח וגרס \"רק הפרנואידים שורדים\". עד היום אינטל הפליאה להיות קשובה לשינויים: קו מעבדי הסלרון, מעבדים חסכניים באנרגיה ועכשיו מעבדים למחשבי tablet ואבטחה בחומרה. כל אלו תגובות של אינטל למגמות שלא הומצאו אצלה אך היא נותרה קשובה. האם מודעות מספיקה? האם ארגון רגיש-לשוק יצליח להיות מספיק גמיש כדי לשרוד את שינויי המגמה בעולם? האם התרבות הארגונית וההשקעות הקיימות לא יכבלו אותו, מתישהו, להשאר בפינה \"נוחה\"? שאלה טובה – אין לי תשובה.

[3] המעבר מ Appliances לענן הוא לרוב קשה בהרבה!

[4] אמזון וספקי IaaS אחרים אוהבים ליצור את הרושם שיש להם Data Centers אינסופיים – אך גם הם מוגבלים.

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 מתייחס לאחד או יותר מהבאים:

  1. חציצה בנתונים ובקונפיגורציה (לקוח אחר לא יכול בשום אופן לגשת לנתונים שלי)
  2. אי-תלות גירסה (אני יכול לבחור בגרסת התוכנה, ללא תלות בלקוח אחר שרץ איתי על אותו השרת).
  3. אי-תלות של תוספים 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 סיבות משמעותיות:

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

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

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

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

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

[4] Content Delivery Network.

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

מבוא ראשוני ובסיסי בהחלט ל Cloud Computing

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

כשעבדתי בחברת SAP הציגו לנו פעם את הטבלאות הבאות: צמיחה של ספקים לתוכנות עסקיות (המגזר בו משחקת SAP), הספקים המסורתיים המובילים (נקרא כאן On-Premise) מול הספקים המובילים בענן (נקרא כאן SaaS):

מקור SoftwareInsiderPOV blog

כפי שניתן לראות, בערך כל הספקים המסורתיים מצטמקים – וכל ספקי הענן צומחים. בעוד SAP בעלת נתח השוק הגדול בתחום (בצורה בולטת), אבל היא איננה בין 20 ספקי התוכנות העסקיות הצומחות – כמעט כל אלו היו ספקי ענן [1].

ובכן, המסקנה ברורה: שים גז על מוצרי הענן, ג\'וני!

אז למה לי מחשוב-ענן עכשיו?
מטפורה אהובה בתחום מחשוב הענן הוא של \"רשת החשמל\". לפני שנים רבות, מסתבר, כל משק בית (בעל תקציב מספיק) היה מייצר ומנהל את החשמל בעצמו: הוא היה קונה גנרטור, דלק, חלפים ומייצר חשמל. ייצור החשמל לא היה כ\"כ יעיל ואיכותי – אך לא הייתה רשת חשמל ארצית. הדרישה הייתה לגנרטור פשוט, זול וקל לתפעול. בנוסף, ההשקעה בחומרה (גנרטור) הייתה ע\"פ צריכת המקסימום: ליידי שושנה מבשלת צ\'ונט וזקוקה לחשמל רב ביום שישי בצהריים? – עבור אותם שעתיים בשבוע יש להחזיק גנרטור נוסף. מסייה שמעון מדליק דוד-חימום בחודשי החורפים הקרים – כל יום ב 9 בערב? – שיקנה גנרטור נוסף משלו על מנת לעמוד בהספק. האופציה לבצע Sharing של גנרטורים בין משקי בית הייתה תאורטית ולא מעשית.

לספק של רשת חשמל מרכזית (חברת חשמל) יש כמה יתרונות ברורים:

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

באופן דומה ניתן לקנות כח מחשוב מספק מרכזי: לא להתעסק בתחזוקה, לצרוך בכל רגע רק כמה שצריך ולשלם בד\"כ פחות. הארגון החליט להעביר את הטיפול ב Exchange Server לענן? התוצאה היא פחות התעסקות למחלקת ה IT (שלא צריכים ללמוד על נבכי ה Exchange Server בכדי לתחזק שרת בודד – המומחים של מייקרוסופט יעשו זאת) ולרוב במחיר נמוך יותר. עוד ועוד ארגונים רוצים כיום להעביר שירותים שפחות קריטיים לארגון – לניהול מרכזי. כך מחלקת ה IT תתמחה באותן מערכות שהתעמקות בהן קריטיות לארגון או בתמיכה פיסית במשתמשי קצה (\"לא הדלקת את המסך, אדוני\").
עוד תסריט אטרקטיבי הוא אימוץ אפליקציה חדשה: אם מחלקה קטנה בארגון רוצה להשתמש בתוכנה ייעודית, במערכת המסורתית היא צריכה לתאם עם גוף ה IT – לרכוש חומרה, על ה IT ללמוד את תפעול השרת. בקיצור – סיפור שלם שעלול לקחת חודשים. אם מדובר באפליקציית ענן, ראש המחלקה יכול להשתמש בתקציב הפנימי שלו לרכוש כמה רישיונות בכרטיס האשראי וברגע זה – לא צריך לדבר עם ה IT. אם המערכת לא מוצלחת – חודשיים אח\"כ מסיימים ומנסים מערכת חדשה.

מי-נגד-מי בענן
בתור התחלה אציג חלוקה קלאסית ל 3 סוגי ספקים של יכולות ענן:
מקור silverlighthack.com

אפליקציות מסורתיות נקראות בהיבט הענן לרוב אפליקציות On-Premise (לעתים כותבים On-Prem), שם שמשמעותו On-Location – מותקנות אצל הלקוח.
אפליקציות ענן, שהן לרוב גם אפליקציות On-Demand נקראות לעתים גם SaaS או Off-Premise = רחוקות.

SaaS – ספקי אפליקציות.
דוגמה טובה לאפליקציות הן GMail או Google Docs:

  • אין לכם מושג היכן או על איזה שרתים או באיזו מדינה האפליקציות רצות.
  • על מנת לגשת לאפליקציה אתם זקוקים רק לחיבור לאינטרנט, שם וסיסמה.
  • הן משרתות מיליוני משתמשים ונותנות לכל משתמש לצפות רק במידע שלו / לבצע התאמה אישית של האפליקציה.  

אפליקציות SaaS קיימות כבר יותר מעשרו (למשל Hotmail), אולם בשנים האחרונות הן נהיות נפוצות יותר ויותר. מדוע? האם אלו הדפדפנים שנעשו מהירים יותר? בשלות של טכנולוגיות אינטרנט? אולי קצב התעבורה ברשת שגדל לבלי-היכר? (מי חלם על קצב של 1Mbps ויותר מטלפון נייד לפני עשור?!) או אולי אלו החלוצות כמו Salesforce, ספקית אפליקציית ענן לניהול לקוחות (CRM – Customer Relationship Management), ששכנעה את לקוחותיה להעביר אליה, ולנהל באמצעותה, את המידע אחד הרגישים ביותר בארגון: מאגר פרטי הלקוחות?
אני לא יכול לומר, אך נראה שלכל אחד מהגורמים למעלה קשר מסוים למגמה.

PaaS – ספקי פלטפורמה.
ברוב המקרים, פיתוח של אפליקציות בענן איננו נעשה מאפס (Scratch). כמו שישנן מערכת הפעלה ובסיס נתונים שאנו יכולים לרכוש רישיונות ולחסוך הרבה מאוד עבודה בפיתוח מערכות מסורתיות – כך ישנן גם תשתיות לענן.
Google Apps היא ספקית PaaS קלאסית: הכנס לאתר ורכוש רישיון שימוש. לאחר מכן הורד את ה SDK ותתחיל לפתח. לכל תוצר רלוונטי אתה יכול לעשות Upload. אתה יכול לחשוף את האפליקציה באינטרנט ולדרוש הרשמה / הרשאות. בסוף כל חודש תקבל מגוגל חשבון ע\"פ מספר פרמטרים כגון זמן המעבד (CPU Type), תעבורת הרשת והשימוש בדיסק של האפליקציה שלך.
היכן היא רצה? על כמה שרתים? מתי ואיך מתחזקים את השרתים? תיקוני באגים בתשתית ה PaaS? שריפה ב Data Center? המהרת תוכן (CDN) עבור משתמשים מאוסטרליה? – אין לך מושג!

עשית Deploy לאפליקציה בענן ושם היא רצה. בנוסף אתה מקבל גישה לתשתיות ייחודיות (דרך ה SDK) החשובות לפיתוח בענן: [5]Multi-tenancy, תקשורת וסנכרון בין השרתים השונים, Middleware וחיבוריות ועוד.

עוד ספקים חשובים של PaaS הם force.com – התשתית של חברת Salesforce שמוצעת כפלטפורמה בפני עצמה ו Azure של מייקרוסופט.

IaaS – ספקי תשתית
עוד קטגוריה חשובה היא ספקי התשתית. ספקי PaaS מספקים קלות שימוש אך גם מציבים מגבלות. פחות שליטה על הביצועים, חיבוריות, יכולת לבצע debug ב production ועוד. מכיוון שעל אותו שרת פיסי יכולות לרוץ גם אפליקציות של משתמש אחר – מגבלות האבטחה עלולות להיות משמעותיות. ספק IaaS יספק לכם את השירות הבסיסי ביותר: חומרה. היחידה הקטנה ביותר – היא לרוב שרת בודד.
הוא יקצה לכם שרתים ע\"פ דרישה, יתחזק את החומרה, יספק תקשורת ופתרונות Storage (כגון NAS) אבל את המערכת תצטרכו לתפעל לבד: גיבויים, עדכוני תוכנה, ניטור השרתים (עומס, תקלות) ושינויים בהקצאת השרתים הנובעים מכך (הכל בעזרת API כמובן).

אם בעבודה עם ספק PaaS אתם מתמקדים בתוכנה בלבד, בעבודה עם ספק IaaS תזדקקו לאיש/צוות/מחלקת Operations משלכם. הם לא יתעסקו עם תקשורת וחומרה – אך יתעסקו בכל היבטי התוכנה של המערכת.

הבחירה בין PaaS ו IaaS היא trade off בין גמישות לנוחות. יותר גמישות = עבודה קשה יותר.
הספק הקלאסי של IaaS הוא Rackspace, שיתיר לכם לבחור את החומרה שאתם זקוקים לה ויאפשר לכם להתקין חומרה ייחודית על השרתים, אולם השחקן הגדול היא חברת Amazon – חברה המתפרנסת ממכירת ספרים ותשתיות ענן [6]. השימוש ב Amazon הוא הרבה יותר סטנדרטי והבחירה שלכם לרוב תסתכם בשרת \"גדול\", \"קטן\" או \"בינוני\".
שחקנים בולטים אחרים הם GoGrid, IBM SmartCloud ו Citrix עם Could.com.

כוכב עולה בתחום ה IaaS הוא פרויקט OpenStack – פרויקט Open Source שיזמו חברת Rackspace ו NASA אך כיום מלווה על ידי עשרות חברות חשובות בשוק (HP, Cisco, Intel, SUSE Linux ועוד רבות אחרות) שמטרתו לייצר API אחיד לפלטפורמות IaaS (אותו API לבקש עוד שרת, פרטים על מצב השרתים, שירותי Storage ועוד) כך שלא יהיה יותר Lock-in לספק ספציפי (בגלל ה API) והתחרות בין הספקים תהיה על בסיס איכות התשתית שהם מספקים – כלומר תהיה יכולת קלה לעבור בין ספק לספק.

כמובן ש Lock-In ניתן ליצור גם למרות API אחיד בבסיס (ראה ערך ANSI-SQL) – אך זוהי בהחלט יזמה מבורכת. נחיה ונראה כיצד היא תצליח במשימה הקשה [7].

מקור silverlighthack.com

אל העולם האמיתי

טוב, עכשיו אחרי שהבנתם את ההבדלים בין SaaS, PaaS ו IaaS, תשכחו את כל מה שלמדתם – זה לא עובד ככה.
וברצינות: החלוקה לשלושת הקטגוריה הייתה יותר נכונה בעבר, אבל הגבולות הולכים ומטשטשים. לדוגמא Amazon מספקת הרבה מאוד שירותים שהופכים אותה לסוג של PaaS בסיסי. ספקי PaaS מתירים לשכור גם שירות יותר בסיסי. ההבחנה שלמדתם כאן היא חשובה בעיקר כשפה וסדר בראש – אל תצפו שהמציאות בשטח תתאים בדיוק, By the book, לתיאוריה.

מקור: Yankee Group

כמו שניתן לראות בתרשים זה או בדוחות של [Deloitte[8, כיום הכסף הגדול הוא צרכני (SaaS) – כצפוי. באופן קצת מפתיע יש יותר שימוש ב IaaS מאשר ב PaaS. הסיבה לדעתי היא שהפלטפורמות השונות (PaaS) עדיין לא טובות מספיק ועדיין לא החל תהליך של Commoditization. הבחירה של חברות SaaS רבות הוא לשכור תשתית (IaaS) ולפתח פלטפורמה בעצמן. נשמע שזה ישתנה בעתיד ו IaaS יהפוך ליותר נישתי – עבור אפליקציות בעלות דרישות מיוחדות.

[עדכון יוני 2014]: מה היה קודם?

קיבלתי מייל עם שאלה – שדי משלימה את נושא הפוסט, ולכן רציתי לשתף אותה:

שלום ליאור. אני תמיד נהנה לקרוא בבלוג שלך. היום כשבונים אפלקיציה מאחסנים אותה בענן – מסיבות של עלויות וסקאלביליות. אני מדבר בעיקר על אתרים על בסיס ג\'אווה ונוד. 
יש לי בעיה למפות את כל האפשרויות – כלומר אם אני לא קונה ענן שיש לי package של ג\'אווה לדוגמא אז זה אומר שהואפציה הישנה היא אתר shared שבו אני מתקין (לא נשמע הגיוני שיתנו לי להתקין משהו על משותף) ג\'אווה. 
אני אשמח אם תפקח לי את העיניים – של מה היו הפתרונות של פעם לעומת הפתרונות של היום. ואיך זה מסתדר עם העלויות. 
אז אם אתה יכול לעשות סדר בבלגן… 

והנה התשובה שלי:

היי xxx,

ה\"אופציה הישנה\" היא בד\"כ אחת מ2:
  • לנהל את השרתים אצלך בחברה
  • לשכור שירות hosting
שירותי hosting ברמת \"האפליקציה\" ניתנו בעיקר לאתרים סטאטיים / PHP או ל frameworks מוכרים כגון wordpress, jumla וכו\'.
אם הייתה לך אפליקציה ייחודית (ג\'אווה למשל) היית שוכר בד\"כ מקום. שירות שכזה מאפשר לך לשים מחשב שלך ב Data Center של מישהו ולקבל שירות בסיסי לטיפול בחומרה (force restart למחשב, החלפת דיסק קשיח / ספק כח וכו\', טלפון בלילה אם המחשב השתגע ע\"פ monitoring מאוד בסיסי).
שירותים יותר מפנקים גם סיפקו לך את החומרה – למשל כמו Rackspace ואולי נתנו שירתים בסיסיים של רשת (Firewall, אולי Load Balancer וכו\') או גיבוי. יש כנראה אלפי או עשרות-אלפי נותני שירותים כאלו בעולם, ועם מהפכת הענן הם נותנים יותר ויותר שירותים ו/או פושטים רגל.

עדיין יש לא מעט שרתים מנוהלים באחת מ2 הדרכים הללו – אך זה הופך פחות ופחות נפוץ.

העלויות היו גבוהות משמעותית. הסיבות העיקריות:
  • היית צריך להחזיק / לשכור חומר ל peak load שלך. אם בשיא הצהריים אתה זקוק ל3 שרתים ובלילה – רק לאחד (ב 20% CPU), היית משלם על שלושה שרתים כל הזמן – והם היו יושבים \"מובטלים\" חלק גדול מהזמן.
  • היכולת שלך או של ספק לקנות חומרה בזול ו/או לתחזק אותה ביעילות.
מקווה שעזרתי,
ליאור

סיכום

זהו זה, מקווה שנהניתם. אני מתכוון להמשיך לצלול לנושאים שונים בענן בכמה פוסטי-המשך.

[1] http://blog.softwareinsider.org/2010/03/18/software-insider-index%E2%84%A2-sii-2009-sii-top-35-enterprise-business-apps-vendors%E2%84%A2/. המגמה מאז קצת התאזנה – המשבר של 2008 משך הרבה לקוחות לפתרון זול, מיידי וללא השקעה גדולה מראש – יתרונות ברורים של מחשוב הענן.

[2] אלמט זה נקרא Annoyance. \"ההתעסקות במטלות שאינן ב core business של החברה מפריעים לה להתמקד בעיקר – ואם ניתן עדיף להוציא אותם מחוץ לארגון\" – היא טענה מקובלת.

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

[4] אם אצלכם בבית אתם לא יכולים להפעיל כמה מכשירים במקביל זו בעיה של התשתית בדירה – הרחיבו את התשתית בהשקעה של כמה אלפי שקלים ותוכלו לצרוך פי 2, פי 10, פי 100 – כמה שתרצו.

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

[6] אם תהיתם כיצד Amazon הגיעה לשירותי ענן הסיפור הוא כזה: בשלב מסוים של חייה, אמאזון הבחינה שהמחסנים (הפיסיים) שלה אינם מגיעים לתפוסה מלאה חלק גדול מהשנה. היו לה יכולות לוגיסטיות יוצאות-דופן שפיתחה במשך השנים – אותן החליטה להשכיר כאחסון (Storage) במחסנים שלה במודל Leasing. כמה שנים אח\"כ חזר אותו הסיפור עם אחסון דיגיטלי ו S3 – שירות האחסון המבוזר של אמאזון. יש לציין שאמאזון, כאחת מהספקיות המקוונות הגדולות, הייתה מובילה טכנולוית כבר לפני שנים. ההמשך מכאן היה דיי טבעי.

[7] לספק מוביל כמו Amazon יש מעט מאוד סיבות לאפשר ללקוח לעזוב בקלות. קרוב לודאי שהיא מעסיקה אנשים שימצאו דרכים לעשות בדיוק את ההיפך.

[8] https://www.deloitte.com/assets/Dcom-Global/Local%20Assets/Documents/TMT/cloud_-_market_overview_and_perspective.pdf