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

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

anan

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

  1. אחד הדברים הבולטים לטובה במסמך הוא התייחסות למחשוב ענן כמו שספקי הענן הציבורי מציגים ומוכרים ולא כל מיני "ענני צעצוע" שכל מיני חברות בארץ מציעות/מוכרות. התנאים עצמם ישר פוסלים את אותם "ענני צעצוע" בכך שיש דרישות שלספקים בארץ אין אותם, הן מבחינת הכנסות והן מבחינת Availability Zones (שמשום מה במסמך הם נקראים "Domains"), מיקומים גיאוגרפים וכו' ואף אחד מהספקים בארץ גם לא מציע 500+ שרותים שונים באותו ענן.
  2. אני שמח לראות שבמשרד האוצר מחפשים שהזוכה יקים בעצם Region אחד ובתוכו Availability Zones אולם לעניות דעתי, חשוב שבמשרד יתעקשו על כך שה-AZ יהיו במרחק רב אחד מהשני.
  3. נקודה שלדעתי חסרה במסמך וחשוב שתצוין (ושהמשרד יעמוד על כך) – שה-AZ יהיה מחובר בחיבורי תקשורת מספקי אינטרנט שונים ולא מספק יחיד. רק לפני חודשים ספורים אלפי אתרים נותקו מהאינטרנט עקב "תקלת תקשורת" של ספק אינטרנט מרכזי. האם משרד האוצר רוצה לחוות חוויה כזו?
  4. אם המתמודדים הם בעצם ספקי הענן הציבורי, מומלץ לבקש לדעתי במסמכי המכרז כי הספק הזוכה ייבא וישתמש בציוד שלהם ולא בציוד COTS. הציוד של ספקי הענן שונה לחלוטין מציוד שחברות רוכשות החל ברמת המעבדים, זכרונות, לוחות, אחסון, תשתיות תקשורת וכו' ויש סיבה טובה לכך – ביצועים הרבה יותר גבוהים.
  5. בבקשה, בבקשה – בלי Azure Stack. כתבתי כאן מדוע לא.
  6. נקודה נוספת שאולי כדאי שמשרד האוצר יחשוב לגביה – שה-AZ יהיו מחוץ ל-Data Centers של ספקי האינטרנט שונים במיקומים כמו הגליל ובאר שבע לדוגמא. בחירה במקומות כאלו יכולה לייצר באופן ישיר מספר מקומות עבודה ובאופן עקיף לאורך זמן – יותר ויותר חברות שיעבדו במקומות אלו.

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

  • מיקרוסופט – Azure
  • אמזון – AWS
  • גוגל – GCP
  • אורקל – Oracle Cloud
  • IBM Cloud

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

יש משהו אחד שקצת לא מסתדר לי עם המכרז והפרויקט עצמו. כן, זה בהחלט דבר טוב שמשרד האוצר עושה צעדים להקים פה Region, אבל הבעיה הגדולה ביותר קשורה לשיטות העבודה והפיתוח במשרדי הממשלה השונים ושוחחתי בעבר עם לא מעט עובדים במשרדים הממשלתיים על כך: צריך לשנות מקצה לקצה את כל מתודות העבודה. להתחיל לעבוד מול GIT, לשלב CI/CD, אוטומציה, להוריד כמה שיותר את העבודה עם מכונות וירטואליות ולהתחיל לעבוד מול קונטיינרים ומול שרות/פלטפורמה כמו Kubernetes/OpenShift, לעבוד במתודה של Scale Out, להשתמש ב-Object Storage, להתחיל לעבוד במתודות Serverless אולי, ועוד ועוד – וכל אלו הם דברים שונים ממה שהמשרדים משתמשים כיום. אם משרד האוצר הולך לשלם על Region עם מספר AZ ושיטות העבודה ישארו השיטות הישנות, אז ניצול ה-Region יהיה אחוזים בודדים בלבד, ובכך יווצר בזבוז כספים משווע (ומה לעשות, לא מדובר פה בתשלום חד פעמי אלא חודשי), ולכן אני תוהה אם משרד האוצר מוכן כבר עכשיו לתכנן מהלך הדרגתי לעבור למתודות העבודה החדשות.

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

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

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

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

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

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

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

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

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

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

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

בהצלחה.

להתקדם בתחום

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

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

בעבר, החיים היו הרבה יותר פשוטים. אם היית רוצה "להתמקצע" בתחום של מיקרוסופט, אז היית לוקח איזה קורס MCSE (או איך שזה נקרא כיום, סורי, אני לא עוקב אחר שינויי השמות), לומד כלים משלימים של מיקרוסופט כמו SCCM, אקסצ'יינג', אולי PowerShell, ועם זה היית הולך לחפש עבודה. אחרים הלכו לתחומים כמו לינוקס ושלל השרותים שנמצאים בלינוקס, יש כאלו שהיו הולכים ללמוד CCNA בשביל תקשורת מחשבים, ויש כאלו שלמדו קורס כלשהו על סטורג', אחרים למדו VCP בשביל וירטואליזציה. בחברות גדולות היו מחפשים יותר דברים ספציפיים כמו אחד מהנושאים שציינתי לעיל (לדוגמא – איש וירטואליזציה), ובמקומות יותר קטנים היו מצפים שתכיר את כל הנושאים שציינתי על מנת להתקבל למקום העבודה.

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

