קטגוריה: כללי

דעה: על רכישת CoreOS ע"י רד-האט

[stextbox id='info' caption='הערה']הדברים הנכתבים כאן הינם דעתי האישית, אינני כותב מטעם Red Hat[/stextbox]

בימים האחרונים פורסמו באתרי טכנולוגיה שונים החדשות כי חברת רד-האט רכשה את חברת CoreOS. חברת CoreOS היתה מתחרה של רד-האט בכל הקשור למערכת לניהול Kubernetes (בשם Tectonic), ניהול Registry לקונטיינרים (Quay), וכמו כן את Container Linux (מערכת הפעלה מצומצמת להפעלת קונטיינרים) וכמובן את etcd שהוצאה כקוד פתוח ורבים (כולל רד-האט) משתמשים בו.

רד-האט (Red Hat) כידוע, היא החברה הכי גדולה בהפצת לינוקס ובמערכות מבוססות קוד פתוח ומטבע הדברים, כשהיא רוכשת חברות קטנות אחרות, יהיו כאלו שידאגו מה יהיה עם המוצרים שהם רכשו, מה עם תחרות וכו' וכו'. בפוסט זה אנסה להסביר מה הולך לקרות לדעתי בהתבסס על רכישות קודמות של רד-האט (כמו Qumranet, InkTank, Gluster ואחרים).

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

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

  • אחד הדברים הראשונים שלדעתי הולכים להשתנות הוא דווקא בצד של רד-האט והוא מוצר ה-Atomic Host. אינני חושב ש-Atomic Host ימחק, אבל יכול להיות שיהיו שינויים שיגיעו מ-Container Linux של CoreOS.
  • בכל מה שקשור ל-Registry, אני בספק אם יהיו שינויים רציניים אם בכלל במוצרים של רד-האט. ה-Registry הנוכחי שקיים ב-OpenShift לא ממש שונה למיטב זכרוני ממה שקיים ב-Quay, אבל יכול להיות שיהיו שינויים מעטים.
  • לגבי Tectonic – כאן זו שאלת המיליון דולר. רד-האט מייעדת את OpenShift ללקוחות גדולים, אלו שמוכנים לשלם כמה עשרות אלפי דולרים על מערכת OpenShift Enterprise (ועוד 2000-3000$ פר Node, ויש עוד כמה תשלומים על כל מיני חלקים) ורד-האט כבר הפיקה לקחים מהעבר לא לעצבן את הלקוחות הגדולים בשבירת תאימות אחורה. אני מאמין שבשנה שנתיים הקרובות יהיו 2 מוצרים: יהיה Tectonic שכולל שינויים (והמרה/תמיכה בפורמט קודם) להיות תואם לפורמט של OpenShift והוא ייועד לתחום ה-SMB (כלומר Small/Medium Business) ותהיה מערכת ה-OpenShift Enterprise שתוכל להמיר מערכת Tectonic ל-OpenShift – לאלו שגודלים ורוצים לעבור ל-OpenShift Enterprise.
  • לגבי etcd – השינויים שיהיו הם מול ה-Upstream, כלומר מה ש-CoreOS קובעים (פחות או יותר) יכנס ל-OpenShift.
  • לגבי RKT – יכול להיות שיקחו חלקים ממנו לצרכי שיפור Docker Container Engine (אני בספק) אבל אישית אני לא רואה את זה ממשיך כמוצר מסחרי.
  • לגבי השאר – כל פרויקט יעבור בחינה אם הוא מתאים לשילוב בדברים קיימים או שהוא ישאר ב-github.

רבים ישאלו: מדוע בעצם רד-האט רכשה את CoreOS? הרי יש להם מוצר כמו OpenShift הן בגירסת Online (שכל אחד יכול להיות מנוי ולהקים קונטיינרים מבלי להרים מקומית מאומה) והן גירסת Enterprise, אז מה להם ול-CoreOS? התשובה היא פשוטה: גודל שוק ולקוחות. השוק יותר ויותר מתרכז סביב פתרונות גדולים, בין אם מדובר בפתרונות ענן של ספקי הענן הציבורי, פתרון Kubernetes ישיר (גירסת הקוד הפתוח) או פתרון ניהול קונטיינרים מבוסס Kubernetes עם "פנים" ל-Enterprise. תמיד יהיו פתרונות כמו DC/OS, Rancher ואחרים שיכולים להתאים לכל מיני סקטורים, אבל ה-Enterprise דורש דברים אחרים ש-Kubernetes עצמו לא נותן לא מבחינת אבטחה, לא מבחינת רגולציה, עמידה בסטנדרטים משפטיים ועוד, והדבר הכי קרוב שיש עבור Enterprise כולל הדרישות הגבוהות שלהם (ולאלו שמוכנים לשלם) זה OpenShift.

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

