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

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

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

ה"היצמדות" ל-CUDA והעתיד

כפרילאנסר, אני מציע שרות שלא מעט חברות ועסקים זקוקים לו בהתחלה – והוא קשור ל-CUDA, הדרייבר של nVidia, והשבב הגרפי הפנימי שנמצאים במעבדים של אינטל (בתחנות עבודה). הצירוף של ה-GPU המובנה במעבד של אינטל וה-GPU של Nvidia לא תמיד יודעים "לעבוד" יחד, במיוחד בכל מה שקשור ל-OpenGL ו-Xorg וצריך לדעת איך "לפשר" ביניהם. מעבר לכך, ה-CUDA של Nvidia יכול לעבוד רק מגרסאות מסויימות בכרטיסי ה-GPU החדשים של NVidia כמו Tesla מסידרה T. כתוצאה מכך אני עוקב בזמני הפנוי אחרי גרסאות CUDA, דרייברים הן של אינטל והן של Nvidia.

מבחינת השוק כיום – בין אם מדובר בסטארטאפים, עצמאים וחברות שעובדים בתחומים הקשורים ל-AI, Deep learning וכו', כרטיסי ה-GPU המועדפים בצורה חד משמעית הם הכרטיסים של NVidia וכמובן הכל הולך לפי התקציב: למי שאין תקציב, רוכש כרטיסי RTX (כרטיסי ה-GTX כבר "מתו"), ולמי שיש תקציב – רוכש כרטיסי Tesla או Quadro. כשזה מגיע לשרתים, ההמלצה החד משמעית היא כרטיסי Tesla הואיל והאיוורור שיש בשרתים אינו מתאים לכרטיסי RTX (זה יעבוד, אבל הכרטיס יוריד עצמאית את מהירות העיבוד בצורה דרסטית בהתאם לטמפרטורות בכרטיס).

כתוצאה מכך, כל פלטפורמות הפיתוח (TensorFlow, Caffe וכו' וכו') תומכות בצורה מלאה ב-CUDA, כמו שהן תומכות בכרטיסי GPU אחרים (אם אין לך GPU של NVidia, אין שום בעיה לעבוד עם כרטיס GPU אחר, או עם ה-GPU המובנה או עם המעבד עצמו – הביצועים יהיו בהתאם). אם ביצועי GPU יחיד של NVidia אינם מספקים אותך (ורכשת כרטיס RTX 2080 ומעלה), תוכל להוסיף GPU נוסף (ויותר) ולחבר ביניהם עם מחבר NVLink שנמצא בחלק העליון של הכרטיס. פלטפורמת CUDA יודעת לזהות מיידית את הכרטיס ולחלק את העבודה ביניהם, תוך כדי שהיא נותנת "ציון" לכל GPU ובהתאם לכך היא מחלקת את העומסים.

כשזה מגיע לעננים ציבוריים, התמונה משתנה במעט. אם אתם משתמשים בעננים של אמזון או מיקרוסופט, אתם יכולים לשכור Instance הכולל GPU של Nvidia (מיקרוסופט מאפשרת כיום גם לשכור GPU של AMD, תיכף אתייחס לכך) ואילו גוגל מציעה ללקוחותיה לשכור Instance עם GPU של NVidia או עם פתרון משלהם שנקרא TPU (שנותן ביצועים שאינם נמוכים ממה ש-NVidia יכולה להציע גם עם הכרטיס הכי חזק שלה).

