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

קיצור תולדות ה SCRUM, חלק 2 – עקרונות ה LEAN

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

לא משנה באיזו מתודולוגיה אג'ילית תבחרו לעבוד ובאיזו תעשייה, שווה להכיר את המקור – הרי הוא ה (TPS (Toyota Production System של חברת טויוטה. להלן כמה מהערונות העיקריים של ה TPS שאומצו ע"י תנועת ה LEAN. קרוב לוודאי שכמה מהמושגים שאציין ישמעו לכם מוכרים.

שייך לסדרה: אג'ייל – מתודולוגיות פיתוח רזות

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

אחד ההבטים שמתקדים בהם ב TPS הוא מציאת ה waste וביטולו. זאת בניגוד לגישת ה Waterfall בה מנסים לקחת תהליך קיים – ולמקסם (maximum) אותו. על פניו, זו נשמעת דקדקנות גרידא – אך ההבדל בצורת החשיבה מוביל לתוצאות שונות לגמרי.

הנה דוגמא משירות המילואים בצה"ל: בשירות המילואים אני מפעיל ציוד מסוים. במשך כמה שנים אנו מוזמנים לקורס רענון של הפעלת הציוד: "זכרו – X לא בשימוש, Y עובד לפי הסדר 1…2…3". מאחר והקורס נמשך בעצלתיים במשך שבוע (וחזר על עצמו שנה אחר שנה) – גברו התלונות מצד אנשי המילואים. תשובת הקצינים של היחידה הייתה (חישבו: חשיבה מערבית – שיפור התהליך הקיים) לקצר את הקורס לשלושה ימים, להפוך את השירות לאינטנסיבי וממושך (כלומר – מ 8 בבוקר עד 7 בערב). רוב אנשי המילואים שבעו נחת, או לפחות הפסיקו להתלונן. לא נראה שניתן היה לשפר את הקורס הרבה מעבר.
אם מומחה TPS היה עושה את אותם המילואים, הוא בוודאי היה שם לב שהמכשירים אותם אנחנו מפעילים אינם נוחים לשימוש. ע"י ביטול (פיסי) של הפקדים של פונקציות שכבר אינן רלוונטיות כיום בצה"ל ושילוט נכון על המכשיר – ייתכן ולא היינו זקוקים לקורס רענון בכלל. במקום לשנן את הכשלים בשימושיות של הציוד – ניתן היה במהלך לא מסובך להפוך את הציוד להיות קל-לשימוש.

5Y, בעצם 5xWhy – "לפתור בעיות מהשורש"
עוד עקרון חשוב הוא תחקור מעמיק על מנת לפתור בעיות מהשורש. ע"פ עיקרון ה 5Y, בכל פעם שנתקלים בבעיה יש לעצור ולשאול את השאלה "למה?" חמש פעמים – ורק אז לגשת לביצוע הפיתרון.

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

למי שעבר אי-פעם בחברת תוכנה ישראלית דיי ברור שאם יציג למנהל ניתוח 5Y, קרוב לוודאי שישמע "טוב, הלכת רחוק. ככה זה אצלנו ואף אחד מאיתנו לא ישנה את זה. חבל על הזמן שבזבזת".
בכל זאת ניתן להתחיל ב 2Y – ניתוח כזה יתקבל כנראה בברכה ויציג שיפור מורגש על פני המצב הקיים.

Stop the Line" – Jidoka"
עקרון מחמיר זה אומר שברגע שיש תקלה (לדוגמא זיהוי חלק לא תקין בפס הייצור) יש לעצור מיד את הקו, לתחקר במקום את הסיבה (זה יהיה נאמר 2Y, לא 5Y), לתקן ורק אז להמשיך ולהפעיל את פס הייצור. היכולת של תחקור ותיקון מהירים היא קריטית להצלחה – ובאחריותם של העובדים (לא סביר להשבית את הקו עד שהמנהל יהיה זמין).

בהקשר זה אני רוצה להציג עקרון מרכזי נוסף של ה TPS (שקשור גם ל 5Y): תיקון בעיות מהשורש והמנעות מהוספת תלאי / שכבה מרפדת.

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

אם נפעל ע"פ עקרונות ה LEAN נעבור ממצב 1 (השמאלי) למצב 2 (במרכז) – בו יש פחות Waste. אולם במצב זה בעיה שעד עתה הייתה מוסתרת – מוענת מאיתנו להמשיך.

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

