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

אין חכם כבעל נסיון

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

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

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

כשהכלי היחיד בידיך זה פטיש, אתה מתייחס לכל בעיה כמסמר

המקרה של Twitter הוא מקרה קלאסי של בחירת פלטפורמה שנעשתה בשל הייפ (Ruby on Rails במקרה הזה), ארכיטקטורה שלא התאימה לפרופיל הגדילה של האתר ואופי השימוש בו במשולב עם פיקסציה ורצון להוכיח כי הבחירה ניתן לגרום לעסק לעבוד אם רק נעשה עוד סבב של אופטימזציות או שינויים ארכיטקטוניים כאלו ואחרים. בפועל, נדמה היה שלצוות הטכנולוגי של Twitter קודם שהוחלף היו כלים מועטים להתמודדות עם הבעיה שצפה היות והיא נמשכה שבועות רבים. בשיא הבעיה Twitter שירתו 11,000 דפים בכל שנייה, מספרים שמציגים אתגר אמיתי בייחוד כשמצרפים להם את מבנה השירות (לכל אחד מאיתנו יש למעשה פיד משלו הכולל את כל העדכונים של האנשים אחריהם הוא עוקב), זה נתון מפלצתי שמערכת טיפוסית המבוססת על Relational Database תתקשה לעמוד בו בלי מאמצי גדילה ועלויות חומרה ותחזוקה מפלצתיים עוד יותר.

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

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

• בחר הובלה טכנולוגית עם ארגז כלים רחב – חשוב שלרשות האחראים על הטכנולוגיה שלך יעמוד ארגז כלים טכנולוגי רחב של פתרונות ונסיון בהתמודדות עם סוגיות scaling בעבר.
• בחר כלים שהוכיחו את עצמם – ככל שזה ניתן, עדיף להימנע מלהמציא את הגלגל מחדש, חשוב להכיר best practices ו-patterns מקובלים ולבחון שימוש בכלים ותשתיות המבוססים עליהם.
• שאל את עצמך – האם אני פותר את הבעיה שלי? באיזשהו שלב נדמה היה שטוויטר מתעקשים להוכיח שהשירות שלהם יכול לעבוד על Ruby on Rails ולהתבסס על Database קונבנציונאלי בעוד הבעיה שלהם היתה איך לספק שירות איכותי לגולשים שלהם בעומסים גבוהים
  
• העדף ארכיטקטורה איכותית על-פני פלטפורמה מדוברת – השתדלו להתעלות מעל לדיון מה עדיף – Ruby / LAMP / Microsoft וזיכרו שבכל אחת מהפלטפורמות הללו ניתן לתכנן פתרון מוצלח ופתרון גרוע, הרבה יותר תלוי בארכיטקטורה עליה תבססו את השירות שלכם.

מאת ג'ואי שמחון, מנכ"ל משותף של Netcraft – המתמחה באפיון, עיצוב ופיתוח פתרונות אינטרנט המאפשרים לייצר הצלחה עסקית ויתרון תחרותי.