הבעיות של היום ומחר – עם פתרונות של אתמול ושלשום

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

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

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

  • ההמלצות טובות ונכונות (אם יהיו לי הערות או נקודות מסויימות – אציין אותן)
  • הרעיון העקרוני בהמלצות נכון, אבל מומלץ לשלב פלטפורמות X,Y וטכנולוגיות A,B.
  • אתם שילמתם על היעוץ הזה? ברצינות? אתם נמצאים בשנות ה-90 או ה-2000 או מה?

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

להלן שתי דוגמאות, מהחודשים האחרונים:

  • חברה מסויימת רצתה להריץ פלטפורמה מסויימת על לינוקס מספר רב של פעמים. המערכת אמורה להיות פתוחה לרשת וההפניות יועברו דרך Load Balancer (אני לא יכול לפרט עקב הסכמי סודיות). היעוץ שהם קיבלו: לרכוש 18 שרתים עם מפרט די "כבד", רכישה של Load Balancer חומרתי, סטורג' מפלצתי, לכל הברזלים רשיון VMWare Enterprise.
    ההצעה שלי (שהתקבלה): במקום 18 שרתים עם מפרט כבד, 2 שרתים עם מפרט נמוך, 4 שרתים עם מפרט כבד (יחסית, הרבה זכרון), מערכת OpenShift, ושרת נוסף קטן שיריץ ESXI כדי להריץ 2 מכונות VM שמריצות Windows. סטורג' – או בניה או לרכוש משהו קטן מכיוון שאין צורך ב-IOPS רציני או כמות אחסון גדולה. הפלטפורמה תרוץ כולה על קונטיינרים, ובהתבסס על הסטטיסטיקה שנמסרה לי, אני מתקשה להאמין שתהיה צריכת משאבים של יותר מ-40% בכל השרתים.
  • חברת מדיה מסויימת רצתה לאחסן תכנים רבים ולהערכתם הם יגדלו בכל שנה בסביבות ה-100-150 טרהבייט. הדרישה – אפשרות גדילה ללא SPOF (כלומר: Single Point of Failure) ומבלי לרדת בכמות רוחב הפס הפנימי, אדרבא – אם אפשר שתהיה גדולה יותר ויותר – הם ישמחו. כאן לא היתה חברה מסויימת שנתנה יעוץ, אלא החברה ביקשה מכל מפיצי הסטורג'ים הגדולים והמוכרים בארץ, ואני התבקשתי להמליץ על אחת מההצעות.
    הבעיה: אף הצעה לא כללה פתרון אחסון Scale Out. כל ההצעות היו פחות או יותר "תוסיף מדף" ובקשר לשרידות – קנה שתי ראשים. לפיכך המלצתי הפשוטה (שהתקבלה) היתה: זרקו את ההצעות ובקשו או פתרון Scale Out או לבנות פתרון Scale Out מבוסס קוד פתוח או תוכנה סגורה שמציעות יצרני שרתים וחברות אחרות, ורשת עם Backbone של 40 ג'יגהביט שיגדלו בהמשך לכיוון ה-100 ג'יגהביט.

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

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

קצת על Scale Out עם פלטפורמות יעודיות

בשנים האחרונות אנחנו עדים ליותר ויותר פלטפורמות שעובדות בשיטות של Scale Out. הפלטפורמה הכי ידועה לדברים כאלו היא כמובן Kubernetes, אך כמובן שישנן פלטפורמות אחרות שקשורות יותר לעיבוד נתונים – Kafka או Cassandra לדוגמא, כל אחת מהן פלטפורמה לצרכים שונים, אבל מבחינת צרכי חומרה, הצרכים הם פחות או יותר זהים: מעבדים בינוניים (לא צריך כמות מפוצצת של ליבות, יספיקו 8-16), ולא צריך דיסקים (קשיחים או SSD) יקרים.