הנה כמה דוגמאות:

  • בעיה: אנו מאחרים ב Deliveries. פתרון Waterfall: להכפיל כל הערכת זמנים פי 2, ראש הקבוצה יכפיל את ההערכות פי 1.5 ומנהל הפיתוח יוסיף עוד שבועיים משלו "בצד".
    • פתרון אגי'לי: שיפור תהליך הערכה כך שיהיה ניתן להסתמך עליו או יצירת חוזה "גמיש" עם הלקוחות, בו מתחייבים על חלק מהתכולות, וחלק אחר נתון להספק משתנה של גוף הפיתוח.
    • הערה: ע"פ ה LEAN כל Buffer הוא Waste, ויש לצמצם buffers למינימום האפשרי.
  • בעיה: אין תקשורת טובה בין קבוצת הפיתוח לקבוצת ה QA. פתרון Waterfall: נוסיף מסמכים שישמשו כתקשורת (!Waste – סביר להניח שרוב העבודה על מסמכים אלו תהיה בזבוז זמן. ייתכן ותעלה הטענה "על שיפור צריך לשלם" – אך זו טעות לוגית, מכיוון שבמקרה זה סביר שנשלם יותר משנדרש).
    • פתרון אג'ילי: למצוא דרכים לשפר את התקשורת בצורה לא בזבזנית: להושיב את הקבוצות קרוב אחת לשנייה, לצרף את ה QA למפגשי סנכרון יעילים עם קבוצת הפיתוח וכו'.
  • בעיה: עובד מסוים לא מבצע עבודתו כראוי. פתרון Waterfall: שמישהו אחר יעשה זאת במקומו. או אולי – נוסיף מישהו בכיר שיפקח על כל צעד שלו.
    • פתרון אג'ילי: לחנוך ולסייע לאותו אדם לבצע את העבודה שלו כראוי ולהגיע לעצמאות.
  • בעיה: שינוי קוד רוחבי במערכת פספס קומפוננטה מסוימת. פתרון Waterfall: להוסיף לכל מסמך Design פרק עם כל הקומפוננטות או ביצוע ישיבות עדכון בה ישתתף נציג מכל קומפוננטה לכל שינוי במערכת.
    • פתרון אג'ילי: לייצר רישום: מי רלוונטי לאיזו קומפוננטה, ולאמן את כל אנשים בפיתוח להשתמש בה בתבונה. זה יכול להיות תהליך ארוך וקשה יותר ליישום – אך בסיומו יהיה מעט מאוד Waste.

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

Kanban ("ארגזים מסומנים")
עקרון חשוב נוסף ב TPS הוא החתירה ל "Flow". מצב בו התהליך מתקתק בצורה טבעית, קלה וכמעט בלתי מורגשת אך בכל זאת – יעילה להפליא. חידוש משמעותי בפילוסופיה האג'ילית הוא שימוש עקרי במשיכה "Pull" כנגד דחיפה [2]"Push" המקובלת בניהול המסורתי.

בתעשייה המסורתית, היו מייצרם בקצב בו המכונות יכולות לעבוד – במקום בקצב בו נדרשת התוצר. בתעשיית התוכנה הקבלה אפשרית היא פיתוח 100 פי'צרים במוצר חדש (כי זה מוצר מבטיח וחשוב להצליח בו) מקום לפתח רק 20 פיצ'רים שידועים שנדרשים. הקצב נקבע ע"פ יכולת הייצור ולא ע"פ הביקוש.

הרעיון של Kanban הוא ליצור רצף (Flow) של משיכות. טויוטה אינה מזמינה כל חודש מהספקים שלה כמות קבועה של חומר גלם וחלקים. היא איננה יודעת כמה מכוניות מדגם זה או אחר הלקוחות באמת יזמינו. במקום זאת, כשיש הזמנה לרכב – רק אז נשלחת בקשה למחלקת ההרכבה (השלב האחרון בשרשרת ייצור הרכב), זו שולחת את הדרישות שלה למחלקות הייצור השונות ואלו מזמינות את החלקים מהספק.
כיצד מזמינים 18 ברגים להרכבת דלת? כמובן שזה יהיה בזבוז. טויוטה מחזיקה מלאי מינימאלי. במחלקת הדלתות יש 10 ארגזים של ברגים. כל פעם שארגז מתרוקן שמים אותו בערמה של ארגזים ריקים. על הארגז רשום בצד אחד "ברגים מסוג 123" ומצד שני "מחלקת דלתות – צוות יושימושי". הארגז יישלח (ביחד עם ארגזים אחרים ריקים) לספק – אשר ימלא אותו בברגים ע"פ הכיתוב: "ברגים 123". הארגז יחזור מלא בחלק החסר לשולח – במקרה שלנו הצוות של יושימושי במחלקת הדלתות.

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

