איך מפתחים באמזון? יעיל או אפקטיבי?

9 בפברואר 2014

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

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

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

אז מה עושים?
מאוד רצוי שבשלב ראשון נזהה באיזה מצב אנחנו:

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

אסטרטגית מוצר מבוססת יעילות קוד

אסטרטגית מוצר מבוססת יעילות קוד

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

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

אמזון דווקא נקטה את השיטה ההפוכה: לכל רכיב תוכנה קיים צוות עצמאי שלרשותו עצמאות מלאה בבחירת התשתיות ואופן הפיתוח. והמשמעות של כך שכל קבוצה באמזון בוחרת את התשתיות שלה, ובמקרה הצורך גם שומרת נתונים פעמיים. הדבר היחיד שאליו מחוייב הצוות הוא API שהוגדר מראש. API זה מגדיר את יכולות הרכיב (אם עבדתם עם Amazon Web Services אתם בוודאי מכירים שכל תכונה חדשה משוחררת קודם כל כ – API ורק לאחר מכן כתכונה חדשה בממשק הניהול). כפילות הנתונים והקוד הם לכאורה בזבוז משווע מצד אחד, אבל הם מאפשרים לצוותים באמזון להמשיך ולרוץ קדימה.

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

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

אסטרטגית קווי מוצרים עצמאיים

אסטרטגית קווי מוצרים עצמאיים

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

בקיצור, אם אתם מסוגלים לארוז את הקוד שלכם כמוצר סגור עם API, רצוי שתבצעו Reuse של הקוד. אם לא, אל תכבידו על הקבוצות האחרות ותנו להם לרוץ קדימה.

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

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

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

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

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

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *