AWS: היכרות עם SxS - "השירותים הפשוטים" של אמזון - חלק א'

SxS הוא לא באמת מונח רשמי - "המצאתי" אותו לצורך הפוסט. מה שיש הוא:

• Simple Notification Service (בקיצור: SNS)
• Simple Queue Service (בקיצור: SQS)
• Simple Workflow Service (בקיצור: SWF)
• Simple Email Service (בקיצור: SES)

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

Simple Notification Service

שירות SNS הוא שירות הודעות פשוט, מבוסס סכמה של Publish/Subscriber - כלומר: שליחת הודעת לערוץ מסוים (topic) מצד אחד, ורישום ע"י מנוי אחד או יותר לאותו ה topic - שיקבלו את ההודעות ב push. מנוי HTTP, למשל, יספק את ה endpoint המדויק אליו הוא רוצה לקבל את ההודעה.

מקור: אמזון

דפוס ה Publish/Subscriber בא גם לספק decoupling בין השולח לנמען (הם לא מודעים אחד לשני), וגם לספק שליחה של הודעה פעם אחת, והעברה שלה למספר נמענים, לפעמים בפרוטוקולים או פורמטים שונים של הודעה.

SNS מאפשר לשלוח הודעות בפרוטוקולים שונים, למנויים (Subscribers) שונים. הוא מבוסס push, מה שאומר שהודעות נשלחות למנויים ברגע שההודעה התקבלה (אין polling). 

דוגמה נפוצה לשימוש ב SNS היא Monitoring של אירועים אפליקטיביים בשרתים (וריאציה מודרנית: שירותים). כשיש תקלה חמורה אנו יכולים לשלוח הודעה מהשירות שלנו SNS, שהוא מצידו ישלח הודעה לשירות ה monitoring שלנו + מייל + SMS לכונן שזמין באותו הרגע.

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

