OKRs - באזז ניהולי בעולם הסטארט-אפים

בשנות ה-50 של המאה העשרים, הציג פיטר דרוקר (אבי הניהול המודרני) - רעיון מהפכני לתקופתו: Management By Objectives.

Management by Objectives (בקיצור: MBO. נקרא לעתים גם MBR) הוא אוסף הרעיונות הבאים:

• במקום שהמנהל יכוון ("ינהל") את העובד באופן שוטף, משבוע לשבוע - ייקבעו המנהל והעובד כמה יעדים ארוכי טווח לעובד (למשל: יעדים שנתיים), אשר על העובד יהיה לנהל את עצמו ולדאוג לכך שהוא מגיע אליהם.
• העובד או העובדים יהיו שותפים לקביעת היעדים. אלו יעדים שהם מסכימים לקחת על עצמם (ולא הנחתה של המנהל).
• היעדים הללו הם יהיו הבסיס להערכת העובדים בסוף התקופה (נאמר: שנה) - יעד מדיד ואובייקטיבי.
• מכיוון שהמדדים הם מספריים (למשל: שיפור של 15% במחזור המכירות) - ניתן להעריך עובד ע"פ Benchmark מול עובדים מקבילים.
• הבהרה: העובדים שותפים לקביעת היעדים, עובד אחד יקבע 13% והשני 15%. בכל זאת אם עובד אחד השיג 12% והשני 10% - אזי ברור שלמרות שלא עמד ביעדים שקבע לעצמו - העובד הראשון עדיין עשה עבודה טובה.

מצד אחד, MBO נשמע דבר מאוד טבעי והגיוני.

מצד שני, יש הרבה ארגונים שלא הגיעו לרמה הזאת.

נכון. למתכנת קצת יותר קשה באמת להגדיר MBO איכותי. לראש צוות - זה כבר הרבה יותר הגיוני.

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

התפתחויות נוספות

התפתחות נוספת בתחום (ב 1981) הייתה ההגדרה של יעדים חכמים (S.M.A.R.T), כלומר: קווים מנחים להגדרת יעדים מוצלחים יותר:

• Specific - מכוונים לשיפור מוגדר היטב וממוקד.
• Measurable - ניתנים למדידה, עדיף בצורה מספרית (אם כי ייתכן גם הערכה של מנהל או מומחה).
• Assignable - שניתן להגדיר במדויק מי אחראי לביצוע
• Realistic - מציאותיים, ולא יעד בלתי-אפשרי. יעד שסביר שעובד מוכשר ישיג אותו.
• Time-related - מוגבל בזמן. 

אני מניח שרבים מקוראי הבלוג נתקלו כבר ב Guidelines הללו....

עוד וריאציה דיי מוכרת היא ה KPIs (קיצור של Key Performance Indicator) - שאלו יעדים מספריים בהכרח. לעתים משתמשים במונח לקבוע מדדים ביצוע של משימה (למשל: "שיפור ביצועים ב 20% אחוז בתצורה xyz"), ולעתים בכדי להתייחס ליעדים שנתיים של עובד (למשל: "גיוס 5 עובדים לצוות חדש").

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

ההתפתחות האחרונה (וה"חמה") בתחום היא OKR, קיצור של Objectives & Key Results. כמו שנראה מייד, זו התפתחות הגיונית וחיובית. באופן קצת מפתיע אולי, מנהלים נהנים להשתמש בטכניקות "חדשות וחמות" לא פחות ממפתחים התרים אחר הטכנולוגיה "החדשה והחמה" ביותר. מנהלים בהייטק - בכלל ☺

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

אני מניח ש MBO בזמנה, באמת הייתה מהפכה ששינתה הרבה.

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

האם שיפור של 1% בביצועי החברה הוא יעד ששווה השקעה של כמה שעות מכל עובדי החברה? - אני מניח שכן.

אם כן, אם OKR יכול להשיג שיפור אפילו קטן בהתנהלות הארגון - כנראה שיש טעם להשקיע בו.

ל MBO (על גרסאותיה השונות) יש כמובן גם חסרונות, או לפחות סיכונים:

• ברגע שלכל העובדים יש יעדים - כל אחד עוסק ביעדים שלו. נושאים שאינם מכוסים ע"י יעדים עלולים להיזנח, כאשר במצב אחר - היו מטפלים בהם.
• Over-fitting ליעדים הוא כמובן סיכון מוכר. בהקצנה: אני אגייס עובדים תאילנדים שלא דוברים עברית - רק בכדי לעמוד ביעד של גיוס צוות בן 5 עובדים בזמן.
• ככל שסביבת העבודה דינאמית יותר, כך קשה יותר להגדיר יעדים ארוכי טווח איכותיים. לפני שהשגתי את היעד - הצרכים כבר השתנו, ויעדים הקודמים כבר חסרי משמעות.
• Mitigation מקובל הוא לבצע review ועדכון של היעדים כל פרק זמן, למשל: כל רבעון.
• אנשים נוטים להיזכר ביעדים לקראת סוף התקופה, וכך להזניח אותם לאורך השנה. אם כל אנשי המכירות שלי מזניחים את היעד ונזכרים בו רק בחודש האחרון - אז נפגעתי כחברה, ו Benchmarks בין העובדים לא יפתור את הבעיה.

"אם ניתן למכור לזה שעות ייעוץ - אזי שירי ההלל לא יאחרו להגיע..." (חוק תכנותקיה)

עולם חדש מופלא