להטמיע סטורג' בקוד פתוח או לא? מה השיקולים?

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

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

מכאן נעבור לצד הטכני: האם מערכות סטורג' בקוד פתוח יכולות להוות תחרות מול סטורג' קנייני מבחינה טכנולוגית? התשובה: כן. האם הן יכולות לתת את 3 השרותים העיקריים שחברות מחפשות (CIFS/SMB, NFS, iSCSI)? בחלק המקרים. האם הן יכולות לגדול (Scale Out)? גם – בחלק מהמקרים. על מנת לפשט דברים, יצרתי טבלה פשוטה עם 3 המתמודדים הידועים בקוד פתוח, מה הם מסוגלים לתת ומה לא.

סוג מערכת NFS iSCSI CIFS/SMB Scale Out Scale Up
ZFS 2✔ 1✔ ✔ 3✔
GlusterFS ✔ ✔ 4✔
Ceph ✔ ✔ ✔ ✔

1 תמיכת iSCSI ב-ZFS על לינוקס עבור VMWare כולל תמיכת VAAI מחייבת Kernel 4.4 ומעלה.
2 תמיכת NFS ב-ZFS על לינוקס תלויה בגירסת הפצת הלינוקס
3 ניתן לעבוד עם ZFS בלינוקס כ-Cluster בשימוש כלים כמו Sanoid או PaceMaker.
4 למרות שניתן לעבוד עם GlusterFS ב-2 שרתים – הדבר אינו מומלץ מעבר לרמת POC.

אלו המערכות העיקריות. לכל מערכת יש מספר גרסאות מסחריות (למעט GlusterFS). מערכת כמו ZFS ניתן לרכוש מערכת עם "ברזלים" ישירות מ-Oracle או ניתן להתקין FreeNAS, או להקים על שרת לינוקס עם הפצת Debian לדוגמא. תוכנת Ceph ניתנת לרכישה מ-רד-האט או מ-SuSE.

כשזה מגיע לתמיכה/תחזוקה – הדברים שונים בהתאם לגודל העסק/חברה:

  • לעסק קטן שמחפש סטורג' ואולי סטורג' עם שרת ב-Standby (כלומר Active/Passive – כ-Scale Up) הייתי ממליץ לבחור פתרון מבוסס ZFS. אם הלקוח מחפש פתרון Scale Out של כמה טרהבייט, אז אמליץ על GlusterFS וחוזה תמיכה עם אינטגרטור.
  • לעסקים בינוניים וגדולים, אם העסק מחפש פתרון מבוסס קוד פתוח ב-Scale Up, הייתי ממליץ על ZFS ופתרון Scale Out מבוסס Gluster. אם החברה מחפשת פתרון Scale Out בגדלים של Petabyte, אני ממליץ על Ceph. במקרים של GlusterFS ו-Ceph אני ממליץ לחברה לרכוש את התוכנה מהיצרן כולל תמיכה, כך שהאינטגרטור יתן תמיכה ואם יש עדיין בעיה – ניתן לפנות ליצרן התוכנה כך שבכל מקרה החברה מכוסה מבחינת תקלות תוכנה.
  • לחברות גדולות המחפשות פתרון סטורג' גדול מבחינת כמות DATA (שוב, פטהבייטים ומעלה) – אני ממליץ על ישיבה ויעוץ לגבי הפתרון מכיוון שבכל מקרה הפתרון הוא יקר ויש צורך לשמוע את 2 הצדדים (פתרון קנייני ופתרון מבוסס קוד פתוח).

בכל אחד מהסוגי לקוחות, הפתרונות המוצעים כוללים פתרון שרידות כך שלמעט תקלות חומרה או הפסקת חשמל, המערכת אמורה לשרוד נפילה אם יש תקלת תוכנה בסטורג' עצמו. אגב, בהזדמנות זו אני רוצה להדגיש: כאשר אתם קונים פתרון סטורג' שהוא Scale Up מ-NetApp או Dell/EMC, פתרון השרידות שלו הוא חלקי: זה שיש בקר RAID כפול, 2 מעבדים – תקלות כמו בעיית זכרון (ECC יכול לתקן תקלות עד גבול מסויים), או בעיה בלוח האם ב"ראש" – הסטורג' יפול, וכדאי לקחת זאת בחשבון כשרוכשים פתרון.

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