הרישום של המנויים הוא בלתי תלוי בשירות ששולח את ההודעה, ונעשה ישירות מול SNS. אמזון משתמשת בעצמה ב SNS לתפעול AWS. לדוגמה, ניתן להירשם ב SNS להודעות על auto-scaling, הודעות על איבוד נתונים ב RRS של S3, או אירועים שונים ב RDS (בסיסי נתונים המנוהלים ע"י אמזון).

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

ניתן לשלוח בהודעת ה SNS טקסט שונה לכל פרוטוקול של מנוי

(email-json הוא אימייל שנשלח בפורמט JSON ולא text-based).

SNS יודע לשלוח גם הודעות Push לשירותי מובייל (יכולת שנוספה בשלב מאוחר יותר):

• Apple Push Notification Service (בקיצור: APNS)
• Amazon Device Messaging (בקיצור: ADM)
• Google Cloud Messaging for Android (בקיצור GCM)
• וכמו כן, לשירותי ההודעות של מייקרוסופט (NPNS ו WNS), ושל Baidu (ענק החיפוש הסיני).

התעריפים של SNS נקבעים ע"פ כמות ההודעות שנשלחו לשירות, וכמות ההודעות שהוא שלח למנויים. התעריפים הם שונים למנויים מסוגים שונים: SMS או מובייל (יקר יותר), אימייל (באמצע), או HTTP/S (זול). הודעות שנשלחות ל SQS הן בחינם.


אמינות ההודעות

מה קורה כאשר נשלחה הודעת SNS ללקוח HTTP שכרגע אינו זמין? אולי השרת בדיוק נפל, או שהייתה תקלת רשת ששיבשה את ההודעה? במובייל ייתכן מצב זמני של ביטול הודעות push / הסרה והתקנה של האפליקציה ("Endpoint is disabled").
עבור חלק מהודעות SNS (למשל SMS, או אימייל), איבוד של הודעה אחת מתוך אלף היא לא בעיה גדולה. במקרים מסוימים - זו דווקא כן בעיה, ואז נרצה לטפל בה.

ל SNS יש מדיניות שליחה מחדש ("Delivery Retry Policies"), המאפשרת להעלות את רף האמינות של ההודעות שנשלחות. לצורך עניין זה אתמקד בהודעות HTTP/S.

מבחינת SNS, הודעה נכשלה אם:

• הנמען החזיר קוד HTTP מסדרת 5xx. (כאשר יש 404 או 403, זו לא ממש הצלחה, אבל אין כנראה טעם לנסות לשלוח מחדש את ההודעה).
• עבר timeout של 15 שניות ללא תגובה מה endpoint.
• תקלת תקשורת ברורה (תקלה בשליחת ההודעה, SSL certificate לא מתאים, וכו').

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

סה"כ ייתכנו עד כ 100 ניסיונות, ובטווח של לכל היותר שעה.

ל SNS יש מודל של 4 שלבים של Retries, בכל אחד מהם ניתן לקבוע קצב retries ומספר ניסיונות שונה ("קודם תנסה בעדינות, אח"כ דפוק בפטישים!"). הגמישות היא רבה למדי.

את מדיניות השליחה-מחדש ניתן לקבוע ברזולוציה של מנוי.

קישורים מעניינים

Amazon SNS FAQs

מדריך (מקיף) של אמזון למפתח
SNS Delivery Retry Policies for HTTP/S

Simple Queue Service

שירות המאפשר לנהל Queues (תורים), לשלוח ולקרוא מהם הודעות. זו צורת תקשורת מעט שונה מ SNS:

ההודעה נשלחת ל Queue, והשירות שמקבל את ההודעה שולף אותה ביזמתו מה Queue. לאחר שסיים לטפל בה - מוחק אותה (סדר זה נקבע בכדי לשמור על Data שלא יאבד). למבנה ה Queue יש כמה יתרונות:

• איזון עומסים בין חלקים שונים של המערכת: כאשר קצב ההודעות מה Producer מגיע ב peaks - ה Queue יאזן אותם. השירות הצורך את ההודעות קובע את קצב העבודה לו הוא מסוגל להגיב - ולכן לא ייפגע מ Self Denial of Service.
• מבנה ה Queue מאפשר לנתק, במידה מסוימת, בין זמן שליחת ההודעה - לזמן הטיפול בה. למשל: לשלוח הודעות ל Queue במשך כל היום אך להעלות ה Service  שמטפל בהן, רק למשך שעות הלילה - ואז לטפל בכל ההודעות באצווה.

לצורך שיתוף Queue בין כמה צרכנים (בד"כ מספר instances של אותו ה service) - לכל Queue מוגדר Visibility Timeout (ברירת מחדל = 30 שניות). אם הודעה נשלפה, היא נחשבת ל "in flight" ואז יש לשירות שאסף אותה 30 שניות למחוק אותה, או לבקש הארכה. אם לא עשה זאת - ההנחה היא שהוא "נכשל" בטיפול בה (למשל: קרס, איבד אותה, וכו') ולאחר 30 שניות היא תהיה זמינה לאיסוף ע"י instance אחר.

ניתן לבצע חלוקת עבודה בין כמה instances, פשוט ע"י שיתוף של Queue ביניהם:

• ניתן להאזין ל Alert על עומק ה Queue, ואם נראה שהשירות לא עומד בקצב - לייצר לו עוד instances. אם תרצו - אמזון תנהל התנהגות זו עבורכם בעזרת SQS Based Scaling.
• בכדי לא לבזבז זמן על Polling, ה API של SQS תומך ב "Long Polling". כלומר: קריאה ש"תתקע" למספר שניות שהוגדר, בהמתנה להודעה שאולי תגיע בזמן הזה - במקום לנסות שוב ושוב לבדוק האם ההודעה הגיעה.

הודעה שנאספה מספר פעמים, אך לא הצליחו לטפל בה - מסומנת כ"הודעה מורעלת" ומועברת ל Dead Letter Queue (אם הוגדרה מדיניות מתאימה).

הנה סיכום של כמה מההבדלים בין SQS ו SNS:

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

עבור השגה של ה Scalability, אמזון מציע Soft-FIFO בלבד. כלומר: הודעות יהיו "בערך" First In-First Out, הסבירות שהודעה a תשלף מה Queue לפני הודעה b גדלה ככל שהודעה a נשלחה זמן גדול יותר לפני הודעה b. ערבוב בין הודעות שנשלחו בזמן קרוב מאוד - הוא יחסית צפוי. ערבוב בין פרקי זמן ארוכים יותר (מספר שניות) - הולך והופך נדיר.

גודל ההודעה האפשרי הוא של 256KB.

ההגדרות של Queue, ב SQS

SQS הוא לא שירות יקר, אבל ניתן לחסוך עוד בעלויות ע"י שליחה של אצוות של עד עשר הודעות, במחיר של שליחת הודעה אחת - כל עוד הגודל הכולל של ההודעות באצווה לא גדול ממחסום ה 64KB.
אמזון מספקת ספרייה בשם AmazonSQSBufferedAsync client שמסייעת לנהל את האצוות, כמעט לבד, עבורכם. כרגע היא זמינה (ככל הידוע לי) רק בSDK לג'אווה.

אמזון מציעה מיליון בקשות ל SQS בחודש (לחשבון, בעת כתיבת פוסט זה), קריאה, כתיבה או מחיקה - בחינם. המחיר של כל מליון בקשות נוספות ל SQS הוא כחצי דולר.
אמנם גודל ההודעה המרבי הוא 256KB, אולם אמזון מחשיבה בקשות הגדולות מ 64KB, לצורכי תמחור, כבקשות נוספות. למשל: קבלת הודעה בגודל של 150KB - תחשב בתמחור כ 3 בקשות, למרות שנעשתה קריאת HTTP יחידה.



SQS vs. Kinesis
אמזון הציגה לאחרונה שירות נוסף בשם קינסיס (פירוש השם: "תנועה") - שגם הוא מספק ניהול Queues, אמין, זמין, היכול לתמוך ב Scale גבוה. קינסיס הוא "חיקוי" של Apache Kafka, עם כמה שינויים קלים.

מצד אחד - באמזון טוענים ש "SQS יכול לעמוד בכל Scale".
מצד שני - בעוד SQS הוא מנוהל לחלוטין יש לו כמה "כאבי ראש" שיש להתמודד איתם:

• עליכם לנהל את ה shards אליהם מחולק ה Queue - בכדי להגיע Scale. כל shard מוגבל לטיפול של אלף הודעות בשנייה.
• קינסיס הוא "פחות realtime-י": הוא לא יאפשר לתשאל על הודעות חדשות (לכל shard) יותר מ5 פעמים בשנייה (כן, הוא סופר).
• הנתונים נשמרים על קינסיס כ 24 שעות (מול 14 ימים של SQS).
• גודל הודעה בקינסיס מוגבל ל 50KB (מול 256KB של SQS),

למה, אם כן, להשתמש בקינסיס ולא SQS?!


על הבדל מהותי אחד, ניתן ללמוד מתוך התמחור של קינסיס:

• כ 2 סנט לכל שעה בו השירות פעיל, ולכל ~7GB של הודעות שנשלח. כלומר: ~10GB כל שעה, לאורך 24 שעות = 24*2*2 = בערך 1$.
• כ 3 סנט לכל מיליון פעולות כתיבה ל Queue. כלומר: ~10GB כל שעה, לאורך 24 שעות = בין 15 סנט ל ~7 דולר, תלוי בגודל ההודעות.
• שימוש ב SQS לתעבורה דומה יעלה בין 10$ ל 360$ (חישוב אצבע, תלוי בגודל ההודעות, שימוש באצוות, וכו').

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

בקיצור: קינסיס (כמו קפקא) היא תשתית שנכתבה להעביר אצוות גדולות מאוד של הודעות - בצורה יעילה, בד"כ: נתונים ב flow של Data processing. אם אתם שולחים GBs של נתונים, מסביב לשעון, כנראה שגם SQS יוכל לספק את השירות - אבל קינסיס עשויה להיות זולה משמעותית ולהתאים יותר לתהליך.

סיכום

בחנו שני שירותים פשוטים, אך חשובים מאוד של AWS: שירות ההודעות, ושירות ניהול התורים.
בפוסט הבא נבחן את שני השירותים האחרים: שירות הדואר האלקטרוני, ושירות ה workflows.


שיהיה בהצלחה!

על העוצמה הטמונה ב"טכנולוגיות משעממות" [דעה]

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

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

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

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

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

מקור: ארה"ב

בעיה של חלוקת-קשב

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

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

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

הקשב שלנו הוא משאב מוגבל. אנו יכולים יכולים להתמקד בנושא אחד לעומק, או בשלשה נושאים במקביל, ולהתעמק רק רבע(~) מכך. למה רבע? כי יש לנו Context Switch יקר [א].


אני חושש, שעבור מהנדסים צעירים בימים אלו, המקבילה של מה שקורס ה"נושאים מתקדמים במערכות היפר-מבוזרות, מתייצבות עצמית, מונחות בינה מלאכותית" היה עבורי - היא בד"כ טכנולוגיות חדשות: Docker, AngularJS, React, Scala, או בקיצור: Just Name It!

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

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

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

רוב הפעמים, רוב מי שמאמץ את הטכנולוגיות לא זוכה לשיפור ביכולת שלו לספק deliveries מהירים יותר או טובים יותר - אלא בעיקר ביכולת שלו להרשים אחרים  ("תשואות, ללא תשואה").

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

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

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

איזון הוא לב העניין

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

מבחינה מסוימת, החתירה של מתכנת או צוות בודד בארגון לאמץ טכנולוגיה חדשה משיקולים אישיים הוא Local Optimization שאולי נחמד להם - אך נוגד את האינטרסים של כלל הארגון (ה Global Optimization).

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

מצד שני, לריבוי שפות-תכנות (או ספריות) שבשימוש יש גם בעיות:

• קוד נוטה לא-להעלם: אם שוכחים ממנו - הוא לא באמת נעלם, הוא רק הופך לקוד Legacy בו צריך לבצע תיקונים מדי פעם. בכדי לבצע תיקונים - יש להכיר את שפת התכנות / הספריות שבשימוש ברמה סבירה כלשהי. "טריפ" של החלפת טכנולוגיות תדירה תשאיר אותנו עם גן-חיות של Legacies שיש לתחזק. זה הזמן לעבור מקום עבודה...
• אף אחד מאיתנו הוא לא ליאונרדו דה-וינצ'י (איש אשכולות [ב]) - כלומר: לא ניתן להגיע לרמת מומחיות גבוהה במספר טכנולוגיות בו זמנית. זה או להגיע לשליטה X ב-3 טכנולוגיות, או X/2 ב-5 או 6 טכנולוגיות. יש כאן trade-off ברור.
• חיבור בין טכנולוגיות שונות מציב, פעמים רבות, תקורה.

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

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

תובנה מעניינת ששמעתי בכנס GOTO; Berlin הגיעה מניתוח השימוש בחנויות ספרים מקוונות: לא רק בעולם הטכנולוגיה יש נטייה ללכת אחרי "החדש". הם הראו שגם רוב ספרי הניהול שנמכרים (ניהול - דיסיפלינה שמשתנה לאט) הם מהשנה האחרונה, או השנה שלפניה.

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

לוח פתקיות. לא "מגניב" כמו Mingle או ScrumWise - אבל עובד מצויין, וללא Learning Curve.

אבל...

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

כמה משעשע יהיה מצדי להראות כיצד שפת התכנות החדשה שהמצאתי, FibLang, מייצרת בקלות רבה יותר מכל שפה אחרת בעולם סדרה של מספרי פיבונאצ'י. הנה הקוד שנדרש:

do!

המ..המ, האם יש לכם שפת תכנות טובה יותר מהשפה הזו? בואו נזרוק את פייטון ונעבור כולנו ל FibLang FTW!!!

אנחנו יכולים להיות נבונים יותר, מכדי ללכת שולל אחרי מצגי-שווא שכאלה.


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

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

כנ"ל לגבי Frameworks, בסיסי-נתונים, וכו'.

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

מה עושים?

ניתן לעשות חישוב עלות/תמורה פשוט בכדי לבחון האם אימוץ טכנולוגיה משתלם - וכך לאמץ טכנולוגיות במינון האופטימלי.

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

• "המעבר אולי ייקח שנה-שנתיים - אבל אז נהנה מכל היתרונות שלה למשך כל השנים שלפנינו!" (ולא נחליף טכנולוגיה שוב כעבור שנים בודדות?)
• "אבל <חברה טכנולוגית מצליחה> משתמשת בטכנולוגיה הזו - ותראו לאן הם הגיעו!!" (אולי נדבר כל היום רק אנגלית במשרד, כי בחברה ההיא עושים זאת - ותראו לאן הם הגיעו !!)
• "מתכנתים פשוט לא ירצו לבוא לעבוד פה, בידיעה שאנו עובדים עוד בג'אווה גרסה 1.6 בלבד..." (אבל חידוש טכנולוגיות הוא התרגשות זמנית למפתח - שמתרגלים אליה מהר מאוד. בסוף היתרונות / חסרונות העקרוניים של הארגון הם שיקבעו).

אם הבעיה היא פסיכולוגית / חברתית, אולי ראוי שגם הפתרון יהיה פסיכולוגי / חברתי?

באוניברסיטה אחת ראיתי ששינו את שם קורס ה"מבני נתונים" ל"נושאים מתקדמים באלגוריתמים". ניסיון נחמד.

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

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

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

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

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


אין לי פתרון. אני לא יודע מה אפשר לעשות.
אני החלטתי לכתוב פוסט בנושא - אולי הוא יעזור במשהו :)





----

[א] מונח מעולם מערכות ההפעלה. כאשר נראה לנו שכמה יישומים רצים על אותו CPU core במקביל, הם בעצם רצים עליו סדרתית, כאשר מערכת ההפעלה מחליפה ביניהם כמה פעמים בשנייה ויוצרת את אשליית המקביליות.
ההחלפה הזו, דורשת כמה פעולות ממערכת ההפעלה ומייתרת חלק מזיכרון המטמון (בעיקר במעבד ובזיכרון) - מה שגורם לכל החלפה לגזול זמן לא מבוטל = תקורה.

באופן דומה, בני אדם שעוברים בין נושא לנושא יהיו פחות מרוכזים בנושא אליו עברו במשך כמה דקות. נוטים לייחס למוח האנושי context switch של 15 דקות, כלומר: כאשר אנו מחליפים נושא לוקח לנו כרבע שעה להגיע לאותה רמת ריכוז ויעילות שבה היינו בנושא הקודם שבו עסקנו. בממוצע גס - ניתן לומר ש 7 וחצי דקות מזמננו (ממוצע גס בין 0 ל 100% ריכוז) מתבזבזות בכל החלפת נושא. אם אנו עושים 20 דילוגים ביום בין נושאים, הלוך ושוב, בזבזנו שעתיים וחצי של פעילות המוח שלנו ביום הזה.

[ב] שנחשב כמוביל עולמי בד-בבד במספר תחומים, בתקופה בה הוא חי.