לטלטל את הספינה

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

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

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

ישראל זכתה למקום די גבוה אצל חברות רבות בתנאים שציינתי לעיל, ומקומות גבוהים גם זוכים להשקעות מאותן חברות ופרויקטים יוקרתיים יגיעו לאותן סניפים באותן מדינות. קחו לדוגמא את אמזון שמפתחת את ה"כתר" שלה מבחינת מעבדים (מעבדי ה-Graviton) פה בהרצליה פיתוח, אינטל שמפתחת פה מעבדי דסקטופ שונים, אפל שפיתחה שבבים מסויימים וכנראה תפתח פה מעבדים חדשים מתוצרתה, נבידיה (לשעבר Mellanox) שפיתחו ביוקנעם את ה-DPU הראשון ויש דוגמאות רבות נוספות. כל אלו מפותחים פה בארץ ולא במדינות כמו סין שגם שם יש לאותן חברות R&D, מכיוון שהסיכוי לגניבת IP בסין הרבה הרבה יותר גבוה מהסיכון בישראל. בגלל זה פה מפתחים מעבדים, ושם מפתחים דרייברים/מודולים.

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

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

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

האם ניתן להגן על מחשב נגד גניבות תוכנה?

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

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

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

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

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

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

אז מה ניתן לעשות? לשכנע את הלקוח לנסות משהו אחר. אחת ההצעות: מכונה שתהיה זמינה Online.

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

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

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

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

ה"פקקים" בדרך לביצוע פרויקטים

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

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

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

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

האידיליה הזו במקרים רבים נשברת על ידי צוותי הנהלה. לי כמובן אין שום דבר נגד צוותי ניהול, אך הבעיה המהותית שמתרחשת זה שדברים שמצריכים החלטה עוברים לדרג ניהולי, וחלק מאותם מנהלים מוסיף לעצמו עוד ועוד דברים וכתוצאה מכך – החלטות מתקבלות לאט (ידידנו האמריקאיים מומחים בכך, תאמינו לי. הם אלו שהמציאו את ה-Project Manager, Product Manager, Director ושלל תארים נוספים) וכך מתרחשים לדוגמא השהיות: נניח ואני צריך עוד שלוש שרתים כדי לבצע עבודה. שום איש IT לא יכול לאשר רכישות כאלו, אז זה צריך לטפס למנמ"ר, ל-CTO, ל-CFO ולמנכ"ל. מכיוון שלכל אחד מהם יש "בצלחת" דברים רבים שהוא צריך לעקוב/להחליט לגביהם, הזמן שיקח עד שיגיעו שרתים – נמדד בחודשים, ועד אז אותו חלק שאני צריך לבצע – מוקפא, מה שאומר שאותו פרויקט יתארך ויהיה צורך לשלם יותר לעובדים החיצוניים.

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

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

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

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

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

קצת על גניבות קוד, קניין רוחני ועוד

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

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

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

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