הבאג הקריטי במעבדי אינטל

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

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

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

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

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

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

איזה מחיר? בביצועים. תלוי מה האפליקציות שאתם מריצים ולאיזה ציוד הם ניגשים – הביצועים ירדו בין 3 ל-30 אחוז אחרי התקנת הטלאי (הטלאי יהיה חובה בכל מערכות ההפעלה). במילים אחרות – אם אתם לדוגמא מריצים מערכת מורכבת נניח על 10 מכונות VM, אחרי התקנת הטלאי ועל מנת לקבל את אותם ביצועים – תצטרכו בין VM ל-3 VM נוספים. ישנם דברים שאינם מושפעים והם יותר קשורים למכונות דסקטופ או מחשבים ניידים כמו משחקים, קידוד וידאו ועוד מספר דברים. הפרטים יתבהרו יותר בשבוע הבא, אבל הנה דוגמאת גרף של מעבד דסקטופ חדש (משפחת CofeeLake, מעבד i7 8700K) בהשוואה למעבד i7 מלפני 2 דורות: ה-i7 6800K (תודה לאתר phoronix.com על הגרפים)

הפס הסגול מציין מצב לפני הטמעת טלאי במערכות Linux והפס הירוק – אחרי. הבדיקה היא גישת יצירה/כתיבה/קריאה ל-4000 קבצים שנמצאים במכונה, בתוך 32 תיקיות, כל קובץ בגודל 1 מגהבייט. כפי שאתם יכולים לראות – לאחר ההטמעה כמו שניתן לראות במעבד החדש – המהירות צונחת חזק מטה. אגב, הגרף נוצר עם בדיקות על Linux אולם גם אם תשנו מערכת הפעלה, התמונה תהיה פחות או יותר אותו דבר.

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

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

קצת על בנקים, מודרניזציה ותשובות למר איל מוסקל

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

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

אז נתחיל עם ה-Mainframe. רבים מהקוראים בוודאי חושבים שמדובר על טכנולוגיה עתיקה וישנהאך אין הדבר כך. נכון, IBM שומרת בקנאות פנאטית על תאימות כמה דורות אחורה, אבל מערכות Mainframe מתעדכנות מבחינת חומרה נון-סטופ ומבחינת ביצועים, מעבד כמו ה-Power9 "מרביץ" למעבדים כמו Xeon-SP בכל מובן שתבחרו. בנוסף, אחד היתרונות הגדולים של מערכות Mainframe הוא תחזוקת חומרה. בשרתים רגילים, אנחנו יכולים להחליף דיסק קשיח מבלי לכבות את השרת או ספק כח, ב-Mainframe אתה יכול להחליף כמעט הכל – מעבדים, כרטיסי PCIE, זכרונות בזמן שהמערכת פעילה והיציבות של המערכת היא אחד הדברים ש-IBM בהחלט יכולים להתגאות בו. זה פשוט לא נופל.

בעבר רוב האפליקציות שנכתבו ל-Mainframe אכן היו ב-COBOL ויש חלק לא קטן מהקוד שעדיין רץ ב-COBOL, אבל בשנים האחרונות בנקים שיש להם Mainframe החלו להשתמש בפונקציונאליות חדשה ש-IBM הכניסו: להריץ מכונות Linux כ-VM על ה-Mainframe בצורה טבעית (ללא אמולציה של X86) עם ביצועים מאוד מהירים בעזרת כרטיסים יעודיים עם מעבדי Power8 (ובזמן האחרון Power9) שמיועדים להריץ Linux. כך הבנקים נהנים מ-2 יתרונות גדולים: אפליקציות Linux שרצות באופן טבעי על Mainframe ובנוסף מערכת ה-Mainframe יציבה מאין כמוה.

לגבי שפת COBOL – נכון, היא שפת תכנות עתיקה (משנות ה-50) אולם היא עברה עדכונים רבים וסטנדרט ה-COBOL גם עבר עדכונים וכיום הסטנדרט ב-COBOL הוא ISO/IEC 1989:2014 – כלומר יש בהחלט עדכונים לשפה. נכון, היא שונה משפות כמו Python, Go, Perl וכו' אך מצד שני היא לא כזו קשה ללימוד, זו שפה שיותר מבוססת על השפה האנגלית.