אז מה אתה יכול לעשות כדי לשפר את סיכוייך למצוא עבודה טובה בעתיד?

יש כמה דברים.

אם אתה רוצה להישאר בתחום ה-IT הקלאסי (לפני כניסת הענן) אז מה שמומלץ לך זה ללמוד את התחומים "השכנים": אתה איש סיסטם מיקרוסופט? תכיר יותר את תחום הסטורג' הרגיל, תכיר יותר נטוורק לעומק (אתה יכול להשתמש בכלי כמו GNS3 לבצע סימולציות), והכי חשוב – להכיר את מערכת ההפעלה ה"מתחרה" לינוקס במובן הטרמינל (לא במובן הגרפי. ברוב המקרים אתה לא תעבוד מול תצוגה גרפית במכונות לינוקס) – מה זה לינוקס, איך הוא בנוי, פקודות לינוקס בסיסיות, כתיבת סקריפטים בסיסיים ב-BASH, הגדרות ציודים שונים, ניתובים, ניהול חבילות תוכנה, ועוד. אם אתה רוצה, יש אתר בשם Linux Academy שמלמד את הדברים (יש מנוי חודשים שעולה 50$ לחודש, שבוע ראשון בחינם). אם אתה יותר טיפוס של ספרים – יש לא מעט ספרים שמלמדים על לינוקס ויש כמובן גם קורסים בבתי הספר המקצועיים השונים שמלמדים לינוקס. לגבי סטורג' ונטוורקינג – אני ממליץ ללמוד לבד.

במקומות גדולים החל לצוץ לו תפקיד חדש לאחרונה (לא באופן רשמי, לפחות ממה שאני יודע) והוא "Cloud Admin" – מה שאתה עושה מקומית, עכשיו בענן, רק שבענן לא יחכה לך איזה סטורג' של Netapp/EMC, אין לך סוויצ'ים, אין לך פיירוול (את זה אפשר להוסיף, כ-Appliance) והכל בעצם נעשה בתוכנה, בין אם דרך ממשק ווב, אבל יותר דרך ממשק CLI וכאן כבר צריך ללמוד איך להגדיר דברים, החל ממכונות VM, נטוורקינג, דיסקים קשיחים וירטואליים ועוד ועוד. בלינק שפירסמתי לעיל יש גם קורסים לכל ספקי הענן הגדולים, כך שאפשר ללמוד שם גם איך להשתמש בענן ואיך לנהל משאבים. העננים הפופולריים ביותר הם של אמזון (AWS) ו-Azure של מיקרוסופט. קצת פחות פופולרי (והרבה יותר טכני) הוא הענן של גוגל, לכן מומלץ ללמוד לפחות את הענן שבו החברה משתמשת ואולי את הענן השני הפופולרי.

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

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

איש ה-Devops טוב צריך לדעת כמה דברים חשובים:

  • הוא צריך להכיר טוב לינוקס, ברמה של כתיבת סקריפטים, הגדרות לינוקס, ניהול חבילות
  • הוא צריך להכיר את עולם הקונטיינרים – החל משימוש ב-Docker כדי לבנות Images, והוא צריך להכיר Kubernetes (או OpenShift או Caas) כדי לבצע אורקסטרציה בין הקונטיינרים השונים שירוצו, שרותים, רשתות, Scaling ועוד.
  • הוא צריך להכיר כלי CI/CD על מנת לאפשר ביצוע Build אוטומטי דרך כלים כמו Jenkins או Teamcity לדוגמא.
  • הוא צריך להכיר כלי ניהול קוד טוב. כל כלי שיודע לעבוד עם GIT זה טוב, בין אם מדובר ב-Bit Bucket או GitLab או כלי אחר, וכדאי להכיר את הדברים לא רק ברמת ממשק הווב אלא גם להכיר את GIT עצמו.
  • "קוד כתשתית" – אחד הדברים ש"רצים חזק" כיום הם כלים שכותבים איתם "קוד" לניהול תשתית כמו הענן הפנימי שלכם בענן הציבורי, כלי כמו Terraform או Ansible או SALT הם כלים מעולים לכך.
  • שפות – BASH מאוד יעזור לכתיבת סקריפטים פשוטים, מומלץ להכיר גם Python.
  • שרותים – כל ספק ענן ציבורי מספק מאות שרותים שונים. תצטרכו עם הכלים הנ"ל להגדיר ולהשתמש בשרותים הנ"ל ואצל כל ספק ענן זה שונה. כן. Not Fun.
  • ניטור באופן שונה – מכיוון שיש הרבה שרותים שספק הענן מציע ולך אין גישה לתשתית השרותים, תצטרך להשתמש בכלים שונים לניטור, סביר להניח דרך כלי הניטור של ספק הענן.