OKRs הופיעו, ככל הנראה, בפעם הראשונה ב 1995, בספרו של אנדי גרוב (המנכ"ל האגדי של אינטל) "High Output Management".

לשיטתו, על ארגון לשאול את עצמו כל פרק זמן:

1. להיכן אני רוצה להגיע? (להלן Objectives)
2. איך אדע שאני אכן מגיע לשם? (להלן Key Results)

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

• פרסום בביזנס אינסידר אודות גוגל ב 2014
• פרסום הטכניקה ב Re:Work (האתר של גוגל לשיתוף טכניקות ניהוליות)
• בפרסומים רבים לאחר מכן, גוגל (וחטיבות בה, כגון YouTube) מוזכרות תכופות כ Case Study.

ואיך אפשר בלי "מחקר מדעי" (סליחה על הספקנות [א]) ש"הוכיח" ש"המעבר ל OKR שיפר ב 8.5% את המכירות של Sears".
יש מחקרים אחדים, ועבור ארגונים רבים - זו סיבה יותר ממספיקה לאמץ מתודולוגיה. (פשוט ברור שגוגל מצליחה בזכות ה OKR. מנוע החיפוש, ושליטה בשוק הפרסום - הם משניים).

OKRs, בבסיס הם שילוב בין הרעיון של MBO לרעיון של חזון ארגוני (המוכר במידה רבה מהספר "לנצח נבנו") + כמה שיפורים.

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

חזון הוא סוג של פיצוי (mitigation) לחולשה של יעדים ברורים, קרי MBO, KPIs - שממקדים אותנו במשימה האישית שלנו, שלעתים יהוו סתירה למקום אליו הארגון רוצה להגיע.

היישום

ע"פ OKRs, ההלצה היא לקבוע 3 עד 5 יעדים (ולא יותר!), לתקופה של רבעון (ולא שנה).

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

יעדים לדוגמה עשויים להיות:

• לשפר דרמטית את הרמה המקצועית בצוות.
• לספק את המוצר A בתאריך d, ובכך לתת ערך ממשי ללקוחות.
• להפסיק להשתמש במערכת x (שהבעיות שלה מוסכמות) - בהנחה שזו עבודה הנדסית מאתגרת.

על היעד להיות:

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

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

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

לכל Objective מומלץ לקבוע 2-3 Key Results.

Key Results (להלן "תוצאות מפתח") הם המדדים, או Milestones - שבעזרתם אנו יכולים לדעת אם אנחנו בכיוון הנכון להשגת היעד.

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

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

למשל: אם היעד שלנו הוא "לספק Continuous Deployment, שיאפשר לארגון לבצע A/B Testing בצורה סדירה", אזי תוצאות המפתח עשויות להיות:

• Deploy נעשה בממוצע 20 פעמים בשבוע.
• ה Availability של המערכת לא נפגע.
• לפחות 5 Deploys בשבוע הם גדולים מ 20 שורות קוד.

ריבוי תוצאות-המפתח "נועל אותי" בפני סוגים שונים של Overfitting:

1. אני לא יכול לבצע Deploy ביום - ולטעון שיש לי CD.
2. אני לא יכול לבצע המון Deploys - אבל לחרב את יציבות המערכת.
3. אני לא יכול לבצע המון Deploys לא משמעותיים (שינויי הערות, או תיקונים של שורה), ולספר לעצמי שזה CD.

כמו כן, תוצאת-מפתח של "ביצוע לפחות A/B Test אחד בשבוע" היא מאוד רצויה לארגון - אבל לא הוגנת, אם היא לא תלויה רק בי.

על תוצאות המפתח להיות מאתגרות למדי, אך אפשריות.
כלל אצבע הוא להציב תוצאות מפתח, שבממוצע הציון הצפוי שלהם הוא 5/10. כלומר: ציון 5 הוא ביצוע טוב.

החשיבה מאחורי גישה זו היא:

• לדרבן את האנשים להשיג יותר. הרעיון ש"אם נציב יעד x - נקבל x. אם נציב יעד 1.5x - נקבל 1.2x, וזה יותר!" 
• לספק מרחב לזיהוי כישרונות יחודיים. מי שמשיג 9 או 10 - הוא כנראה כשרון יוצא דופן.

בגוגל, אגב, החליטו שהנורמה תהיה 7/10 - אולי כדי לא לייאש את העובדים, ואולי בגלל שכל העובדים בגוגל מאוד מוכשרים - והכישרון יוצא-הדופן, נמצא רק קצת מעל הנורמה.

תוצאות המפתח אמורות לספק לנו: 

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

נוהל יום ראשון (תרגום מ: "Monday Commitments")

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

בכל נקודת מעקב כזו מומלץ:

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

קבלת שבת (תרגום מ: "Friday Celebrations")

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

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

מה עם מי שלא מצליח לו? האם אפשר להציג גם אי-הצלחות ולפרק כך קצת מתח? האם זה לא חופף ל Sprint Demo בסקראם?

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


On-Boarding 

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

על כן, ההמלצה היא להתחיל ביעד אחד ברבעון הראשון, ולהעלות משם.
ניסיון לעבור בפעם אחת ל 100% ניהול ב OKRs - עלול להיות חוויה שלילית ושוחקת. במיוחד שמדובר באלמנט שמוסיף לחץ נוסף למערכת.

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

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

סיכום

סה"כ OKRs נראה מנגנון או שיטה שיש בהם הרבה היגיון.

האם OKRs מתאימים יותר לאנשי מכירות מאשר מתכנתים? אולי. מצד שני יש הרבה חברות תוכנה שמאמצות את השיטה.
האם OKRs מתאימים יותר לראשי צוותים או צוותים מאשר מתכנתים בודדים? אני חושב שכן, אבל אולי אני טועה.
בד"כ ב MBO וב OKR יש יעדים ארגוניים, מחלקתיים, קבוצתיים, צוותים, ואישיים - וכדומה (תלוי במבנה הארגון).


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


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



---

טיפים לאימוץ OKRs מחברות מובילות:
https://www.wrike.com/blog/12-okr-tips-google-linkedin-twitter-intel

בת'כלס, רוב העצות הללו טובות, באותה המידה, לאימוץ CI, סקראם, או MBO...


---

[א] במקרה בדקתי, והתוודעתי לכך שהחברה של "ספק סביר" חזרו לשדר. יוהוו!

רברסים 2016

ב 19-20 בספטמבר, יתקיים כנס רברסים 2016.

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

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

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

תמונה מרברסים 2015, בטכניון

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

אם אתם מתכוונים להגיע, הגשתי שתי הצעות להרצאות:

Microservices Insights with Microservices

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

 הבסיס הוא המצגת שלי מ DevConTLV, אך אחדש וארענן אותה.

Software Punk: examining controversial ideas in Software Development - that just might work

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




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

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

אם אתם בכנס - קפצו גם לומר שלום.



נתראה,
ליאור

ארכיטקטורות ללא שרת (Serverless Architectures) - מה זה השטויות האלה?!

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

"עכשיו תעשה לי את זה בלי שרת" - מבקש המראיין.
ווב, בלי שרת? כלומר... Rich Client שלא מתקשר עם אף אחד?

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

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

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

הרי קשה להתעלם מהבאזז המוזר הזה של "Serverless Architectures", באזז שכולל Frameworks, ספרים, ואפילו Conference שמוקדש לנושא.

בפוסט הזה אנסה להסביר את הנושא. נראה שבעצם כל התשובות נכונות.

הכרזה של ServerlessConf בניו-יורק

אז מה בעצם הכוונה ב "Serverless"?

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

את באזז ה Serverless ניתן לקשר לשלושה כיוונים עיקריים:

BaaS (קיצור של Backend as a Service) - שירות המאפשר למפתחי צד-לקוח (בעיקר מובייל, ולכן לעתים נקרא גם MBaaS) לבצע bootstrapping[א] מהיר ללא הצורך בידע והשקעה בצד השרת.
שירותים כמו parse.com (שנקנתה ע"י פייסבוק ואח"כ נסגרה), Firebase, או Kinvey הפכו פופולריים בעולם הסטארטאפים, וקיימים גם פתרונות פופלארים בקהילות הסגורות של עולם ה Enterprise (יבמ, אוקרל, סאפ) שבוודאי יהיו פחות מוכרים לאיש התוכנה הממוצע.

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

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

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


FaaS (קיצור של Functions as a Service) היא הגל השני של ה Serverless Architectures, שעלה לכותרות בעיקר בעקבות ההצגה של שירות AWS Lambda. למרות שהשירות שוחרר בגרסתו הראשונית עם מגבלות רבות, הוא הגיע משחקן מוכר ומוערך מאוד (אמזון), עם מחיר כניסה אפסי (אפשר להתנסות בו במחיר של סנטים), ובמרחק נגיעה - כי למאות אלפי (?) מתכנתים יש כרטיס אשראי כבר מוזן באמזון, והם יכולים להפעיל את השירות במרחק של קליק.

הפתרון, בגדול, מאפשר לכתוב ולעשות deploy לפונקציה בודדות - שתופעל כתגובה לקריאה ל endpoint (נקראים: "event sources") שנגדיר.
תפעול הפונקציות הללו (ניהול עומס, monitoring, ו High Availability) מנוהל ע"י אמזון. רק מעדכנים את קוד הפונקציה - ואמזון דואגת לשאר.
בעצם FaaS הוא סוג של PaaS (כלומר: Platform as a Service, סליחה על השימוש התכוף בבאזזים) ברזולוציה קטנה הרבה יותר: במקום אפליקציה - פונקציה.

מאז הצגת AWS Lambda הזדרזו המתחרים להציג שירותים מקבילים, והיום יש לנו גם את Google Cloud Functions (עדיין באלפא, בעת כתיבת פוסט זה), את Azure Functions (גם הוא חדש), ואת OpenWhisk של יבמ (שרצה על פלטפורמת Bluemix של יבמ, פלטפורמה מוכרת בכנסים - וקצת פחות מפתרונות בפרודקשיין).

במקביל לענקיות הענן, ישנם גם מפתרונות של שחקנים קטנים, למשל:StackHut או WebTask.

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

תת-וריאציה (מעט משונה) של FaaS היא DBFaaS, הגישה הזו גורסת שלעתים קרובות אנו זקוקים ב FaaS לפנוקציות שמבצעות עיבוד קל על נתונים. היכן יותר יעיל לשים את הפונקציות הללו - אם לא ב Database עצמו?
לחברת SAP יש מוצר בשם HANA, בסיס נתונים in-memory, שמאפשר ממשק וובי ישיר ל stored procedures שלו.
גישה זו שוברת כמעט כל מוסכמה של Layered Architecture או MVC, ומציבה דאגות רבות (Scalability? אבטחה? יכולת debugging ותהליכי תוכנה נכונים?). אני עדיין לא מצאתי איזון בריא לגישה הזו - אך אין ספק שהיא מערערת מוסכמות וגורמת לחשיבה מחודשת של הדברים. למה בעצם לא??

טרנפורמציה של ארכיטקטורת Client-Server לארכיטקטורת Serverless. מקור: Bliki

Serverless Web Site (אין קיצור מגניב)

תצורה אחרונה, וקצת פחות מהותית מהאחרות אליה מתייחסים כ Serverless Architecture היא לארח אתר אינטרנט (לרוב עם פונקציונליות מוגבלת, ובעיקר חוסר-תקשורת בין המשתמשים השונים) כ Static Content, ובניית כל הפונקציונליות ב JavaScript.
את קובצי ה HTML/CSS/JavaScript מארחים בשירות אכסון כמו S3 או אפילו עדיף - CDN.

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


כמה שהגישות השונות שהצגתי הן שונות זו מזו - יש ביניהן סינרגיה.

כאשר אנו משתמשים ב BaaS, תחת היכולות הגנריות שמציע השירות הספציפי - מה יותר טבעי מלהוסיף קצת custom server functionality כ FaaS?

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


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

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

אז מה הם באמת התכונות העיקריות של ארכיטקטורה "ללא-שרת" (קרי: מבוססת FaaS)?

אפשר לייחס ל Serverless Applications את התכונות הבאות:

• התבססות במידת האפשר על שירותי צד-שלישי.
• ה Flows העיקריים של האפליקציה מנוהלים בצד-הלקוח. צד השרת מספק בעיקר "פונקציות".
• בניגוד לשרת שחי לאורך זמן, וטיפל בבקשות שונות - ב Serverless Architectures המופע של צד-השרת חי לאורך טיפול בבקשה. יכולים להיות אלפים כאלו שמופעלים ונדומים בשנייה.
• זו תכונה טכנית יחסית, שעשויה להשתנות. ייתכן והספקים יתחילו לספק הנחות למי שמבטיח כמות מסוימת של שימוש בשעה - והדרך להוזיל עלויות תהיה כן להחזיק כמות מסוימת של instances קבועים.
• יתרונות נוספים של instances קבועים הם cache "חם" (ברמות השונות) וביטול / קיצור ה initialization latency.
• ארכיטקטורות Serverless לוקחות את רעיון ה Continuous Deployment לאקסטרים חדש: כעת ניתן, בכל רגע, לבצע דיפלוי ברזולוציה של פונקציה בודדת.

יתרונות:

• חסכון בעלויות, כי משלמים רק על מה שרץ - במיוחד כאשר יש traffic דליל. בסקייל בינוני ומעלה - זה יותר יקר.
• יותר אופרציה מנוהלת ע"י ספק השירותים, או קצת בהקצנה: noOps#. רעיון ה Platform as a Service (בו כמעט כל היבטי ניהול אפליקציות מבוצע ע"י הספק) לא הצליח כ"כ בפועל, אך יש סיכוי שמודל ה FaaS יצליח יותר.
• כאשר כל פונקציה (עם מאפייני הביצועים הייחודיים שלה) היא מבודדת - קל יותר לעשות Scaling. טעות נפוצה היא ש FaaS הוא "infinitely scalable". כאשר יש לפונקציה state משותף כזה או אחר - צווארי הבקבוק של ה scalability יהיו שם - כפי שהיה תמיד.
• אפשרות לקרב את הפונקציה למשאב אחר, למשל: קרוב מאוד לשירות צד-שלישי ולבצע חישובים שם, קרוב לנתונים, או אולי קרוב ללקוחות (למשל: לשים פונקציות שירוצות אצל ספק ה CDN וכך יספקו תשובות מאוד מהירות למשתמשי הקצה שלי, בכל רחבי העולם).

