על מדיה דיגיטלית, ענן ציבורי וגדילה דינמית

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

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

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

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

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

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

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

על בניית אתרים ואחסונם – דברים שחשוב לדעת

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

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

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

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

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

  • אם אין לך שרת וירטואלי, תשכור אחד, לא צריך בישראל ולא צריך לשלם הרבה. אמזון Lightsail מציעים מכונות החל במחיר של 3.5$ (אני ממליץ לקחת את החבילה של ה-20$ אם זה לא אתר נשכח שנכנסים אליו 2 גולשים בשבוע), ואם אתם לא מעוניינים בהצעות של אמזון, יש גם את Digital Ocean (המחירים די זהים)
  • קחו איש לינוקס מקצועי שיבצע את הדברים הבאים:
    • יקים את המכונה, יעדכן ויגדיר אותה בהתאם לצרכים
    • שיקבל את האתר ב-ZIP מבוני האתר (חברות רבות שבונים אתרים מבקשים גישת FTP. לא לפתוח את זה, שילמדו לעבוד עם GIT!), כולל DB DUMP אם צריך.
    • שיגדיר את כל הדברים הנחוצים כולל הרשאות קבצים, גישה לשרת, מפתחות, SSL וכו'
    • אם האתר הוא מסחרי, אנליטיקות וכו' – בקשו מאיש הלינוקס להריץ בדיקת עומסים. אם השרת לא מצליח לעמוד בעומס נורמלי שאתם צריכים, פנו לחברה שבנתה אותו, בדרך כלל מדובר בקוד SQL גרוע, או במקרים רבים – חוסר אופטימיזציה של קוד, אי שימוש ב-Cache וכו'.
    • במידה ומדובר באתר גדול עם אלפי גולשים, דאגו ליידע מראש הן את איש הלינוקס והן את בוני האתרים. יתכן שיתווספו דרישות לבניית האתר מאיש הלינוקס.
    • בכל ויכוח מקצועי לגבי מכונת הלינוקס – דעתו של איש הלינוקס קובעת, לא הדעה של חברת בוני האתרים (אין לי מספיק שערות בראש מכמות הויכוחים שעברתי בנושא הזה, שחברת בוני האתרים מילאה את ראשו של הלקוח בשטויות!)
  • במסגרת ההסכמים שלכם עם איש הלינוקס וחברת בניית האתרים, דאגו ש:
    • בתמחור לאיש הלינוקס תהיה חובת עדכון השרת אחת לחודש במשך שנה
    • חברת בוני האתרים יחויבו לעדכן את הקוד שלהם לגבי באגים וגרסאות תיקון של השפה בה הם מפתחים (NodeJS, PHP, Python וכו') – למשך שנה
  • כשאתם רוכשים את החבילה, בקשו מאיש הלינוקס גיבוי אוטומטי של השרת בהתאם לצורך (אחת ליום, אחת לשבוע וכו') כך שיאפשר שיחזור נתונים מיידי במקרה של תקלה/פריצה.
  • אם יש לכם את הכסף – העבירו את הקוד של חברת בניית האתר למישהו שיודע לבצע Code Auditing לקוד.
  • והכי חשוב: לא לתת גישת sudo/root לחברת בוני האתרים בשרת, בשום מקרה!

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

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

אורקל מקימה region בישראל ומי צריך את זה?

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

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

אתחיל ברשותכם בחלק של "מי צריך את זה?"

ספקי אינטרנט בישראל מוכרים מספר שרותים: קווי תקשורת, Colo (אחסון שרתים), עוד כמה שרותים, ושרות VPS מנוהל או לא מנוהל. בכל מה שקשור ל-Region לא תהיה ממש פגיעה במחלקת מכירת קווי תקשורת, אך יכולה להיות פגיעה בכל מה שקשור ל-Colo (במקום להשקיע ברכישת ברזל חדש, יכול להיות שההצעות מספקי ענן ציבורי עם Region מקומי יהיו קוסמות יותר). מה שבהחלט יפגע לדעתי – זה בכל מה שקשור ל-VPS. אין מה לעשות, ספקי הענן הציבורי מורידים מחירים מפעם לפעם, מה שלא קרה בארץ אפילו פעם אחת! תארו לכם שמישהו צריך להריץ אפליקציה על שרת VM ועד היום הוא שילם נניח 200 שקל על אותו VM ועתה ספקי הענן הציבורי עם Region מקומי מציעים לו את החבילה ב-100 שקל. כמה חברות לא ינטשו את הספקים הקודמים? לא הרבה. רובם ישמחו לעבור לענן הציבורי. אותו דבר גם לגבי חברות שרוצות DR מחוץ ל-DC המקומי שלהם. אם ההצעה החדשה אומרת שאתה לא צריך לרכוש כלום אלא לשלם מחיר נמוך (יחסית) בכדי לשכפל את המערכת שלך למערכת Instances בענן, אני מאמין שהרבה חברות יעברו, במיוחד שאין יותר בעיה של Latency גבוה.

יש לא מעט אנשים שחושבים שאין ממש צורך ב-Region מקומי, ואני חושב שזה יותר קשור ל"ביצה ותרנגולת". אדגים: נניח שאתה כחברה מעוניין בשרת MySQL עם 5 מכונות רפליקציה ושיקבל בממוצע חצי ג'יגהבייט מידע בשניה וישרת במקביל מאות או אלפי חיבורים. כאן, כרגע בארץ, אף ספק לא יכול להציע לך דבר כזה שבכמה קליקים תוכל להקים, תצטרך לשכור מישהו שיקים לך דבר כזה – כך שהעלות הראשונית תהיה גבוהה. מה שיש פה בארץ מבחינת מכונות VM אלו דברים שאמזון מציעה במסגרת שרות ה-Lightsail (רק שאמזון מציעה במחיר נמוך בהרבה בהשוואה למה שה-ISP בארץ מציעים לדוגמא). רוצה משהו יותר מורכב? קח מישהו שיקים לך את זה או שתלך ל-Regions החיצוניים של ספקי ענן ציבוריים.

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

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

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

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

  • חושבים לארח את הברזלים בארץ אצל Colo זה או אחר? לא בטוח שזה יעבוד. למיטב ידיעתי, אף ספק בישראל לא בנוי לקבל או להתמודד עם ציודים בסטנדרט OCP. תביא שרת שמקבל הזנה של 48V-DC ותהיה לך בעיה לחבר את זה.אפשר כמובן להרים פאנל חשמל עם ממיר וכו', אבל כדאי לקחת זאת בחשבון. ככלל, אני בספק אם יש כאן ספק COLO שיכול לעמוד בסטנדרטים של Data Center של גוגל, אמזון או מיקרוסופט.
  • הטבות: אם תקים DC בצפון או בדרום, אתה יכול לקבל הנחות מפליגות בארנונה ומסים באותם אזורים. זה לא קשור ל"טובות" כלשהן, זה משהו שקיים מזמן – הממשלה (והרשויות המקומיות) מעניקות הנחות לחברות שמקימות תשתיות וחברות באזורים אלו ואז יכול להיות שבחישוב OPEX, יהיה זול יותר לך להקים חוות משלך.
  • קווי תקשורת: כמה שפחות לסמוך על ספקים מקומיים כולל ספקי תשתית. צריך קווי תקשורת לארה"ב ואירופה? צור קשר עם תמר'ס, מד-וואן, או בזק בינלאומי ותוודא שאתה לא מקבל משהו משותף, ואם אפשר – קח חיבור כפול על כפול. בכל הקשור לקווי הולכה עד ל-DC, קח בחשבון שגם כשיש SLA, השרות לא תמיד משהו, צפה לנפילות תקשורת פתאומיות.
  • אנרגיה חלופית: בישראל יש חברת חשמל אחת גדולה וכמה קטנות שפועלות עם גז. אם אתם בצפון, אתם יכולים לשוחח עם Energix Group לגבי חשמל מטחנות רוח וחברות אחרות מספקות אנרגיה סולארית – הכל תלוי במיקום ה-DC.
  • פוליטיקה: מבחינה פוליטית, השלום בין ישראל לירדן הוא "קר", השלום עם מצרים הוא "פושר", ושלום בין ישראל לרש"פ נע ונד, תלוי באיזה יום (פוליטית אנחנו "ברוגז", מבחינת ביזנס לעומת זאת, לא מעט חברות ישראליות שוכרות עובדים פלסטינים). יחד עם זאת, יכול להיות שמקומות אלו כן ירצו להתחבר ל-Region מקומי, כל עוד ה-Latency הוא נמוך. אולי כדאי לחשוב על כך.
  • פרויקט נימבוס: סביר להניח שכל ספק ענן ציבורי ירצה להתחרות במכרז זה ואולי לזכות. יחד עם זאת, לפני שמתחילים לתכנן את ה-Region הישראלי, מומלץ לחכות למסמכי המכרז עם פירוט השרותים שתצטרכו לספק (הימור שלי: משהו בגודל Outpost ממש לא יספיק) – יכול להיות שתצטרכו להקים משהו הרבה יותר רציני ממה שתוכנן מלכתחילה ואולי שת"פ עם COLO לא יהיה כל כך רלוונטי.

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

כשצריך תשתית של עננים ציבוריים – מקומית

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

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

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

גם גוגל החלה להציע פתרון משלה לאלו שרוצים תשתית ענן ציבורי אך מקומית ב-DC שלהם, אם כי הוא שונה מהמתחרים. אם אצל המתחרים השלב הראשון הוא רכישת/השכרת ברזלים, בגוגל פשוט ממליצים לך להשתמש בתשתית המקומית שלך או בתשתית הענן הציבורי שלהם או של אחרים ושם המוצר הוא Anthos. עם Anthos הלקוח מקבל את פלטפורמת הקונטיינרים של (Google Cloud (GKE לשימוש מקומי. זה לא בדיוק נשמע משהו מלהיב – אחרי הכל, לרוב החברות יש מאות ואלפי מכונות VM שהם לא רוצים/לא יכולים להמיר לקונטיינרים ולכן גוגל כוללים בחבילה גם את Anthos Migrate שמאפשר לך להעביר מכונות VM (בשלב זה מכונות מבוססות לינוקס בלבד) מ-VM ישירות לקונטיינר, כאשר המערכת של גוגל מנתחת את ה-VM, מקימה קונטיינרים, מזרימה אליהם את המידע ותוך רגעים ספורים אתה יכול להשתמש בקונטיינרים במקום במכונות ה-VM, גם כשהמכונות VM עדיין לא הועברו בשלמותם לפתרון של גוגל.

לגבי שאר ספקי הענן הציבורי:

  • ל-IBM יש Cloud Private שנותן לך בעצם Kubernetes עם שרותים נוספים של IBM שירוצו מקומית.
  • ל-Alibaba, Huawei, Baidu יש גם פתרונות מקומיים אבל אני בספק אם הלקוח הישראלי החשדן יסכים לשכור מהם שרותים שישבו מקומית.
  • Oracle מציעים את Oracle Cloud at customer – שכוללים את "רוב" השרותים שהם מציעים בענן (אחרי שנברתי בערימת מסמכים רוויי Buzzwords – קשה להבין מה הם בדיוק נותנים, מה עוד שהתיעוד שלהם לגבי ספקי ענן מתחרים לוקה בחסר ולכן לא מומלץ לסמוך על התיעוד שלהם).
  • VMware – נכון, VMWare היא אינה ספק ענן ציבורי, אבל עם מוצר כמו Tanzu אתה יכול להרים תשתית קונטיינרים/Kubernetes מקומית (PKS) ובעננים ציבוריים גדולים.

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

פרילאנסר – הממשלה רוצה אותך

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

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

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

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

  • קודם כל – Python ולא Paython.
  • עבודה עם Dot Net: אני ממליץ מאוד למינהל להתחיל בתכנון מעבר מ-Dot Net ל-Dot Net Core מהסיבה הפשוטה שקוד Dot Net Core יכול לרוץ גם על לינוקס, דבר שיעזור מאוד כשהקוד יצטרך לרוץ בענן הממשלתי. Dot Net Core מפותח ע"י מיקרוסופט ומיקרוסופט מספקת גם תיעוד כיצד לעבור מסביבה אחת לשניה.
  • פיתוח אפליקציות Mobile – אולי כדאי לחלק זאת לשתי סעיפים: iOS ו-Android. לא כל אחד שמפתח למערכת אחת, מומחה למערכת השניה.
  • סעיף "ארכיטקטורה" לא מובן לי. ב"ארכיקטורה" יש המון דברים הקשורים לתשתיות, אוטומציה, קונטיינרים, וירטואליזציה ועוד דברים רבים אחרים. האם המסמך יכול להכיל יותר פרטים?
  • הסבות בסיסי נתונים – על כך יש לי לאמר מספר דברים:
    • אני לא ממליץ ללכת על MySQL של אורקל אלא לעבור ל-MariaDB שכלול בתוך הפצת הלינוקס. למיטב ידיעתי, MariaDB מתפתח בקצב יותר מהיר וכולל תאימות לאחור ואין צורך לשלם עליו בנפרד.
    • ישנו פתרון RDBMS יותר רציני שנקרא PostgreSQL שגם נכלל בהפצות לינוקס (ונתמך ע"י רד-האט/SuSE בצורה רשמית) ויכול להיות שהוא יתאים יותר להסבה אליו מפתרונות DB אחרים.
    • הסבת נתונים מבסיסי נתונים כמו Oracle, MS-SQL, DB2, Adabas אל MySQL (או MariaDB) הם פרויקטים מסובכים וקשים. על מנת לעבור לדוגמא מ-MS-SQL ל-MySQL, יש מספר כלים ומתודות (כפי שניתן לראות כאן), אולם הקושי העיקרי הוא שינוי כל הקוד והלוגיקה באפליקציות שמשתמשות באותו DB. הרוב משתמשים ב-SQL כ"שפה" אבל לכל DB יש מימוש שונה. ב-DB אחרים כמו DB/2 ו-Adabas ההמרה תהיה הכי מורכבת.
    • אם אין בעיה של רשיונות, אפשר להתחיל להתעניין ב-SQL Server for Linux של מיקרוסופט (גירסת 2019 – זו הגירסה שיכולה לרוץ בקונטיינרים ובמערכות Kubernetes/Openshift).

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

  • איכות הקוד/מימוש הפרויקט: קבלת ממליצים ושיחה איתם לא תתן מידע שיכול להעיד על איכות הקוד של המתכנת או איכות ביצוע הפרויקט (מבחינה טכנית) ע"י המועמד. אם מישהו שוכר עצמאי לכתוב נניח אפליקציית שעון נוכחות, הדבר היחיד שמעניין את המזמין – הוא שהאפליקציה תעבוד ועדיף שיהיה גם תיעוד כלשהו לגבי תקלות. האם מזמין החברה יכול להעיד משהו על איכות הקוד של המפתח? לא. המקסימום שאפשר לקבל מידע מהממליץ, הם דברים "מסביב": האם המועמד ביצע את העבודה לשביעות רצון הלקוח, האם הוא עמד בלוח זמנים, האם הוא דאג "לסגור פינות", דברים כאלו, אבל שום דבר טכני שיכול להעיד על איכות הקוד, ולכן אני חושב שאולי כדאי להוסיף מבחן שהמועמד יצטרך לעמוד בו לכתוב קוד ושמישהו יבדוק את הקוד.
  • קוד הדוק ומאובטח: אנחנו נמצאים במדינה שמותקפת מבחינת סייבר מכל כיוון שתסתכל, ולא חשוב מה תשים "מקדימה" – אם הקוד גרוע מבחינת אבטחת מידע, יהיו דרכים לפרוץ למערכת. (לא צריך ללכת רחוק כדי להדגים – הנה מה שקרה עם מאגר נתוני האשראי רק לאחרונה), ולכן לעניות דעתי, אולי כדאי להוסיף מבחן או בדיקה של קוד מאובטח שיבדק ע"י מישהו שמבין ב-Code Auditing ושיתן ציון גבוה עבור קוד מאובטח.
  • Agile – זה שמישהו יודע לפתח זה טוב, אבל מה עם שימוש בכלים מודרניים? האם המפתח יודע להשתמש ב-GIT? האם הוא יודע לכתוב Pipeline ב-Jenkins לדוגמא? או Dockerfile (מאובטח) כדי להריץ את הקוד בקונטיינר? ומה שיותר חשוב – האם הוא יודע לכתוב Automated Tests בכדי לבדוק אוטומטית את הקוד שלו? גם לכך, לעניות דעתי, צריך לתת ציון.

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

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

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

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

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

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

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

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

במקרים כאלו ה-Lightsail הוא פתרון מעולה. השימוש בו ממש קל: אתה יכול להרים לך מספר מכונות, אתה יכול להשתמש בשרותי ה-DB המנוהלים של אמזון גם ללא הכרה של ה-RDS המורכב, אתה יכול להשתמש ב-Load Balancer הפשוט שאמזון מציעה כדי לנתב את התעבורה, ואתה יכול להשתמש בשרותי ה-Snapshot כדי לשכפל מכונות תוך דקות ספורות, ויש דברים נוספים שלא עולים לך כמעט כלום: אתה יכול להשתמש בשרות ה-SMS לשם משלוח מיילים החוצה (בכמויות שסטארטאפים קטנים מתחילים – הם לא ישלמו כלום), אתה יכול להרים GIT פרטי (5 משתמשים ראשונים זה בחינם), אתה יכול גם להשתמש בשרות ה-DB המנוהל עם אפשרות Cluster שיעבוד כ-Active/Passive עם גיבוי אוטומטי כל 5 דקות, ויש לך מגוון שרותים שאתה יכול להשתמש עם ה-Lightsail מבלי להכאיב לארנק.

ברגע שהסטארטאפ רוצה לגדול, Lightsail מאפשר לך להעביר את התשתית שלך כמו שהיא ל-AWS המלא. צור Snapshot למכונות, ותוכל להקים אותם כ-Instances ב-EC2 ואותו דבר לגבי ה-DB – תוכל להעביר אותו בקלות ל-RDS ולהשתמש בשרותים מתקדמים כמו רפליקות וכו'.

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

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

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

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

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

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