כמו שאתם רואים – ערימה לא קטנה של דברים. אגב, כמעט את כולם ניתן ללמוד ב-Linux Academy בלינק שנתתי לעיל.

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

לסיכום: לא לכל אחד מתאים להיות Devops, וזה בהחלט מובן. יחד עם זאת, חשוב לעדכן את הידע כדי להישאר רלוונטיים בשוק העבודה כשכירים. תמיד מומלץ לנסות ללמוד דברים חדשים ולהתנסות, וכיום לדוגמא רוב ספקי הענן יתנו לך איזו חבילה חינמית לכמה חודשים ואם אתם לומדים דרך ה-Linux Academy אז הם נותנים לכם 6 שרתים וירטואליים להתנסות (זמנית, השרתים נכבים אחרי שעה, אבל זה מספיק בשביל לבדוק פקודות או הגדרות מסויימות).

בהצלחה.

כמה מילים על המרה מערכת לניהול גרסאות קוד

בשנה האחרונה ביצעתי מספר פרויקטים הקשורים להמרת מערכת לניהול גרסאות קוד, ממערכות שונות למערכות מבוססות GIT (כמו GitLab, או Bit Bucket ואחרים), ורציתי לשתף עם הקוראים כמה תובנות בנושא.

אם יש סוג מסויים של עסקים בהם אין עבודה כזו, אלו הם הסטארטאפים. אני לא מכיר ולא שמעתי אפילו על סטארטאפ אחד שלא משתמש בפתרון מבוסס GIT (בין בשימוש שרת GIT, שימוש בשרותי GIT של ספקי הענן וכו'). בדרך כלל עניין ההמרה מתרחש אצל חברות ותיקות, ושם אצל אותן חברות ותיקות יש כל מיני פתרונות לניהול קוד, בין אם מדובר ב-TFS (או VSS), ב-Subversion או Mercurial, וכן .. יש גם חברות שמשתמשות ב-CVS. כמעט בכל חברה, מעבר למערכת ניהול קוד אחרת זה תהליך לא קל (בירוקרטית וניהולית, טכנית ניתן להמיר את הדברים ביום או יומיים, תלוי בכל מיני פרמטרים).

ככל שעובר הזמן, עניין המעבר ל-GIT נהיה פחות "אופציה" ויותר "צורך". חברות שחושבות לעבור להשתמש במערכות מבוססות קונטיינרים (בין אם זה Kubernetes, OpenShift, CaaS, Rancher, Mesos ועוד) יצטרכו להבין עוד בהתחלה שמבחינה טכנית ניתן איכשהו לעבור עם מערכת ניהול קוד הנוכחית שיש להן, אבל אם מכניסים מערכת קונטיינרים ל-Enterprise, הצורך לעבור ל-GIT יהיה יותר דחוף.

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

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

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

  • אם אתם חברה גדולה ומסודרת, ואני אוריד את מערכת הקוד הנוכחית ואמחק אותה, והמחלקה המשפטית שלכם תשמע את זה, הם ירדפו אחריי עם נבוטים. קוד ישן ומערכות ישנות צריכות להיות זמינות במקרה שהחברה נתבעת על העתקת קוד או הפרת פטנטים. ישנה חשיבות קריטית לזמנים (תאריכים, כולל שעה מדוייקת) של הכנסת קוד והדברים האלו יוצגו בבית משפט/דיונים מול התובעת כדי להראות סתירות בתביעה. לכן, מה שעושים לגבי מערכות ניהול קוד קיימות (לאחר מעבר לעבודה עם GIT) – הוא שמירת גיבוי, כיבוי המכונה אך לא למחוק אותן.
  • העברת היסטוריה מלאה של קוד קיים ממערכות ניהול קוד אחרות ל-GIT: זה אפשרי בחלק מהמקרים (לדוגמא: mercurial או TFS) אך בעייתי במקרים כמו CVS או Subversion, ולכן בדרך כלל ההמלצה היא להעביר קוד נוכחי ולשמור קוד/Branches ישנים במערכת הקודמת. מיקרוסופט בעבר הבטיחו ללקוחות כי הם יעבירו בקלות קוד מ-SVN ל-GIT כולל היסטוריה מלאה, ורק אחרי שהם התחילו את הפרויקט, הם ראו כמה זה לא ממש ריאלי (במיוחד אם יש קוד ענק של מספר שנים) ומאז הם ירדו מכך.
  • האם להשתמש בשרותי Code Repository של ספק הענן שאיתו אתם עובדים או להרים VM עם אפליקציית שרת GIT (כמו GitLab, BitBucket, GitHub Enterprise)? זה תלוי בכם. אם חתמתם עם ספק הענן על חבילת תמיכה רצינית, אז אולי כדאי להשתמש בשרות (שימו לב, שתצטרכו לשלם תשלום חודשי על כך. באמזון AWS ה-5 משתמשים ראשונים הם בחינם). לעומת זאת, אפשר להקים Instance ולהקים מערכת GIT כמו אלו שציינתי במחירים נוחים:
    • מערכת GitLab היא חינמית כל עוד אינכם צריכים תמיכה מסחרית מהחברה.
    • מערכת BitBucket היא חינמית ל-5 משתמשים ראשונים, 2$ לאחר מכן (מינימום 10 משתמשים) ואתם מקבלים גם אינטגרציה עם Jira.
      שימו לב: ב-2 המקרים אתם מקבלים גם תמיכת Pipelines כדי לבצע אוטומציה לקימפולים, קונטיינרים וכו'.
  • עבודה עם מערכת ניהול קוד נוכחית יחד עם GIT: אם יש לכם מערכת ניהול קוד ישן מבוססת Subversion, ניתן להקים מערכת (היא בתשלום אם יש יותר מ-10 משתמשים) המאפשרת לעבוד מול ה-Subversion והמערכת המסחרית תמיר מיידית את הקוד למערכת ה-GIT שלכם ולהיפך, כך שניתן להמיר את המפתחים לעבודה ב-GIT ואת האוטומציה (Jenkins, Team City וכו') בהדרגה ולא במכה אחת.
  • תמיכה והדרכה – חשוב לסגור את העניין במסגרת חוזה הפרויקט. קל מאוד לעשות שטויות מצד אחד ובמקרים רבים גם לא מנצלים את היתרון של מערכות מבוססות GIT מצד שני – וחבל.

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

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

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

(הערה: מכיוון שמערכות כמו OpenShift, IBM Private Cloud, CAAS, Rancher ועוד מבוססים על Kubernetes ועל זה הם הוסיפו דברים אחרים, אתייחס בפוסט זה ל-Kubernetes או בשמו המקוצר הידוע – K8S).

אחד הדברים הראשונים שמנמר"ים ואנשי IT רבים עדיין לא מבינים, זה את הבסיס, שקונטיינרים אינם מכונות וירטואליות. קונטיינר שקם משתמש ב-Images והוא לא מיועד לאחסן נתונים באופן פרמננטי כמו במכונה וירטואלית, לשם אחסון נתונים יש Volumes שעליהם אתייחס בפוסט זה בהמשך. בקונטיינר אין מערכת הפעלה מלאה, אלא מה שהותקן בעת הקמת ה-Image וברוב מוחלט של המקרים מדובר במשהו מזערי שאמור לספק את דרישות האפליקציה שתרוץ בקונטיינר. בנוסף, קונטיינר מאובטח לא אמור להריץ שרותים כמשתמש root אלא כמשתמש רגיל (ללא הרשאות root/sudo) ולבסוף – קונטיינרים לא אמורים להריץ מספר אפליקציות, אלא אפליקציה אחת בכל קונטיינר/POD ו"לדבר" עם POD/קונטיינרים נוספים שמריצים אפליקציות אחרות, בשביל זה יש לנו TCP/IP ובשביל זה יש שרות DNS פנימי שרץ על K8S שיודע לתקשר בין החלקים והשרותים השונים.

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

הרעיון של Volume הוא שונה מכל מה שאנחנו מכירים וקשור לאחסון. במערכות וירטואליזציה לדוגמא, אנחנו מגדירים "אחסון" (כמו Datastore ב-VMWare) שיש לו Backing שיכול להיות iSCSI, NFS ובמקרה של Hyper-V זה יכול להיות CIFS. בפתרון הסטורג' שלנו אנחנו מקימים LUN או מחיצה כלשהו שייוצאו כ-NFS/CIFS לפתרון הוירטואליזציה (לא ניכנס עכשיו לכל עניין שרידות, Multipath ושאר ירקות) ועל המקום הזה פתרון הוירטואליזציה שלנו יוצר/משתמש בדיסקים וירטואליים כדי להריץ את מערכת ההפעלה ולאחסן את המידע שלנו.

ב-Volumes לעומת זאת, הדברים שונים לחלוטין. אנחנו עדיין צריכים את ה-Backing (רק שיש הרבה יותר אופציות מאשר iSCSI, NFS – יש 26 אופציות, ו-OpenShift מוסיף עוד כמה) מהסטורג' כדי לאחסן את ה-Volumes, אבל כשאנחנו באים ליצור/להשתמש ב-Volume, אנחנו צריכים קודם כל להגדיר Persistence Volume, להגדיר מה הגודל של אותו Persistence Volume, מה יקרה ל-DATA באותו Volume אחרי שהקונטיינר מת, ומה ההרשאות שיהיה לאותו Persistence Volume מבחינת קריאה/כתיבה. בהגדרות הקונטיינר עצמו אנחנו נשתמש ב-Persistence Volume Claim (או PVC בקיצור) כדי להתחבר לאותו Persistence Volume (או PV בקיצור) ולהגדיר גם Path להיכן להתחבר. ה-PV בדרך כלל מוגדר ברמה של מגהבייט או ג'יגהבייט.

דבר חשוב נוסף קשור לעננים ציבוריים, ואת הטעות הזו אני רואה במיוחד אצל לקוחות שלאחרונה התחילו להשתמש בעננים ציבוריים. מה הטעות? לנסות לבנות מערכות לקונטיינרים כאילו מדובר בתשתית מקומית. זו טעות. K8S נותן מספיק אפשרויות להשתמש בשרותי סטורג' ותקשורת שאותו ענן ציבורי נותן. דיברתי מקודם על Volumes, אז יש Volumes "טבעיים" לכל ספק ענן, לא צריך להקים שרת שיתן שרותי iSCSI או NFS בשביל Volumes ואפשר להשתמש בשאר שרותי הענן לצרכים שונים כדי להריץ K8S.

לכן, אם אנחנו רוצים להקים פלטפורמת K8S, אנחנו קודם כל צריכים להחליט, האם אנחנו מקימים את זה "על הברזל" או על מכונות וירטואליות? אם על מכונות וירטואליות והפתרון מבוסס vSphere, אז אנחנו יכולים להסתכל על VMware Kubernetes Engine™ VKE לדוגמא (ואפשר במקביל להציץ גם ב-PKS של VMWare/Pivotal). חובבי מיקרוסופט? בחודש הבא יוצא Windows Server 2019 שכולל את Kubernetes בתוכו. אם לעומת זאת אנחנו מעדיפים פתרונות כמו OpenShift, CAAS ואחרים, נצטרך להקים מכונות לינוקס ועליהן להריץ את אותם פתרונות. לא אכנס כאן ליתרונות וחסרונות של פתרונות "טבעיים" מול הקמת פתרונות על מכונות וירטואליות – אבל אחת הנקודות שחשוב לזכור, זה שפתרונות שמקימים על מכונות וירטואליות – זה שקל להזיז את הפתרון לעננים או למקומות אחרים במקום להיות "נעול" על פתרון שיצרני ה-OS ווירטואליזציה מציעים. חוץ מזה קיים גם עניין המחיר.

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

  • תקשורת 10 ג'יגהביט. שוב, אין בקונטיינרים Live Migration שמשתנה בו כמה קבצי קונפיגורציה וה-VM "קופץ" למכונה אחרת, יש הקמה מחדש של קונטיינרים ולמרות שה-Image נמצא בסטורג', בחלק מהמקרים הוא מועתק לדיסקים מקומיים ולכן פתרון תקשורת 1 ג'יגה יאיט הכל.
  • סטורג' עם שרידות – יש לא מעט חברות שבטוחות שזה שהדיסקים מחוברים בבקר RAID כפול יש אחלה שרידות. לדעתי – עדיף שרידות שאם "ראש" נופל, "ראש" אחר לוקח מיידית פיקוד, אבל שוב – הכל תלוי בתקציב וכמה הפלפורמה תהיה פרודקשן.
  • דיסקים מקומיים – מאוד חשוב. ה-Images ימצאו בדרך כלל ב-Container Registry, אבל הם יועתקו לדיסקים מקומיים ברוב המקרים ועם הדיסקים מקומיים איטיים, זמן הקמת הקונטיינר יתארך (ותהיו בטוחים שיהיו ערימות קונטיינרים, חוץ מהקונטיינרים שלכם, תלוי בפלטפורמה). דיסקים מכניים זה פתרון לא רע אבל אם רוצים ביצועים – תחשבו על SSD Mixed Intense.
  • אם המערכת הולכת להיות חשופה החוצה לאינטרנט (הכוונה השרותים כמו WEB חשופים לאינטרנט) – אז אבטחה רצינית היא חשובה: לא להקים Images כ-root, תקשורת ו-Namespace מופרדים ועוד דברים חשובים שמצריכים הכרה עמוקה עם פלטפורמת הקונטיינרים. תזכרו: קונטיינר שרץ כ-root וחשוף לרשת – יכול לתת לפורץ הרבה יותר ממה שאתם חושבים.

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

פוסט עדכני על קורסים בחברות

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

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

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

  • קורסים מסויימים מלמדים על כמה הפצות לינוקס במהלך הקורס. זו, לעניות דעתי, טעות. לי, אישית, כשאני לומד עדכון של הפצה שאני כבר מכיר, לוקח לי כמה שעות במשך כמה ימים ואילו הפצה חדשה לוקח לי יותר זמן ללמוד (מה לעשות, צריך גם להתפרנס, לא? 🙂 ). לעומת זאת, מישהו שהוא חדש בתחום  הלינוקס, יקח לו הרבה יותר זמן ללמוד, ולימוד הפצות שונות באמצע די מבטיח בלבול רציני. כבר ראיתי מישהו שדי חדש בלינוקס מתעקש במשך שעה לנסות להתקין חבילות תוכנה עם פקודת zypper (שקיימת להפצת SuSE) בשעה שהוא היה צריך להשתמש בפקודת yum (שקיימת בהפצות Red Hat ו-CentOS) ולכן קורס טוב לדעתי צריך להתמקד בהפצה עיקרית אחת.
  • שיטת לימוד של "נזמין את המדריך ליומיים שלוש" להדרכה, היא שיטה די בטוחה שהכסף שיושקע ילך לטמיון. לינוקס זה לא לימוד MCITP ורוב מוחלט של החומר הנלמד הם פקודות טקסטואליות שצריך לשנן, ולנסות. קורס יומיים? תהיה בטוח ש-90% מהחומר ישכח ע"י רוב התלמידים, ועל כך יכול להעיד המייל אצלי. יש צורך לפרוס את זה ליום או יומיים בשבוע לשעות ספורות.
  • רלוונטיות: מכיוון שהשוק פתוח וכל אחד יכול להציע קורסים כאוות נפשו, מגיעים אליי כל מיני שאלות אם אני יכול להעביר קורס על טכנולוגיה זו או אחרת. טכנית, אין לי בעיה להעביר, אבל התועלת לחברה חשובה לי לא פחות מכך וצריך לבדוק (כן, תחת NDA) היכן זה משתלב. כך לדוגמא פנו אליי בעבר להעביר קורס מעמיק ב-Docker. זה, לדוגמא, קורס שהתוכן שרלוונטי הוא אולי 10% כי בסופו של יום אם מתחילים לבנות בחברה קונטיינרים, משתמשים במערכת ניהול והרצת קונטיינרים כמו OpenShift או Kubernetes – כך שללמד איך לבנות קונטיינרים – כן, איך להריץ ואת החלקים הפנימיים ב-Docker – לא ממש, תשאירו את זה להדרכות על כלי הניהול.

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

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

אנשי שיווק מול אנשי מקצוע

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

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

זה כמובן שינה את מצב השיחה למטר שאלות: "מה פתאום שזה לא ירוץ?" "היו פה אנשי השיווק ואנשי מקצוע של אותו מוצר והתחייבו שזה ירוץ".

תשובתי: אם אדוני מעוניין, אשמח לחבר אותו ל-LAB אצלי, שם המוצר שבחרתם רץ, ואשמח להראות לאדוני שהמוצר שבחרו אינו עושה את אותם דברים עם הברזלים שיש לכם.

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

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

עוד דוגמא: חברה מסויימת פנתה אליי בקשר למוצר שהם משתמשים וכבדרך אגב אותו אדם שפנה אליי סיפר לי שגם להם יש שרתים כמו שרכשתי (X3550 M3 של IBM) והם בדיוק הולכים  לרכוש הרחבת זכרון ל-256 ג'יגהבייט. הסברתי לבחור משהו פשוט: אתה תרחיב זכרון, ותראה נחיתה של 40% בביצועים. הוא לא האמין, הנציג שמוכר לו את הזכרון לא סיפר לו כלום על כך, אז שלחתי לו מסמך של לנובו שמראה שבשרתים עם מעבדים המבוססים על פלטפורמה של Westmere או Sandy Bridge, ברגע שממלאים את הזכרון, מהירות הזכרון יורדת מ-1333 מגהרץ ל-800 מגהרץ. אז יהיה יותר RAM, אבל הגישה תהיה יותר איטית. עדיף להוסיף שרתים – וזה ההבדל בין מישהו מקצועי לאיש שיווק.

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

  1. הפתרון שלהם מתאים אולי לשנת 2000, לא לשנת 2018.
  2. אין שום גדילה אופקית בפתרונות שהציעו
  3. אין שום שרידות רצינית בפתרונות שהציעו
  4. אין שום עדכוני אבטחה בפתרונות שהציעו.
  5. ההשקעה הכספית הראשונית גבוהה.
  6. הפתרון שהצעתי לאותה חברה הוא פתרון מבוסס קונטיינרים בענן. לאותה חברה יש ספק ענן מועדף ובכל הקשור לתמחור – יש לפנות לאיש השיווק של אותו ספק ענן.

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

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

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

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

מעבר ל-CI/CD בחברות גדולות

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

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

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

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

  1. לבחור צוות שיעבור ל-CI/CD מתוך כל הצוותים שיש בחברה. כדאי שבצוות יהיו אנשים עם מוטביציה ועם ראש פתוח. בלי זה – המעבר יכשל, מבטיח לכם.
  2. להעדיף כלים מבוססי קוד פתוח או פתרונות מסחריים מבוססי קוד פתוח. כלים קנייניים הם מקור לצרות בעולם ה-CI/CD שמתפתח בקצב מהיר. לעומת זאת, כלים בקוד פתוח צריכים בד"כ הרצה של פקודת YUM או APT כדי לעדכן.
  3. האם בהזדמנות זו מכניסים פתרון קונטיינרים? (אפשר לבצע CI/CD ללא קונטיינרים) – אם כן, כדאי להחליט אם הולכים על פתרון מסחרי של Kubernetes (כמו CAAS של SuSE) או על OpenShift של רד-האט שהוא גם מבוסס Kubernetes אבל נותן הרבה הרבה יותר יכולות. (ישנם כמובן גם פתרונות אחרים אבל הם לא עונים לצרכים של Enterprise).
  4. פיתוח כ-Multi Platform – חשוב במיוחד לבנקים, חברות ביטוח וחברות פיננסיות. זה נחמד וטוב לפתח ל-Windows אבל אפשר בעזרת עבודה די קצרה לעבור ל-Multi Platform. עובדים ב-JAVA? מצוין, אפשר גם עם לינוקס, צריך בסה"כ לשנות מספר סקריפטים (אם כתבתם) כדי לעבוד בלינוקס. עובדים עם Dot Net? תכירו את Dot Net Core שמאפשר לכם עבודה עם Windows ולינוקס. היתרון של עבודה עם לינוקס הוא שמגוון רחב של כלים יהיה זמין לכם (במיוחד אם אתם עובדים עם קונטיינרים).
  5. טסטים טסטים טסטים … יש עדיין מקומות שמעסיקים אנשי QA. ברוב המקומות לעומת זאת, כבר אין חיה כזו מהסיבה הפשוטה שהיום פשוט כותבים טסטים שרצים במערכת כמו Jenkins המבצעים בדיקות Unit testing ועוד מספר סוגי טסטים על מנת לוודא שמה שמפותח – הוא יציב ועובד.

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

ועוד משהו אחד שרבים לא יאהבו שאני כותב זאת: החיה הזו בשם "איש Devops" זו המצאה שגויה של אנשים שלא מבינים מה זה Devops. הבה נסתכל על משהו פשוט בחברה גדולה: החברה מחליפה תוכנת גיבוי, תוכנת Code Repository, אולי כלי אוטומציה ועוד מספר דברים. האם אותה חברה צריכה פתאום שכיר נוסף? לא, כי צוות ה-IT אמור לדעת לתמוך בכלים. אפשר לקרוא למישהו מבחוץ שילמד ויתרגל את הצוות, אבל הצוות יכול בהחלט להמשיך ולתחזק את אותם כלים. אדרבא, הן אנשי ה-IT והן צוותי הפיתוח צריכים להכיר את הכלים (ברמות מסויימות כמובן, ה-IT ברמה של Sysadmin והשאר ברמה של Usage).

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

סטארטאפים ואבטחת מידע בענן

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

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

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

וכאן בדרך כלל מתחילות הבעיות הקשורות לאבטחת מידע.

לא מעט אנשים שמתחילים סטארטאפים חושבים להם שאם יקימו את התשתית שלהם בענן, ספק הענן יגן עליהם בצורות כלשהן וזו כמובן טעות ענקית. לא חשוב מי ספק הענן, כמות ההגנה המסופקת ללקוח היא ברמה אפסית (אינני מדבר על הגנות בתוספת תשלום כמו נגד DDoS). אתה יכול להפעיל Multi Factor Authentication כדי למנוע כניסת אנשים לא מורשים לחשבון בענן, אבל זה לא אומר כלום לגבי ה-Instances שאתה משתמש. מהרגע שיש לך Instance חי ויש לו כתובת IP ציבורית, עשרות אלפי סקריפטים ינסו לחדור לשרת שלך בכל דרך. כל שרות שתפעיל באותו Instance ושאינו סגור לכתובת הציבורית (כמו שרבים נוטים להשאיר פורטים פתוחים לשרותי SQL/NOSQL, GUI, או SSH עם סיסמא (ללא מפתחות) – הסקריפטים ינסו להיכנס, ואם הם יצליחו, חלקם יעבירו את המידע חזרה מבלי לנגוע במידע בשרת וחלק אחר של סקריפטים פשוט "יגייסו" את המכונה להריץ BOT או תולעים או 1001 דברים מזיקים אחרים ויש כמובן גם סקריפטים שישמחו פשוט למחוק את המכונה.

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

לכן ההמלצה הראשונה שלי לכל סטארט אפ שכולל מס' קטן של מפתחים זה לקחת מישהו חיצוני שיעשה את עבודות הסיסטם ואבטחת מידע ברמה מספקת של הגנה כלשהי על התשתית. הגנה ברמה גבוהה מצריכה הרבה עבודה בכל מיני אספקטים כמו API, שרתי Web שנותנים את השרות, TLS ודברים רבים אחרים וכאן זה תלוי אם איש ה-Devops שלכם יודע לעשות זאת או שילוב של מישהו חיצוני שיעבוד יחד עם איש ה-Devops שלכם.

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

  • אם מדובר במספר עובדים בסטארטאפ אחד שיושבים במשרד כלשהו, דאגו ל-VPN וחברו את ה-VPN כ-Site To Site לחשבון הענן שלכם. מי שרוצה להתחבר מהבית, יתכבד הבחור ויתחבר ל-VPN שלכם ומשם לתשתית.
  • עבודה עם סיסמאות לכניסה לשרתי לינוקס היא no no. השתמשו במפתחות בלבד והחליפו את קבצי ה-PEM שניתנו לכם ע"י שרות הענן שלכם במפתחות שלכם בחלוקה של פרטי/ציבורי (עדיף ליצור עבור כל מפתח מפתח, להכניס את החלק הציבורי לשרת ואת החלק הפרטי למכונה של המפתח כך שאפשר לדעת מי נכנס עם איזה מפתח), כך שמי שצריך להיכנס למכונה יהיה לו את החלק הפרטי של המפתח (החלק הציבורי נמצא בשרת). קבצי ה-PEM למיניהם קל "לדוג" אותם מכל מיני פורומים, אימיילים ושאר מקומות.
  • מקימים DB? ראשית יש להקשיח את ה-DB לפני שמכניסים אליו נתונים. אם זה mysql לדוגמא, יש להריץ קודם כל mysql_secure_install, ואם זה mongoDB יש למחוק משתמש דוגמא,  ובכל המקרים יש לוודא כניסה רק דרך IP מסוים פנימי.
  • משתמשים בשרותים שונים של ספק הענן? ודאו שאתם משתמשים בכתובות IP פנימיות בלבד. זה לא מצליח? יש לכם בעיה עם ה-VPC (במקרה של אמזון), כדאי לבדוק הגדרות.
  • שימוש ב-DB – לפני שכותבים נתונים ל-DB, כדאי "להמליח" דברים כמו סיסמאות ומידע חשוב (להלן לינק לוידאו המסביר איך לעשות זאת ב-MySQL לדוגמא), כך שמי שיצליח לגנוב את ה-DB, לא יוכל לעשות הרבה עם זה. אפשר כמובן לשפר את זה ולהשתמש בכל מיני שרותי Vault לשמור את המפתח להמלחה אך זה כבר עניין אחר.
  • גיבויים ל-S3 או כל מקום ששומר Object Storage – לאחר יצירת הגיבוי, יש להצפין אותו ורק אז להעלות אותו (כמובן שכדאי לוודא שהרשאות ה-S3 שלכם מוגדרות בצמצום).
  • לא לקחת כתובות IP ציבוריות עבור כל Instance (טריק שלצערי ראיתי פעמים רבות שנעשה בחברות שונות). אם אין אפשרות להקים ולהשתמש ב-VPN ויש צורך להתחבר ממקומות שונים עם IP שונה, מומלץ להשתמש בטריק שנקרא Linux Bastion, זו מכונת לינוקס קטנה שבה נשתמש כ"מקפצה" (להלן לינק למאמר שמסביר זאת) ולמכונה זו יש להגדיר Security Groups עם הכתובות שיכנסו אליה (חשוב: לא להוסיף כל פעם כתובות אלא לעדכן ב-SG).
  • תעודות SSL – אם המכונה פונה החוצה ואין לכם עדיין תעודות SSL מסודרות, אפשר להשתמש ב-Let's Encrypt כדי ליצור תעודות SSL תקינות זמניות (שניתנות להארכה בפקודה פשוטה) במקום להשתמש ב-Self Signed Certificates. באותה הזדמנות כדאי לבטל Ciphers ישנים ולאפשר אך ורק ל-TLS מהגירסא האחרונה להיכנס.

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

שלח לחמך על פני המים

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

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

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

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

לפיכך, יצרתי טופס שנמצא כאן. בטופס הזה אתם ממלאים את הפרטים שלכם והם מתווספים לקובץ Google Sheets. אני מעביר קישור (שלא ניתן לעריכה) לחברות כך שהם יכולים לשמור את הקישור ובעת הצורך הם יכולים לחפש לפי מילות מפתח ולמצוא פרילאנסרים שנותנים שרות והם יכולים ליצור קשר במייל או בטלפון (אין חובה להשאיר מס' טלפון) עם הפרילאנסר ומשם לסכם תשלום, תנאים וכו' וכו'.

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

תודה,
חץ בן חמו
[email protected]