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, כלומר:
• http://painting.org/france/paris/louvre/leonardo-da-vinci/mona-lisa   הוא URI טוב
• http://painting.org/painting/UDF-444LR123   הוא תיאור לא מוצלח, כי אינו חושף שום פרט.
• כל "/" מתאר בהכרח רמה היררכית של מבנה המשאבים.
• יש להשתמש במקף ("-") ולא בקו תחתון ("_") להפרדת מילים. כדרג אגב ע"פ התקן (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 מחייבת שכל צומת מתאר משאב שניתן לגשת אליו. לדוגמא, אם השתמשתי ב:

http://example.com/orders/2009/10/776654

אזי גם:

http://example.com/orders/2009/10

http://example.com/orders/2009

http://example.com/orders

http://example.com

צריכים להיות משאבים נגישים.

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

• 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. למשל, הנה תשובה אפשרית לקריאת ההזמנה:

<order self='http://example.com/orders/3321'>

<amount>23</amount>

<product ref='http://example.com/products/4554' />

<customer ref='http://example.com/customers/1234' />

<link rel='edit'

ref='http://example.com/order-edit/ACDB' />

</order>

אני מקבל תיאור מפורש של סט הפעולות בעזרתן אני יכול להמשיך: 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 הוא טעות נפוצה מאוד של מתחילים.
• http://example.com/myapi?operation=findOrder&orderid=41245
• בניית URI בעזרת Query Parameters (רמז: Query param אמור לשמש ל... Query)
• http://example.com/customer?name=AMEX&objType=order&objectid=1112234
• שימוש לא נכון או שיכפול יכולות שקיימות כבר ב 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

RESTful Services - שירותי הרשת של המחר, החל מאתמול (1)

פוסט ראשון מתוך שניים. את ההמשך אפשר למצוא כאן.

