OpenStack – ענן בקוד פתוח

בפוסט זה אדבר על פרויקט OpenStack, פרויקט ה IaaS (קיצור של Infrastructure as a Service) הפופולרי.
(אם אין לכם מושג מה זה PaaS או IaaS – הנה הפוסט בשבילכם)

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

OpenStack (בקיצור: OSK) מנסה להיות \"הלינוקס של ה IaaS\": חינמי, חופשי, פתוח, ומפותח ע\"י קהילה. האם יקח גם לו כ 10 שנים לסגור את הפער? (אנשי לינוקס – אל תתרגזו. זו דעתי האישית).

ל OpenStack בהקשר זה יש גם אתגרים: הפרויקט כנראה נולד כצעד הגנתי של חברות IT שעיקר הרווח שלהן הוא בעולם ה On-Premises (קרי: לא בענן) כנגד AWS, גוגל (GAE) או Azure. קבלת החלטות שיטיבו עם OSK אבל יפגעו ברווחים של השותפות המרכזיות – הוא בעייתי. כמו כן, החברות ב OSK מצד אחד אמורות לתרום לפרויקט, מצד שני רבות מהן מוכרות שירותי OSK, ולכן רוצות לשמור יכולות מסוימות שפותחו – רק לעצמן.
אולי בגלל כל צפיפות האינטרסים האלו, קשה למצוא דיונים ביקורתיים ב OSK שנובעים מתוך הקהילה: רוב מה שתשמעו מהחברות הללו הוא PR שבא להאדיר את OSK. חסך בדיונים שכאלו עשוי לפגוע בפרויקט בטווח הארוך.

בהקשר זה כדאי להזכיר גם את פרויקט CloudFoundry (בקיצור: CF), שמנסה להיות ה\"לינוקס של ה PaaS\" (שכבת ה Platform as a Service). אין עדיין שחקן בולט במיוחד בעולם ה PaaS, אם כי BeanStalk של אמזון מתקדם לשם בצעדי-ענק, וגם MS Azure ו Google AppEngine (בקיצור: GAE) נראים כשחקנים משמעותיים [א].
ל CF יש עדיין מתחרה משמעותית בעולם הקוד הפתוח: OpenShift של Red Hat.אמנם CF זכתה להרבה מומנטום בחודשים האחרונים בצורת חברות שהתייצבו מאחוריה – אולם הקרב עדיין לא הוכרע.

הפוסט מניח שאתם יודעים קצת על:

טכנולוגיות ענן (עסקתי בהם גם בפוסט2, פוסט3). כדאי גם להכיר מעט על וירטואליזציה.
מושג כללי אודות שירותי middleware – כגון Authentication & Authorization או Message Queuing.

מקורות

OSK הוקם ע\"י שיתוף פעולה של נאס\"א ו Rackspace (חברת server hosting גדולה): שתיהן פתחו תשתיות ענן שנראו דומות – וב 2010 החליטו לשלב כוחות. OSK, כמעט כולו, כתוב בשפת פייטון (Python).

ב 2011 אובונטו (הפצת לינוקס) החליטה לשלב את OSK באסטרטגיה שלה להפוך להפצת הלינוקס הבולטת בענן.

ב 2012 הוקם ל OSK ארגון ניהול ללא מטרת רווח בשם \"The Open Stack Foundation\" שנועד לקדם את הפלטפורמה, תוך כדי שמירה על עקרונות של פלטפורמה פתוחה המפותחת ע\"י שתוף פעולה של קהילה רחבה.
הארגון מורכב מ:

קהילת מומחים (technical committee) מצומצמת שמתווה את הכיוון הטכנולוגי.
מועצת מנהלים (24 נציגים, 8 עצמאיים ועוד 16 מחברות תומכות).
קהילת משתמשים פעילה, הכוללת אלפי תורמי קוד ותיעוד.

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

מאז הצטרפו לפרויקט כ 200 חברות. אפשר לציין את AT&T, AMD, EMC, IBM, HP, Intel ו SAP (החברה בה אני עובד). פרויקט OSK גבר על כמה מתחרים – וכיום הוא פרויקט הקוד הפתוח הבולט ביותר בעולם ה IaaS, ואחד מפתרונות ה IaaS היחידים בעלי הסיכוי להתחרות ב AWS של אמזון.

OpenStack, תומך ב API \"תואם אמזון\" – כך שבתיאוריה ניתן להריץ אפליקציה שנכתבה עבור AWS (בפועל: בהתבסס על שירותים מאוד מסוימים) על OSK – עם שינויים קלים בלבד.

הגרסאות של OpenStack ששוחררו עד היום. שמותיהן על שמות ערים בעולם – בסדר עולה של ה ABC.

מבנה הפרויקט

OSK בנוי בצורה מודולרית, ומחולקת לשירותים (Services) עצמאיים, סוג של macro-services. רבים מהשירותים ניתנים להחלפה ע\"י שירותים חיצוניים – מה שמוכיח את טענת המודולריות.
כל שירות של OSK מנוהל כפרויקט (כמעט) עצמאי, והוא מורכב בד\"כ מכמה תתי פרויקטים משלו.
בדומה לפרויקטי קוד פתוח אחרים, פיצ\'רים גדולים חדשים מתחילים ב Incubation projects ורק כאשר צוברים תאוצה – מצטרפים כפרויקטים מהמניין. מייד נעבור על השירותים / פרויקטים של OpenStack.

הארכיטקטורה של OpenStack. הסברים בהמשך. מקור: OpenStack documentation

התקנה:

בכדי להתקין OpenStack צריך:

host OS (בד\"כ לינוקס).
בסיס נתונים (בד\"כ משתמשים ב MySQL. אפשר גם PostgreSQL או אפילו SQLLite3 – אך לא בסביבת production)
Message Queuing Service, בד\"כ מתקינים RabbitMQ.

אפשר להתקין את OSK גם על VM ולא ישירות \"על הברזלים\".

שירותים:

כפי שציינתי, ל OpenStack יש 5 שירותי ליבה, שנדרשים ל(כמעט) כל תצורה:

Identity Services (שם קוד: KeyStone)
Compute Services – מה שמריץ את ה VMs. (שם קוד: Nova)
Image Services – כלומר Images של VMs. (שם קוד: Glance)
Networking Services – (שם קוד: Nova Networking או Neutron)
Dashboard (שם קוד: Horizon)

בנוסף יש עוד כמה שירותים שהם extended / אופציונליים – ומותקנים רק במידה והשירותים שלהם מתבקשים. אותם אכסה בחלק השני של הפוסט.

כנראה אחד הדברים שמעניינים הם הקבלה ל Amazon Web Services, שלא יכלו שלא לשמש השראה ל OpenStack:

Nova דומה מאוד ל EC2, וכפי שציינתי יש לו API תואם EC2 בו ניתן להשתמש.
Glance דומה מאוד ל AMI Catalog של אמזון
Cinder (עליו נדבר בהמשך) דומה ל EBS (כלומר: Elastic Block Store) של אמזון.
Swift (עליו נדבר בהמשך) דומה ל S3, וגם הוא מממש חלקים מה S3 APIs.

אחוזי ההשתפות ב OpenStack, מתוך האתר הרשמי.

שירותי הליבה של OpenStack

Keystone
זהו שירות ה Authentication & Authorization של OpenStack.
השירות נקרא Keystone מכיוון שהוא חיוני לכל פעילות של OpenStack. הוא מנהל הרשאות של:

משתמשי-קצה
שירותים
Endpoints של שירותים (כלומר: יישות שדרכה צורכים את השירות)

לאחר שמשתמש מבצע login / עובר authentication ראשוני, הוא מקבל מהשירות token שיזהה אותו ולא ידרוש זיהוי מחדש לאורך ה login session הנוכחי.
Keystone תומך במודל של Role-Based Authorization, אותו הסברתי בפוסט הזה.

ניתן לחבר את Keystone לשירותי LDAP חיצוניים ולשירותי Federated Identity כמו SAML (עליהם כתבתי בפוסט הזה). OAuth, עד כמה שידוע לי, עדיין לא נתמך – אך התמיכה בו היא כרגע בפיתוח.

Nova
נובה היא שירות ה compute של OSK, המנהל את מחזור חיי המכונות (הפעלה / השבתה / התאוששות) בענן של OpenStack. נובה הוא השירות הגדול והמורכב ביותר ב OSK.
שירות נובה לא כולל יכולות Virtualization עצמאיות (כלומר: hypervisor או container[ב]), אלא רק ניהול שירותי VM של צד-שלישי: KVM, Xen VSphere, Hyper-V וכו\'.

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

בנובה מגדירים:

Region (אזור גאוגרפי): התקנה מלאה של OSK, המכילה כמה Availability Zones.
Availability Zone: מיקומים שונים שנבנו ברמת ה data center כך שכשל של אחד (שריפה, ניתוק התקשורת, וכו\') לא ישפיע על האחר.
Host) Aggregates): קבוצות לוגיות של מכונות מרוכזות ע\"י תכונות, למשל: כמות מסוימת של זכרון (נאמר 128GB), רשת 10G, חומרה מיוחדת, וכו\'. קבוצות אלו משמשות ל Queries ולניהול הפריטים בקבוצה יחדיו.

Availability Zones שונים באותו ה Region משתפים את שירותי ה keystone וה Horizon שלהם – לצורך פשטות העבודה של שירותים אלו.

Nova-Networking

Nova-Networking הוא תת שירות של נובה, המספק (בצורה וירטואלית) שירותי רשת ל VMs שרצים בנובה:

VLANs (\"שכבה 2\")
הגדרת רשתות IP למחשבים (\"שכבה 3\") – בכמה אסטרטגיות שונות.

VLAN

דבר שעשוי להיות לא ברור הוא הצורך / משמעות ה VLAN:
\"אני מכיר VPN, או הפשטות שונות של רשת, אבל מה ההיגיון ב LAN וירטואלי? האם LAN הוא לא הרכיב הבסיסי ביותר עליו עושים את וירטואוליזציית הרשת?!\" – אתם עשויים לשאול

בארגונים נהוג לחלק את הרשת הפיסית לתתי רשתות, משיקולי ביצועים (או בעצם SLA של תתי רשתות ספציפיות) ושיקולי אבטחה. למרות שבאוניברסיטה מלמדים עליהם, כבר לא משתמשים היום ב Hubs, Bridges או Repeaters (תרגיל: נסו לקנות bridge של Cisco או HP) – בעצם משתמשים רק ב Switches (\"שכבה 2\") או Routers (\"שכבה 3\") שהם חכמים יותר ויודעים למלא תפקידים של Bridge, Hub או Repeater (ע\"י Switch) או Proxy ותפקידים אחרים (ה Router). בעוד ש switch ביתי הוא דבר זול מאוד (בערך 100 שקל?), הסוויצ\'ים בהם משתמשים בארגונים יכולים לעלות אלפי שקלים. מדוע? בגלל אמינות, ביצועים, ויכולות שליטה ובקרה מתקדמות (SNMP, קנפוג מרחוק, וכו\'). תוספת עלות נוספת לארגונים הוא התפעול / תחזוקה של ה swtiches הללו ע\"י אנשי IT.

הרעיון של VLAN הוא פשוט מאוד: מחברים את כל המחשבים ברשת הארגונית ל switch יחיד (או מערך משורשר של switches – כשיש יותר מ~50 מחשבים, אולי מחזיקים עותק נוסף עבור redundancy) ואת כל תת-הרשתות מגדירים ע\"י קונפיגורציה של ה switch ולא ע\"י חיווט ידני. יש לכך תקן – תקן 802.1Q (נקרא בע\"פ: \"דוט וואן קיו\") המוסיף ל header של Ethernet frame שדה חדש בשם VLAN: ערך מספרי בין 0-4095. לכל פורט (חיבור פיסי לכבל) של ה switch – כזה שמחובר למחשב כלשהו, מוגדר VLAN אליו הוא שייך. המחשב עצמו לא אמור לדעת שהוא נמצא ב VLAN – רק ציוד התקשורת (שאלו בעצם ה switches) מודע לשדה זה. כל הודעת Ethernet שנכנסת מהמחשב ל switch דרך הפורט תסומן בתגית עם מספר ה VLAN שהוגדר (נאמר VLAN מס\' 3). כל הודעה שיוצאת מה siwtch דרך הפורט למחשב כלשהו – תוסר ממנה תגית ה VLAN (כי המחשב לא אמור להכיר אותה). תגיות אלו משמשות רק בתוך ה switch ובין switches שמחוברים זה לזה דרך \"Trunk Ports\".

היתרונות: פחות חומרה (\"כל הפורטים ב switch מנוצלים\"), פחות חיווט פיסי, יותר שליטה בתוכנה.
נושא זה הופך לחשוב אפילו יותר – בענן.

ממשק ניהול של Enterprise Switch, לא גן ילדים

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

לגבי הגדרות IP למחשבים (\"שכבה 3\"), nova-networking תומכת בכמה מודלים:

Flat Networking – המחשבים מקבלים IP בזמן ה boot. ייתכן ש tenents שונים יקבלו כתובות IP עוקבות, זה לא אמור לשנות.
Flat DHCP – המחשבים מקבלים כתובות IP ע\"י שירות ה DHCP של OPK (הדרך הנפוצה יותר).
VLAN Manager – ה Tenant הוא זה שמספק למחשב את ה VLAN וכתובת ה IP המתאימה ביחד.
Flat and Private: המחשב מקבל כתובת בתוך הענן במודל Flat Networking ועוד כתובת לרשת פנימית שייחודית רק עבור ה Tenant אליו הוא שייך.
גישה אחרת הנקראת \"Provider Router\" מגדירה לכל tenant \"רשת-על\" משלו, שהיא מחוברת לתת-רשתות פנימיות שה tenant הגדיר. וכו\'.

הרבה פעמים מחברים כל מחשב בענן ל2 רשתות: רשת פנימית לצריכת שירותי ענן / תקשורת עם nodes אחרים, ורשת נפרדת לתקשורת עם האינטרנט. יש כמה וכמה גישות, וכמה trade-offs שיש לשקול בכל גישה. אלו עניינים ברמת תכנון ה landscape וה Operations.

Project Neutron (לשעבר Quantum).

שירות נובה של OpenStack הלך ונהיה מורכב, ולאורך הגרסאות התחילו להתפצל ממנו שירותים נפרדים. למשל: nova-volume שדאג להקצות שטח דיסק (וירטואלי כמובן, בפועל האכסון נעשה על NAS או פתרון דומה) לכל מחשב, השתכלל לשירות Cinder עליו נדבר בהמשך. ה APIs של nova-volume עדיין עובדים – הם פשוט קוראים היום ל Cinder.

גם שירות ה nova-network נהיה מורכב, מצד אחד, ולא מספיק גמיש – מצד שני.
Open Stack Foundation החליט להקים את פרוייקט Quantum (שהיו בעיות על זכויות השם, ולכן שמו שונה ל Neutron) שיהיה שירות ה Next-Generation של הגדרת וניהול רשתות ב OpenStack. הוא מאפשר:

להתמודד עם scales ש nova-networking התקשה להתמודד איתם. כנראה זה אזור של יותר מכמה מאות nodes במערכת.
Software Define Networking – הגדרת רשתות ו SLAs מעשיים, בצורה כמעט וגמישה לחלוטין. (SDN הוא באזז בימנו. שווה פוסט).
תמיכה בתקנים משופרים (יותר מ 4095 VLANS, תמיכה ב IPv6, וכו\')
תמיכה במודלים נוספים (למשך GRE או VXLAN)
מבנה מודולרי יותר, המאפשר הרחבה ב plugins. רשתות הוא נושא מורכב, וכמעט תמיד יהיה צורך לפלח שוק מסוים בפנוקציונליות נוספת: או תמיכה בחומרה ייעודית (למשל: Cisco) או תוכנה ייעודית (למשל VMWare) ייעודית בצורה טובה יותר, או תמיכה בפרדיגמות שונות לניהול הרשת.

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

Glance
Glance (\"מבט חטוף\") הוא שירות שמאחסן images (תמונת-כונן) של VMs.

Glance מאכסן תמונות-כונן ברמת ה Tenant או ברמה הגלובאלית (זמינות לכולם) + מאפשר שליטה נוספת בהרשאות כמו: מי יכול לעדכן תמונת-כונן, מי יכול להשתמש בה וכו\'.

תמונות-הכונן עצמן יכולות להשמר בכמה מקורות אחסון שונים:

Cinder או Swift – שירותי האכסון של OSK עליהם נדבר בהמשך.
מערכת הקבצים המקומית (לא מומלץ)
כל שירות חיצוני שמאפשר לקרוא אותם אח\"כ דרך HTTP, למשל: S3 של אמזון.

תת שירות של glance הוא glance-registry המאכסן metadata כל תמונות-הכונן השונות. ה metadata מאוכסן בנפרד מתמונות-הכונן, מה שמאפשר לבצע עליו חיפושים וחיתוכים שונים ביעילות.

כפי שהזכרנו קודם לכן, OSK אינו כולל את טכנולוגיות ה VM – הוא משתמש לשם כך בפתרונות צד-שלישי. בהתאמה: תמונות-הכונן שהוא שומר יכולות להיות בפורמטים שונים, ע\"פ ה VMs השונים שבשימוש. ניתן להשתמש ב OSK במקביל בכמה סוגי VM (למשל: VMWare ו Virtual Box).

Horizon

Horizon הוא ה Dashboard של OpenStack אליו מתנקזים נתונים מכל השירותים השונים.
חשוב להבין ש Horizon הוא קודם כל שירות שאוסף ומארגן את הנתונים, ורק אח\"כ – שכבת ה Presentation שהיא ה Dashboard הויזואלי שכולם רואים.

ל Dashboard (\"לוח הזינוק\"?) של OSK יש בעצם 2 גרסאות עקריות:

Dashboard ל Admin – מנהל המערכת, נקרא System Dashboard
Dashboard למתשמש – לאו דווקא משתמש קצה, אלא בעל האפליקציה, נקרא User Dashboard. בעיקרון, Dashboard זה הוא subset של ה Dashboard של ה Admin.

ה Dashboard עצמו (נקרא גם \"OpenStack Dashboard\") הוא אפליקציית Django (ספריית פייטון מאוד פופולרית ל Web UI), שבנויה בצורה מודולרית (ניתן להרחיב) ו Brandable (ניתן לשנות צבעים ולוגו בכדי לשקף את זהות מיישם ה OpenStack הנוכחי באותו הרגע).

את כל הפעולות שניתן לעשות ב Dashboard ניתן לעשות גם בצורה פרוגרמטית, בעזרת APIs.

System Dashboard עם מיתוג של OpenStack

User Dashboard עם מיתוג של Redhat

סיכום

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

—

[א] הנה סקירה מעניינת (ומעט מוטה לטובת CF), של השחקנים בעולם ה PaaS.

[ב] מן מכונות וירטואליות רזות שמשתפות בניהן תהליכים של מערכת ההפעלה – וכך צורכות הרבה פחות זכרון או דיסק, ומאפשרות אתחול מהיר במיוחד => MTTR נמוך מאוד. נושא ה Linux Containers מצדיק פוסט בפני עצמו.

Techkiz – לחשוף סטודנטים לעולם

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

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

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

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

מפגש הפתיחה של הקורס, במעבדות סאפ

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

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

במסגרת הקורס נבחרו 40 סטודנטים (מתוך כמאתיים שנרשמו) לשבוע במעבדות SAP. איך נבחרו? כנראה על בסיס ציונים, נכונות להשקיע וכו'.

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

איך מתפקדת חברת תוכנה
איך מוכרים תוכנה
מערכות ווב
בסיסי נתונים
טכנולוגיות ענן
מתודולוגיות פיתוח
תהליכי תוכנה (build, delivery, version control וכו')
איך להתמודד עם ראיונות עבודה
ניהול קריירה
יזמות
וכו'

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

אני סיימתי את התואר שלי לפני 11 שנה בערך. העולם המקצועי השתנה לא מעט, ואני מקווה שהתארים גם השתנו – בהתאם [א]. גם המדיה ואמצעי הלמידה השתנו – ונראה לי שסטודנטים של היום הרבה יותר מודעים למה שמתרחש סביבה (כמעט כולם שמעו על Big Data, ענן או Hadoop. מעטים מאוד הבינו במה מדובר)

בימי, הדרכים הכי טובות שמצאתי להתעדכן במה שמתרחש בעולם היה לשוטט בספריה בחיפוש אחרי ספרים חדשים, לקרוא PC Magazine (האא… הוא חוזר על עצמו מתישהו), או לקרוא בצמא את c2 wiki.

היום יש את Hacker News, גיקטיים, StackOverflow וכו' – שהרבה יותר סטודנטים נחשפים אליהם מאלו שנחשפו למקורות שלי – בזמני. בעצם: נראה לי שאני הייתי היחידי, במחלקה אם לא באוניברסיטה :).

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

טוב שכך.

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

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

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

אני אישית העברתי כמה הרצאות:

ארכיטקטורת תוכנה + ארכיטקטורה של מערכות ווב (לבסוף איחדתי את 2 ההרצאות להרצאה אחת ארוכה).

שם ליווינו סיפור דמיוני על אתר מהפכני שתכננתי, בשם "ספר-פנים", שמתחיל כקובץ HTML פשוט, אך גדל בהדרגה להיות אפליקציית ווב, ואח"כ מערכת ווב שלמה (בסיס נתונים, Load Balancer, multi-tier Architecture, צד שרת וצד לקוח, וכ'ו).

שפות תכנות של העולם

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

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

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

מתודולוגיות פיתוח

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

אח"כ חזרתי לשורשים הפילוסופיים של כל זן מתודולוגיות (טיילור ל RUP ו TPS של טויוטה ל Agile) – והעקרונות / רעיונות שעומדים מאחוריהן.

לבסוף סקרתי כמה פרקטיקות מ 3 מתודולוגיות אג'יליות מודרניות: XP, סקראם ו Lean Startup.

זהו.

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

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

ליאור

—-

אתר הקורס

אתר הפייסבוק של מעבדת SAP בארץ – שם יש עוד כמה פרטים על הקורס

—-

[א] קיבלתי לעיון את כל חומר הלימודים מסטודנט שיסיים לאחרונה תואר זהה לשלי – והשינוי שם היה דיי מתון. אני חושב שרוב הקורסים לא השתנו משמעותית (עדכונים קלים בלבד), וגם התכנית בכלל – רק השתנתה במעט. 11 שנה בעולם התוכנה – זה דור.

דעה: איך להתקדם בארגונים?

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

מדוע אם כן אני כותב אותו?

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

על בסיס איזו מומחיות אני כותב את הפוסט?

לתפקיד הראשון שלי (ארכיטקט) התקדמתי דיי מהר – פחות מ 4 שנים בתעשייה. מאז קצת יותר לאט 🙂
בעיקר בתור צופה, שעובד עם הרבה אנשים וצוותים – וחווה את הדינמיקות הארגוניות כבר שנים.
בהקצנה: כפי שניקולו מקיאוולי כתב על משילות, למרות שמעולם לא שלט בעצמו.
על בסיס 2 ה Reviewers שלי לפוסט, בעלי הניסיון הרב הנושא: אליאל שורמן (מנהל קבוצת פיתוח ב SAP) ונמרוד ברק (דירקטור פיתוח ב SAP) אשר קראו, הוסיפו, ותרמו באמת לפוסט. תודה רבה אליאל ונמרוד!

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

תיאום ציפיות קצר: אל תצפו לקסמים.

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

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

המודל הבסיסי

אני לא מכיר שום מודל קיים בנושא, ולכן אגדיר אחד:

קידום מתבצע כאשר מתקיימים 3 תנאים:

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

על תנאים 1 ו 3 – אין לכם הרבה שליטה. זה עניין של סבלנות, הזדמנות, ומזל.
תנאי מס' 2 – הוא כולו באחריותכם.

והנה הפתעה: את הקרדיט הזה לא בונים בעזרת "עשיית התפקיד שלכם בצורה הטובה ביותר".

הקרדיט בעצם בנוי מ-2 מרכיבים עיקריים:

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

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

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

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

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

הקרדיט הכולל שלכם מנוהל בכמה "חשבונות" בצורה מצרפית:

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

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

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

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

"הישרדות": אל תיקחו משם רעיונות, אלא אם אתם מתכננים לחזור הביתה לאחר 3 חודשים…

טקטיקות נפוצות לקבלת קידום – וניתוחן ע"פ המודל

הנה טקטיקות נפוצות בהן ראיתי שאנשים משתמשים – וניתוח היעילות שלהן:

"לעשות שרירים" (bully) על חברים לצוות – שכולם ידעו שאתם הכי דומיננטיים בצוות
שורף (מפחית) לכם קרדיט אצל ה peers, ולא כ"כ סביר שייצור איזשהו קרדיט חיובי אצל מנהלים אחרים.
בקיצור: להימנע!

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

בקיצור: טקטיקה שנויה במחלוקת.

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

אכפתיות והפתעה לטובה
לעשות דברים קטנים שלא מבקשים מכם, ולהיות אכפתיים יכולים לייצר לכם הרבה קרדיט חיובי.
דוגמה אישית 1: פעם בכל התקנה של מכונה אצלנו, היה צריך לקחת template של XML ולמלא אותו עם פרטי המכונה ולזרוק באיזו תיקיה. כמתכנת – כתבתי servlet שמייצר את ה XML אוטומטית בזמן ריצה ושיניתי את הקוד שיקרא את ה servlet ולא את הקובץ בדיסק. זו הייתה עבודת תכנות קטנה מאוד – אבל שיצרה לי המון קרדיט בקרב peers ומנהלים.
דוגמה אישית 2: בחברה אחרת, היו במטבח 4 קופסאות עוגיות אטומות, שכל יום שמו בהן חטיפים אחרים. כן, עוגיות. כל מי שבא להפסקת קפה היה פותח את כל הארבעה אחת אחרי השנייה – בכדי לבדוק מה המבחר באותו הרגע. זה היה טקס מציק – אך כולם עשו אותו מבלי לשים לב. ביקשתי תקציב וקניתי 4 קופסאות שקופות – והפעולה הקטנה הזו יצרה לי יותר קרדיט מהרבה עשייה מורכבת וקשה יותר. היא לא הייתה קשורה לתוכנה, אבל היא נגעה לכולם והפגינה אכפתיות.

בקיצור: מצוין!
הפתעתם מישהו לטובה: זכיתם בקרדיט. הפתעתם הרבה אנשים לטובה: זכיתם בהרבה קרדיט.

walk the walk, talk the talk

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

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

בקיצור: אפקטיבי רק כאשר יש לכם קרדיט משמעותי.

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

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

בקיצור: להימנע! זוהי טקטיקה יעילה רק בדבר אחד: למנוע מעצמכם קידום.

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

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

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

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

בקיצור: לא מספיק טוב.

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

חשבו גם על המנהל של המנהל שלכם: האם הוא יעדיף לנהל מישהו שמוציא את מנהלו טוב, או רע? – נחשו לבד.

בקיצור: טקטיקת בסיס חשובה.

אבני דרך חשובות

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

צרו לעצמכם הזדמנויות לקבל "קרדיט ניהולי"

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

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

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

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

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

בכל מקרה – כבדו את אסטרטגיה של הארגון

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

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

זו עוד הייתה הגרסה החיובית-יותר לביקורת על דרכו של הארגון. מה עם:
"איזה מטומטמים: במקום לעשות טונות של כסף ב X – הם תקועים עם הגישה שלהם ל…. הם סתם מפחדים מדברים חדשים". או "כל המנהלים בארגון הזה דפוקים/לקקנים/משהו אחר", וכו'.

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

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

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

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

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

הפגינו מחויבות לארגון

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

כיצד נמדדת מחויבות לארגון?

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

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

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

אור הזרקורים

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

תכונות עצמיות להן כדאי לשים לב

נראות

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

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

להבין את רמת הנהילות שלכם

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

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

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

Troubleshooting

מנהל לא-טוב

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

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

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

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

המנהל אומר לי שאני מתאים, אך כבר זמן מה לא קורה שום דבר

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

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

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

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

סיכום

עבודה טובה היא לא קרדיט,
קרדיט הוא לא מוכנות לקידום,
מוכנות לקידום היא לא קידום,
קידום הוא לא אושר

כל עוד אתם זוכרים זאת – אזי הכל בסדר 🙂

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

לאן אשר תלכו – שיהיה בהצלחה!

—-

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

[ב] או מנהלת, כמובן.

להבין Maven (הצצה ראשונית)

מייבן (Maven, מלשון \"מבין\" ביידיש) היא ספריית build ו dependency management לסביבת ה JVM, וג\'אווה בפרט.

מייבן איננה חדשה, והיא איננה הטרנד החם בתחום – אך היא עדיין נפוצה מאוד. ע\"פ סקר מ 2013 – כ 70% ממפתחי הג\'אווה משתמשים בה.

אמנם ל Gradle (ספרייה מתחרה, שהיא הטרנד החם בתחום) יש כמה יתרונות מובנים על פני מייבן (קלות תחזוקה: DSL מול XML + מהירות ריצה) – אבל ייקח עוד זמן עד שהיא תוכל להחליף את מייבן: ל Gradle אין עדיין repositories משלה, וכמות ה plugins הזמינים עבורה – נמוכה בהרבה. היא גם מתבססת על Groovy – שפה עם קהילה לא כ\"כ גדולה [א].

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

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

יש כמה וכמה כלי Build נפוצים:

Make של C או ++C ו Unix (שנת 1977)
Ant של ג\'אווה (שנת 2000)
מייבן של ג\'אווה (שנת 2002)
Rake של רובי (לא יודע ממתי בדיוק)
SBT – קיצור של Simple Build Tool, של סקאלה (שנת 2008)
Gradle לג\'אווה / גרובי (שנת 2012)
Grunt ו Gulp לג\'ווהסקריפט (חדשות למדי).

ויש גם כמה כלים לניהול תלויות:

מייבן – הכוללת גם כלי ניהול תלויות. אולי הראשון מסוגו.
Ivy (שנת 2007) – קיימת כתת פרויקט של Ant, אך יש לה זכות קיום עצמאית. משמשת את SBT ואולי גם כלים אחרים.
Gradle – התחילה כתלויה ב Ivy, אך פיתחה עם הזמן מערכת ניהול תלויות עצמאית.

מערכות לניהול תלויות הן מערכות דומות מאוד ל package managers, כמו אלו של לינוקס, npm של node.js, או bower של ספריות ג\'אווהסקריפט. ההבדל הוא שהן מנהלות source code ולא code ל production (כך שאין צורך לבצע התקנה), ושיש להן אינטגרציה לכלי build: כאשר ב build מסומנת תלות בספרייה שלא קיימת – כלי ה build יוריד אותה בצורה אוטומטית, כך שה build יוכל להסתיים בהצלחה.

מה מייבן מספקת, ובמה היא טובה מ Ant?

קרן Apache מנהלת גם את Ant וגם את Maven. מדוע לנהל 2 ספריות מתחרות? מה מייבן (המאוחרת יותר) מנסה לעשות ש Ant לא עשתה?

המודל של Ant דומה למודל של MAKE: סקריפט המפעיל סדרה של פעולות לבניין התוכנה: העתקת קבצים, קומפילציה, מחיקת קבצים זמניים, וכו\'. סקריפט פרוצדורלי / אימפרטיבי.

לסקריפט (קובץ build.xml, במקרה של Ant) יש כמה יעדים (Targets / Goals) שנקראים לרוב משהו כמו: build, clean, jar ו test – כ\"א הוא תיאור של סדר הפעולות האטומיות (העתקת קבצים, קומפילציה וכו\') הנדרש להשגת מטרה זו. בין ה targets השונים ניתן להגדיר תלות, כך שהפעלת אחד (למשל: אריזה ב jar) – תפעיל גם את התהליך בו היא תלויה (למשל: compile). מנגנון התלויות בין ה targets מאפשר לנו לעשות שימוש חוזר בסקריפט ה compile גם ב targets כמו jar או install.

תכונה שימושית נוספת ב Ant היא הגדרה של משתנים – המאפשרים לשנות במקום אחד פרמטר (כמו path מסוים) – ולהשפיע על כל הסקריפט.

דוגמה ל Ant Task פשוטה

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

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

יש לקמפל את קבצי ה java לקבצי class ולשים אותם בתיקיה זמנית.
מקמפלים ומריצים את הקוד של בדיקות היחידה.
במידה והבדיקות עברו בהצלחה – בונים jar או war.
מנקים את הקבצים הזמניים שנוצרו.

מדוע לכתוב את ה Script הזה כל פעם מחדש? האם האנושות לא יכולה לחסוך לעצמה את \"המצאת גלגל ה build\" – בכל פעם מחדש?

מייבן מספקת Archetypes (מעין templates) של פרויקטים נפוצים: פרויקט jar, פרויקט ווב, פרויקט ווב של backbone וכו\'. שימוש ב Archetypes חוסכת הן עבודת קידוד והן עבודת תכנון – כיצד להרכיב את פרויקט ה build, באיזה מבנות תיקיות להשתמש וכו\'.

ה Archetypes לא קיימים באוויר (ואין להם חופש פעולה מלא) – הם מצייתים למודל מובנה של מייבן שמתאר תהליך של build. המודל מחלק את תהליך ה build לכ 20 שלבים סטנדרטיים, וכל archetype מגדיר את עצמו בתוך המודל הגנרי של מייבן.

כל פעולות ה build עצמן (יצירת תיקיות, העתקת קבצים, הפעלת קומפיילר וכו\') מגיעות כ Plugins – וניתנים להחלפה. מייבן מספקת את המודל, קובץ הקונפיגורציה של מייבן מתאר את ה Strategy (ה design pattern), וה plugins עושים את העבודה.

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

מרגע שמבנה הפרויקט ידוע וקבוע – ניתן לספק הוראות הרבה יותר high level מאשר ב Ant: \"בצע קומפילציה\" במקום \"צור תיקיה זמנית x\", \"הפעל את javac עם target של x\", \"העבר קבצים מתיקיה x לתיקיה y\", וכו\'.

פרויקט פשוט במייבן

יצירת פרויקט של מייבן מתוך Archetype (להזכיר: סוג של template של פרוייקט) יכולה להיעשות בעזרת command line, אבל בפועל כיום יש אינטגרציה לכל IDE נפוץ – כך שאין כ\"כ צורך להכיר את ה command line. הבה נבחן את מבנה התיקיות של הפרויקט הגנרי של מייבן:

כמה הסברים:

תיקיית src נועדה לקוד, ותיקיית target לתוצרי קומפילציה (קבצי class., למשל).
תיקיית ה src/main נועדה לקוד שמיועד לדילוור, ותחתיה יש תיקיה לכל שפת תכנות. יכולה להיות, למשל, תיקיה ל java, ל scala ול javaScript. ספריית ה src/test נועדה לקוד של בדיקות יחידה / אינטגרציה. בפנים יש תיקיות של ה java packages – כמו בכל פרויקט java רגיל.
תיקיית src/main/resources/ נועדה לקבצים אחרים של הפרויקט שאינם קוד, למשל קבצי הקונפיגורציה של Spring Framework.
את תיקיית ה target מחלקים לתוצרים של קוד שהולך לדילוור (classes) ותיקיית הקוד שלא הולך לדלוור (test-classes).
pom.xml הוא קובץ הקונפיגורציה של מייבן, המקבילה של build.xml של Ant.

קובץ ה pom.xml (קיצור של Project Object Model) הוא קובץ XML, דקלרטיבי, שמגדיר את ה Strategy של תהליך ה build שלנו.

הנה דוגמה ל pom.xml מינימלי ביותר:

הסברים:

כל פרויקט מייבן מוגדר באופן ייחודי ע\"י שלושה פרמטרים:

groupId – סוג של namespace שאמור להיות globally unique. בד\"כ כתובת אתר האינטרנט של החברה שלכם בסדר הפוך של tokens.
artifactId – שם ייחודי, פנימי אצלכם, לפרויקט.
מספר גרסה, בפורמט: ..-, כאשר ה qualifier הוא טקסט [ב].
ל qualifier בשם \"SNAPSHOT\" (אותיות גדולות) – יש משמעות מיוחדת, והיא משמשת לציין גרסה שעדיין בפיתוח שמשתנה כל הזמן. במקום לבדוק אם הגרסה התעדכנה בעזרת מספר הגרסה, הוא יבדוק את התאריך, כך שהמפתח לא נדרש לשנות כל רגע מספר גרסה בכדי שחבריו יקבלו גרסה עדכנית בכל build.

הגדרה של תלות בספריה JUnit. כ default קיבלנו את גרסה 3.8.1 – אך אנו יכולים להחליט שאנו רוצים לעבוד עם JUnit 4. שימו לב שגם ספרייה זו מזוהה בעזרת השילוש הקדוש: קבוצה, artifact וגרסה. זהו הזיהוי הייחודי ב repositories של מייבן.
זוהי תצוגת ה IDE למייבן של IntelliJ – בכל IDE יהיה משהו שנראה אחרת. אנו רואים את השלבים המרכזיים בתהליך הבילד כפי שהוגדר.

שנייה! לא הגדרנו כמעט כלום בקובץ ה pom.xml שלנו. מאיפה מגיעות ההגדרות הללו?

אם אנסה להריץ אחד השלבים, למשל test, מייבן יוריד לי ערמה של maven plugins הנדרשים להרצה – ויריץ קומפילציה ובדיקות בהצלחה. כיצד הוא יודע מה לעשות?

פרויקטים של מייבן מוגדרים בדלתאות (deltas): ההגדרה הבסיסית נמצאת ב super pom.xml – קובץ שנמצא בתוך אחד ה jars של מייבן עצמו (ואפשר, אך לא כדאי, לשנות אותו). הגדרות נוספות מגיעות מה settings של מייבן או מחושבות בזמן ריצה (כמו \"תיקיה נוכחית\"), אח\"כ מ pom.xml אבות של ה pom.xml המדובר (בפרויקט גדול – מרכיבים קבצי pom.xml בהיררכיה), ואז לבסוף, מה pom.xml הנוכחי – שבמקרה שלנו הוא כמעט ריק.

במקרה שלנו אין pom.xml אב, והקובץ שלנו כמעט ריק – אז ההתנהגות בה אנו חוזים מגיע בעיקר מה super pom.xml ומה settings. הרכבה של כל השכבות המוגדרות בקובצי ה pom.xml הרלוונטיים השונים נקראת effective pom.xml, ניתן לראות אותה ב eclipse בתוך ה IDE. ב Intellij אני לא מכיר דרך לראות אותה, ולכן אני מריץ את ה command line הבא:

mvn help:effective-pom -Doutput=effective-pom.xml

דוגמה ל Effective-pom.xml מינימליסטי

הנה ה effective-pom.xml שנוצר לנו. בואו נבחן אותו. שימו לב שכמה חלקים הם collapsed:

ה dependencies היחידים הם אלו שהגיעו מה pom.xml שלנו – תלות ב Junit 3.8.1
ה repositories וה pluginRepositories כרגע הם ה central repository של מייבן, קרי http://repo.maven.apache.org/maven2.
ה repositories מכילים הרבה (מאוד) פרויקטי open source ו/או maven plugins – אותם מייבן ידע להוריד אלינו למחשב ע\"פ הצורך. כאשר עובדים ב IDE וזקוקים לאיזו ספרייה – פשוט מוסיפים אותה כתלות ב pom.xml ומייבן יביא אותה לבד ב build הבא. אם הספרייה שציינתם תלויה בספריות אחרות – מייבן תביא גם אותן. כמו כן – אותה הורדה תתרחש גם אצל מפתחים אחרים בצוות. זה היופי של ניהול התלויות של מייבן.
כאן ניתן לראות את מבנה הספריות של הפרויקט, כפי שתיארנו אותו קודם (כ full paths). מייבן משתמש ב super pom.xml במשתני-סביבה בכדי להגדיר את הנתיבים, וה effective-pom.xml כבר מכניס בהם את הערכים.
כפי שציינו, plugins הם אלו שעושים את כל עבודת ה build בפועל. ניתן לראות בדוגמה למעלה שני core plugins שמתארים את ההתנהגות של שלבי ה clean וה install של מייבן.
Plugins אחרים שלא נכנסו לצילום המסך הם:

maven-resources-plugin
maven-surefire-plugin – הפלאג-אין של מייבן להרצת בדיקות-יחידה. אין לי מושג למה הוא קיבל \"שם מגניב\", ורבים אחרים – לא.
maven-compiler-plugin
maven-jar-plugin – כפי שהשם מצביע, הוא פשוט אורז קובץ jar.
maven-deploy-plugin
maven-site-plugin – הפלאג-אין של מייבן ליצירת תיעוד לפרויקט

בהמשך, נרחיב עוד על Plugins והקונפיגורציה שלהם.

Build Lifecycles

המודל של מייבן מגדיר 3 פעולות שמייבן יודע לעשות:

לבנות תוכנה (ואולי גם להתקין אותה) – מה שנקרא ה default lifecycle
לנקות שיירים (קבצים זמניים וכו\') מבנייה קודמת (בעקרון: ספריית ה target) – מה שנקרא clean lifecycle
בניית תיעוד לתוכנה (יצירת מערכת דפי html) – מה שנקרא site lifecycle, כלומר אתר אינטרנט (סטטי) הכולל את התיעוד של התוכנה.

כל אחד ממחזורים אלו בנוי מרשימה מוגדרת-מראש של שלבים (phases).
המשתמש יכול לבחור לבצע רק חלק מהמחזור שהוגדר ע\"י מייבן. למשל: להפעיל את ה default lifecycle רק עד שלב הקומפילציה. שלבים מוקדמים יותר במחזור, כגון validation של פרויקט המייבן או יצירת ה resources הנדרשים – יופעלו, אבל השלבים המאוחרים יותר (כמו בדיקות או התקנה) – לא יופעלו.

שלבי ה Lifecycle השונים של מייבן, כאשר השלבים החשובים / היותר שימושיים – מוגדשים

כאשר אנו מפעילים את מייבן בכדי לנקות שיירים של בנייה קודמת, אנו מקלידים ב command line:

mvn clean

מה שיגרום למייבן לזהות שזהו שלב (phase) של ה clean lifecycle ולהפעיל את ה livecycle הזה עד שלב ה clean. שלב ה pre-clean יתבצע, אך שלב ה post-clean – לא יתבצע. כמובן ששלבים רבים במחזורי הפעילות של מייבן הם שלבים ריקים – אלא אם נגדיר בהם משהו.

בכדי להפעיל את כל ה clean lifecycle יש להקליד mvn post-clean. בד\"כ אנו מסתפקים ב clean, הקצר יותר להקלדה.

האם איי פעם תהיתם מדוע אתם מקלידים (הפקודה הכי נפוצה אולי) \"mvn clean install\",
אבל לא \"maven clean compile install\", או משהו דומה?

התשובה עכשיו ברורה: clean נדרש מכיוון שהוא שלב ב lifecycle שונה מה default lifecycle. כאשר מפעילים את mvn install – הוא יבצע את כל 20 ומשהו השלבים מ validate ועוד install. הוא רק לא יעשה deploy.

הנה כמה מלים על מה שמייבן עושה בשלבים השונים של ה default lifecycle:

validate – מוודא שפרויקט המייבן תקין, למשל: ולידציה של ה pom.xml, שכל המשתנים שבשימוש – מוגדרים, וכו\'.
generate sources / resources – שלבים שהוגדרו בכדי לשמש לשלבי pre-proccesing להתרחש (במידה ואתם משתמשים בכלים שמג\'נרטים קוד או resources).
compile – קומפילציה של קוד תחת ספריית main (לא כולל קוד של בדיקות)
process-classes – שלבי post processing על קבצי ה class. שקומפלו, למשל \"אריגה\" של AspectJ על קבצים שכבר קומפלו (יש אפשרות כזו).
test-compile – מקמפל רק את קבצי הבדיקות. אם אתם לא מתכוונים להריץ בדיקות – חבל על הזמן לקמפל את קוד הבדיקות, לא?
package – אריזת הקוד ל jar, war, ear וכו\'.
integration-tests – שלב מיוחד של הרצת בדיקות על מערכת \"חיה\". מתקין את ה deployable שכרגע נארז על מערכת בדיקות, ומריץ מולה בדיקות אינטגרציה / מערכת (איך שאתם קוראים להן). ה plugin של מייבן שמריץ בדיקות אינטגרציה נקרא \"failsafe\".
verify – שלב בו ניתן לבצע בדיקות נוספות על ה package הארוז – לוודא שהוא תקין.
install – השם של השלב הזה הוא מעט מבלבל: ההתקנה היא של ה deployable ל local maven repository – ולא לשרת ה production כמו שאולי זה נשמע. ה local repository הוא צד של מייבן שעדיין לא נגענו בו בפוסט זה. נאמר כרגע שזו איזה תיקייה של מייבן בה הוא שומר deployables, pugins ו ספריות שנדרשות בגלל התלויות.
deploy – עושה את מה שאפשר לחשוב: מתקין את ה deployable על שרתי ה production.

סיכום

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

מהם בדיוק ה repositories?
כיצד ה plugins משתמשים בשלבים השונים שמייבן מגדיר? מהם ה goals?
ואולי הכי פרקטי: כיצד משנים את הגדרות ה pom.xml ורותמים את מייבן לצרכים הייחודיים של הפרויקט שלנו ?

אני מקווה לכסות לפחות כמה מנושאים אלו בפוסט המשך.

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

—

[א] Groovy היא (מלבד ה nested classes) בעצם superset של ג\'אווה. לכאורה, מאוד קל למתכת ג\'אווה לעבור אליה: לשנות את סיומות הקבצים ל groovy. ולהימנע משימוש ב nested classes. בפועל, כמעט כל דוגמאות הקוד של gradle משתמשים בתחביר מתקדם של שפת Groovy – שיהיה זר ומוזר למתכנת ג\'אווה שלא ישקיע זמן ללמוד אותו ואת הדקויות שלו.

[ב] בגלל שמייבן מתייחס ל qualifier כטקסט, יש פה pitfall מסוים:
גירסה:

0.9.9-CR10

תחשב כמוקדמת יותר מגירסה:

0.9.9-CR2

(בגלל שהתו \"1\" נמוך בערך ה ASCII שלו מ \"2\").

לא טוב היותה לבדה: על אינטגרציה של מערכות (מבוא)

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

זה לא בגלל שבוני המערכת לא יודעים לכתוב כזה פיצ׳ר. הרבה פעמים זה גם לא עניין של מאמץ או זמן פיתוח – אלא עניינים הקשורים למשתמשים או למערכת האחרת:

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

אפילו אם תספקו למשתמש אותן סט יכולות באיכות מעולה – זה לא ישתווה לשירות אליו המשתמש רגיל.

נהוג לומר:

!If you can't beat them – join them

ואם אתם לא יכולים להחליף מערכת אחרת – כדאי שתתחברו אליה.

צורות התחברות למערכת אחרת

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

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

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

רמה 2: שליפת נתונים חד פעמית. לדוגמה: קבלת אנשי הקשר מ LinkedIn.

רמה 3: שליפת נתונים אונליין. לדוגמה: קבלת אנשי הקשר המעודכנים, בכל רגע, מ LinkedIn.

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

רמה 5: סיפוק נתונים אונליין. לדוגמה: LinkedIn מציג גם את אנשי הקשר מהמערכת שלי, כאילו הם שמורים אצלם במערכת.

מספרי הרמות באים לתת תחושה גסה (אך לא מדויקת) של הסיבוכיות של כל סוג אינטגרציה. זה לא (חס וחלילה) ש"רמה 4" היא טובה יותר מ"רמה 1.1". הרבה יותר שימושי לי להזניק את Waze עם יעד בעל משמעות, מאשר לשנות את שם הרחוב אליו אני רוצה להגיע לשם "רח' תגיע-לכאן".ניתן להבדיל בין רמה 1 שהיא אינטגרציה של invocation, מול שאר הרמות שהן אינטגרציות של נתונים (data integration). רמה 1 היא מוגבלת בשימושיות שלה (ופשוטה מאוד ליישום) אך כל שאר הרמות יכולות להיות שימושיות באותה מידה – תלוי בתסריט העסקי הנתון.

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

אינטגרציה של הפעלה (Invocation)

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

אפליקציית Rest שלה כפתור שמזניק את Waze. שימושי.

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

ללמוד את הפורמט/פרוטוקול להעברת context (למשל: כתובת לניווט) לאפליקציית היעד.
(צעד רשות): לוודא שאכן האפליקציה השנייה זמינה (כי ניסיון להפעיל אותה מבלי שהיא זמינה – עלול להראות לא טוב).

דפוס חוזר של הפעלה של אפליקציה כזו הוא decoupling by intent:

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

דוגמה אחת ל decoupling by intent יכולה להיות מערכת ההפעלה "חלונות", בה ניתן "לקשור" אפליקציה (למשל Word) לסיומת של קובץ (למשל docx.*) ואז הפעלה של הקובץ (פקודת start ב command line) תפתח את הקובץ באפליקציה הקשורה. אני יכול גם להתקין Libre Office ואז קבצי ה docx.* יפתחו בעזרת אפליקציה בשם Writer.

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

אספר שבמערכות שאנו עובדים איתן ב SAP יש יכולת לנהל סט חוקים מורכב המשפיעים על אלגוריתם ההחלטה – אולם רק לקוחות מעטים באמת משתמשים ביכולות המתקדמות האלה. המערכת המורכבת היא לא רק משוכללת, אלא גם קשה להבנה ולשימוש. רוב הלקוחות משתמשים בחוקים פשוטים הדומים לאלו של מערכת ההפעלה "חלונות" (מין רשימה עם priorities, ע"פ האפליקציה הראשונה שזמינה).
פריט המידע שמועבר בין המערכת המקומית לאפליקציה המרוחקת עשוי, בתסריטים של Enterprise, להיות זיהוי של אובייקט עסקי – שאותו האפליקציה המרוחקת תוכל לערוך / לבצע עליו פעולות (על בסיס גישה משותפת של האפליקציות לבסיס הנתונים, או סוג של RESTful APIs).

מנגנון של decoupling המתבסס על כוונה (intent) מאפשר:

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

בתסריטים העסקיים שאני מכיר – decoupling by intent עשוי להיות שימושי ורב-עוצמה.

אינטגרציה של נתונים (data integration) – מושגים בסיסיים

נוהגים לחלק אינטגרציה של נתונים ל 4 סגנונות עיקריים [א]:

אינטגרציה ע"י העברת נתונים בקובץ.
אינטגרציה ע"י שיתוף בסיס נתונים.
אינטגרציה ע"י קריאה מרוחקת (RPC).
אינטגרציה ע"י שליחת הודעת (messaging / events-based).

כמו כן, פעולות האינטגרציה מתרכזות לרוב בסכמות הבאות:

שכפול נתונים בין מערכות (Replication) או סנכרון נתונים בין מערכות. סנכרון זה מצב יותר בריא, בד"כ 🙂
קיבוץ (Aggregation) נתונים ממקורות שונים למקום אחד – עבור דו"ח או Dashboard (לוח בקרה).
הרכבה של תהליכים "עסקיים", הרכבת כמה אפליקציות פשוטות לאפליקציה מרוכבת ומועילה יותר (Business Processes). אני מדבר ב"שפה עסקית" אך זהו גם הסיפור של אפליקציית Rest שפותחת את WAZE שפותחת את גוגל (לקבל עוד נתונים בעקבות פרסומת בדרך).
סיפוק שירותים נקודתיים, כדי למנוע שכפול נתונים או פונקציונליות – למשל שירות של מילון (Dictionary) או שירות קבלת כתובת דואר של עובד. שירותים אלו יכולים לשמש UI (כלומר: משתמש קצה) או מערכות אוטומטיות.

כן, אבל…

אם נדמה לנו שמאמץ האינטגרציה נגמר בהעברת נתונים או הזנקה של אפליקציה – אנו מעט אופטימיים.

אינטגרציות כוללות גם לא מעט קשיים בדרך:

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

ואחרי שכל האינטגרציה "הסתיימה":

שינויים ב API / חוזה (contract) של המערכת המרוחקת.

הבהרה: לא כל אינטגרציה באמת מחייבת פתרון / התעסקות עם כל הנושאים הנ"ל, אך זו הרשימה של האתגרים השכיחים.אינטגרציה היא לא דבר חדש ויש Framework / מערכות לאינטגרציה, כדוגמת TIBCO (חבילת מוצרים גדולה), BizTalk של מייקרוסופט או Apache Camel (הקטן והחביב). למה לא פשוט להשתמש בהן – ולא "לשבור את הראש"?
ספריות / מערכות אלו הן כלי עזר לאינטגרציה – אך לא "פתרונות קסם" ש"מסירים מהדרך" את הבעיות הנ"ל. למשל: במקום לכתוב 100 שורות קוד בכדי להאזין לשינויים בתיקיית קבצים, לפרסר את הקובץ ולשלוח את המידע החדש שנוסף כ JMS message – תוכלו אולי לכתוב בעזרת הספריה 4-5 שורות דקלרטיביות או ב DSL שיעשו אותה עבודה. בכל זאת, לא תמצאו שם פתרונות אוטומטיים לבעיות אבטחה, הבדלי מהירות או זמינות בין המערכות וכו'. בטח שלא לבעיות של תקשורת בין בני-אדם 🙂
יהיה עליכם להבין את האתגרים האפשריים, לחשוב, לנתח – ולפתור.

אפרופו יש קטגוריה של פתרונות בשם ESB (קיצור של Enterprise Service Bus) – שמופיעים כמודול ברוב פתרונות ה Middleware של החברות הגדולות (IBM, Oracle, TIBCO וכו') או בגרסאות חופשיות (למשל Apache Mule).
אלו בד"כ פתרונות יותר כבדים מ"מערכות האינטגרציה" אותן הזכרתי, הם קשורים בצורה הדוקה בד"כ לארכיטקטורת SOA שמרנית, ונחשבים כלא כ"כ מוצלחים (כקונספט – אני לא מדבר על המימוש).
אני לא מנסה לדבר עליהם, ולא רוצה שתבינו בטעות שכדי לבצע אינטגרציה – זקוקים לתשתית כלשהי. כלים שכאלו כדאי להכניס לשימוש כדי לחסוך זמן (במיוחד כשיש הרבה עבודה) – לא כדי "לפתור את הבעיה".

תהליך אינטגרציה: ממה להיזהר? וכיצד?

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

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

אפשור גישה ברמת הרשת
אם שתי המערכות המעבירות בניהן מידע נמצאות באותה רשת מקומית – אז אין בעיה.
במקרים אחרים הן נמצאות ברשתות שונות, שבניהן מותקנים רכיבי רשת מגבילים (חומות אש, IPS או אמצעי הגנה אחרים).
לפעמים מערכת אחת יושבת בענן, והשנייה ברשת הפנימית של ארגון (ואז יש שאלה איך ניגשים מהענן לרשת הפנימית).
לפעמים משתפים מידע בין 2 רשתות פנימיות של ארגונים שונים, שחוץ מחיבור זה – זרים זה לזה.

ענייני רשת – יש לפתור נקודתית למצב הנתון.
יש כלל מנחה שאומר שאת היוזמה לתקשורת עושים מהאזור המאובטח יותר – לאזור המאובטח פחות. כך יתר קל להתמודד עם אמצעי ההגנה השונים. למשל: מן הרשת הפנימית של הארגון – לענן, או מן הרשת הפנימית של ה Data Center לרשת הארגונית ה"רגילה".
במקרים בהם אין יכולת לתקשורת ישירה (בגלל מורכבות של רשתות ה LAN בארגון) – מציבים agent או broker בדרך שיאפשר להעביר הודעות / נתונים.

עבודה בפורמטים שונים
בעוד מערכת אחת עוטפת את המידע ב XML בצורה אחת – והשנייה ב XML בצורה אחרת. עצם השימוש "המשותף" ב XML לא מוסיף לאינטגרציה כמעט דבר, אם הפורמטים שונים. גם בתוך ה XML (או JSON, CSV וכו'):מערכת אחת מתארת תאריך בפורמט ארוך – והשנייה בפורמט קצר, אחת כתובת בשדה אחד והשנייה במספר שדות שונים, וכו'.
עבור קריאות מרוחקות (RPC), ההבדלים יכולים להיות גדולים יותר: DCOM מול CORBA או RMI מול REST API – צורת התקשורת שונה, ולא רק פורמט אותו ניתן להמיר.

יש גם נושא של Data Integrity: מערכת אחת מוכנה לקבל רשומה כאשר שדה x חסר (ערך ריק) – ומערכת שניה לא מוכנה לקבל זאת. אולי תאימות בין הנתונים: מערכת אחת בודקת את ערכי השדות שיתאימו לכלל מסוים – והשנייה לא.

את המידע ממירים בעזרת Adapters (או Transformers/Normalizars במערכת מורכבת יותר) – בכדי לתאם בין הפורמטים / פרוטוקולים. לפעמים עושים תהליך נוסף של Data Quality – תיקון הנתונים בכדי לעמוד ב"סטנדרטים" של אחד הצדדים (שלמות, דיוק וכו').

עניין של פורמטים הוא בד"כ לא "נושא מורכב" (זו קרקע מצוינת לכיסוי עם Unit Tests) – אך זו עבודה. בד"כ ככל שהמידע הוא Human Friendly – ההמרה תהיה קלה יותר. המרה של מידע בינארי, נוטה להיות מורכבת יותר.

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

כאשר אנו רוצים לשלוף נתונים ממערכת Legacy שלא התאימה את עצמה ל export של המידע לו אנו זקוקים – משימת האינטגרציה יכולה להיות קשה. תת-תחום, מוכר יחסית, של נושא זה הוא העולם של Web Scrapping– שליפת נתונים ממערכות ע"י פענוח ה HTML שהן מייצרות (ולא תמיד בהסכמתן). משימות של Scraping בדרך כלל יותר נוח לעשות בשפות דינאמיות עשירות בספריות לטיפול בטקסט כמו פייטון או רובי, אם כי יש מגוון רחב של ספריות. אפשרויות אחרות הן "דיג" של נתונים מתוך לוגים או קבצי נתונים שהמערכת מספקת – אך תוכננו לצורך אחר.

אימות זהות ואבטחה
בעולם הווב / Social יש היום את OAuth שמקל על המשימה – לשלוף נתונים בצורה מאובטחת ממערכת מרוחקת. בעולם ה Enterprise התמיכה ב OAuth היא עדיין מועטה.
כאשר משתמש מזניק (invocation) אפליקציה אחרת – נרצה לחסוך ממנו הקשה נוספת של משתמש/ססמה, בעזרת SSO. כנ"ל לגבי שליפת / עדכון נתונים. בהרכבה של תסריטים עסקיים מורכבים, ייתכן והמשתמש יפעיל כמה אפליקציות שונות בכמה דקות. הקלה של ססמה כל פעם – היא שוחקת ומכבידה.

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

סנכרון ו concurrency

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

הבדלי מהירות / קיבולת בין המערכות

נושא זה הוא מעט טריקי, ולעתים מפספסים אותו עד שלב מאוחר. כאשר אנו צורכים שירות/מידע ממערכת אחר יש להתייחס למצב בו המערכת לא זמינה. האם הקוד שלנו ידע להתמודד זה במצב סבירה או שעוד ועוד threads ילכדו ב timeout על קריאה למערכת המרוחקת?
להבהיר: כאשר כל ה threads שלנו תקועים – לא נותרים threads ב Pool לפעולות אחרות, ואז ייתכן שגם המערכת שלנו – נתקעת ולא מגיבה.כלומר: אי-זמינות של מערכות הוא מדבק, ויש לבנות מנגנונים (נקראים Circuit Breakers) למניעת הידבקות זו.
Circuit Breakers יכולים להופיע כמנגנונים האוכפים timeout קצר בניסיון לקריאה ממערכת מרוחקת.
יש כאלו שיזהו רצף של תקלות וימנעו ניסיונות תקשורת – עד אשר תהיה התערבות ידנית / מנגנון שמזהה התאוששות יפעל.

Circuit Breaker מתוך הפוסט של מרטין פאוולר בנושא.

וריאציה אחרת היא בהבדלים במהירות או Scalability בין המערכות:

נניח שהמערכת המקומית מסוגלת לטפל באלפי בקשות בשנייה (tps) אך המערכת המרוחקת – לא ביותר מ 50 קריאות בשנייה. ברוב המקרים זה מספיק – כי רק במקרים מאוד מסוימים אנו פונים למערכת המרוחקת. מצד שני, פעם בכמה זמן יכול להיות peak בו אנו פונים למערכת המרוחקת 100 פעמים בשנייה – גורמים לה לקרוס, ואז אם אין לנו מנגנון הגנה, אנו יכולים לקרוס בהמשך בעצמנו. הכל בגלל אינטגרציה קטנה ושולית.מנגנון הגנה אפשרי הוא ליצור (מטאפורה:) סוג של צינור מצר, בעצם זה סוג של counting lock שלא מאפשר למערכת שלנו לבצע יותר מ x קריאות למערכת המרוחקת בו-זמנית. אנו מגנים עליה – כי זה אינטרס שלנו שהיא לא תקרוס. מנגנון כזה נקרא (Throttling (controller. כמובן שהמערכת המרוחקת יכולה לקרוס מסיבות אחרות – וזה לא תחליף ל Circuit Breaker בסיסי יותר.

שינויים ב API / חוזה (contract) של המערכת המרוחקת

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

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

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

סגנונות אינטגרציה וכיצד הם מתמודדים עם האתגרים השונים

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

אינטגרציה ע"י העברת נתונים בקובץ

אינטגרציה זו היא בסגנון export של נתונים במערכת ב' ואז ביצוע import של הנתונים אל המערכת שלנו.

יתרונות:

"מדלגת" על מגבלות של רשת או הרשאות. ה export/import וה transport נעשים עם הרשאות של משתמשים ספציפיים.
פשוט למימוש

חסרונות:

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

אינטגרציה ע"י שיתוף בסיס נתונים

יתרונות:

קל למימוש
יעיל מבחינת ביצועים (גישה ל raw data)
Consistency (יחסי) של הנתונים

חסרונות:

אין הכמסה. מערכת אחת נוגעת במבנה נתונים של מערכת אחרת. ניתן לראות זאת כממשק מאוד מאוד רחב בין המערכות – וזו הסיבה העיקרית שגישה זו היא הכי-פחות מועדפת עלי באופן אישי, מכל הסגנונות. שינויי סכמה משפיעים מיידית על 2 המערכות.
גישה ישירה לבסיס הנתונים עוקפת Business Logic ואימות נתונים שבא איתה, Caches של ORM או שכבות עליונות וכו'.
בסיסי נתונים (רלציוניים בעיקר) הם מאותגרים scalability והוספת מערכת נוספת שעובדת על אותו בסיס נתונים יכולה להיות מגבילה / לדרוש שדרוג יקר של החומרה.

אינטגרציה ע"י קריאה מרוחקת (RPC)
RPC הוא קיצור של Remote Procedure Call (שם שמקורו היסטורי) והכוונה היא לכל הטכנולוגיות של הפעלת פונקציות מרחוק: REST, RMI, XML-RPC, אולי RPC ברמת מערכת ההפעלה ועוד.

יתרונות:

הכמסה בין המערכות
ממשק מוגדר היטב
online

חסרונות:

תלות חזקה בין המערכות (ממשק + ידע על מיקום/כתובת המערכת המרוחקת)
תקשורת סינכרונית בלבד

אינטגרציה ע"י שליחת הודעת (messaging / events-based).
שליחת הודעות נעשית בד"כ דרך מנגנון לשליחת הודעות ייעודי, מה שנקרא MOM (קיצור של Message Oriented Middleware). מערכות נפוצות שבשימוש הן Apache ActiveMQ, RabbitMQ, רדיס (Redis) ומנגנון ה Pub-Sub שלו (עליו כתבתי בפוסט בעבר), Apache Kafka (ל Scale גבוה) או מימושים שונים של מנועי JEE/חברות התוכנה הגדולות.

יתרונות:

גמישות רבה לאינטגרציות מורכבות
פוטנציאל Scalability נהדר (בכמות הנתונים)
אפשרות לאסינכרוניות ו reliable messaging (אולי תכונות חשובות, לא דווקא יתרונות)

חסרונות:

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

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

יש גם מרחב גדול של מימושים באמצע מבוסס REST/HTTP/JS – שזה סוג של RPC, אבל עם טכנולוגיות ווב מודרניות ופשוטות (וקצת פחות "RPC by the book")

סיכום

שוב תכננתי פוסט קצר….

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

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

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

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

אולי הדרישה לניהול מרחוק והדרישה ל"אלסטיות" של המערכות מעודדת יותר ארכיטקטורה מונחית שירותים / Micro-services? – מה שהופך את האינטגרציה לקלה יותר. לא יודע.

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

—-

[א] המקור המוקדם ביותר שמזכיר חלוקה זו, שאני מכיר, הוא הספר Enterprise Integration Patterns, אולם נתקלתי בחלוקה זו שוב ושוב ממקורות שונים.