Amplify Learning / Amplify Feedback
עוד עקרון חשוב, שהוא אולי המוכר ביותר במתודולוגית SCRUM, הוא העקרון של קיצור מחזורי ה feedback על מנת להגביר את הלמידה.

  • אם "מכל שחרור של גרסה מקבלים מידע חשוב מהלקוחות" – שחררו גרסה פעם בחודש, ולא פעם בשנה.
  • אם "ביצוע Build תופס בעיות אינטגרציה" – בנה כל הזמן (Continuous Integration) ולא פעם בשבוע.
  • אם שיחת הערכה של עובד-מנהל היא טובה ועוזרת לתאם ציפיות – עשה אותה פעם ברבעון ולא פעם בשנה.

וכו'

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

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

  • גמישות מרבית לבצע את המשימות הנכונות. בעולם התוכנה: לא עוד פיצ'רים בקומפוננטה A שלא מעניינת אף לקוח כרגע – רק כי שם יש אנשים פנויים.
  • אחריות כוללת ואי נפילת בעיות "בין הכסאות". לא עוד מצב בו עובד א' ועובד ב' עשו עבודה נהדרת – אך התוצאה הכוללת היא גרועה.

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

Andon – "נראות"
את המידע החשוב יש להבליט החוצה, כך שמקום שיהיה צריך לחפש אותו – אי אפשר יהיה להתעלם ממנו. לוח ה Sprint Backlog בחדר הצוות הוא דוגמא לכך. במקום מנהל יישב עם העובדים, אחד אחד, בכדי לבנות תמונה מלאה איך הספרינט
מתקדם – התהליך בעצמו יוצר את התמונה על הלוח.

Genchi Genbutsu – "לכלך את הידיים"
עקרון זה טוען שהבנה טובה נרכשת רק דרך עשייה. במקום שמנהלים יקראו ספרים על SCRUM ויביטו בו מרחוק – עליהם להתנסות ולהצטרף לצוות SCRUM. על הארכיטקטים ללכך את הידיים בקוד ולא להסתפק בישיבה במגדל השן ולהעיר הערות. על המפתחים להתקין את המוצר בעצמם בסביבה דומה לזו של לקוח בכדי ללמוד מה מצפה ללקוח או ה QA שמשתמש בקוד שלהם.

[1] Retrospective גם מתמפה לעקרון ב TPS שנקרא Hansei – התבוננות עצמית.

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

קיצור תולדות ה SCRUM, חלק 1

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

לא מעטים יספרו על גוגל – חברה שכמוה לא הייתה מעולם: ״איזו חברה מאפשרת לעובדים לעסוק יום בשבוע במה שמתחשק להם??". ויש גם את SCRUM, XP וכל תנועת ה Agile: מי שמע על דבר דומה בתעשייה המסורתית?

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

שייך לסדרה: אג'ייל – מתודולוגיות פיתוח רזות

מי שעוד מתמודד עם הבנת SCRUM – מוזמן לבדוק את התרגום העברי לספרון המצויין: "סקראם מהשוחות" (שוחה – קדמת שדה הקרב)

במשך השנים תעשיית התוכנה חיפשה רבות, אך כמעט ולא מצאה כלים שמסייעים משמעותית לפריון (Productivity) : לא OO, לא IDEs, לא שפות תכנות חדישות, לא שיתוף קוד ולא SOA. אולי אפילו ההפך [1].

היו מספר שיפורים מורגשים. המעבר משפת אסמבלי לשפות עליות היה שיפור גדול מאוד. השימוש ב Garbage Collator הוא עוד שיפור מובהק. גם המעבר לעבודה במתודולגית SCRUM נראה כשיפור משמעותי. כנראה הגדול בעשור האחרון.

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

בואו ונחזור אל ההיסטוריה, מאין הגיע ה SCRUM/AGILE/LEAN וכיצד הוא נוצר…

מפעל המכוניות של משפחת טויודה

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