אחד הדברים שמר מוסקל לא מתייחס אליהם הוא נושא פרויקטים שהבנקים (כל הבנקים) מבצעים: שכתוב מחדש של קוד COBOL ישן ל-Java מודרני. אף בנק לא מעוניין "להיתקע" עם מערכת ישנה שאין לה אף אחד שיתחזק אותה, ולכן מבוצעים הפרויקטים הנ"ל, ובבנקים נכנסים יותר ויותר לעבודה עם כלים סטדנרטיים כמו GIT, יש גם Jenkins שיודע להתחבר ל-zOS (מערכת ההפעלה העדכנית של ה-Mainframe של IBM) וגירסת Docker Enterprise Edition 17.06 יודעת להתחבר למערכות System Z (ה-Mainframe) להריץ קונטיינרים על Linux שרץ ב-Mainframe.

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

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

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

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

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

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

כשצריכים VPN טוב ובחינם

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

לכן, חיבור VPN הוא חשוב ורוב העסקים והחברות רוכשים קופסאות Appliance (או VM) של VPN מיצרניות מוכרות כמו Cisco, Fortinet, Juniper, Check Point, Palo Alto ועוד רבים אחרים. לאלו שמעוניינים בחיבורים בודדים, יש את ה-OpenVPN שמאפשר עד 2 חיבורים סימולטנית ללא תשלום, וניתן כמובן לרכוש רשיונות נוספים. אפשרות נוספת בקוד פתוח היא StrongSwan שמאפשר חיבוריות בין שרת VPN לכל מכונת לינוקס/מק/Windows.

אפשרות פופולרית חדשה שקיימת נקראת Wir eGuard ולמרות ש-Wire Guard אינו מתאים להחליף VPN כ-Client/Server עדיין (אין עדיין Clients ל-Windows ומק אם כי הוא יכול לשמש כ-Client/Server בין מערכות לינוקס), הוא יכול לסייע במקום אחר שהוא מאוד חשוב.

נניח ויש לנו מספר שרתים בחוות שרתים ביפו, וישנה קבוצה של עובדים שיושבים בחיפה שצריכים להתחבר לאותם שרתים. חיבור בשיטת ה-Client/Server לכל מחשב שיושב בחיפה למחשבים שיושבים ביפו אינו פתרון יעיל מכיוון שעדיף חיבור שיוצר מעין "LAN" (או ליתר דיוק: WAN) שרץ בעצם על ה-VPN, ואז בעצם אנחנו מחברים בשיטה שנקראת Site to Site VPN. כך לדוגמא עובדות חברות שיווק רבות שיש ברשותן סניפים, כאשר בכל סניף יש מספר מחשבים מקומיים.

כל היצרנים המסחריים מציעים כמובן במסגרת חבילת ה-VPN גם שרות Site to Site (או בקיצור S2S, יש כאלו שמחליפים זאת ב-StS), אך במקרים רבים השרות הנ"ל כרוך בתשלום נוסף, וכאן ל-WireGuard יש יתרון גדול.

תוכנת ה-WireGuard נכתבה בצורה כזו שהיא מפיקה לקחים מפתרונות VPN ישנים יותר (ה-WireGuard זמין בצורה יציבה בערך שנה וחצי) והיא תומכת ב-cryptographic primitives ידועים כגון: Curve25519, HKDF, ChaCha20, Poly1305, BLAKE2s, SipHash24 (אפשר לראות מה כל אחד משמש כאן). בנוסף התוכנה כתובה בצורה יעילה וכל הקובץ הבינארי שוקל … 4 קילובייט כך שטווח התקיפה הוא מאוד קטן (נסו להשוות לכל תוכנת VPN אחרת), הוא רץ ברמת Kernel והביצועים שהוא נותן עוקפים פתרונות אחרים בקוד פתוח (כפי שאפשר לראות כאן), להלן גרפים לדוגמא:

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

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

כמה מילים על הטמעת CUDA

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

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

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

  1. כרטיסי ה-Quadro מגיעים עם יותר זכרון (בגרסאות הדסקטופ, לא בגירסאות ה-Mobile) בהשוואה ל-GTX. בכרטיסים מסויימים יש לא פחות מ-24 ג'יגהבייט זכרון (שהוא מאוד יקר), מה שנותן לאפליקציות שמשתמשות ב-CUDA יותר מקום והביצועים מהירים פי כמה בהשוואה ל-GTX.
  2. הכרטיס כולו בנוי בצורה מעט שונה (אם כי לא רואים זאת ישר). כרטיסי Quadro מיועדים לעבוד 24/7 באופן רציף בתפוקה מלאה, וזאת בניגוד למשתמש טיפוסי של GTX שמשחק פה ושם משחקים או מרנדר וידאו מלא (או 2) ביום. הכרטיסים בנויים עם איוורור מעט שונה וגם האחריות בהתאם – לכרטיס Quadro יש אחריות ל-5 שנים.
  3. לכרטיסי Quadro יש דרייברים מיוחדים המפעילים פונקציות שאינן פעילות כלל ב-GTX. החסרון (אם אפשר לקרוא לזה כך) זה שכרטיסי Quadro אינם מתאימים כל כך למשחקים אך הם בהחלט מתאימים לעבודות מאסיביות והדרייברים מאפשרים שלל תכונות שדרושות בדיוק לסוג העבודות הללו.

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

