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

אז מה אסור להניח?
אל תתייחס למערכות Cloud Computing כאל "העולם החדש". אל תתבלבלו הן בהחלט כן, והן מציבות בפנינו אתגרים משמעותיים כמו עבודה ב - 24X7 והתמודדות עם נפחי ענק, אבל בסופו של דבר אל תשכחו לשמור על אותם עקרונות בסיסיים שהנחו אתכם עד כה בניהול הפיתוח.

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

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

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

איך עושים את זה?

1. Scale Out: הרעיון העומד בבסיס תפיסה זו הוא ששרת חזק פי 4 עולה פי 16. לכן כאשר נרצה לתמוך בפי 4 משתמשים נרצה לעשות זאת באמצעות 4 שרתים זולים ולא באמצעות שרת גדול יותר.
2. Sharding: מידע הוא בד"כ צוואר הבקבוק במערכות תוכנה, וזאת מכיוון שאפיון קלאסי של מערכות מרכז את כלל המידע בנקודה אחת (יש כאלו שקוראים לזה בסיס נתונים או Database). אם זה המצב אצלכם, בחרו במה שהגדולים כבר עשו לפניכם: בצעו Sharding לבסיס הנתונים שלכם, ללא תלות אם מדובר ב - MySQL או SQL Server.
3. In Memory Databases: שימוש בזיכרון מהיר פי 5-10 משימוש בדיסק. לכן אם אתם יכולים לבצע פעולות בזיכרון כמו צבירה של צפיות במודעה ולרדת לדיסק רק פעם בכמה שניות, זאת יכולה להיות אסטרטגיה מצויינת. זהו פתרון מצויין גם במקרה שאתם יכולים להתמודד עם אובדן של מספר שולי של טרנזאקציות. במקרה שאתם לא יכולים להתמודד עם כזה אובדן, שימוש ברפליקציה של הזיכרון בין שרתים שונים יכולה לתת את המענה הרצוי.

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

הגדירו אסטרטגיית יציאה (Exit Strategy)
אתם חייבים לזכור שספק מחשוב הענן שבחרתם (Cloud Operator) הוא ספק ככל ספק אחר. יתכן שהשותף המצויין שלכם כשהייתם מערכת קטנה יהפוך למכשלה כאשר אתם בעצמכם תהפכו לענק. לכן בחרו בזהירות את הפתרונות הטכנולוגיים שבהם אתם משתמשים מתוך מבחר הכלים אותם מציע ספק מחשוב ענן. לדוגמה, אני ממליץ לחשוב פעמיים לפני בחירה בפתרון שמירת מידע קנייני כדוגמת ה - SimpleDB של אמזון. במקרה שאתם בוחרים בכלים מסויימים, הקפידו לייצר ממשק שיעטוף את הכלי וודאו שיש לכם תוכנית יציאה למקרה הצורך.

ומה אם אני מומחה מיקרוסופט?
בוודאי שמעתם כבר שכולם מפתחים ב - Open Source. גוגל עושה שימוש אגרסיבי ב - Python, פייסבוק עושה שימוש ב - PHP וטויטר בכלל דוגלת ב - Ruby.
כמו שכתבתי לפני כן, ההמלצה שלי היא להתחיל עם מה שאתם מכירים. יש כיום ספקי מחשוב ענן רבים שמספקים פתרונות של Windows+.Net. כאשר תגדלו, תוכלו להחליף את אותם מנגנונים שמהווים 20% מהקוד שלכם ומייצרים 80% מעלויות המחשוב שלכם לפתרונות חלופיים כדוגמת Erlang ל - Push ו - LAMP ל - Web ולשמור על עלויות סבירות.

ומה עם איזה טיפ של אלופים?

1. CDN: הוציאו את התוכן הסטטי של האתר (תמונות, עמודי HTML וסרטונים) ו - Streaming Media לספק CDN. המהלך הזה יקטין את תעבורת הרשת, ניצולת השרתים וישפר את חווית המשתמש של האתר שלכם.
2. משתמשים חכמים: הפכו את האפליקציה שלכם לבעלת מודעות לבעיות ברשת ונצלו אותה להתגבר על נפילות. אם השתמשתם ב - Gmail וקיבלתם הודעת Loading... במקום עמוד 404, אתם בודאי יודעים למה אני מתכוון (ואם לא, גגלו על JQuery)
3. גידול אלסטי: אם צריכת המשאבים שלכם לא אחידה לאורך שעות היום ו/או לא צפויה, נצלו את היכולת של להעלות שרתים ולכבות אותם על מנת לשמור על ההוצאות נמוכות ולתת מענה לשיאים בדרישה גם אם הם רגעיים.
4. רפליקציה: אל תשכחו לגבות את הנתונים גם בגיבוי קר וגם בגיבוי חם. אבל אל תשכחו לעשות את זה גם באמצעות חומרה ותוכנה בסיסיים.
5. התכוננו להשבתות ושדרוגים. במערכות ענק תמיד יש תקלות. וגם הבלתי צפוי תמיד יקרה ושרתים יפלו, יכשלו ויהיו תקלות. לכן התכנון שלכם צריך להיות בנוי שגם במקרה של שדרוג תוכנה, לעולם, לא כל האתר ישובת.
6. NoSQL: התחילו עם בסיס נתונים סטנדרטי (SQL בעברית). כאשר תתחילו לספוג עומסים בבסיס הנתונים, זהו מה מהנתונים מתאים לאחסון לצרכי OLTP בתצורה של Key-Value וישמו עבורו פתרון NoSQL.

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

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

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

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

נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!

ממשיכים לפתח,
משה קפלן