בשנת 1937 הקים טויודה חברה לייצור מכוניות – תחום מבטיח שצמח במהרה. אולם באותה תקופה ביפן לא היו מקובלות הלוואות, מכירה באשראי או השקעות חיצוניות (כגון Venture Capital). זו הייתה מגבלה חמורה ליכולת של העסק לצמוח במהירות. רק לאחר שסיים את ייצור batch של רכבים יכול היה למכור אותם ברווח קטן ולהתחיל ב batch גדול מעט יותר. מהירות הכנת ה batch (מה שנקרא Lead Time) וכמות המזומנים הזמינה בכיס בכל רגע נתון, הפכו להיות הגורם המרכזי ביכולת החברה לצמוח. טויודה התמקד במשימה: פיתוח הדרכים היעילות ביותר לקיצור ה Lead Time והגדלת ההון הנזיל.

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

  • את המשימה (למשל: בניית רכב) יש לחלק למשימות פשוטות וסדרתיות.
  • על המנהל להדריך את העובד ולהקים עבורו סביבת עבודה אופטימלית ליעילות גבוהה – אין להשאיר דבר ליד המקרה (או מוחו המוגבל של העובד).
  • כל עובד מתמחה במשימה ספציפית ומתוגמל ע"פ הספק.
  • הקמת מכוונת הכי גדולות, הכי יעילות בעזרתן כל עובד יוכל לבצע משימה כלשהי במהירות אדירה.
  • ניהול מלאי מספיק גדול בכדי שהמכונות לא יפסיקו לעבוד לרגע. Time is money, friend.
בקיצור – פס הייצור המודרני.

יעילות נוסח המהפכה התעשייתית / Waterfall
יעילות עור-ועצמות

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

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

תרומה משמעותית נוספת הייתה של פרופ' אדוארד דמינג, חוקר אמריקאי שהציג גישה חדשה לאיכות: "איכות אינו שלב בתהליך, איכות צריכה להיות שזורה בתהליך – לכל אורכו" (מה שנקרא TQM – Total Quality Management). בעוד שבארה"ב לא התייחסו אליו ברצינות, ביפן גילו עניין עצום בתורתו, אימצו אותה והוא קיבל מעמד של גורו-על.

התוצאות לא איחרו לבוא והיו ניכרות. טיויטה בראה יעילות ואיכות שלא נראו עד כה בתעשיית הרכב.

יעילות נוסח טויוטה / Agile / Lean

מפגש התרבויות

למרות שהייתה מצליחה מאוד ביפן, טויוטה החלה לייצא למערב רק לקראת שנות השישים. היא זכתה ליחס קריר ועניין מצומצם מצד הלקוחות האמריקאיים. לזכרונות מלחמת העולם השנייה כנראה עוד הייתה השפעה, אך מעבר לכך המכוניות שטויוטה יצרה היו קטנות וחסכוניות בדלק, כמתאים לשוק היפני (כבישים צפופים, דלק יקר), הפוך לחלוטין מהמצב בשוק האמריקאי. דבר נוסף שלא הקל הוא מס גבוה על יבוא רכב שהוטל בארה"ב בשנות השישים – כדי להגן על התעשייה המקומית האמריקאית בפני תחרות מהמזרח.
לעזרת היפנים, במקרה, הגיע משבר האנרגיה של 1973 – כאשר מדינות ערב עצרו את אספקת הנפט למערב כתגובה לתמיכתן בישראל במלחמת יום הכיפורים. מחירי הנפט האמירו בצורה חדה (המחיר עלה פי 4 תוך זמן קצר. בחישוב מנורמל להיום: מ 15$ ל 60$ לחבית). התלות של המערב בנפט הייתה טוטאלית: עסקים הפסיקו לעבוד (לא יכלו לייצר ברווח), הכלכלה קרסה ולחלופות זולות ומיידיות לאנרגיה היה ביקוש רב. הצרכנים האמריקאים החלו לחפש רכבים הצורכים מעט דלק וכך שיחק מזלן של היצרניות היפניות: הן הצליחו לחדור בצורה משמעותית לשוק האמריקאי. משבר האנרגיה הסתיים ב 1974 כאשר מצד אחד ארה"ב דרשה מישראל לסגת מסיני (לא, נראה שזו לא הייתה יזמה ישראלית. חומרי הלימוד של משרד החינוך בהסטוריה הם קצת מגמתיים) ומצד שני בריטניה הציגה בפומבי תוכנית אופרטיבית לפלוש למדינות ערב ולקחת את הנפט בכוח.
אותה שנה הספיקה לטויוטה להגיע למספיק לקוחות אמריקאים בכדי שיגלו שני דברים:

  • המכוניות של טויוטה לא כ"כ גרועות.
  • המכוניות של טויוטה, באופן מוזר, אינן מתקלקלות.