מכאן נעבור להתקנת CUDA.

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

  • כשזה מגיע לגירסת לינוקס – אין להתקין גירסת לינוקס שמיועדת לדסקטופ, כלומר אובונטו 15,16,17 (בין אם בגרסאות 04. או 10.) שמיועדות לדסקטופ אינן מתאימות לפרודקשן הואיל והעבודות שירוצו עם ה-CUDA הן למשך מספר שנים ולא לשנה שנתיים, ובנוסף – נדרשת יציבות מקסימלית ולכן יש להתקין את אחת מהפצות הלינוקס הבאות:
    • גירסת CentOS 7.3 (ואם אתם עדיין מתעקשים על גירסה 6 של CentOS – אז CentOS 6.9)
    • SLES 12 SP2 ומעלה – של SuSE
    • Debian 8-Jessie או Debian 9-Stretch. ניתן להשתמש גם ב-Debian 7-Wheezy אולם סביר להניח שיהיו בעיות קומפילציית מודולים בהמשך, קחו זאת בחשבון.
    • אובונטו – הנה הפתעה לקוראים: הגירסה היחידה המומלצת היא Ubuntu 16.04.2 LTS (אם יש לכם 16.04.01 – בצעו שדרוג ל-16.04.02). זו הגירסה היחידה לשרתים שקנוניקל משחררת ותעמוד מאחורי גירסה זו ל-5 שנים הקרובות. שאר הגרסאות מיועדות לדסקטופ והן משתנות תדיר, דבר שממש לא מומלץ להתקין בשרת.
  • אחת הטעויות הנפוצות (במיוחד מאנשי לינוקס שהתחילו עם אובונטו) היא התקנת סביבה גרפית גם בשרת. זו טעות, במיוחד אם אתם משתמשים בכרטיס GTX לעבודות CUDA. ה-GPU צריך לרנדר את הסביבה הגרפית 60 פעם בשניה (או 50 בחלק מהמקרים) וזה סתם מוסיף עבודה ל-GPU ולכן: בשרת, לא מתקינים סביבת עבודה גרפית. תתרגלו לטרמינל, מה קרה? 🙂
  • לא להריץ update/upgrade סתם כך! במקרים רבים עדכון הפצת הלינוקס ישדרג גם את הספריות והקרנל ובמקרים רבים אין קרנל מודול ל-GPU שמקומפל לקרנל החדש, מה שמצריך או קימפול מחדש או שימוש ב-kmod/dkms כדי לקמפל מודולים לקרנל החדש. שימוש בקרנל חדש מצריך reboot ולכן עדכונים ושדרוגים – יש לבצע בסוף יום עבודה או לקראת סופ"ש על מנת שלא להפיל עבודות שמשתמשות ב-CUDA.
  • לא להפעיל RAID תוכנה על השרת. תלוי בסוג העבודה, יכול להיות שבנוסף ל-GPU, גם ה-CPU יהיה מלא בעבודה ולכן בד"כ מומלץ שלא להקים RAID תוכנה אלא RAID חומרה עם כרטיס (למעט בשרתים בהם יש RAID חומרה על לוח האם). אני מודע לכך שזו נשמעת המלצה מוזרה, אולם ראיתי מקרים כאלו ש-RAID תוכנה נפל (במיוחד שמדובר בדיסקים SATA "ביתיים" פשוטים) כשה-CPU היה חנוק עם כל הליבות שלו. כרטיס RAID פשוט עולה 50$ ואם המערכת שלכם הולכת לייצר המוני קבצים לקריאה וכתיבה סימולטנית – חברו אותה לסטורג' או במינימום NAS טוב.
  • אם יש לכם הפצת CentOS – השתדלו לא להשתמש בקרנלים מ-ElRepo Repository. ה-REPO הזה נותן קרנלים חדשים ל-CentOS אולם מנסיוני הם מלאים באגים כרימון.

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

בהצלחה.