כלומר – אם אתה צריך להריץ פלטפורמה שעובדת ב-Scale Out מקומית בתשתית שלך, אל תנסה לחפש את היוקרתי עם כל מילות הבאז האחרונות, אלא ההיפך – מי הספק שיכול לתת לך את ההצעה הכי זולה שתעמוד במפרט שנקבע מראש, SLA שאתה צריך וכו'. ב-Scale Out אין את מושגי השרידות מעולם ה-Scale Up. אין Heart beat, אין Active/Passive, Active/Active וכו'. עם Scale Out בדרך כלל הפלטפורמה תהיה בנויה כך שאם שרת למטה/אינו זמין/אינו פעיל, המערכת תאזן את עצמה אוטומטית (למי שמשתמש ב-Kubernetes ורוצה לראות זאת – תורידו Node ותראו איך זה עובד).

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

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

אחת השגיאות שאפשר לראות בפורומים שונים, זה שאנשים שעובדים עם פתרונות Scale Out מחפשים איך לאחסן את כמות הנתונים שהולכת וגודלת והם עדיין לא מכירים/מבינים את עניין ההוספה המתמדת של ברזלים ודיסקים מקומיים – והם תמיד יקבלו את הצעות הפתרונות שמתאימים ל-Scale Up: לתכנן את הגדילה למשך שנה וכו' וכו' ואז לבחור סטורג'. זו טעות, כי בעולם המדידות/דגימות ושימוש בפלטפורמות Scale Out אתה מחפש לקבל כמה שיותר מידע, לא כמה שפחות, ויכול להיות שהחודש הקרוב אתה תוסיף עוד 4 טרה מידע לחודש אבל בעוד 3 חודשים זה יקפוץ ל-15 טרה לחודש. בגדלים כאלו, שום פתרון סטורג' קנייני אינו מתאים, אלא אם רוצים "לשרוף" את תקציב החברה, ולכן יש צורך ללכת לפי הפתרון של הפלטפורמה, לא לפי שם/דגם של סטורג'.

ולכן:

  • אם הולכים להשתמש בפלטפורמה שהיא בראש ובראשונה Scale Out לצרכי עיבוד נתונים/קליטת נתונים – נצטרך דיסקים ושרת מהקצה הנמוך-בינוני, מבלי להשקיע יותר מדי כספים פר ברזל (קחו דיסקים בסיסיים, בפוסט קרוב אסביר לגבי הגדרות אחסון מקומי למערכות כמו Kafka ו-Cassandra), (אגב, אם אתם רוצים להריץ Kafka בענן, אמזון לדוגמא שמחה להציע לכם את MSK).
  • אם אנחנו רוצים לשמור כמות גדולה מאוד של מידע לאחר עיבוד או ארכיבאי כשהכמות גודלת כל הזמן, או שאנחנו צריכים Object Storage – פתרון אחסון Scale Out (כמו Gluster) יתאים יותר לשימושים הללו מכיוון שעלות הגדילה היא זולה, והביצועים גודלים ככל שמוסיפים ברזלים לאותו אחסון.

לסיכום: בעולם ה-Enterprise, הסטורג' הקנייני היה ה-דבר הכי חשוב וקריטי. אין סטורג', שום דבר לא פועל. מאז הגיעו ספקי הענן הציבורי הגדולים שהכריזו שאצלם אין ולא יהיה שום סטורג' מרכזי, ובמקביל התפתחו יותר ויותר פלטפורמות שמחזירות את השימוש בדיסקים מקומיים ומאפשרות לבנות אחסון מדיסקים זולים וממשאבים צנועים, וזהו בדיוק החלק שבמחלקות ה-IT או ה-CIO/CTO צריכים להבין: אל תנסו לכפות פתרון Scale Up על פתרון Scale Out.

הפתרון למעבר מ-VM לקונטיינר: Kubevirt

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

כל מי שהתחיל ומשתמש בקונטיינרים, Kubernetes וכו' – מבין בוודאי שקונטיינרים אינם מכונות וירטואליות. בניגוד ל-VM, קונטיינר מקבל שרותי OS ממערכת ההפעלה המותקנת על ה-VM (או על הברזל) שמריץ את הקונטיינר, ולפיכך קונטיינרים ברוב המקרים הם דברים די קטנים בהשוואה למערכת הפעלה מלאה שמותקנת ב-VM, גם כשהיא מותקנת כ-Minimal.

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

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

  • האפליקציה רצה ומבוססת על Windows
  • האפליקציה רצה על גירסת לינוקס מאוד ישנה
  • האפליקציה רצה על מערכת הפעלה שאינה מבוססת לינוקס
  • ה-VM נבנה ע"י מומחה חיצוני ולאף אחד אין מושג ירוק איך הדברים מוגדרים ב-VM (לדוגמא: Cobol ישן)

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