עוד ועוד לקחות רכשו את "המכוניות שאינן מתקלקלות" וחברות הרכב נלחצו וניסו להבין "איך היפנים עושים את זה?" [5].
ב1980 פורמה כתבה ברשת NBC שעוררה הדים בשם "?If Japan Can, Why can't we".

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

אימוץ השיטות של טויוטה בעולם המערבי
השם שנתנו האמריקאים לשיטה היפנית הוא Lean Manufacturing ולרעיון של ניהול מלאי – (Just In Time (JIT. שם אמריקאי ומדריכים אמריקאים עזרו רבות לקבל בחום את השיטה. אימוץ השיטה התחיל אמנם מתעשיית הרכב אולם התפשט לתעשיות אחרות רבות. כיום רוב תעשיית הייצור, אך גם חלק גדול ממגזר השירותים, הבנייה, רשתות קמעוניות ואפילו משרדי ראיית חשבון והמוסדות האקדמים אימצו את עקרונות ה Lean. הייתרון התחרותי הינו כ"כ חד-משמעי, כך שבתעשייה בה קם שחקן שאימץ את השיטה בהצלחה – נאלצו שאר המתחרות לאמץ אותה גם כן על מנת לשרוד[6]. אם תבקרו, למשל, בסניף של דומינוס פיצה ותצפו בעובדים בפעולה – תוכלו לזהות רבים מהעקרונות שאציין בהמשך. אם תשאלו את העובדים האם הם עובדים "Lean" קרוב לוודאי שתענו: "מה?? … לא. סתם. ככה אנחנו עובדים פה".

בתעשיית התוכנה, היו כמה נסיונות ליישם מתודולוגיות פיתוח המבוססות על עקרונות ה Lean כבר באמצע שנות ה-90. תשומת הלב המשמעותית הגיעה לדעתי עם הופעת ה Extreme Programming אותה הציג קנת בק – מתודולוגיה קיצונית אך מעוררת מחשבה.
עולם התוכנה נתן שם משלו לסגנון ה LEAN ושמו: Agile. עבודה רבה נעשתה ע"י מרי וטום פופנדיק אשר חזרו למקורות ועזרו לתרגם את רעיונות ה LEAN לעולם התוכנה בצורה מקיפה [7]. בשנת 2001 התכנסו כמה מראשי המתודולוגיות השונות לחתום על מסמך הסכמות המשותף לכל המתודולוגיות – הרי הוא ה Agile Manifesto.

נראה שרק שבאמצע שנות האלפיים ה Agile "חצה את התהום" – והגיע למיינסטרים. כיום חברות רבות, כגון Microsoft, Yahoo, Google, SAP, IBM, Salesforce ועוד אימצו בחלקים כאלו או אחרים את SCRUM ובהצלחה.

היוצרות התהפכו כך שהיום SCRUM (ומתודולוגיות Agile אחרות כמו Extreme Programming ו Kanban) הם בחזית הבמה. מלבד ההייפ שאולי מלחיץ את מי שלא ניסה עדיין "מה זה הדבר הזה? איך אני הייתי מסתדר בכזו סביבה"?, כנראה שיש פה באמת צעד גדול לתעשייה. במשך חיי המקצועיים ראיתי כמה וכמה הייפים שהתפוצצו – אך באמת ובתמים, נראה לי ש Agile הוא כאן בכדי להשאר, ואפילו – לשלוט.

על העקרונות המהפכניים שהציגה גישת ה LEAN אפשר לקרוא בפוסט ההמשך.

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

[1] מה שנקרא "There is no Silver bullet".

[2] ישנם דיווחים על הצלחה של SCRUM בחברות שונות, גדולות וקטנות – אך עדיין מוקדם לדעת בוודאות מה גודל ההצלחה. מנסיון אישי, קשה לי לחשוב על שינוי משמעותי בתעשייה בעשור האחרון שמשתווה ל Agile. למשל, TDD הוא נהדר – אבל הוכח כבר שאינו מתאים לכל אחד = אינו scalable ברמת התעשייה. SCRUM הצליח אצל אנשים שאהבו אותו יותר ופחות, ארגונים קטנים וגדולים, פרוייקטי פיתוח ותחזוקה. כמובן שיש ש SCRUM לפעמים הצליח פחות ולפעמים יותר.
[3] כמובן שהשפל הגדול היה האטה משמעותית במגמה, אך זה רק היה עיכוב – והיא המשיכה  והתעצמה.

[4] מספר משיכות המכחול לכתיבת "טויוטה" הוא שמונה. מספר מזל בתרבות היפנית, שאינה נקייה מאלמנטים מיסטיים.

[5] כיום לטויוטה (ולמותג היקרה שלה – לקסוס) יש רק ייתרון קל באיכות ע"פ המתחרות האחרות (ע"פ סקרי J.D Power אשר בונים בסיס נתונים על תקלות ברכב של עשרות אלפי לקוחות). בשנות ה-80 פער האיכות היה משמעותי ביותר, אך נראה שהפער הצטמצם בכך שכל חברות הרכב בעולם אימצו את שיטת ה Lean.

[6] דוגמא טובה היא DELL שהצליחה לייצר מחשבים מהר, טוב וזול מהמתחרות ושברה את השוק. HP אימצה את שיטות ה Lean גם כן, התאוששה, סגרה פערים ואפילו התקדמה קצת מעבר.

[7] הספר הבולט והמומלץ ביותר הוא כנראה Lean Software Development שיצא ב 2003 אך עדיין מאוד רלוונטי.

RESTful Services – כיצד מיישמים בפועל? (2)

תזכורת: REST הוא סגנון ארכיטקטוני, המתואר כסט אילוצים שעל המערכת לציית להם. הוא מקדם שימוש נכון ומדוייק בפרוטוקול HTTP וה Web Standards. הוא "חי בהרמוניה עם ה Web" ולא רק "משתמש ב Web כאמצעי תעבורה". ארכיטקטורה ירוקה : )