[stextbox id='info' caption='גילוי נאות']הטמעות ותיקון תקלות הקשורות ב-CUDA זה חלק מהשרות ש"חץ ביז" נותן[/stextbox]

שידור וידאו: על קידוד וצרות של רוחב פס ומחיר (חלק 1)

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

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

בעבר אתרי אינטרנט רבים העבירו שידור וידאו או קליפים בקידוד WMV של מיקרוסופט או VC, או VCM בחלק הקטן מהמקרים, אולם כיום כולם (למעט אתרים שלא עודכנו שנים ועדיין חושבים שהעולם הוא עדיין ברובו משתמש במיקרוסופט) עברו לשדר בקידוד של MPEG-4 עם פרופיל Base או Main והאודיו מגיע או כ-AAC או כ-MP3. היתרונות של מקודדים (Codecs) אלו הוא בכך שכל מערכת הפעלה, טלפונים סלולריים וטאבלטים – תומכים בכך וכל מי שמשדר מעוניין להגיע לכמה שיותר קהל מבלי שהגולשים יצטרכו להתקין אפליקציות/תוספים מיוחדים, מה שגורם במקרים רבים לתקלות ולאנשים שאין להם תמיכה והם נוטשים וממשיכים הלאה.

אז כיצד בעצם אפשר לדחוס יותר משתמשים על אותו רוחב פס?

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

אבל יש פתרון אחר, שכולו קוד פתוח ונתמך בפלטפורמות כמו Wowza ואחרים (כן, גם במערכות בלוגים כמו WordPress) שנקרא Opus שמגיע מ-קרן Xiph ומהנדסים רבים בעולם עובדים בהתנדבות בזמנם הפנוי על פיתוחו. גירסה 1.2 (ו-1.2.1) שוחררה לא מזמן. אתם יכולים להיכנס לדף הזה, לגלול לאמצע ולבחור בקידוד וב-Bit Rate. אני ממליץ לבחור שם Opus 1.2 עם 32 קילוביט לשניה ולנגן ותתרשמו בעצמכם מהאיכות.

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

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

אז מה עושים? לשמחתנו ב-HTML5 יש אפשרות לקבוע Fallback כך שאם הציוד של הלקוח אינו תומך ב-Opus, הוא יועבר לגירסה ב-MP3 או AAC.

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

מה רע? 🙂

בפוסט הבא נדבר על ה"חבר" של Opus – קידוד וידאו VP9.

מחשבות על Nano Scale

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

קחו לדוגמא את עניין הוירטואליזציה ואם תקפצו ל-IBM, תראו שהחברה מימשה רעיונות וירטואליציה הרבה לפני כולם ב-Main Frame שלה. קונטיינרים? קיימים במערכות יוניקס במימושים שונים כבר עשרות שנים. עם הזמן המימושים השתפרו ולעולם ה-PC נכנסה הוירטואליזציה ע"י כל מיני חברות ובראשם VMWare ובכל מה שקשור לקונטיינרים – Sun, IBM ואחרות מימשו בצורות שונות עד שהגענו ללינוקס עם קונטיינרים כפי שהם מוכרים היום ולאחרונה גם מיקרוסופט הצטרפה לעגלת הקונטיינרים (הם נכנסו לוירטואליזציה מעט אחרי ש-ESXI-3 של VMWare יצא).

תחומים "חדשים" (שוב, הם היו ממזמן ב-Main Frame במימוש שונה בעבר) היו ה-Micro Services, ה-Serverless ומושגים שהיום חזרו להיות טרנדיים רק שהם היום הרבה יותר נוחים. קחו לדוגמא את אמזון שממשת את עניין ה-Serverless בעזרת מספר חלקים קריטיים כמו Lambda, DynamoDB ועוד. בתצורה הזו אתה לא חושב על שרתים, אתה לא חושב על קונטיינרים או על תצורת מחשוב קלאסית. המושגים שונים לגמרי.