כאן מתחיל העניין שנקרא תחרות, ואת התחרות מייצג פתרון שנקרא OpenCL. פתרון OpenCL זקוק למימוש בדרייבר עצמו וכל יצרן (כולל NVidia) כותב זאת ומציע זאת ללקוחותיו. היתרון המוחץ של OpenCL על CUDA, הוא בכך שהוא מזכיר את OpenGL ו-DirectX – אתה יכול להשתמש באיזה GPU שתרצה, ובהתאם למימוש בדרייבר – התוצאות יהיו בהתאם. גם ה-TPU של גוגל וגם הפתרון GPU של AMD משתמשים ב-OpenCL במימושים שונים על מנת לאפשר למפתחים ולפלטפורמות את תמיכת ה-OpenCL שהן דורשות. (למעוניינים, להלן לינק המשווה בין OpenCL לבין CUDA. מי שמחפש את הגירסה המקוצרת: CUDA = פתרון סגור, OpenCL = פתרון פתוח לחלוטין שנתמך בכל GPU)

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

  • אינטל הכריזה לאחרונה על שני פתרונות ל-AI (גאווה ישראלית: הם פותחו כאן בארץ). הפתרונות הללו לא רק תומכים ב-OpenCL אלא במגוון פלטפורמות וכמיטב המסורת של אינטל בקטע הזה, הכל בקוד פתוח. זהו הכרטיס הראשון ל-AI ו-DL שמשתמש ב-PCIe 4 X16. הקטע האירוני: בשביל להשתמש בכל רוחב הפס, תצטרך כיום .. מעבד ולוח של AMD..
  • עוד פתרון חומרה כחול לבן הוא של חברת Habana שמציעים את GOYA ככרטיס למחשב ושרת, ואת GAUDI כפתרון כחלק ממערכת מלאה (כרטיס יעודי). גם כאן, יש תמיכה מלאה ל-OpenCL ומגוון פלטפורמות AI ו-DL.
  • עוד פתרון מגיע מסין מחברה מאוד ידועה – Huawei, אם כי בניגוד לשאר, החברה הציגה מעבד בלבד (כלומר לא פתרון קצר) בשם Ascend 910 שהחברה טוענת שהוא מעבד ה-AI הכי מהיר בעולם.
  • ל-AMD יש כרגע את כרטיסי ה-GPU מסידרת Instinct ל-AI ו-DL. החברה מתעתדת בחודשים הקרובים להכריז על הדור הבא.
  • אינטל (כן, שוב) – מתעתדת בשנה הקרובה להוציא משפחת כרטיסי GPU חדשים שתתחרה הן ב-GPU הרגילים של NVidia ו-AMD והן GPU למטרות AI ו-DL – הם יהיו תחת משפחה בשם "Xe".

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

