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

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

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

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

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

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

1. אנשי המכירות מתחילים לשאול שאלות איך למכור ללקוחות של השוק הראשון את המוצר של השוק השני.
2. כמות הבקשות ליישם תכונות של המוצר הראשון במוצר השני ולהיפך הולכת וגדלה.

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

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

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

1. חברת NetApp היא אחת מחברות האחסון הגדולות ביותר בעולם. החברה מוכרת מוצרים המבוססים על ארונות של  דיסקים קשיחים וידועה מתחילת דרכה בכך שהיא מוכר "ראש חכם" אשר תומך בגדלים שונים של אחסון, ובתכונות שונות וזאת רק ע"י הכנסת רשיונות תוכנה המאפשרים אותם וזאת ללא צורך שינוי החומרה של ה"ראש החכם".
2. חברת Radware, שעל פי מקורות זרים מועמדת למכירה ל - IBM ו - HP לפי שווי של מליארד דולר, מתמחה בהתקני תקשורת בכניסה למרכזי מחשבים. פתרון ה - OnDemand Switch שהחברה הציגה לפני כשנתיים, פועל בצורה דומה, התקן התקשורת נמכר במחיר ראשוני נמוך עבור תמיכה בנפח תקשורת נמוך יחסית. עם הזמן הלקוח יכול להוסיף יכולות נוספות או להגדיל את נפח התקשורת הנתמך וזאת ע"י הכנסת רשיון תוכנה בלבד ללא שינויי חומרה.
3. מערכות SaaS כדוגמת Gmail מבוססות על מתן פתרון ראשוני בחינם ו/או במחיר נמוך, כאשר המגבלות (מספר משתמשים, נפח אחסון וכו') משוחררות תמורת מחיר אטרקטיבי יותר או פחות. דוגמה טובה היא חברת Kampyle אשר מספקת פתרון חינמי לקבלת תגובות ממשתמשים באתר ונותנת פתרון חינמי (שומחבא בתחתית העמוד) וסדרה של תמחירים שהבדל העלויות בינהם מבחינת החברה מזערי, אבל מבחינת השורה התחתונה משמעותי מאוד.

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

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

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

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

1. ייצרו הצלחות: התחילו בניצול הזדמנויות קטנות ויצרו הצלחות מהירות במקומות עם סיכון נמוך.
2. הסבירו את ההגיון האסטרטגי מאחורי העניינים.
3. הסבירו את הערך האסטרטגי: אין פה מטרה של צמצום כ"א, אלא להיפך: מיזוג המוצרים יגביר את המכירות, יגדיל את הרווחים ולכן יאפשר השקעות גדולות יותר בחדשנות ובמוצרים חדשים. מי מאיתנו לא רוצה להתעסק עם מוצר חדש ולא להמשיך עם ה - Ctrl-C, Ctrl-V בין שני המוצרים.

איך מצמצמים סיכון?

1. מגדילים את ההשקעה ב - QA בפרק הזמן הרלוונטי.
2. מייצרים מומנטום של הצלחה.
3. חושפים את היתרונות כלפי חוץ, כולל שיקוף של ההצלחות והצגה של תכונות חדשות שנוספות למוצר ושידור של היתרונות לאנשי השיווק והמכירות. קבלת הרוח הגבית מגורמים אלו, תסייע להקטין התנגדויות בשל חוסר יציבות ו/או ירידת איכות שיכולות להתלוות לתהליך. אם אנשי השיווק שלכם ממוקדים ביכולות עתידיות, הסבירו להם כיצד הפיתוח הבא ימומש לשני המותגים במקביל תוך חסכון של 40-50% בזמני ועלויות הפיתוח.

למה HTML5 הולך להצליח בגדול?
בד"כ אני לא נוטה לקחת הימורים, אבל אני מאמין גדול בהצלחתו של תקן ה - HTML5. מה הקשר של זה לפוסט?
אחת הבעיות הקשות ביותר בפיתוח למערכות מובייל כיום הוא ריבוי פלטפורמות הפיתוח, עבור Symbian תידרשו לכתוב ב - C או ב - Java, עבור BlackBerry ו - Android ב - Java, עבור iPhone תאלצו ללמוד Objective C ואם מיקרוסופט תצליח עם Windows Phone תאלצו להתמודד גם עם Silverlight. אם יש לכם תחושה שתאלצו להמציא את הגלגל לפחות 5 פעמים אתם צודקים.
מה היה קורה אם יכולתם לפתח פעם אחת לכל הפלטפורמות? כנראה שתראו ירידה של 80% בעלות תחזוקת התוכנה למוצרי ה - Mobile שלכם.
HTML5 יתן את פתרון הקסם הזה, ולכן הוא ידחף באגרסיביות ע"י גופי פיתוח התוכנה, שהפתרון הזה יחסוך להם עלויות גדולות.

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

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

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

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