בעולם המחשוב כיום, כשמריצים אפליקציה על VM או על קונטיינר, כמעט תמיד יווצר בזבוז משאבים. אתה מקים VM של 4 ג'יגהבייט בשעה שהאפליקציה צריכה 2.5 ג'יגהבייט.נכון, טכנולוגיית Memory Balooning פותרת בעיה זו בוירטואליזציה מקומית כמו ESXI, אבל מה קורה בענן ציבורי? שם הספק לא כל כך יכול להשתמש בטכנולוגיה כזו כי הוא לא "משחק" את המשחקים של Over Provisioning מטורף כמו ספקי הוסטינג קטנים. ב-ESXI אפשר לקבוע שמכונה תוזז למכונה פיזית אחרת אם היא פתאום צריכה הרבה יותר משאבים ממה שהיא היתה צריכה לפני זמן קצר, בענן קצת קשה לעשות זאת וכלקוח אינך יכול להעביר את ה-Instance שלך ממכונה פיזית אחת לשניה כמו ב-vSphere. הבעיה קיימת פחות (אך עדיין קיימת) עם קונטיינרים – גם שם אתה צריך להגדיר לקונטיינר כמה זכרון יהיה לאפליקציה/ות בתוך הקונטיינר אולם אם הן לא משתמשות בזכרון, אז נוצר בזבוז (שוב, עם אותם הסתייגויות כמו ל-VM).

הפתרון של Micro Servicess הוא פתרון טוב, אבל לעניות דעתי פתרון טוב יותר יהיה ברמת ה-Nano.

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

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