דבר שחשוב לדעת: שוק פתרונות החומרה ל-DL, AI מתחיל להשתנות ולפצל דברים ל-2: יש את פתרונות ה-Training (כלומר – הדברים שרצים אצלכם בחברה – אתם "מזינים" אלפי תמונות/וידאו וכו' ומאמנים את המערכת) ויש את החלק של Inference שצריך להתמודד עם העולם האמיתי, והחלק של ה-Inference אמור לכלול פתרון יעודי (כרטיס מיוחד או חלק מלוח אם) שישולב בפתרון החומרה שיותקן אצל הלקוח.

עוד נקודה חשובה: ישנם כל מיני אנשים שממליצים לבצע את ה-Inference על מעבדים. אם אתם רוצים לעשות זאת על מעבדים, קחו את המעבדי EPYC החדשים של AMD – גם תחסכו 40-70% במחיר (תלוי בכמות הליבות) ותוכלו לבחור מעבד עם עד 64 ליבות או 2 מעבדים עם 128 ליבות (שימו לב: אתם צריכים את הסידרה החדשה 7XX2, לא את הישנה 7XX1).

לסיכום: כמו תמיד, אינני ממליץ לשים את כל הביצים בסל אחד. כן, הפתרון של NVidia הוא פתרון מעולה אך הוא פתרון סגור שרץ רק על הכרטיסים של Nvidia. אם אתם מפתחים פלטפורמה או קוד בפלטפורמה או אפליקציה משלכם, תבדקו אם היא עובדת עם OpenCL. אחרי הכל – אינכם יודעים מה הלקוח שלכם ירצה להריץ וחבל למצוא את עצמכם בדקה ה-90 מציעים פתרון שלא יכול לרוץ בתשתית של הלקוח. השוק ישתנה ב-2020 ועוד יותר ב-2021 (לכל החברות "נפתחו העיניים" וכולם רוצים את הרווחים המאוד נאים ממכירות כרטיסים ופתרונות כאלו).

האם תוכניות DR באחסון ישראלי שוות את הכסף?

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

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

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

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

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

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

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

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

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

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

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

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

(גילוי נאות: "חץ ביז" מציע את שרותי ה-DR לעננים ציבוריים)

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

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

כמה מילים על Azure Stack וספקי אינטרנט

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

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

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

מערכת Azure Stack בנויה לשימוש ב-2 אופנים: Connected ו-Disconnected, כאשר ב-Connected אתם יכולים להעביר את התשתית הוירטואלית/מכונות/קונטיינרים/אחסון לענן האמיתי של Azure ובמצב Disconnected – האינטרנט מנותק, והכל רץ מקומית בארונות של ספק ה-Azure Stack שלכם (או אצלכם מקומית אם רכשתם את המערכת).

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

החסרונות של Azure Stack לעומת היתרונות – גדולים:

  • הסיבה המרכזית שחברות עוברות לענן – זה ה-Scaling שאותו לא מקבלים באותה צורה ובאותו גדול בהשוואה לענן עצמו. כנ"ל לגבי שרידות – לכל ספק ענן ציבורי יש Zones ויש Regions ואפשר להקים שרידות נפלאה. איזו שרידות תקים ב-Azure Stack? בין שרתים שהכל מקומית? אנשים שוכחים בכל פעם את התקלות שיש פה לכל מיני ISP שמשביתות אלפי לקוחות במכה אחת, ובענן ציבורי אפשר לבנות מערכת שגם תעמוד ברעידות אדמה, זה לא כזה מסובך.
  • ביצועים – עם Azure Stack אנחנו חוזרים שוב למודל ה-Enterprise מבחינת ציוד, וזאת בניגוד מוחלט למה שיש בענן ציבורי: באף ענן ציבורי אין שרתי מותג, אין דיסקים Enterprise, אין מתגים של מותג מסוים – הכל בניה "מקומית", החל מרמת המעבד והזכרון וכלה באוורור, ובעברית: מכונת VM שרצה בענן תרוץ יותר לאט על השרתים הקנייניים שמריצים את Azure Stack כי גם המעבד וגם הזכרון שונים (ספקי ענן רוכשים גרסאות Custom של מעבדים וזכרונות הרבה יותר מהירים ממה שיש בשרתים הרגילים).
  • מחירים: בניגוד למצב רגיל שאתה לוקח מספק Hosting כלשהו מכונת VM נניח עם 4 ליבות, 8 ג'יגה זכרון, 40 ג'יגה דיסק ותעבורה של 5 מגהביט והכל כלול במחיר אחד – כאן הכל שונה, אתה משלם על כל פיפס בנפרד. נתראה בחשבונית החודשית (וכן – התכוונתי ל-Azure Stack. מיקרוסופט מכתיבה זאת).
  • שרותים – הבסיסיים נמצאים + עוד כמה שרותים. השאר? עדיין נמצאים רק בענן הציבורי.
  • תאימות API בין ריצה ב-Azure Stack ל-Azure הרגיל – חלקית בלבד. תצטרכו לעשות לא מעט פליק פלאק כדי להעביר דברים מהענן מקומית וההיפך.

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

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

פרילאנס: חשיבות הלבוש בראיונות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

למי מתאים OpenStack?

"היי חץ, אנחנו שוקלים מעבר מפלטפורמת VMWare למשהו אחר, עדיף יותר זול. האם OpenStack יכול להתאים לנו?"

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

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

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

  • הקמת והגדרת Cluster
  • ביצוע Live Migration למספר מכונות VM בין Clusters
  • ביצוע Live Migration בין 2 Datastores
  • הגדרות Fault Tolerance

איך אתם תבצעו את הדברים?

  • דרך ה-Vcenter web client (הממשק הוובי) או ה-vcenter client שרץ על מכונת Windows
  • דרך PowerShell או דרך סקריפטים שכתבתם בפייתון או בשפה אחרת

התוצאות:

  • אם אתם משתמשים אך ורק בכלי ה-GUI/WEB ש-VMWare מספקת – תרדו מהמחשבה על מעבר ל-OpenStack.
  • אם אתם "פוחדים"/מתעצלים/לא מעוניינים להשתמש ב-API או לכתוב סקריפטים לאוטומציה או שימוש On Demand במקרה הצורך – רדו מ-OpenStack.

בקיצור – אם אתם הטיפוסים של "קליק קליק קליק" – OpenStack לחלוטין אינו מתאים לכם.

ברכותיי, חסכתם כמה מאות שקלים של דמי יעוץ 🙂

אחד הדברים שבגינם אני כותב את הפוסט הזה, זו המחשבה המוטעית ש-OpenStack הוא איזה פתרון CSN (כלומר Compute, Storage, Network) שמהווה תחליף ל-VMware. מבחינה טכנית "על הנייר" – הוא מסוגל בהחלט לתת שרותי CSN, אבל לא בשביל זה קונים ומטמיעים את OpenStack, כמו שלא מקימים מערכת Kubernetes בשביל להריץ 2-3 קונטיינרים.

הדברים שצריך להבין לגבי ה-OpenStack ומדוע הוא ה"דארלינג" של כל עסק HyperScale (כלומר עסק גדול שנותן שרותי ענן – כמו רוב חברות התקשורת הגדולות בחו"ל – AT&T, Verizon, SK-Telecom ועוד רבים אחרים) הם דברים מהותיים כמו:

  • OpenStack מאפשר לך להקים שרותים כמו Object ו-Block storage מצד אחד, אבל מצד שני, OpenStack יכול להתחבר בקלות לסטורג' שלך ולקבל את השרותים מהסטורג', וכל יצרני הסטורג' הגדולים (והיקרים) תומכים ב-OpenStack. שלח מייל ליצרן הסטורג' שרכשתם ותקבל בחזרה קובץ PDF או קישור איך לחבר ביניהם, כך ש-OpenStack לא מנסה להתחרות ביצרניות האחרות, אבל מצד שני אם אין לך את המשאבים/תקציב – הוא מאפשר לך להקים פתרון.
    אותו דבר מבחינת שרותי וירטואליזציה – אתה יכול להשתמש בשרותי ה-KVM של OpenStack או לחבר את ה-vSphere אל ה-OpenStack כך שמערכות ESXI יריצו את המכונות הוירטואליות. הנה התיעוד.
  • מבחינת רשתות (סיבה עיקרית שחברות הטלקום אוהבות אותו) ה-NFV (כלומר Network Functions Virtualized) של OpenStack מאפשר להתרחב למימדים מפלצתיים! גם כאן, אפשר או להקים או פשוט לפנות ליצרן ציוד התקשורת שלך שכבר תומך מספר שנים ב-OpenStack (כן, כל הגדולים תומכים).
  • שרותים, שרותים, שרותים: OpenStack התחילה את חייה כמערכת IAAS קלאסית, אבל כיום OpenStack מציעה מאות שרותים שאתה יכול לשלב ל-OpenStack ולתת/למכור את השרותים הללו ללקוחות. הלקוח רוצה שרותי ניהול DNS? אולי DB? להריץ קונטיינרים ב-Kubernetes או OpenShift? ניהול, הקמת והגדרות ברזלים (Provisioning)? שרותי Identity? שרותי Telemetry ועוד? יש, רק תגדיר במערכת ותתחיל להשתמש ולהציע ללקוחות – ולמנמר"ים שכמובן חושבים על תקציבים ותשלומים בראש ובראשונה – אני רוצה להכיר לכם את … CloudKitty.

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

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

ה"חסרון" של OpenStack – הוא שמדובר במערכת שאינה "קליק קליק קליק". כן, יש ממשק Web אך הוא יחסית די בסיסי (במיוחד אם מנסים להשוות אותו לממשקים כמו של VMWare) ורוב העבודה נעשית מול API או binding עם שפות כמו Python. זו מערכת מסובכת, מורכבת, אבל לאחרונה (בגירסת Stein) קיימת תת-מערכת חדשה, AirShip שמאפשרת הקמה והגדרת דברים בצורה קצת יותר קלה – עם YAML (אגב, למי שרוצה לשחק עם Airship על מכונת לינוקס, אפשר להריץ את הפקודות כאן ולהתרשם בעצמכם).

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

קליפים על הקמה/שימוש ב-OpenStack – בקרוב.

אחסון Scale Out בקוד פתוח – פוסט עדכון

כתבתי בעבר לגבי Ceph ולגבי GlusterFS. בפוסט זה אנסה לענות לשאלה שחוזרת מדי פעם אצלי באימייל: במי מהם לבחור אם הולכים על Scale Out Storage?

בשביל לענות, נתחיל מההתחלה הפשוטה: רוב הארגונים רוכשים לעצמם סטורג' קנייני כלשהו שעובד בשיטת ה-Scale Up: רוצה יותר אחסון? תוסיף מדפי דיסקים, SSD, Cache וכו' וכו'. ברוב הארגונים לעומת זאת, כשחושבים לדוגמא על Cluster Storage במובן של 2-3 מכונות סטורג' נפרדות שמסונכרנות ביניהם – המחיר של הפתרון הקנייני מרתיע ואז מתחילים להישלח אימיילים ולחייג ליועצים שונים.

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

כיום, אני שמח לציין, שום ארגון רציני (כולל משרדי ממשלה, משרד הבטחון וכו') לא פוסל מלשמוע הצעות על SDS (כלומר Software Defined Storage) מבוסס קוד פתוח, במיוחד שיש לזה "אבא" בארץ כמו Red Hat או SuSE. בכל הארגונים שציינתי יש פתרונות של יצרני הפצות הלינוקס הנ"ל.

מבחינת תחרות, יש 2 פתרונות, וכל אחד מהם מיועד לשוק ולצרכים מסויימים. אף אחד מהם לא הולך "לסגור את הבאסטה" בקרוב. 2 הפתרונות הם Ceph מול GlusterFS. את Ceph אפשר לרכוש מ-Red Hat ו-SuSE, ואת Gluster מ-Red Hat (את שתיהם כמובן אפשר להוריד בחינם, אבל אני לא ממליץ במערכות פרודקשן קריטיות להריץ את הגרסאות קוד פתוח).

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

  • משרד האוצר פונה אליי בבקשה להקים SDS בגודל 4 פטהבייט שיאכסן ארכיב של מידע ישן: הודעות לעיתונות, גיבויים, מסמכי הצעות שונות ותוכן נוסף שכולו מורכב מקבצי אופיס ופורמטים אחרים. הגישה אל האחסון למשתמשים תהיה דרך SMB/CIFS בלבד עם הרשאות AD. אין גישת Web או שום דבר אחר. אחסון קבצים קלאסי.
    ההצעה שלי אליהם: GlusterFS.
    מדוע? GlusterFS מיועד לתת גישה לקבצים בלבד, בין אם דרך NFS או SMB/CIFS. קל להרחיב אותו (מוסיפים עוד ברזלים עם דיסקים, מחברים לסוויצ', מתקינים מערכת הפעלה, מריצים כמה סקריטפים ותוך שעות ספורות יש עוד כמה מאות טרהבייט זמינים) והרבה יותר קל לנהל אותו בהשוואה ל-Ceph.
  • ערוץ "כאן" פונה בבקשה להקים SDS בגודל 20 פטהבייט. בסטורג' הזה יאוחסן כל הסרטים, הסדרות, החדשות וכל מה שצולם עוד מימי הערוץ הראשון והטלויזיה החינוכית – והכל יהיה זמין דרך פורטל VOD לגולשים בארץ דרך נגן HTML5 יעודי והוידאו יוגש בזרימה או להורדה לתצוגה ב-Offline.
    ההצעה שלי אליהם: Ceph.
    מדוע? במערכת Ceph כל דבר שמאוחסן – מאוחסן כאובייקטים שבתוכם יאוחסנו הנתונים בפורמט שאנחנו רוצים. במקרה של "כאן" לדוגמא – כל קבצי הוידאו יאוחסנו כ-Object Storage וכל קליפ מקבל זיהוי יעודי משלו, מה שעוזר מאוד בגישה מהירה לקליפ ולהתחלת השידור שלו. כך, אגב, רוב חברות המדיה מאחסנות באמזון את קבצי הוידאו שלהם (ב-S3 ולא תחת File system עם איזה סטורג' כלשהו). ל-Ceph יש יתרון של Seek מהיר מאוד, והעברת מידע מהירה.
  • משרד הבטחון מקים מרכז מיחשוב חדש לאחד מהחילות. במרכז יהיו 200 שרתים פיזיים שיריצו וירטואליזציה כלשהי (נניח OpenStack או VMware) ומערכת Kubernetes או OpenShift. במשרד מעוניינים ב-SDS בגודל 30 פטהבייט עם אופציה לגדילה מהירה.
    ההצעה שלי אליהם: Ceph
    מדוע? כי Ceph יכול לאפשר ליצור Block Devices וירטואליים וגישת קבצים קלאסית (File System – CephFS) עם שרידות גבוהה. אם לדוגמא הם ישתמשו ב-OpenStack, הם יכולים ליצור דרך Ceph דבר שנקרא RBD (כלומר Raw Block Devices) ואם הם משתמשים ב-VMware – הם יכולים לקבל iSCSI כמו שהם רגילים אליו, ואם הם מעוניינים ב-NFS – אפשר ליצור ולייצא את זה מ-Ceph דרך ה-CephFS ואפשרי לתת להם גם שרותי PV ל-Kubernetes לדוגמא.
  • חברת "שופרסל" מעוניינת ב-SDS  בגודל 5 פטהבייט שיאכסן גיבויים, קבצים וכו'. הם מעוניינים שבחוות שרתים אחרת ישב SDS זהה עם סינכרון מתמשך בין ה-2.
    ההצעה שלי: GlusterFS
    מדוע? מכיוון שגם כאן מדובר בקבצים בלבד בשיטה המסורתית ו-GlusterFS כולל  בתוכו פונקציות לסינכרון מתמשך בתנאי תקשורת שונים מבלי להעמיס על התקשורת או להאיט את שרותי ה-File Server.

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

נסכם את היתרונות והחסרונות של כל מערכת SDS:

  • ל-Ceph יש יתרון גדול בכך שזו מערכת רצינית לתת לך כל סוג של פורמט נתונים שאתה רוצה, בין אם מדובר ב-File Server קלאסי, Block Device, Object Storage ועוד. למערכת יש שרידות מצוינת (כך שאם נופל שרת Ceph – המערכת ממשיכה לעבוד כרגיל). ב-Ceph יש תמיכה ל-tiering, דחיסה, Dedup וכל הדברים שמוצאים ב-Scale Up.
  • ל-GlusterFS יש יתרון בכך שהיא מיועדת בדיוק לדברים הקלאסים של File Server (דרך CIFS/NFS) ותו לא. אפשר להקים אותה על ברזלים ישנים, היא תומכת גם ב-RAID חומרה או RAID תוכנה, היא לא דורשת המון משאבים (מבחינת CPU/זכרון) וממש לא אכפת לה מה ה-File System מתחתיה. ל-GlusterFS יש Load Balancing מובנה, כך שאם יש צורך ב-File Server שישרת מאות משתמשים ובגדלים של עשרות או מאות טרהבייט ומעלה – GlusterFS היא בחירה טובה ויחסית קלה יותר ללימוד בהשוואה ל-Ceph.

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