חברות רבות נותנות לעובדיהם מחשבים ניידים כדי שיוכלו לעבוד מרחוק (בד"כ דרך VPN) על קוד או על תשתית של החברה (אני אתרכז יותר במפתחים). עובדים שעובדים מהבית בד"כ או שעובדים בצורה גמישה (משרד/בית) משתמשים במחשב הנייד כדי לקבל גישה לקוד (נניח דרך GIT), להוריד שינויים, לבצע שינויים קוד ולבצע Commit ו-Push. עד פה לאף אחד אין בעיה עם זה.

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

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

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

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

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

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

לגטימי? כן.

וכאן יש נקודות שכל סטארטאפ צריך לעשות:

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

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

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

המעבר לענן ציבורי – התהליכים המקדימים

דמיינו לעצמכם סיטואציה פשוטה: יש לכם 20 שרתים בחברה (פיזיים) שמערכת vSphere רצה עליהם. הכל מתקתק ועובד טוב עד שיום אחד האחראי על ה-vSphere בחברה מפוטר עקב סיבה כלשהי. האם יהיה קשה למצוא עובד חלופי לאותה משרה? לא ממש, השאלה למה אתה מצפה: אם לדוגמא העובד שפוטר היה כותב סקריפטים ב-Powershell או ב-PERL לאוטומציה של ה-vSphere ורוב העבודה היתה נעשית באוטומציה כלשהי ללא שימוש ב-GUI – אז כן, אתה תתקשה למצוא מחליף (וגם אם תמצא, תצטרך לשלם לו הרבה יותר ממה שחשבת). אם לעומת זאת אתה מחפש מישהו שינהל רק ברמת הממשק Web, תמצא לא מעט כאלו בקלות ותוכל לשלם להם משכורת יותר נמוכה אפילו (תלוי בכישורי המו"מ שלך והבטחון העצמי של המועמד). מצד שני, אם יש לך תקלות שמתאפיינות במסך סגול וגוגל לא ממש עוזר – תתכונן לשלם והרבה, בין אם זה ל-VMware או למישהו מומחה.

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

מה בעצם העבודה שהרוב יציעו ויעשו? הם יעשו מה שאני קורא "Copy Paste". נניח שיש 10 מכונות VM, הם פשוט יעלו אותן לענן כ-Instances, יקצו להן כתובות IP חיצוניות פר Instance (תתפלאו כמה חוסר מקצועיות יש בנושא), יגדירו Security Group שנושאת מטוסים יכולה לעבור דרכו, חס ושלום VPC חדש ונורמלי, או ניתובים קצת יותר מוקשחים. אם הלקוח מתעקש על Firewall, אז יתקינו איזה משהו שקיים ב-Market עם חוקים מאוד "רפים". אני לא מנסה "ללכלך", אני בדרך כלל מי שמגיע אחרי כן לבדוק מדוע הדברים לא עובדים טוב וזה מה שאני מוצא. אני כמובן שלא אומר שכולם כך, יש דווקא לא מעט אנשים מקצועיים בתחום.

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

בהעברת התשתית לענן יש לנו 3 מטרות חשובות:

  • הורדת המחיר פר מכונה
  • קבלת ביצועים יותר גבוהים
  • הגנה יותר נאותה.

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

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

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

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

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

קצת על CDN וישראל

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

הדוגמא הכי פשוטה שאני יכול לתת היא בלוג זה שאתם גולשים בו כרגע. הוא מתארח ב-AWS בוירג'יניה, אך הוא נעזר בשרותי CDN של Cloudflare וכ-600-1500 איש גולשים בו ביום, הם מקבלים את הדפים במהירות, והעלות הכוללת היא מזערית (20$ + מע"מ לחודש). בלי שרותי CDN, המכונה הקטנה הזו (2 ליבות, 4 ג'יגה זכרון) לא היתה מחזיקה מעמד עם אותה כמות של גולשים ובלוגים שאני כותב.

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

  • שרתים וירטואליים (או פיזיים) שמפוזרים ביבשות ובמדינות מפתח שונות הכוללים שרתי Web, שרתי אפליקציה, שרת (או שרותי) בסיסי נתונים, שרות DNS ועוד ועוד. לחלופין במקום שרתים, אפשר להשתמש (ומומלץ) בקונטיינרים עם שרותי קונטיינריזציה שספקי ענן ציבורי מציעים (או להקים משלכם, אם כי בעננים ציבוריים זה קצת פחות מומלץ והרבה יותר מסובך).
  • תשתית שמאפשרת לבצע Scaling דינמי
  • תשתית אחסון
  • תשתית ניטור
  • הגנה – חומת אש, WAF…
  • CDN
  • ועוד ועוד..

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

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

אחרי שאנחנו מבינים את הצורך ב-CDN, נשאלת השאלה – איזה CDN כדאי להשתמש?

שרותים כמו Incapsula ו-Cloudflare מציעים פתרון שמאוד מזכיר דבר כמו Reverse Proxy. אתה צריך להעביר את ניהול ה-DNS שלך לספק כזה ומאותו רגע, כל התעבורה אל ומהאתר שלך עוברת דרך אותו ספק ענן (אפשר כמובן להחריג בכך שבוחרים רשומות A records מסויימים שלא יעברו דרך הענן). בשיטה זו יש יתרון גדול בכך שאותו ספק CDN יכול לאפשר לך דברים כמו:

  • חסימת כתובות IP מסויימים או חסימת גלישה ממדינות שונות
  • שרותי הגנה נגד התקפות שונות
  • SSL חינמי
  • שרות DNS מאובטח
  • אופטימיזציה של התכנים מבחינת תעבורה
  • טעינה זריזה של דפים
  • שמירת Cache מקומית
  • ועוד

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

ה-CDN של ספקי הענן הציבורי – שונה והוא יותר ה-CDN ה"קלאסי" המוכר. אתה ממשיך להשתמש בשרותי ה-DNS שלך (או בשרותי ה-DNS של ספק הענן, גם אם זה ספק ענן אחר ממה שאתם משתמשים לארח את התשתית האחרת שלכם) ואתה צריך לפתוח A record נוסף שישמש לשרותי ה-CDN וכמו כן עליך לבצע שינויים באתרים שלך על מנת שתוכלו להשתמש בשרותי ה-CDN (במקרה של אמזון יש ספר שנגיש דרך אפליקציית Kindle במחיר של 0$ כאן איך להשתמש בשרותי ה-CDN שלהם).

יש מספר יתרונות של ה-CDN של ספקי ענן כמו אמזון מול שרותי CDN כמו Cloudflare:

  • אין צורך בשרתים ובאחסון להנגיש תכנים סטטיים. פשוט מאחסנים אותם ב-Object Storage כמו S3 ומגדירים את ה-CDN להנגיש אותם לפי הצורך.
  • ניתן להנגיש דרך ה-CDN תכנים מוגנים כמו וידאו, מוסיקה, וקבצים מיוחדים שמיועדים ללקוחות משלמים בין כהורדה ובין כהזרמה (Stream).
  • ניתן לקבל Raw Access Log (ב-Cloudflare זה בתשלום, ב-Cloudfront זה ללא תשלום נוסף) שניתן להכניס למערכת עיבוד לוגים (Elastic Stack וכו')
  • ניתן להשתמש ב-Wildcard SSL
  • ניתן "לדחוף" תכנים

(מצאתי כאן טבלה שמשווה בין Cloudflare ו-Cloudfront אך היא אינה מעודכנת לגמרי).

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

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

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

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

תנו להם הזדמנות?

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

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

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

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

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

רק שכאן יש את העניין שבגינו הזכרתי את רמי. איך אתה "מוכר" את עצמך.

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

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

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

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

אז אכפת לכם לתת להם הזדמנות?

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

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