וכאן נכנסת לתמונה אפליקציית Kubevirt.

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

מאחורי הקלעים, מה ש-Kubevirt עושה, הוא להשתמש ב-KVM (הוירטואליזציה המצויה בכל לינוקס) ובספריית Libvirt וספריות נוספות בכדי ליצור POD ובתוך ה-POD להריץ VM. את אותו VM אנחנו נגדיר בעזרת קבצי YAML, כמו שמגדירים כל דבר ב-Kubernetes, וכך נוכל להגדיר כמות זכרון, היכן הדיסק הוירטואלי יושב, האם ה-VM יהיה בעצם Immutable (כלומר שכל שינוי ל-VM ימחק ברגע שה-VM "כובה"), ועוד פונקציות נוספות. הגישה ל-VM תוכל להתבצע בכלים הרגילים (SSH, RDP) או VNC וחיבור סריאלי וירטואלי (במקרה שמדובר בלינוקס או כל מערכת תואמת UNIX אחרת).

מכיוון שב-Kubernetes אפשר להשתמש בכל מיני "דרייברים" (Storage Classes, Volumes), נצטרך להמיר בשלב ראשון את הדיסקים הוירטואליים של ה-VM מהפורמט הנוכחי (VMDK ב-vSphere) לפורמט ש-KVM ו-libvirt יכולים להבין ולהשתמש. סוג הדיסק שאנחנו נצטרך יהיה RAW וכלי ההמרה (שצריך לרוץ תחת לינוקס) הוא virt-v2v (זה קצת יותר מורכב ממה שהקישור מראה). מהרגע שביצענו זאת, אנחנו "מנתקים" בעצם את ה-VM מהוירטואליזציה הנוכחית (נניח vSphere), אבל ה-VM עדיין נשאר ב-vSphere. ברגע שיש לנו את הקובץ בפורמט RAW, נוכל להשתמש בכלי כמו CDI כדי לבצע Import של ה-Image לתוך Volume שנגדיר. אחרי שהצלחנו (שוב, לא דבר כל כך קל, אלא אם אתם משתמשים ב-Openshift דרך ה-WEB UI), אנחנו נגדיר POD עם ה-VM ושם אנחנו נבחר דברים כמו כמות זכרון, מערכת הפעלה, וכו'. בזמן ההגדרות נוכל להוסיף דיסקים וירטואליים חדשים ל-VM ועוד. לאחר שהתהליך מסתיים ונפעיל את ה-VM, תופיע כתובת IP שדרכה נוכל להתחבר אל ה-VM.

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

  • Kubevirt עובד על כל גירסת Kubernetes מ-1.10 ומעלה, ו-OpenShift 3.11 ומעלה.
  • בשביל לקבל ביצועים טובים עם ה-VM, יש צורך בתמיכת Nested Virtualization (אם ה-Kubernetes שלכם רץ כמכונה וירטואלית).
  • עננים ציבוריים: אם אתם רוצים להריץ Kubevirt על ענן ציבורי, תצטרכו לבחור Instances שכוללים תמיכת Nested Virtualization. גם לאז'ור וגם לגוגל יש מכונות כאלו, ב-AWS אין ולפיכך ב-AWS מכונות VM כאלו ירוצו יותר לאט מאחר ומדובר באמולציית X86-64 בתוכנה.
  • דיסקים וירטואליים: מכיוון שאין Thin Provisioning בשיטה כזו, הווליומים יהיו גדולים (כמה שהגדרתם ב-VM בהתחלה תחת vSphere), לכן אם הגדרתם את ה-VM עם דיסק של 100 ג'יגה אבל השתמשתם רק ב-15 ג'יגה, הקטינו את הדיסק (הוראות נמצאות כאן אם מדובר ב-vSphere).
    נקודה נוספת חשובה לגבי דיסקים וירטואליים: אפשר לצרף אותם ישירות ל-Image של הקונטיינר אך הדבר אינו מומלץ (אלא אם אתם רוצים להפיץ את ה-Image החוצה).
  • קישוריות ל-VM ותקשורת: במקור כברירת מחדל יש ל-VM חיבור רשת יחיד. יחד עם זאת ניתן להשתמש ב-Multus או Genie כדי להוסיף דברים רבים הקשורים לרשת: VLAN, Bridges, אפילו PXE Boot – תשתוללו חופשי.
  • ניתן לשכפל את ה-VM לפי כל פרמטר שתרצו כדי לעמוד בעומסים. לשם כך תצטרכו להגדיר בקובץ YAML את ה-AccessModes לפי הצרכים שלכם.
  • KVM – מכיוון שה-VM שלכם ירוץ תחת KVM, כדאי להכיר את KVM. תרימו מכונת לינוקס, תפעילו Nested Virtualization ותריצו את Virt Manager (נקרא גם VMM). יש המון פונקציות והגדרות וכדאי להכיר אותם לפני כן, אחרת תקבלו הפתעות (במיוחד אם מכונת ה-VM שלכם משתמשת ב-UEFI. יש תמיכה ל-UEFI אבל תצטרכו להגדיר כמה דברים לשם כך).

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

