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

וכאן הדברים מתחילים להיות מפותלים..

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

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

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

ניקח סתם פרויקט דמיוני: חברת חבצלת מקימה אתר מסחרי גדול לקניון שוקי. רועי, איש ה-IT של חברת חבצלת מקבל יעוץ משמעון שהוא צריך לרכוש 10 שרתים פיזיים, סטורג' אימתני ו-Windows Server 2012 עם SQL Server Enterprise. במבט ראשון יהיו כאלו שיחשבו שאולי יש הגיון בהמלצות של שמעון, אבל שמעון לא יודע שהאתר יכתב ברובו ב-ruby, וחלק ב-Python. במחיר שחברת חבצלת תשלם רק על הרשיונות, ברזלים וסטורג' (עוד לא דיברנו על הרוחב פס) אני יכול להרים לחברת חבצלת את כל התשתית בענן כלשהו על מערכות לינוקס עם גידול אוטומטי, עם קונטיינטיזציה (אם צריך), וגם עם חברת חבצלת תיקח אותי ל-3 שנים הקרובות לעבודת ריטיינר חודשית על אותו אתר – היא עדיין לא תוציא אפילו שליש ממה ששמעון יעץ לרועי. אם רועי רוצה רק Windows אז אפשר לבצע את אותה עבודה רק מבלי לקנות את הברזלים, הסטורג' וכו' ואפשר להשתמש בשרותים של ספק הענן ושוב – חסכון כספי ענק לחברת חבצלת.

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

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

[stextbox id="info" caption="גילוי נאות / תודות"]מכשירי ה-Raspberry Pi-3 ניתנו לי ע"י SuSE ישראל[/stextbox]

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

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

כשזה מגיע לפיתוח, בין אם מדובר בפיתוח Low Level או בפיתוח בשפות אחרות, רוב הזמן המפתחים יכתבו את הקוד על ה-PC שלהם וישתמש ב-Cross Compile עם הקומפיילר החביב עליהם כדי ליצור קבצים בינאריים לציוד מבוסס ARM. אחרי הכל, לקמפל דברים על ARM זה לא כיף (זה איטי … אלא אם יש עליך איזה 500$ למערכת Jetson TX2 של nVidia ששם זה עובד יפה). הבעיה מתחילה בכל מה שקשור לבדיקות הרצה "על הברזל". פתרון של אמולציה זה לא רע (במיוחד אם האפליקציה לאנדרואיד וכתובה Native ב- ++C), אבל לפעמים צריך להריץ את האפליקציה "על הברזל" – במיוחד אם האפליקציה מתקשרת דרך ה-GPIO של הלוח (או דרך USB, יציאות סריאליות בלוח, JTAG וכו') – במקרים כאלו אמולציה לא תעזור ולחבר PC, להריץ אמולציה, למפות כתובות לתוך האמולציה בשביל להריץ את האפליקציה – זה סיבוך עם פוטנציאל להרבה נקודות כשל.

בקטע הזה – קונטיינרים על ARM יכולים להיות פתרון מעולה:

• האפליקציות עצמם יכולות לרוץ אפליקציה פר קונטיינר על ה-Pi-3 ועוד קונטיינר יכול לשמש כ-DB קטן לדוגמא (SQLite) או אפליקציה קטנה שמקבלת תוצאות טסטים מהקונטיינר הראשון ואפשר להרחיב ולהרים קונטיינר נוסף שמקבל סדרות טסטים להריץ משרת כלשהו, כך שקונטיינר A (שמריץ את האפליקציה העיקרית) מתחבר לקונטיינר C (שמקבל משרת חיצוני את הטסטים שיש צורך להריץ), מבצע את הפעולות ומדווח את התוצאות לקונטיינר B (שמריץ DB או אפליקציה קטנה שאוספת לוגים ויוצרת סטטיסטיקות קטנות). שלושת הקונטיינרים רצים על מכשיר Pi-3 יחיד שמשמש בעצם כ-Node ומנוהל ע"י Master עם Kubernetes או OpenShift (שהם רצים על שרת רגיל).
• לא צריך לכתוב גרסאות שונות של האפליקציה מחדש ל-eMMC, מערכת ה-Scheduling של הקונטיינר תעיף את הקונטיינר עם הגירסה הישנה ותפעיל על אותו מכשיר קונטיינר חדש. לא צריך Reboot, לא צריך להגדיר מחדש כלום. המפתח מוציא 20 גרסאות ביום עם תיקונים שונים? זמן ההקמה לבדיקה מתקצר בעשרות אחוזים.
• לא חשוב מה המעבד ARM שיש, כל עוד יש לו גירסת לינוקס וחיבור רשת (ולא מדובר ב-MCU שעליו מבחינת חוסר משאבים לא ניתן להריץ קונטיינרים – כמו במקרים שיש לך כמה קילובייטים בודדים) – ניתן לעשות את הדברים הללו.
• הקץ לאמולציות איטיות 🙂

ביצעתי בימים האחרונים טסט קטן שכולל 3 לוחות Raspberry Pi-3 ששימשו כ-Nodes ומכונת CentOS אחת שהריצה את OpenShift (שבתוכו יש את Kubernetes). מכיוון שהח"מ אינו חברת שמייצרת פתרונות חומרה, הקמתי מערכת שמריצה LAMP (שהתוכן מאוחסן ב-NFS) ו-2 מכונות וירטואליות שמריצות 20 קונטיינרים רזים (שמריצים ab כ"דפדפנים"). זה לא היה טסט לבדיקת ביצועים, אבל במחשבה שניה – כל Pi-3 הצליח להחזיק בערך כמה עשרות חיבורים סימולטניים. הפלתי כל פעם לוח (ניתוק חשמל) מתוך 3 לוחות ה-Pi-3 ולקח בממוצע כ-8 שניות עד שהמערכת זיהתה Node לא פעיל והזיזה את התקשורת ל-Nodes התקינים האחרים.

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