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

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

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

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

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

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

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

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

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

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

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

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

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

על נקודות חשובות בעת מעבר לענן

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

בפוסט זה אני אעלה מספר נקודות ואתייחסן אליהן.

שרותי SAAS כחלק ממעבר לענן
SAAS (כלומר Software As A service) זה דבר מעולה, בתנאים ובדברים מסוימים. צריך לשלוח עשרות אלפי מיילים? יש כמה ספקי SAAS וסביר להניח שספק הענן שתבחר (טוב, למעט Azure לפחות ממה שידוע לי) שישמחו להציע לך שרות כזה. אם תיקח עצמאי שיקים לך דבר כזה, זה יעלה לך לא מעט, ובנוסף יש צורך לתחזק זאת ברמה שבועית או פחות (RBL, Black List ושאר צרות שמגיעים עם זה), כלומר במקרה כמו המקרה הנ"ל – השימוש ב-SAAS הרבה יותר זול מבחינת עלות ראשונית (ואולי גם בהמשך, תלוי בכל מיני פרמטרים) והוא שרות מוצדק.

לעומת זאת, אם לדוגמא אתה צריך שרות כמו MySQL או PostgreSQL בתצורה כמו Master ו-2 Slaves שיהיו מותקנים באזורים זמינים (Availability Zones במושגים של AWS), יהיה לכם יותר זול להקים זאת בעצמכם עם MariaDB (ו-Galera) לדוגמא, מכיוון שאתה יכול לבחור איזה גודל מכונה שתרצה (ולא רק מה שיש מבחינת SAAS), וגם התחזוקה עצמה אינה מסובכת. הבעיות הנפוצות ביותר שקיימות עם SQL (ולא חשוב איזה SQL) הם בד"כ השאילתות שנכתבות ע"י צוות הפיתוח וחוסר אופטימיזציה, וכאן שרותי SAAS לא יעזרו הרבה כי בסופו של יום – יותר קל וזול לתקן שאילתות מאשר להוסיף 20 שרתי רפליקציה ל-SQL.

מה שמוביל לנקודה הבאה..

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

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

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

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

מה שמוביל לנקודה הבאה..

סקריפטים, קוד ואוטומציה
כשיש לנו תשתית פנימית שנמצאת בחדר השרתים, סביר להניח שצוות ה-IT יכתוב במהלך הזמן עשרות או מאות סקריפטים (ב-PowerShell, Bash, Python, Ruby וכו') על מנת להריץ דברים מסויימים כמו תהליכים מתוזמנים (Cron), ניקוי ומחיקת קבצים ועוד עשרות דברים שונים.

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

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

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

מה שמוביל לנקודה הבאה…

אימוץ טכנולוגיות חדשות
הנה אחד הדברים שאני שומע: "אנחנו מעוניינים שתקים לנו את הדברים בקונטיינרים, אנחנו רוצים גם לעבוד ב-CI/CD עם Jenkins ושהכל יהיה עם Auto Scaling".

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

לכן, בד"כ ההמלצה היא להכיר ולעבוד אחד אחד. רוצים ש-Jenkins יקים עבורכם קבצים (Build) שמגיע ממערכת GIT? קודם תכירו את זה, ואחרי שיש לצוות ידע, נמשיך לקונטיינרים, נכיר את המושגים השונים ונתחיל להעביר לאט את הדברים לשיטה החדשה. "לזרוק" על הצוות ערימת טכנולוגיות מבטיחה שדברים יזוזו לאט, עם המון באגים, ואבטחת מידע ברמה נמוכה. אלו דברים שלוקחים זמן ולעניות דעתי – שווה להשקיע את הזמן הזה. זה שאני (או עצמאי או חברה אחרת) יקים את הדברים וזה יעבוד – זה נחמד, אבל אם הצוות לא מכיר כלום, יהיו המון בעיות.

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

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

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

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

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

שבוע טוב 🙂

Exit mobile version