אם אתם רוצים עוד הסברים על Kubevirt כולל הדגמה של לינוקס ו-Windows Server 2012, אתם מוזמנים לצפות בקליפ (הארוך – שעה) הבא.

לסיכום: אם אתם רוצים לעבור לקונטיינרים והדבר היחיד שמפריע זה מכונה אחת (או מספר מכונות) שבעייתי להמיר אותן ידנית לקבצי Docker Images ושירוצו כקונטיינרים טבעיים, Kubevirt יכול לסייע בכך. חברות כמו SAP, nVidia, Cloudflare כבר משתמשות ב-Kubevirt. חשוב לציין: Kubevirt עדיין לא מוגדר כגירסה סופית (מצד שני, גם Kubernetes לא מוגדר כך). אם אתם משתמשים ב-OpenShift מגירסה 3.10 ומעלה (גם בגירסת OKD – גירסת הקוד הפתוח) – קל מאוד לשלב את Kubevirt והחל מגירסה 4.2 – ה-Kubevirt יהיה חלק אינטגרלי (בגירסה הנ"ל תוכלו להתחבר ישירות ל-vCenter ולהמיר את ה-VM בכמה קליקים).
מיקרוסופט וגוגל כבר מזמן הבינו שאם רוצים למשוך את הלקוחות אליהם כדי שישתמשו בשרותי ה-Kubernetes שלהם, צריך לעזור ללקוחות בכך שיציעו המרה של מכונות VM להרצה בתוך קונטיינרים, וזה יהיה כנראה ה"גל" הבא.

הקמת Region בישראל: עוד קצת מידע

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

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

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

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

  • קמצנות: נניח שאנחנו תוהים איך זה שאין פה בארץ מישהו שמספק שרות קונטיינרים כמו EKS/ECS שקיים באמזון, רק יותר קטן. בשביל להקים דבר כזה, אתה צריך השקעה מאוד רצינית במפתחים, אינטגרציה וכו'. מבחינת תמיכה, אתה לא יכול להביא אנשי תמיכה משרות לקוחות פרטי ("תכבה את הראוטר ותדליק") כדי שיעזרו ללקוח עם בעיות ב-namespace או מדוע קונטיינר קורס מיד אחרי שהוא עלה – כל הדבר הזה עולה ממון רב, ואף ספק (למיטב ידיעתי) לא היה מוכן להשקיע. איך אני יודע? כי הושכרתי להקים PoC לספק כזה. הוא התרשם מאיך שזה רץ ואיך שזה עושה Scaling, אבל כשתיארתי לו איזו חומרה הוא יצרך ואיזו הכשרה יש צורך להעביר לתומכים והעלות המוערכת לכך – הוא ביטל את הפרויקט, וזה, אגב, ממש לא ספק קטן.
  • עצלנות: בארץ הספקים מעדיפים להציע ללקוחות כפתרונות מוכנים את הדברים הקטנים, כמות Fixed של VM עם אחסון כלשהו, וכל דבר נוסף נחשב אקסטרא במחיר מטורף (אתם לא תאמינו כמה עולה אצל רוב הספקים Load Balancer מבוסס תוכנה – במחיר חודשי). הם בהחלט מוכנים לקחת דברים גדולים ולשכור אנשים שיקימו את אותם דברים גדולים, אבל המחיר להקמה יהיה מאוד גבוה ללקוח הקצה. כמה גבוה? סביר להניח שהלקוח יבחר די מהר לעבור עם ספק ענן ציבורי עם Region אירופאי כלשהו. אז הם פשוט מוכרים את הקצה הנמוך.
  • מחיר: המחירים בארץ יקרים, מאוד, ללא הצדקה. כשספק אומר לך שהאחסון שתקבל הוא "SSD", תהיו בטוחים שמדובר ב-SSD מהקצה הנמוך, שהמעבדים הם 2 דורות אחורה או יותר (אם יש למישהו VPS ישראלי, הוא מוזמן להריץ את פקודת: lscpu ולראות זאת), רוחב הפס הוא קטן מאוד, ואם אתה מחפש תקשורת מהירה בין מכונות וירטואליות שונות – תשכח מזה. על זה הם גובים מחירים שהם גובים פי 2 ומעלה מהצעות בחו"ל, ובניגוד לספקי ענן ציבוריים שמורידים מעת לעת את המחיר של מה שאתה שוכר, בארץ המחיר נשאר אותו דבר או עולה.

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

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

מפסידים

  • יבואנים ומפיצים של שרתים מכל החברות. אם אתה צריך ברזל בשביל וירטואליזציה, אתה יכול לשכור ישר Instances מספק הענן לפי הגודל והצורך, ואם אתה צריך את אותו Instance כדבר קבוע למשך מספר שנים, אז אתה יכול לקבל עד 60-70% הנחה במחיר אם אתה משלם מראש ל-3 שנים נניח. אתה יכול לשכור גם Instances שמכילים ציוד שיעלה לך המון (כרטיסי Tesla לדוגמא או TPU במקרה של גוגל) ואתה יכול להריץ דברים למספר שעות או ימים ולמחוק ולשלם רק על השימוש. ברגע שמבינים ומתרגלים לרעיון – הצורך לרכוש ברזלים חדשים במקרים רבים יורד.
  • סטורג' – אם יש Regions בארץ וחברות עוברות אליו, הדרישה לרכישת סטורג' יורדת. בענן ציבורי יש מספר שיטות לאחסון, יש שרותים שחוסכים כספים רבים, יש שרותים עם יתירות שעוקפת כל סטורג' שתרכוש, ובקיצור – אלו שיצטרכו לרכוש סטורג' הם אלו שיעדיפו להשאיר את הציוד ב-DC שלהם.
  • ספקי תקשורת ישראליים: כל מי שעיניו בראשו ויש לו תשתית אצל ספק ישראלי, מספיק שידע לתכנן נכון והוא יוכל לחסוך במחירים בכך שיעבור ל-Region מקומי בענן ציבורי ולהפסיק את ההתקשרות עם כל מיני חברות COLO, Hosting וכו', ואני מאמין שתהיה הגירה המונית.
  • ספקי תקשורת לחו"ל: כל ספק Region ירצה קווים עם רוחב פס רציני מאוד, ובמחירים הרבה יותר נמוכים ממה שאותם ספקים מוכרים בארץ. כל ספק ענן ציבורי שירצה להקים פה Region יעשה את המוות לספקים המקומיים ואם המחירים עדיין לא ימצאו חן בעיניהם, אותם ספקי ענן ציבורי יתאגדו ויסללו כבל מטורף מחו"ל לארץ. גוגל, פייסבוק, אמזון ומיקרוסופט עשו זאת בעבר כמה פעמים, אז אין סיבה שלא יעשו זאת שוב אם הם לא מקבלים את המחירים שהם רוצים. ועוד משהו קטן אחד: הם רוצים לנהל את הקווים שלהם בעצמם.

מרוויחים

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

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

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

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

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

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

לרובוט אין הפסקות סיגריה, אין כאבי גב, אין "עצבים" בגלל עובדים אחרים, אין עיצומים/שביתה, קל ללמד אותו דברים נוספים (זה לוקח בערך 2 דקות ואת זה ניתן לעשות בעת הטעינה שלו), והשאיפה היא ש-1-2 עובדים יוכלו לנהל צי של 50-100 רובוטים במקום גדול (רוב החברות בארץ שעובדות על רובוטים, עובדות על רובוטים שיתנהלו במרחבים ענקיים). גם מבחינת קופות ממוחשבות, הקופות שיש כיום בשרות עצמי מהוות (שוב, לא בארץ) מעין Stop Gap והשאיפה היא לעשות את הכל עוד בעגלה עם מחשב קטן וסורק, כשהתשלום ואריזה יבוצעו בעת החזרת העגלה, כך שסופר גדול בחו"ל מחזיק לדוגמא 30 קופאיות, הוא ירד ל-3-4.

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

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

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

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

אחד הדברים שבגללו אנשים רבים לא ניגשים ללמוד תחומי היי-טק הוא החשש עקב אי הכרת התחום מהעבר. איך אמר לי מישהו "חץ, לך יש יותר מ-20 שנה נסיון, לי יש אפס נסיון", והתשובה שלי אליו היא שברוב הדברים זה פשוט לא רלוונטי. יש דברים בסיסיים שצריך ללמוד, כמו מה-זה רשת תקשורת, מושגי מחשב בסיסיים וכו', עניין שיכול לקחת בין כמה שעות לכמה ימים, אבל אם יבוא מישהו כמו אותו בחור לעיל ללמוד לדוגמא Javascript ואני אבוא ללמוד Javascript, ההבדל בינינו יהיה מזערי – כי אני לא פיתחתי כלום בעבר ב-Javascript ולא למדתי את השפה. כשאני התחלתי לעבוד בתחום, מערכת הקבצים ברשתות היתה Novell Netware 2.11 ורשתות התקשורת היו מבוססות Token Ring. מבלי להיכנס להסברים על מה זה – נאמר שאף אחד כיום לא משתמש באף טכנולוגיה כזו.

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

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

אשמח אם תוכלו לשתף פוסט זה עם חברים שאתם חושבים שהיי-טק ופיתוח יכול להתאים להם.

יש לך גיבויים למכונות שלך בעננים?

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

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

"As part of using Amazon EC2, you agree that your Amazon EC2 resources may be terminated or replaced due to failure, retirement or other AWS requirement(s). We have no liability whatsoever for any damages, liabilities, losses (including any corruption, deletion, or destruction or loss of data, applications or profits), or any other consequences resulting from the foregoing. "

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

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

אז מה ניתן לעשות? להלן מספר אפשרויות:

  • כל ספק ציבורי מאפשר ליצור Snapshot לדיסקים שנמצאים ב-Instnace. השימוש ב-Snapshot יכול להיות הן לשחזור, והן להמרה ל-Image (אם אתם רוצים ליצור Image חדש ל-Instances חדשים). יצירת ה-Snapshot נעשית "מבחוץ" (בין אם דרך ממשק ה-Web, דרך ה-SDK/CLI, או דרך כלי אוטומציה שתבחרו) ואין צורך ב-Agent כלשהו. ההוראות לבצע זאת ב-AWS נמצאות כאן.
  • Immutable מול Mutable: רוב האנשים שמגיעים מעולם הוירטואליזציה שרצה On Prem ומתחילים להשתמש בעננים ציבוריים – עובדים בשיטה שנקראת Mutable: יש לנו VM, עליו רץ כמעט הכל: האפליקציה, שרת ה-Web, אולי גם שרת SQL וכו' וברוב המקרים ה-DATA נשמר מקומית. בשיטה הזו גם המתודה לשדרג לגרסאות חדשות ולשנות דברים היא די בעייתית (במקרים רבים אפליקציות מצריכות שינויי הגדרות בין גירסה לגירסה, לדוגמא), ואם לא מדובר ב-instance יחיד אלא כמה וכמה – זה נהיה יותר מורכב, והשדרוג לא תמיד מצליח.
    שיטת ה-Immutable היא שיטה הרבה יותר קלה לעבודה: אנחנו מכינים Image Master שאינו כולל DATA, אך כולל את כל ההגדרות שאנחנו צריכים, ובעת ה-Deploy של ה-Image אנחנו נריץ סקריפט שנמצא בתוך ה-Image שיבצע את השינויים וההגדרות האחרונים שאנחנו רוצים (אפשר לדוגמא לכתוב סקריפט קצר של 2-3 שורות שימשוך מ-GIT את הסקריפט שיבצע עדכון הגדרות, לא לעדכן/להתקין חבילות אחרת זה רק יאיט את הזמן עד שהמכונה תהיה זמינה – את זה תעדכנו ב-Master Image). ב-Instance החדש שום דבר לא נשמר מקומית: לוגים עוברים לשרתי עיבוד (Elastic וחבריו), SQL רץ במקום אחר (שרות מנוהל או ממכונה אחרת), קבצים שצריך להנגיש מגיעים מ-EFS או S3, כך שבשרת עצמו שום דבר מהותי לא יכתב, ואם צריך – נוכל למחוק מיידית את ה-Instance ללא נזקים. את ה-Image הזה נוכל לעשות Deploy בכל כמות שנרצה (לא לשכוח לחבר אותם ל-Load Balancer). בשיטה הזו אין צורך לגבות את המכונות, אבל כן כדאי לגבות את ה-DATA שנשמר במקומות אחרים מחוץ ל-Instance.
    למעוניינים, יש בלינק הזה קליפ שמסביר זאת בצורה יותר מוחשית.
  • קונטיינריזציה/אורקסטרציה: עם קונטיינרים, אין שמירה של הדברים, הואיל וכשקונטיינר מפסיק לעבוד, הוא "מת" ולכן עבודה עם קונטיינרים מחייבת עבודה מול אחסון חיצוני. חשוב: את ה-Volume של הקונטיינר (או PV/PVC במקרים של Kubernetes או OpenShift) למפות למקור חיצוני. Kubernetes/OpenShift יודעים לתמוך במגוון מקורות כמו NFS, וגם Docker יודע לדוגמא לתמוך ב-NFS (תמיכה ב-iSCSI ל-Docker – בדרך).

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

קצת על פוליגרף, גופים פיננסיים וגופי בטחון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשאין נסיון מספק בתחום

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

כפרילאנסר – החיים מאוד דינמיים ומאוד תובעניים. ככל שאתה מכוון ליותר "גבוה" לפרויקטים והזדמנויות רווחיות – אתה צריך "להשיל" תחומים מסויימים בגלל שהשוק באותם תחומים מוצף בעצמאים שיהיו מוכנים לתת מחיר תחרותי מאוד. לדוגמא: תחזוקת מכונות Windows Desktop או תחזוקת שרתי Windows – יש מספיק בשוק שיציעו מחירים של 70-150 לשעה. אם אני אבקש "מאות" שקלים לשעה, ההצעה תידחה ולכן בדברים כאלו צריך לוותר ולכוון לדברים היותר רווחיים – קונטיינריזציה, עננים ציבוריים, כלי CI/CD, אוטומציה, אינטגרציית לינוקס, מערכות  משובצות, HPC, Scale Out, אחסונים גדולים (מעל פטה) ועוד.

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

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

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

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

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

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

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

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

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

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 בארץ זהו צעד מבורך, אולם כדאי לשים לב לדברים שונים כדי שהפרויקט יצליח, ובמיוחד כדאי כבר מעכשיו לחשוב איך להעביר את כל הצוותים במשרדי הממשלה וביחידות הסמך לעבוד לעבור במתודות מודרניות.

על שני פרויקטים מוצלחים – ולקחים

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

באותם פרויקטים שהקמתי, היו מספר רב של שרתים שהריצו מערכת DB שהיא Scale Out ובחלק מהשרתים רצות אפליקציות שונות שמשתמשות ב-DB כדי להעביר פנימה והחוצה נתונים לשם ניתוח. בנוסף רצו מכונות VM שונות לתשתית שנתנו שרותים שונים על מערכות הפעלה שונות.

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

  • מיישם הפרויקט – צריך להשתתף בפרויקט עוד בשלבים המוקדמים: במקרים רבים מתבצעת התקשרות עם איש מקצוע להקמת תשתית/פתרון אחרי שנבחרה חומרה שתריץ את הדברים. ההחלטות לגבי החומרה מתקבלות ע"י האיש המקצועי בחברה או שמוגשות המלצות ע"י אנשי השיווק של יצרן החומרה ואז אחד הקודקודים בחברה מחליט אם לרכוש או לא ומה לשנות (פקטור של מחיר וכו'). אני מבין את התהליך, אולם לעיתים יש דברים שניתן לשנות מבלי להרים את תקרת המחיר – שנותנים ביצועים יותר גבוהים או שרידות גבוהה, ולכן כדאי לשכור את האיש מקצוע לפני קבלת ההחלטות לגבי הברזלים.
  • תוכנות בקוד פתוח מסחרי או רגיל: אחת הנקודות שחשוב לתת עליה את הדעת עוד בשלב החישובים הכספיים, היא ההחלטה אם במערכת החדשה יוטמע פתרון מבוסס קוד פתוח חינמי שמורידים מהאינטרנט, או שרוכשים פתרון קוד פתוח עם תמיכה מסחרית מיצרן התוכנה. דוגמאות לכך לא חסר: OpenStack, Ceph, GlusterFS, RHV ועוד ועוד. אפשר כמובן להוריד מהאינטרנט ולהתקין בלי לשלם שקל, אולם מה קורה כאשר המערכת הזו תהיה פרודקשן ויש תקלה באפליקציה המרכזית? במקרים כמו OpenStack או Ceph לדוגמא, כמות האנשים בארץ שיכולים "לחטט" בקוד ולתקן באגים מאוד קטנה וללא תמיכה מסחרית רשמית – מערכת פרודקשן כזו יכולה להיות מושבתת למשך ימים, ולכן אם מדובר במערכת פרודקשן שתיצור הכנסות – מומלץ לבחור בדרך המסחרית. זה יותר יקר מבחינה כספית – אבל זה נותן שקט ומענה לבעיות בטווח הארוך.
  • כמה שפחות תלויות: לא משנה מי הפרילאנסר או החברה שמקימה עבורכם את הפתרון, חשוב לכלול כמות שעות מסויימת שתוקדש לתיעוד והדרכה של הצוות בחברה, ובמיוחד Troubleshooting. אם לדוגמא המערכת מנותקת מהאינטרנט ויש תקלה, הצוות בחברה (בהינתן הידע) יכול לטפל בתקלה הרבה יותר מהר מאשר פתיחת טיקט, המתנה, ולאחר מכן עבודה בשיטה של copy/paste מהטיקט למכונות.
  • חיבור אינטרנט למערכת: לא מעט לקוחות מבקשים להקים מערכת שבמצב פרודקשן תהיה מנותקת לחלוטין מהאינטרנט. זהו דבר מובן ומקובל, אבל עדיין חשוב לבנות חיבור אינטרנט (ישיר או עקיף, ע"י הקמת Proxy או VPN לדוגמא) לעדכונים ותיקונים חשובים. ראיתי לא מעט מקרים בהם אנשים הורידו קבצי RPM וחשבו שהם יוכלו להתקין אותם ישירות בפרודקשן מדיסק און קי, ואז הם ראו דרישה מהמערכת לערימת קבצי RPM נוספים כתלויות. על מנת לאבטח את המערכת, חיבור כזה צריך להיות מופעל ידנית כמובן כך שלא ניתן להיכנס אוטומטית מרחוק.
  • דאגו ל-Gateway: נניח שיש לי 50 שרתים, כולם תחת אותו Class של כתובות (נניח 24/). מטבע הדברים יספיק שרת DNS פנימי פשוט כדי שהמכונות יכולות לשוחח בינן לבין עצמן ואין צורך בשום Gateway, אבל הבעיה מתחילה בכך שאם נניח מכונות 3,8,10,14,30 צריכות עכשיו להתחבר לאינטרנט להוריד דברים מסוימים (ואין Proxy), בלי Gateway זה יהיה בעייתי, ולכן מומלץ שאפילו ה-Switch המקומי ישמש כ-Gateway מקומי.
  • לוח זמנים – בחיים ניתן לשלוט על דברים רבים, אך יש דברים שאין עליהם שליטה. פרויקט אמור להימסר ללקוח בעוד חודשיים אך עדין לא מצאו איש מקצוע בתחום מסוים. יש צורך בהחלפת רכיב מסוים בכל השרתים. יש צורך בשינוי דחוף בארכיטקטורה. הלקוח לא מרוצה מהביצועים – קחו טווח זמן יותר ארוך ממה שאתם חושבים שתצטרכו.

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