REST הוא עוד באזז של השנים האחרונות: חברות אינטרנט רבות אימצו אותו, ספרים רבים נכתבו, גוגל יצרה וריאציה משלה בשם GDATA ומנסה להפוך אותו לסטנדרט. מייקרוסופט מצידה הגדירה אלטרנטיבה בשם [ODATA[1.

על מה כל המהומה?? - אנסה לענות במאמר זה.

מהו בעצם REST?
טוב, קחו נשימה עמוקה: REST הוא סגנון ארכיטקטוני (Architectural Style) ממש כמו Pipes & Filters, Layered Architecture או (SOA (Service Oriented Architecture.
סגנון ארכיטקטוני הוא לא ארכיטקטורה, אבל אם אתם יודעים מהו הסגנון הארכיטקטוני של מערכת (וגם הסגנון הזה נשמר לאורך הפיתוח) - תוכלו לדעת דיי הרבה על איך המערכת נראית ומה העקרונות שעומדים בבסיסה. ממש כמו שאם אתם הולכים לראות מבנה שאתם יודעים שהוא בסגנון גותי, סיני או ערבי - תדעו פחות או יותר למה לצפות.

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

REST הוא סט חוקים שמערכת יכולה לבחור ולאמץ. ב High Level הוא אומר שני דברים עיקריים:

• תיאור ממשק המערכת כעולם של Entities (כ"א instance של אובייקט) כבעל מזהה (URL) ייחודי, דרכו ניתן לבצע פעולות. ממערכות כאלו נקראות Resource-Based Distributed System - שכל entity הוא כאילו משאב מסמך עצמאי עליו עושים פעולות[2].
• הצמדות מדויקת לפרוטוקול HTTP - פרוטוקול שיש בו הרבה חוכמה שאנו נוטים לפספס.

ה API שנחשף החוצה, הוא התוצר - לא העיקר.


איך אני יודע אם אני משתמש ב REST

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

על מנת להשתמש ב REST API (נקרא גם RESTful Service) לא צריך לדעת כמעט שום דבר: פשוט פותחים connection של HTTP, שולחים פרמטרים ע"פ התיעוד של ה API ומקבלים תשובה בפורמט שתואר.
מצד אחד קצת חבל שכמעט כל מי שמשתמש ב REST לא מודע לעקרונותיו היפים, אבל מצד שני: היי - זה דבר נהדר! הכמסה (Encapsulation) במיטבה! אל תסבכו את הצרכן שלכם בידע מיותר.

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

אם אתם כותבים מערכת REST, יש הרבה מה לדעת - המשיכו לקרוא.

קצת היסטוריה

תחום האינטגרציה של מערכות ארגוניות (EAI - Enterprise Application Integration) הוא תחום מסובך ויקר במיוחד. רכשת מערכת כספים מספק א' ומערכת ניהול קשרי לקוחות מספק ב' - על מנת לנצל את היתרון שהמערכות ממוחשבות וניתן להצליב בניהן נתונים, אתם צריכים לגרום למערכות לדבר אחת עם השנייה. בגלל שהמערכות מדברות בשפה (Conceptual Model) שונה ובגלל שהארכיטקטורות שלהן שונות - המאמץ הוא אדיר. כשאנחנו נזכרים בסיפורים בהם משרדי ממשלה לא מצליחים להצליב נתונים (ביטוח לאומי ומס הכנסה, או ארגוני ביון אמריקאים לפני שנת 2001) אנו נוטים לחשוב שזהו מצב של חלם, אבל בפועל עלות האינטגרציה היא אדירה ולעתים קרובות עולה על מחיר המערכות עצמן[3].

כך נראה פרוייקט EAI של ארגון בגודל בינוני

בתחילת שנות האלפיים חברו כמה חברות בראשן BEA, Microsoft, IBM ו SAP ליצור סטנדרט בתעשייה שיקל על פעולות האינטגרציה של מערכות. תקן זה ידוע כ "Web Services" הכולל Stack של פרוטוקולים שהעיקריים שבהם הם: SOAP, WSDL, UDDI ו XML (שהיה כבר קיים אך אומץ ע"י הסטנדרט). תוך כדי התפתחה מאוד ההתעסקות ב (Service Oriented Architecture (SOA. העיקרון אינו חדש: זה תיאור של מערכת מבוססת services ו מבני נתונים המחזיקים את המידע העובר בין ה services, ממש כמו שתכנתנו פעם בפאסקל או C. גם היום חלק גדול ממערכות ה .NET וה Java בנויות כך, לעתים מתוך החלטה, לעתים "כי פשוט יצא ככה". החידוש ב SOA היה הידע שנצבר והתפתח עבור אותה פרדיגמה במערכת מבוזרת.

יוצרי ה Web Services היו זקוקים לשם מפוצץ ("SOA") וצבא של יועצים-מומחים בכדי לשכנע את השוק לאמץ את גישתם. על פני השטח זה נראה כמו וויתור על פרדיגמת ה Object-Oriented (אותה, אותם יועצים ממש, מכרו כמה שנים לפני כן כ "חובה לכל ארגון") וחזרה לסגנון התכנות הפרוצדורלי (ברמת המערכת) שהיה שם קודם לכן. הם ניסו לשכנע שזו לא התדרדרות אחורה - אלא התקדמות קדימה. האמת - הם צדקו [4].

עם השנים (כמה שנים בודדות, לא יותר) תקן ה Web Services הסתבך לעשרות תקני משנה, הידועים כ WS-* (כוכבית = wildcard כמו WS-RPC, WS-Security וכו') שניסו לפתור עוד ועוד היבטים של אינטגרציה בין מערכות תוך כדי שהם נהיים מורכבים יותר ויותר לשימוש. קשה היה לאדם בודד להכיר את כל התקנים ובטח לא להתמצא בהם. בעיה נוספת הייתה performance: בגלל שהתקן מאוד כללי (בנוי לקשר בין מערכות מספקים שונים, הכתובים בשפות תכנות שונות ובין גרסאות שונות) ובגלל שהוא מבוסס על קבצי XML גדולים, פורמט המרבה במילים (verbose) - תקשורת מבוססת Web Services הייתה צוואר בקבוק גם של הרשת, אבל בעיקר של צריכת זיכרון (בשל ה parsing של קבצי xml ענקיים). עניין זה היה מטרד למערכות ארגוניות, ומכת מוות למערכות אינטרנט High Scale.

חברות האינטרנט הקטנות והיעילות יצאו למלחמה רבתי: "REST נגד SOA" - ראה [5]
הם הציגו את REST כאלטרנטיבה פשוטה, מהירה ונוחה למתכנת לייצר Web Services. הם גם נתנו לשירותים אלו שם מפוצץ משלהם: "RESTful Services". אני זוכר שהייתי בכנס QCON בלונדון בשנת 2008, ורבים מה sessions היו על נושאים ב REST או ב SOA (למשל, אני זוכר session שנקרא "REST eye for a SOA guy"). כל פעם באו אנשי המחנה השני, קראו קריאות ביניים והפריעו למרצה ב Session. מהר מאוד למדתי להדיר רגלי מכל Session באחד משני הנושאים הללו.

מכיוון שפוסט זה עוסק ב REST ולא ב Web Services אתם יכולים להסיק, בצדק, ש REST ניצחה במלחמה. השימוש ב Web Services הצטמצם משמעותית ונותר בעיקר בנישה של מערכות שונות של ספקים שונים. אפילו החברות אשר יזמו וקידמו ללא ליאות את הסטנדרטים (עבדתי ב SAP - אני יודע) הוציאו הנחיות פנימיות לצמצם שימוש ב Web Services למינימום ההכרחי.

הפשטות ניצחה את ה Coverage.


הבנת ההבדל בין Web Service ל REST
גם REST וגם Web Service הם אמצעי תקשורת בין מערכות שונות המבוססים על XML העובר על [HTTP[6 - היכן ההבדל הגדול?

עדכון: תודה לארנון רותם-גל-עוז שהאיר את עיני לכך ש REST אינו coupled ל HTTP ואותם עקרונות יכולים להיות  מיושמים על גבי פרוטוקולים אחרים (אישית, לא נתקלתי בכזה מימוש).

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

getOrderDetails()
updateOrder()
Subscribe()
cancelSubscription()
findMatchingOrder()
listOrderProviders()

פונקציות כמו ()Subscribe או ()ListOrderProviders אינן קשורות בדיוק להזמנה, הן בתחום. את ה interface השירות חושף בעזרת XML שנקרא WSDL כך שמי שצורך אותו יוכל בקלות לבצע import ל IDE אשר ייצר proxy לוקלי לקריאה לשירות כאילו מדובר באובייקט מקומי. Visual Studio, כבר מימיו הראשונים של .NET עושה זאת בצורה נהדרת.
כאשר מתבצעת קריאה ל Web Service בפועל, נוצר XML עם הפרמטרים הרלוונטיים. XML זה נעטף ב XML נוסף הנקרא Envelope של פרוטוקול ה SOAP (ה envelope מוסיף נתונים העוזרים ל cross platform interoperability אך ייתכן ויהיה גדול משמעותית מההודעה עצמה). אם ה Web Service תומך או דורש שימוש בכל מיני שירותים נלווים (WS-* למיניהם) יש להתייחס אליהם וייתכן שהם יוסיפו תוכן או ישנו את צורת ההתקשרות.


RESTful Web Services
REST, כפי שאמרנו, מתאר Resource-Based Distributed System. הגישה היא ל resource (או האובייקט) עצמו ולא לשירות. לרוב מדובר על המון משאבים (הממופים כ"א ב URL), אשר כל כ"א סט מצומצם וקבוע של פעולות המוגדרות  בפרוטוקול HTTP.

על מנת לקרוא את פרטי ההזמנה אבצע קריאת HTTP GET ל URL:

http://example.com/orders/2009/10/776654

על מנת לעדכן את ההזמנה אבצע קריאת HTTP PUT ל URL:

http://example.com/orders/2009/10/776654

את נערכים שאני רוצה לעדכן אשלח כ Post Parameter בפורמט XML או JSON הכולל את הערכים הרלוונטיים.
על מנת לבצע שאילתה על כל ההזמנות בשנת 2009 של לקוח AMEX אני אבצע קריאת HTTP GET ל URL:

http://example.com/orders?year=2009&customer=AMEX

האובייקט הוא orders, אני מבצע קריאה ושולח פרמטרים ל Query בשם year ו customer.

כמובן שאני לא יכול לשלוח מה שבא לי - רק מה שהוגדר ע"י ה שAPI ומתועד ב API Documentation.

ועל מנת לבצע שאילתה של listOrderProviders נגשים ל"אובייקט" ה OrderProviders, כמובן:

http://example.com/orderproviders?orderid=776654

אם ביצעתי קריאת GET להזמנה שאינה קיימת אקבל כנראה שגיאת HTTP 404, המוגדר בפרוטוקול HTTP כ "Not Found". אם ביצעתי קריאת POST (הוספת ערך חדש) אצפה באופן טבעי לתשובת HTTP 201 המוגדרת בפרוטוקול HTTP כ "Created". עבור ביצוע אסינכרוני אצפה ל 202 "Accepted" וכו'

כפי שאתם מבינים על מנת לעבוד ב REST אני צריך להשתמש נכון בפרוטוקול HTTP, אבל מי שצריך להבין את הפרוטוקול הוא מי שמגדיר את ה REST API - המשתמש ב API פשוט עוקב אחרי התיעוד ושולח / מצפה למה שנאמר בתיעוד.

קשה לי לתאר במילים כמה פרוטוקול REST פשוט יחסית לפרוטוקול WS-*. אחד הטיעונים נגדו היה שזהו Hack שלא יחזיק מים במערכות גדולות ומורכבות (טעות). פעם בקורס על Web Services ב SAP ישבנו שעתיים רק לסקור את סוגי השירותים השונים של WS-* וזה היה על קצה המזלג.

חשוב להבין ש RESTful API (כלומר, מימוש נכון של REST) משפיע רבות על המבנה הפנימי של המערכת. עצם העובדה שכל instance של אובייקט הוא נגיש החוצה וניתן לבצע עליו סט סגור של פעולות הוא עיקרון שיצליח אם מערכת בנויה בצורה X אך יכול להיכשל אם מערכת בנויה בצורה Y.

המשמעות של הוספת RESTful API למערכת קיימת שאינה בנויה בצורה REST-friendly היא לרוב להוסיף שכבת Adapting עשירה או לא להצליח להנות בפועל מיתרונות ה REST. ייתכן וכל מה שאתם מחפשים הוא לחשוף API בצורה שהמשתמשים רגילים (REST like) ולכן יתרונות ה REST האחרים הם לא חשובים. לגיטימי.

הקשר בין REST לפרוטוקול ה HTTP וארכיטקטורה של Resource-Based Distributed System אינו מקרי.
בפוסט ההמשך ארחיב על נושאים אלו יותר לעומק.



[1] Open Data. מכיוון שהצלחה נראתה כיעד אסטרטגי מהותי - היא שיחקה עם גוגל במגרש שלה, פתחה את התקן כ Open Source ושחררה ספריות התומכות ב .NET כמובן, אך גם PHP, Java ו JavaScript.

[2] היסטורית מקובל לחלק מערכות מבוזרות ל 4 סוגים:

• Object-Based Systems: מערכות שמאפשרות לגשת מרחוק ולהפעיל אובייקטים עשירים בפרדיגמת Object-Oriented. דוגמאות הן Corba, DCOM או EJB כאשר עובדים עם Remote Interface.
• Distributed Database / Storage System - כאן נכנסים כל מערכות ה NoSQL שתיארתי בפוסט על Big Data או מערכות קבצים מבוזרות נוסח Gopher, WebDAV או HDFS ו GFS המודרניים.
• Distributed Coordination-Based Systems: מערכות תיאום מבוזר כמו Rendezvous או Jini של ג'אווה שנכשל ונולד מחדש כ Apache River. דוגמה מודרנית יכולה להיות פרוטוקול Gossip או מערכות peer 2 peer.
• ומה שחשוב לפוסט זה: מערכות Resource-Based (לעתים נקראים גם "Document-Based") מבוזרות אשר ניגשים ל Resources ("מסמכים") אחד אחד לצורך פעולות קריאה, כתיבה וכו'. דוגמה אחת: האינטרנט (מסמכי HTML). דוגמה שנייה: מערכות REST.

[3] זה הסיפור העיקרי עליו מבוססת מכירת מערכות ERP של חברות כמו SAP או Oracle: "אין לנו את ה CRM הטוב ביותר או ה SCM הטוב ביותר - אבל אתה קונה את האינטגרציה built-in".

[4] שנים רבות Object Oriented Programming נחשב לשם נרדף לקדמה ומקצועיות, אבל בפועל הוא לא היה Silver Bullet - כלומר לא הביא לשיפור חד משמעי בעולם התוכנה. לתכנות פרוצדורלי יש הרבה יתרונות ונראה שיש לו עוד מקום של כבוד בעולם התוכנה בשנים הבאות. כמובן שעדיף להבין את היתרונות והחסרונות המעשיים של כל גישה ולבחור בחירה מודעת. סימן אחד לכוחה של הפרדיגמה הפרוצדורלית היא שהרבה מאוד פרויקטים שניסו לייצר מודל OO כשלו וגמרו עם מודל פרוצדורלי. כלומר: OO הוא קשה למימוש, פרוצדורלי הוא קל. חישבו על כך - זהו יתרון משמעותי.
תכנון מונחה עצמים Object Oriented Design, לעומת זאת, הוכיח את עצמו יפה והוא מוצלח משמעותית מכל מיני פרדיגמות עתיקות כמו DFD (השם ירחם!) או ERD שנהגו להשתמש בהם בשנות השמונים (או בסוף שנות התשעים באקדמיה - אותה תקופה בה למדתי את התואר הראשון). יהיה זכרם ברוך.

[5] SOA היא ארכיטקטורה טובה, הם בעצם התכוונו לצאת נגד Web Services. עקרונית REST הוא סוג של SOA.

[6] REST לא מגדיר מה פורמט ההודעה, XML נפוץ מאוד וכך גם JSON ואפשר גם להשתמש בפורמט אחר כלשהו.

מה הביג-דיל ב Big Data? (או NoSQL)

הקדמה
אם הייתם עסוקים במיוחד בשנה-שנתיים האחרונות, ייתכן והרמתם את הראש ונוכחתם שהמושג Big Data מוזכר לעתים קרובות, מבלי שאתם מבינים בדיוק על מה מדובר.

פעם (לפני כעשור), מערכות ה High Scale היו בעיקר מערכות ה Enterprise המיועדות לארגונים גדולים. לחברת Siemens יש 120,000 משתמשים (users)? וואהו - אתגר ארכיטקטוני מרשים. מערכת המסחר של וול סטריט מבצעת מאות פעולות (transactions) בשנייה אחת? - בלתי נתפס!
חברות ענק כמו SAP, Oracle ו IBM הן אלו שבד"כ התמודדו עם אותם scales , בעיקר בזכות העובדה שאותם לקוחות-ענק קנו מערכות מורכבות שיצרנים אלו סיפקו. יצרן קטן - scale קטן, יצרן גדול - scale גדול.

מאז שנת 2000 האינטרנט פרץ למיינסטרים. מוצרים כמו MySpace ו SecondLife ואח"כ Facebook ו Youtube עקפו בסיבוב את חברות הענק וטיפלו במיליוני משתמשים, petabytes של שטחי אחסון ואלפי (tps (transactions per second. בהדרגה, עוד ועוד חברות קטנות נאלצו להתמודד עם scales אדירים. הכלים להתמודד עם כמויות גדולות של נתונים (כמו פתרונות של Teradata וOracle) גם היו יקרים מדי עבור אותן חברות קטנות, וגם לעתים לא עמדו בקיבולת המבוקשת - וכך אותם ארגונים החלו לייצר חלופות זולות ויעילות להתמודדות עם scale ענק. לא סתם Facebook, Amazon או Twitter שרדו מבין חברות דומות (שלעולם לא שמענו או נשמע עליהן). מלבד הרעיון המגניב, היה צריך להתמודד עם אתגרים טכנולוגיים יוצאי-דופן. רעיון מגניב + ניהול נכון + מצוינות טכנולוגית הוא שילוב נדיר אשר היה דרוש להצלחה.
בסולם ה Scale הוגדר ערך חדש הגבוה מהערך הגבוה הקודם ("High Scale"). מעתה, אמרו "Internet Scale".

הבעיות
הערה:כמו שצוין למעלה, ב Big Data יש עניין מוצהר - טיפול בכמויות אדירות של נתונים, ועניין לא מוצהר, אך לא פחות חשוב - פתרון זול המתאים גם לחברות קטנות. עדיף Open Source, עדיף מאוד Commodity Hardware (שרתים במחיר של, נאמר, עד 10K$ כל אחד)

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

הגדילה בתעבורה של אתר Netflix כמו שדווח על ידם

כאשר יש לכם כמויות גדולות של נתונים, אתם צריכים:

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

למרות ש MySql (או כל בסיס נתונים רלציוני) הוא מוצלח, ישנו גבול של נתונים שהוא יכול לטפל בו. הגדילה הראשונה היא כנראה לקנות שרת יותר חזק (vertical scalability הקרוי גם scale-up). השרת יטפל בפי n כמויות מידע ויעלה לרוב משמעותית יותר מפי-n.
השלב הבא, ברוב בסיסי הנתונים, הוא ליצור cluster של בסיסי נתונים (horizontal scalability הקרוי גם scale-out), בחוות שרתים שלכם או ב Cloud.
איך מטפלים בכפילות מידע? דרך אחת היא ששרת אחד מוגדר לכתיבה בלבד (ומעדכן את השאר) ושאר השרתים רק מבצעים שאילתות קריאה ומשחררים עומס מהכותב. כמו שאתם מבינים זהו בסה"כ קצת אוויר לנשימה.
Partitioning של המידע: לאחסן על כל בסיס נתונים (או cluster כמתואר למעלה) פלח מידע שונה, לדוגמה: פילוח ע"פ מדינות, אות ראשונה בשם המשתמש וכו"
offloading to data warehouse - מדי כמה זמן להעביר את המידע שאליו ניגשים פחות (לרוב מידע ישן) לבסיס נתונים אחר ("מחסן") כדי לגרום לבסיס הנתונים עליו המידע החשוב להיות זמין יותר.

בשיטת ה Partitioning יש שתי בעיות עקרוניות:
א. אם מפצלים נתונים לשרתים שונים, יש להתפשר או על זמינות (availability) או על עקביות הנתונים (consistency) - עקרון הידוע כ CAP Theorem (כלומר - ללא ACID).
ב. שאילתות הכוללות מספר בסיסי נתונים אחד הן מורכבות למימוש ואיטיות במיוחד (במיוחד אם דורשות נעילות). למרות שלספקי בסיסי הנתונים היו שנים רבות ללא תחרות קשה בתחום - הם לא פיתחו את התחום בצורה משמעותית.

Big Data
אותן חברות סטארט-אפ שלא יכלו לשלם על פתרונות יקרים ונזקקו לכלים לטפל בכמויות אדירות של נתונים פיתחו כמה מהפלטפורמות הבאות שרובן הגדול זמין כיום כ Open Source (מסודר ע"פ תחום):

• CPU - לרוב אין צורך בפתרון מיוחד. מקימים Cluster עם שרתים זהים ובעזרת Load Balancer מחלקים לכל אחד מנה מהתעבורה. פתרון שקיים כבר שנים.
• אחסון פיזי: S3 של אמזון, GFS של גוגל או HDFS* של אפאצ'י (היחידי שזמין לקהל הרחב).
• אחסון לוגי: אלו בסיסי הנתונים המפורסמים (הסבר בהמשך) השייכים לאחת מארבע קטגוריות:
• Document Oriented
• Columnar DB
• Graph Database
• Key-Value DB
• יכולת לבצע שאילתות מבוזרות: Hive, Hadoop Map-Reduce, Cascading, MrJob ועוד.

בסיסי נתונים NoSQL

פירוש השם NoSql התחיל כ "לא צריך SQL", אולם עם הזמן התפכחו הדוברים והבינו שאין כאן Silver Bulltet - לרוב המקרים בסיס נתונים רלציוני עדיין מתאים. היום ההסבר השגור לשם הוא: "Not Only SQL". 

הרעיון פשוט למדי: בסיסי הנתונים הרלציונים הם עשירים ומורכבים: הם מאפשרים שאילתות SQL מורכבות (שאילתות מקוננות, סיכומים סטטיסטים ועוד), הבטחת פעולות ACID**, אכיפה של constraints, טריגרים ו Stored Procedures ועוד. מה היה קורה אם היינו מוותרים על רוב היכולות ומתמקדים רק במערכת היכולה לטפל ב Scale מרבי למקרה הספציפי? 

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

Document Oriented DB

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

אם נלך לפי העיקרון האקדמי של בסיס נתונים רלציוני ומנורמל תהיה לנו כנראה טבלת סניפים (נאמר 20) המקושרת לטבלת עסקאות (נאמר מיליון בשנה, עשר שנים = 10 מיליון), המקושרת לטבלת פריטים בעסקה (Line Item), נאמר 20 בממוצע בעסקה.

טבלת הפריטים של כל המערכת תהיה בגודל של 4 מיליארד רשומות. כלל האצבע בבסיסי נתונים הוא שמעל 10 מיליון רשומות בטבלה - בסיס הנתונים מתחיל להגיב לאט. כלומר-  לא מעשי. בנוסף הכנסה מקבילית של הרבה קופאיות לאותן טבלאות (מקושרות) ייצור רצף נעילות שיגביל מאוד את המערכת (עוד קצת על מקביליות ונעילות - בתחתית הפוסט) מצד שני אנחנו יכולים לקחת את ההנחות המקלות:

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

פיתרון קיים (יצא לי פעם להתנסות בו) הוא במקום טבלת הפריטים - לייצר בטבלת העסקאות עמודה מסוג "string" המכילה XML או JSON עם פרטי העסקה. זהו שיפור משמעותי ב scale, מכיוון שיש לנו פחות rows, פחות אינדקסים לתחזק ופחות joins להריץ. מצד שני יש יותר custom code שצריך לכתוב - עבור דברים שהיינו מקבלים קודם בשאילתה. יתרונות אחרים של גישת ה Document Oriented DB הן שניתן לשנות את הסכמה מבלי לבצע Alter table יקר ואם ישנן עמודות דלילות ב DB - לא נבזבז עליהן מקום מיותר (מה שנקרא Semi-structured data).

בסיסי נתונים Document Oriented נותנים פיתרון מובנה לעקרון זה שכולל לרוב API פשוט לשימוש וכלי שאילתות מבוזר נוסח Map-Reduce. דוגמאות הן MongoDB ו CouchDB. במקום להמציא את הגלגל - קחו Open Source.

Columnar DB

קטגוריה זו, הידועה גם כ Vertical DB פותרת בעיקר בעיות של Data Warehousing: איך לבצע שאילתות יעילות על מחסני נתונים. דמיינו טבלת ענק עם 10 עמודות בגודל x בתים (bytes) כל אחת.
לרוב בשליפות ה SQL אנו שולפים עמודות בודדות. אם הרצתי שאילתה על 3 עמודות, בסיס הנתונים עדיין צריך לקרוא מהדיסק לזיכרון את כל עשרת העמודות - כלומר פי 3 מידע ממה שנדרש. הקריאה מהדיסק היא הפעולה היקרה. אם הייתי מאחסן כל עמודה בקובץ נפרד בדיסק, אולי הייתי מוגבל בשאילתות מורכבות מאוד, אולם השאילתות הפשוטות היו דורשות משמעותית פחות עבודה של הדיסק.
במחסני נתונים, לעתים קרובות, רוצים לבצע חישוב ממוצע / התפלגות ערכים / whatever על עמודה בודדת (ומספרית) מתוך טבלה הכוללת הרבה עמודות שחלקן הגדול הוא מחרוזות (התופסות נפח גדול בהרבה). היכולת לטעון מהדיסק עמודה בודדת יכולה להאיץ את ביצוע השאילתה בעשרות מונים.

דוגמאות בולטות הן Vertica או InfoBright. חברת SAP זכתה לתשואות כאשר באופן מפתיע הצטרפה לחגיגה עם HANA - גרסה In-Memory של בסיס נתונים columnar. כולם פתרונות שאינם open source.

Graph DB

בסיסי נתונים רלציונים הם גרועים במיוחד בתיאור גרפים. נניח שהייתם מפתחים אפליקציה כמו LinkedIn והייתם רוצים לדעת מה הקשר בין שני אנשים, מתוך מאגר של 100 מיליון משתמשים.
ישנו כלל מקל האומר שכל שני אנשים מקושרים ע"י שרשרת של 6 הכרויות. מה נעשה? Join משושה של 100 מיליון משתמשים?? קחו טיול חצי שנה לדרום אמריקה לפני שהשאילתה תסתיים***.

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

Key-Value DB

האם הייתם רוצים להשתמש ב HashTable בגודל של מיליארדי רשומות - שגם יאפשר מקביליות גבוהה? כמה נוח. Key-Value DB יספקו זאת, רק אל תבנו על (O(1 בזיכרון. זוהי פרדיגמה פופולרית במיוחד בקרב חברות אינטרנט:

גוגל יצרה את BigTable ושחררה מסמך מפורסם החושף ארכיטקטורה מהפכנית, אמזון יצרה את Dynamo ושחררה מסמך מפורסם אחר - לא פחות מרשים.

פרויקט Hadoop מימש את התכנון של גוגל ויצר את HBase ו LinkedIn מימשו את התכנון של אמזון ויצרו את Voldemort (כן, הנבל מהארי פוטר).

פייסבוק ערבבה רעיונות של גוגל ואמזון ויצרה את Cassandra שזוכה להצלחה רבה. יש גם את Redis שהוא In-Memory Database המבוסס על אותה פרדיגמה.

סיכום

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

עדכון 1: תודה ליקיר שהזכיר את RavenDB, בסיס נתונים Document Oriented עבור פלטפורמת .NET שפותח בארץ ע"י אורן עיני - מפתח ישראלי בולט.

עדכון 2: ripper234 העיר ובצדק (בפרסום ב newsgeek): "מה שהייתי שם בפתיחה למאמר כזה שאסור להתאהב בטכנולוגיות וב-"Big data". פגשתי יותר מדי אנשים שהחלום הרטוב שלהם זה Big Data / NoSql / Technology Buzzwords, אבל שוכחים בדרך את האג'יליות ואת העבודה שבסטארט-אפ עובדים בשביל ליצור value אמיתי, כמה שיותר מהר, ולא מערכת מטורפת שתחזיק 100 מיליון יוזרים 5 שנים קדימה אבל תיקח שנתיים לפתח."

במאמר זה ניסיתי להתמקד בטעות נפוצה אחרת: המחשבה ש Big Data הוא Silver Bullet, שהוספת בסיס נתונים NoSQL תפתור תכנון בסיסי לקוי. ניסיתי להציג את אותם בסיסי נתונים ולהסביר "מה הטריק שלהם", כי לפעמים בצורה מאוד נקודתית ניתן לממש את הטריק הזה לבד ללא מעבר full-fledged לבסיס נתונים שכזה.

* Hadoop Distributed File System השייך לפרויקט העל Hadoop. השם Hadoop הוא שמו של פיל-הצעצוע האהוב של בנו הקטן של מפתח הפרויקט - ומכאן לוגו הפילון.

**  ACID - Atomic, Consistent, Isolated and Durable הרי הן ה transactions.

*** סתם. ה DB יקרוס אחרי כמה עשרות דקות.