קצת להכניס אתכם לסלנג של שועלי ה REST המשופשפים (לא הייתי מגדיר את עצמי ככזה):
  • ראשי התיבות REST מייצגים Representational state transfer
  • POX הוא Plain Old XML, על משקל POJO. על מנת לציין ש REST הוא XML פשוט על הנשלח על גבי [HTTP[1
  • ל REST אפשר לקרוא גם (WOA (Web Oriented Architecture – על מנת לתאר את הקשר ל SOA או (ROA  (Resource Oriented Architecture – על מנת לתאר את הקשר ל Resource-Based Distributed Systems.
  • WS-* מוקצה לחלוטין. עדיף למלמל "השם ירחם" כל פעם שמזכירים אותם ולהזכיר מיד שהם מפרים עקרונות רבים של HTTP ו ה Web (כמו למשל – ביצוע queries לקריאה בלבד ב POST).
  • שימוש רק ב URI ולא ב URL. יש הבדל קטן (URI הוא ללא ה filename), אבל מי שחי REST לרוב מקפיד לדייק.
זהו, עכשיו לא נביך את עצמנו בקרב המומחים, ואנו מוכנים לצלול לפרטים.
The REST Uniform Interface
REST מציג את החוקים הבאים:
שימוש ב URI כמתאר של resources
דוגמאות ל resources הם: instance של הזמנה, לקוח או פוסט בבלוג – המקביל ל instance של class ב OO.
כמה כללים צריכים להשמר:
  • ה URL (אני אשתמש ב URI ו URL לסרוגין. סליחה) צריך לספק שקיפות על מבנה ה Resources, כלומר:
  • כל "/" מתאר בהכרח רמה היררכית של מבנה המשאבים.
  • יש להשתמש במקף ("-") ולא בקו תחתון ("_") להפרדת מילים. כדרג אגב ע"פ התקן (RFC 3986) החלק הרלטיבי של ה URL מוגדר כ case sensitive.
  • וכו'
מידול Resource-Based
חלק זה הוא בעל ההשפעה הגדולה ביותר על ארכיטקטורת המערכת, והוא לעיתים הסיבה מדוע מימוש REST אינו ישים במערכת קיימת ללא Refactoring מקיף.
כמו שציינתי בפוסט הקודם, בעזרת ה URI אני ניגש ל Resource ישירות ומבצע עליו פעולה. ה Resource אינו מגדיר מתודות (כמו service), אלא אני יכול לבצע עליו רק את פעולות ה HTTP הסטדרטיות:
  • GET = קריאת ה resource. מקביל לקריאות פונקצניונליות כגון getOrderDetails אולי getOwner או findBid.
  • PUT = במקור מתואר: פעולת rebind של resource. הוספת resource חדש או עדכון resource קיים.
  • POST = שליחת מידע ("post") ל resource קיים. מקביל לקריאות פונקציונליות כגון executeOrder או updateOrder. שינוי ה state הקיים.
  • DELETE = מחיקת ה resource. ביצוע פעולת Delete על משאב Subscription הוא מה שהיינו מתארים ב WS כ unsubscribe().
עודכן בעקבות תיקון של אלון.למי שמכיר HTTP, מוגדרות בו יותר מ 4 הפעולות הבסיסיות הנ"ל. לדוגמא: HEAD, TRACE, OPTIONS וכו'. הגדרת ההתנהגות שלהן היא קצת פחות ברורה ופתוחה לפרשנות של מפתח מערכת ה REST.

כלל חשוב נוסף הוא שאין חובה לתמוך בכל 4 הפעולות הבסיסיות על כל משאב. ייתכן משאב שעליו ניתן לבצע רק GET ומשאב אחר שעליו אפשר לבצע רק POST. מצד שני הגדרת ה URI מחייבת שכל צומת מתאר משאב שניתן לגשת אליו. לדוגמא, אם השתמשתי ב:

אזי גם:
צריכים להיות משאבים נגישים.
ובכן, על פניו היצמדות למודל זה נראית לא מעט טרחה! מה היתרונות שאני מקבל מהם:
  • Cache: ה Scale של האינטרנט מבוסס לחלוטין על קיומם של Caches. ה Cache יכול להיות באפליקציה, שרת ה Web (למשל IIS או Apache), רכיבי הרשת או רשת ה CDN (כמו Akamai שסיפרתי עליה כאן). הכלל מאוד פשוט: קריאות GET (וגם HEAD או OPTIONS) הן cached וקריאות POST, PUT וכו' מוסיפות dirty flag על ה cache של אותו resource. אם כתבתם אפליקציות רשת רבות ואינכם זוכרים שכתבתם קוד כזה – זה מובן. המימוש נעשה ע"י שרת האינטרנט וברמות שונות של ה network devices השונים. כולם מתואמים ומצייתים לאותם חוקים. תארו לכם איזה שיפור אתם מקבלים כאשר ה router דרכו עובר משתמש באוסטרליה מספק לו את התשובה לאפליקציה שלכם מתוך cache אוסטרלי איי שם במקום להעמיס על המערכת שלכם. כל זאת, מבלי שאתם כותבים שורת קוד בודדת.
    אפליקציות רבות נוהגות להשתמש ב POST תמיד (משיקולי אורך URL אפשרי, או שקר כלשהו לגבי אבטחה) וכך מאבדות את הייתרון המשמעותי הזה. מצד שני, אם הגדרתם קריאת GET שמשנה את ה State – אכלתם אותה: ה caches לא יהיו מעודכנים[2]
  • ציוד רשת כגון Proxies, Firewalls, Web Application Firewalls מנועי חיפוש ושירותי רשת שונים מכירים את כללי ה WEB / HTTP ופועלים לפיהם. אנו נהנה מאבטחה טובה יותר, פחות בעיות לגשת לשירותים שלנו, diagnostics משופרים, ביצועים וכו'. השיפור שיושג משימוש ב CDN למשל יהיה משמעותי יותר.
  • היכולת להשתמש ב hyperlinks כשפת referencing. זה נשמע ייתרון קטן, אבל אני יכול להחזיר בתשובה לקריאה link למשאב אחר, אותו לינק הוא יציב – ניתן לשמור אותו ולהשתמש אח"כ. הוא תמיד מעודכן. זהו כלי מאוד שימושי. דוגמאות: פעולת GET על הזמנה נותנת לי links ל100 פריטים. אני יכול לסקור ולקרוא רק את הפריטים שמעניינים אותי ומתי שמתאים לי. פעולת POST שמייצרת דו"ח (או שאילתא – ברמת ה data זה בערך אותו הדבר) מחזירה לי URL שאפשר לגשת אליו כל פעם שאני רוצה לקבל את הדוח.
  • נגישות / תפוצה רחבה: כל פלטפורמה, וכל שפת תכנות כמעט יכולה לגשת למערכת שלי בקלות ללא שימוש בספריות מיוחדות (מה שלא כ"כ נכון ל WS-*). ניתן לגשת בקלות מ JavaScript או Flash. ניתן אפילו להפעיל ידנית מה Browser (למי שקצת יותר טכני).
  • פשטות: אחרי שנכנסים לראש REST הוא לא קשה במיוחד. קל לתחזק ולהרחיב את המערכת.
שימוש ב Hypermedia לניהול שינויי state
טוב, זהו נושא קצת יותר מורכב וקצת שנוי במחלוקת. אין מחלוקת שהוא חלק הגדרת ה REST, אבל פעמים רבות בוחרים לדלג עליו ולא להשתמש בו מכיוון שהוא מורכב יותר למימוש.
עקרון זה אומר שאחרי שביצעתי פעולות (לדוגמא קריאת GET של הזמנה), הפעולות האחרות הרלוונטיות האפשריות יהיו חלק מתשובת ה GET. למשל, הנה תשובה אפשרית לקריאת ההזמנה:

23
<link rel='edit'
ref='http://example.com/order-edit/ACDB' />
אני מקבל תיאור מפורש של סט הפעולות בעזרתן אני יכול להמשיך: edit עם לינק מתאים, ואת הפרטים של המוצר והלקוח.

היתרונות הם:
  • על הלקוח להחזיק / לעקוב אחר URL יחיד (Entry Point) למערכת שלי. מכאן והלאה הוא יובל בעקבות פעולותיו.
  • קוד הלקוח יכול לדעת באופן דינמי מהן הפעולות האפשריות ולאפשר אותן. השרת מצידו יכול להרחיב ולצמצם את סט הפעולות, עם הזמן, כרצונו[3].
  • אינני צריך לבצע עוד rountrip בנוסח קריאת GET ל OrderDetails על מנת לקבל קישורים למוצר או הלקוח.
כפי שאמרתי, זה נושא מורכב (מורכב = סיבה טובה להזהר) – אך הרעיון מקורי ומעניין.
Self descriptive message
יש גם עניין של הודעות שמתארות את עצמן, כלומר קריאות ללא ידע מוקדם. לדעתי זה עוזר בעיקר ל visibility ו debug – עקרון שהייתי מגדיר כנכון אוניברסלית ולא רק ל REST.
טעויות נפוצות של מימושי REST
  • שימוש ב POST לביצוע פעולות read (היה צריך להיות GET) או כל פעולה שאינה "create new". העניין הוזכר כבר למעלה. תתי בעיות:
    • התעלמות מ Caches (הוזכר למעלה)
    • נסיון להעביר XML שכולל מידע / פעולות מעורבות או שלא קיימות בסט המצומצם. לדוגמא פרמטר POST בשם operation ואז חזרה לעולם ה Services הוא טעות נפוצה מאוד של מתחילים.
  • בניית URI בעזרת Query Parameters (רמז: Query param אמור לשמש ל… Query)
  • שימוש לא נכון או שיכפול יכולות שקיימות כבר ב HTTP. דברים כמו:
    • Status / Error Code. תזכורת: פרוטוקול HTTP מותיר להוסיף לשגיאה טקסט חופשי (= גוף ההודעה).
    • Cookies
    • Headers
    • MIME Types
  • נסיון לשמור Server Side State על כל client. בעיה אוניברסלית ל Web.
  • המנעות מהוספת לינקים לתשובה: אמנם שימוש בלינקים (hypermedia) לניהול כל ה state הוא עקרון שנוי במחלוקת, אך המנעות מלינקים בכלל – נשמעת טעות. לא טוב להסתמך על קוד ב client שמתאר את מבנה ה API לשוא וגם חבל ליצור קריאות מיותרות.
  • נסיון לבצע Implicit Transactions.
    במוקדם או במאוחר תזדקקו ל Transactions. הדרך המומלצת לטעמי הוא לייצר resource שמתאר את ה transaction. כל דרך אחרת לעשות זאת בצורה לא מפורשת שנתקלתי בה – נגמרה בכאב.
מקווה שנהנתם.
 
[1] על מנת לדייק זה לא חייב להיות XML, ועקרונות ה REST יכולים להיות מיושמים גם ללא HTTP – פשוט אפשר להשתמש בהרמוניה בפרוטוקול אחר ובאותה הרוח ש REST "מתלבש" על HTTP.
[2] יצא לי להיתקל במערכת "REST" דיי גדולה ומורכבת שלא הקפידה על הכלל והיו לה בעיות עם Caches לא מעודכנים. המפתחים שלה התחכמו והוסיפו HEADER לכל קריאות ה GET שציין שאסור לשמור את הקריאה ב Cache. בעולם ה Security קוראים לזה (SDoS (Self Denial of Service
[3] ניתן להסתכל על זה כ interface דינאמי. ב Web Services הייתי קורא WSDL וה IDE היה יוצר לי stub – שזה מאוד נחמד. מצד שני, לכאורה, לא הייתי יכול להגיב לשינויי Interface ללא שינויי קוד.
אני אומר לכאורה מכיוון שיש כמה דרכים לבצע זאת בכל זאת (בצורה קצת יותר מסורבלת)

לינקים רלוונטים:
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api