תארו לכם שאפליקציות שיש כיום – יהיה ניתן לפרק אותם ל-Nano Scale, כלומר פיסות קוד שצריכות קילובייטים (ולא מגהבייטים או ג'יגהבייטים) והם יכולים לתקשר עם פיסות קוד אחרות במהירות ללא צורך בבנייה של תשתית עם האמצעים הרגילים כמו Load Balancer או HAProxy או דברים כאלו. פיסות הקוד (בחלוקה לדוגמא שכל פונקציה היא "נאנו מכונה") יוכלו לבצע פעולות, לשדר את התוצאה ולמות ופיסות אחרות יכולות לקום והכל תוך מילישניות – לפי הצרכים. הדבר שכן קיים כיום בתצורה מאוד דומה היא ב-GPU (כמו של nVidia) ששם יש אלפי ליבות וכל ליבה יכולה לעשות דברים מאוד בסיסיים אך עבודה של מאות ליבות ביחד יוצרת משהו שלם שמועבר למחשב.

כיום יש לנו משהו קרוב לכך ב-Micro Services יחד עם ה-Serverless שנותן בערך את אותו רעיון, אך עדיין זהו דבר בעייתי מכמה סיבות:

  • קשה לתרגם אפליקציה קלאסית לתצורה זו
  • החלקים אינם קטנים מספיק (זה לא בעיה כשזה רץ בענן, זה כן בעיה אם זה ירוץ על Micro Controller Unit – כלומר MCU) או על IOT או על מערכות IOT עם כמות זכרון קטנה וכו'.
  • הפתרונות הטכנולוגיים הללו עדיין לא זמינים בתצורה קלה ונוחה להרצה מקומית על תשתית וירטואליזציה של חברות או על PC מקומי בקלות.

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

השאלה – מי ירים את הכפפה.

קוד פתוח מול קוד סגור ו"נעילת" לקוחות

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

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

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

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

הנה דוגמא: לא מעט חברות שנכנסות יותר ויותר בשימוש עננים ציבוריים "מגלים" כשהם משתמשים בלינוקס ומערכות CI/CD את האוטומציה, ותתפלאו – חברות רבות לדוגמא עד היום לא הכניסו שום אוטומציה. יש פלטפורמות אוטומציה רבות ללינוקס כמו Chef, Puppet, SALT ובוודאי עוד כמה – אולם אני ממליץ ספציפית על Ansible מכמה סיבות:

  • הקוד של "המנוע" – פתוח לחלוטין וכתוב ב-Python.
  • אין צורך ב-"שרת" Ansible. כל הפעילות היא Serverless לחלוטין.
  • הכתיבה של ה"תסריטים" (או Playbooks איך שזה נקרא ב-Ansible) היא פשוטה ולוגית. המשתמש יכול תוך שעה שעתיים אחרי שהוא קרא את התיעוד לכתוב דברים בסיסיים שיכולים לרוץ על המכונה שלו ומכונות אחרות, כך שעקומת הלימוד – היא די קטנה.
  • יש לכם שרתי Windows? אולי הגיע הזמן גם ששם תהיה אוטומציה? אז ל-Ansible יש גם מודולים ל-Windows, בין אם מדובר להתקין קבצי MSI, להגדיר IIS, להעתיק קבצים, פעולות דוט NET, ניהול משתמשים וקבוצות ודברים נוספים. העלות לחברה? יקרה מאוד .. אפס שקלים.
  • מחפשים ממשק Web? אתם יכולים לרכוש את Ansible Tower (וביחד עם זאת לקבל תמיכה רשמית מ-רד-האט) או שאתם יכולים להשתמש בממשק וובי אחר (ויותר בסיסי) בקוד פתוח שנקרא Ansible Semaphore.
  • חושבים לעבור לאוטומציה אחרת מסיבה כלשהי? לרוב המתחרים יש כלים אוטומטיים להעביר את ה-Playbooks שכתבתם אל המערכת החדשה (אם כי עדיין לא נתקלתי בחברה שעברה מ-Ansible למערכת אחרת).

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

אותו הדבר גם בכלים לניהול סביבת חיים (Life Cycle) של קונטיינרים וסביבות המורכבות מעננים פרטיים וציבוריים. ניקח לדוגמא את קטגוריית ה-CMP (כלומר Cloud Management Platform). בתחום זה יש מתחרים רבים, החל מ-VMWare עם ה-vRealize לגרסאותיו, RightScale, ועוד. האם פלטפורמות אלו מבצעות את מה שהן מבטיחות? בהחלט! אולם אם תפסיק לשלם את התשלום החודשי או השנתי, תיתקלו באחת מהסיטואציות הבאות:

  • במקרים כמו של RIghtScale – אתה "בן ערובה", כל עוד שתשלם – הכל עובד. הפסקת לשלם, תתחיל לבנות מחדש את כל מה שבנית – על מוצר אחר.
  • במקרים כמו vRealize אם אתה מפסיק לשלם, המערכת לא תתעדכן לשרותים והגדרות חדשות של עננים ציבוריים, OpenStack ואחרים, אין תמיכה ואין עדכונים לגרסאות חדשות.

לעומת זאת, במוצר כמו CloudForms שנותן לך לבצע CMP (כולל כמובן עמידה ברגולציות וכו'), אם לא בא לך לשלם יותר, אתה יכול לייצא ולייבא את ההגדרות, הקבצים והתכנים לגירסת הקוד הפתוח (ManageIQ) בדיוק כמו שאתה יכול לעבור מ-RHEL ל-CentOS מבלי לאבד פונקציונאליות או תאימות. כשזה מגיע לקונטיינרים, אתה יכול לעבור מגירסת OpenShift מסחרית ל-OpenShift Origin שמבוססת על Kubernetes כך שבעצם למעט שרותי תמיכה (שאותם תוכל לקבל מצד ג' בין כה), אינך מפסיד דבר. להיפך: אתה שומר על כל העבודה שהצוות ביצע ואפשר לאחר המרה לגירסת קוד פתוח – להמשיך לעבוד כרגיל.

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

שבוע טוב 🙂

למי מתאים הפצות וכלים של SuSE

שוק הלינוקס בשנים האחרונות בארץ תופס תאוצה ובשנה וחצי האחרונות נכנס כח חדש לישראל – חברת SuSE ישראל שמייצגת את SuSE העולמית ונותנת תמיכה (בגיבוי SuSE העולמית) למוצרי החברה בארץ ואף משתפת פעולה במחקר ופיתוח בחברות שונות.

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

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

כשזה מגיע ל-Storage, המוצר של SuSE לדוגמא יותר בשל מהמוצר של רד-האט בדיוק מאותה סיבה שציינתי לעיל: SuSE בוחרים בפינצטה ואז משקיעים רבות בהקמת מוצר עם כל התחזוקה לאורך שנים. הדוגמא הכי פשוטה היא ההקמה של המוצר: ב-SuSE נותנים לך הוראות איך להקים זאת על המחשב הנייד שלך או מחשב טסטים עם VirtualBox או VMWare Workstation או KVM והולכים איתך שלב אחר שלב בתיעוד כך שגם אדם שמעולם לא שמע על Ceph יוכל תוך זמן קצר להרים סביבת נסיון ולאחר מכן הוא יוכל להמשיך ללמוד את שאר הפונקציונאליות (ויש לא מעט שמאוד שונה מ-Storage רגיל). ב-רד האט לעומת זאת יש הרבה יותר "תיאוריה" ופחות "בשר" להקמה על המחשב הנייד/מחשב טסטים.

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

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

עוד נקודה חשובה: לא מעט חברות נכנסות היום לתחומי ה-Embedded/IOT ול-SuSE יש את ה-SuSE Embedded Linux הן למעבדי אינטל והן למעבדי ARM עם 64 ביט עם מערכת הפעלה רזה מאוד שנקראת Jeos ואם משווים את המוצר לזה של רד-האט, תוכלו לראות ש-SuSE מתקדמים בהרבה מהמתחרים (וכן, יש גם תמיכה רשמית מלאה למחשבים כמו Raspberry Pi לחברות שמתנסות עם המכשיר).

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