תגית: Enterprise Architect

על Domain Driven Design

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

הקדמה
הקשר בין גודל התוכנה לסיבוכיות שבה הוא קשר ברור וידוע.

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

בסופו של דבר (בשאיפה), התוכנה פוגשת לקוח, הלקוח מרים גבה, הדרישות משתנות, והשינויים במערכת גדולה ומורכבת – הם קשים.

כיצד ניתן לשנות זאת?

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

עד כאן, לא חידשנו כלום.
כיצד מקבלים דרישות איכותיות יותר? "מתמקדים בלקוח"? "שמים את הלקוח במרכז"? "חושבים טוב-טוב"?
ואיך בכלל יוצרים מערכת פשוטה יותר? "חושבים פשוט"? "עושים KISS"? "עובדים לאט ובזהירות"?

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

ובכן, היכונו! אוונס וה DDD (כלומר [Domain Driven Design [1) הולכים ללמד אתכם כיצד לקבל דרישות איכותיות יותר וכיצד לבנות מערכת שתהיה גמישה יותר לקבלת דרישות עתידיות. הדרך להתמקצעות היא לא פשוטה, אך כל מי שיש לו גישה לדרישות של לקוחות וקצת חשיבה מופשטת יכול די מהר להגיע לתוצאות ראשונות.

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

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

על התהליך הנפוץ לתכנון תוכנה
לא משנה אם אתם עובדים Waterfall או Agile, קרוב לוודאי שהמתכנתים לא אוספים את הדרישות מהלקוח בעצמם. יתרה מכך, גם שמדברים עם הלקוח לא תמיד יהיה זה המומחה העסקי. ייתכן ואתם מדברים עם מנהל התפעול בבנק ("לקוח") שרוצה מערכת לניהול משכנתאות, אבל אתם לא מדברים עם מי שמתעסק עם זה בפועל (Domain Expert). על מנת לפשט לכם את הנושא, מנהל התפעול משתמש במושגים שיותר קלים להבנה. ה PM לוקח צעד אחד הלאה ומשתמש במושגים יותר מקובלים מהעולם-הלא-מקצועי כי "מפתחים יאבדו כיוון אם נציף אותם בכל המידע הזה". זהו הרי תפקידו.
הארכיטקט או המומחה הטכנולוגי מפשט את הדברים קצת יותר להתאים לתשתית הקיימת , זה תפקידו, והופ – המפתחים מבינים בקלות על מה מדובר וניגשים מייד לעבודה.

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

מקור: softwarearchiblog

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

מקור: softwarearchiblog

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

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

הפתרון "הרשמי"
אז מה עושים? אחד העקרונות המרכזיים של DDD הוא שפה-רוחבית (ubiquitous language). על מישהו, ה business analyst, לחפור ללמוד ולהגדיר עם ה DEs שפה אחידה ומוסכמת על פיה כולם יעבדו, שפה שבעצם תגזר מתוך Conceptual Model ברור ומלוטש (במידת האפשר).

מקור: softwarearchiblog

הנה הנקודה החשובה: כאשר אנו אוספים דרישות מלקוח אנו נוטים הרבה פעמים "להתמקד בחלקים שרלוונטיים לתוכנה", להתמקד בדרישות בטווח הקרוב ולהתמקד ב UI – כלי שעוזר מאוד להמחשה של רעיונות.

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

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

אז מה יותר יציב מרשימת use-cases ומסכי UI? היכן אנו יכולים להשקיע בלמידה של המקור ממנו באות הדרישות? ידע יציב שאינו נוטה להשתנות בקלות?
ובכן – זהו ה Domain, תחום העיסוק, הביזנס, הידע שמי שעוסק בתחום חייב לדעת על מנת לעסוק בו. הביזנס אינו משתנה במהירות.

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

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

המודל לא צריך להיות מושלם או מפורט במיוחד – הוא צריך להיות נכון לשם המטרה ומועיל.
דרך מקובלת ונוחה לתאר מודל היא תרשימי Class Diagram של UML. כמובן שזו רק דרך אחת, אפשר בכל תרשים חופשי, טקסט וכו'.

מודל קונספטואלי המתאר פעולה בנקאית. האם המפתחים, מנהלי המוצר והלקוחות שותפים לאותה תמונה (או הבנה)? מקור: martinfowler.com

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

אילוסטרציה: domain experts.
כמעט ושמתי תמונה אומנותית של מנהל חשבונות זקן משנות ה-50, אך כנראה שבישראל בשנות ה-10, תתקלו יותר ב domain experts שדומים לאלו, שני מנהלים ב-888.
מקור: כתבה ב"אנשים ומחשבים".

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

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

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

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

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

זכרו: "(You can run, but you cannot hide (a bad conceptual model". אם "תשקרו" את המערכת ותעבדו עם מודל לא מדוייק, זה יחזור אליכם בדמות תחזוקה קשה ודרישות עתידיות הקשות ליישום.
לדוגמא: תיאור של מחשב עם 2 כתובות IP כשני מחשבים עם אותו השם, כל אחד עם כתובת IP אחת – אולי יקצר את הפיתוח בשלב הראשון, אך יחזור אליכם כמוברנג כחלק מדרישות עתידיות. ניסיתם "לשקר" במודל.

סיכום
למי שהתנסה בהצלחה במידול בכלל או DDD בפרט, מידול נראה חלק הכרחי בבנייה של כל מערכת. תורת המידול אינה נפוצה ואינה קלה – אך היא מביאה תוצאות ממשיות. המקור הטוב ביותר שאני נתקלתי בו עד היום הוא הספר Analysis Patterns של Martin Fowler, ספר קצת לא-מסודר אך בעל תובנות עמוקות.

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

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

[1] בעברית: תכנון מונחה-תחום, תרגום לא כל-כך מוצלח לדעתי – אך לא מצאתי טוב יותר.

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

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

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 PUT ל URL:

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

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

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

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

אם ביצעתי קריאת 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 ואפשר גם להשתמש בפורמט אחר כלשהו.