חסרונות:

• חלוקה של מערכת להרבה פונקציות קטנות דיי מהר הופכת לאתגר תפעולי מצד המתכנתים. רבים מהמימושים המוצלחים של FaaS כרגע - מבוססים על פונקציות מעטות.
• חלוקת המערכת להרבה פונקציות קטנות עלולה ליצור קשיים בהשגת אמינות גבוהה: הרשת יכולה לשבש קריאות בין פונקציות שונות - ואם אנו זקוקים ל"אפס פספוסים", אנו נצטרך להתגונן בפני כשל של הרבה מאוד נקודות אינטגרציה.
• Lock-In ל Vendor המספק לכם את השירותים. אולי הפונקציות עצמן מבודדות (isolated), אך סביר שהן משתמשות ב infrastructure נוסף (הרשאות, API Gateway, אכסון נתונים, וכו') שכובל אתכם לספק הספציפי.
• כאשר כל פונקציה רצה בפני עצמה בשרת צד-שלישי, ולא ניתן להריץ את הקוד לוקאלית - הפיתוח נעשה מורכב יותר. 
• לא יפתיע אותי אם נראה בקרוב יותר ויותר אמולטורים שמאפשרים להריץ את פתרונות ה FaaS (בצורה פחות יעילה / אמינה - רק לצורך פיתוח) על המחשב המקומי.
• לפחות כרגע, לפתרונות כמו AWS Lambda יש Initialization latency לפונקציה - כלומר: אתחול הפונקציה מוסיף לזמני התגובה כ 100-600 מילישניות (ע"פ דיווחים שונים). זה בסדר ל Event Processing, אבל קצת פחות טוב ל UI או מערכות semi-realtime.

איזה סוג של מערכות אם כן, מתאימות יותר ל Serverless Architectures?

• UI-Centric Apps - אפליקציות בהן חווית המשתמש היא המרכזית, והצרכים מצד השרת הם מצומצמים. אלו יהיו בעיקר אפליקציות מובייל - אך לעתים גם מערכות ווב.
• Message-Driven Systems - מערכות שעיקר עיסוקן הוא טיפול באירועים, למשל: טיפול בטרנזקציות בנקאיות, איתור Fraud, או מערכת שמחליטה איזו מודעה להתאים למשתמש. מערכות אלו ניתן לפרק בקלות יחסית לסדרה של פונקציות, כאשר יש הגיון לשפר כל פונקציה בנפרד: הן מבחינת ביצועי תוכנה = לרוץ מהר יותר, והן מבחינת ביצועים עסקיים = לתת תשובה קצת יותר מדויקת.
• אם המבנה הלוגיקה העסקית הוא של Pipes and Filters - מבנה ועקרונות של Serverless Architectures עשויים בהחלט להיות רלוונטיים.
• באזז נוסף שמתקשר ל Message-Driver Systems ו FaaS הוא IoT (קיצור של Internet of Things): אירועים שמגיעים מהמון מכשירים קטנים.
• חיזוק לנאמר לעיל: מערכות בהן אין (או כמעט ואין) State בצד השרת.
• בשפה של תכנות פונקציונלי: הפונקציות של FaaS הן Pure Functions.
• (קצת תיאורטי) יש טיעון שמערכות שחוות spikes גדולים מתאימות ל Serverless Architecture בגלל הציפיה לתשלום ע"פ גרנולריות מדויקת של שימוש, ויכולת Scalability גבוהה כאשר הפונקציות הן stateless.
• כאשר AMI של אמזון (שנבנה בצורה המתאימה) יכול לעלות ולהיכנס לשימוש בטווח של דקה או שתיים - רוב ה spikes יכולים להיות מטופלים בצורה סבירה עם autoscaling. קשה לי להאמין שהעלויות של FaaS יוכלו להתחרות בעלויות של ניהול התשתית בעצמנו (IaaS) - כאשר מדובר ב Scale גבוה. אין ארוחות חינם.

לגבי העלויות ארצה לציין זאת במפורש: יש אינסוף אזכורים לכמה AWS Lambda עשויה זולה יותר מ EC2. שמעתי לא פעם את המספר "80% חסכון!". זה סיפור טוב. כשצוללים לפרטים, ניתן לראות סיפורים על חסכון משמעותי - כאשר יש 3 קריאות ביום (מול שרת t2.micro).

יותר קשה למצוא ניתוחים של עלויות AWS Lambda ב scale גבוה. כל הניתוחים הללו שראיתי (הנה דוגמה) מראים מחיר גבוה יותר בשימוש ב Lambda מאשר בשימוש ב EC2.

סיכום

"כמה זמן יעבור עד ש Serverless Architectures יהיו הסטנדרט?" - היא שאלה שכבר שמעתי.
"כמו שהענן הולך להעלים את תצורות ה On-Premises... הרי Serverless יעלימו את ה Client-Server"

האמת - שאני לא יודע.
ייתכן וזה באזז שיחלוף, וייתכן שלגישת ה Serverless Architectures תהיה השפעה רבה על עיצוב מערכות מכאן ואילך.

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


למרות שיש דמיון בין הגישות, קרי: חלוקת המערכת לחלקים קטנים הרבה יותר, יש הבדל מהותי במוטיבציות:

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

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

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


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



---

[א] קרי - להעמיד מוצר ראשוני / התחלתי