"התכניתנים הם המלכים החדשים"

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

אמיר ציפורי, מנהל פתרונות בכיר ברד-האט. צילום: ניב קנטור

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

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

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

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

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

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

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

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

סיפור פרויקט – ב-Unity

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

Logz.io מבצעת ניתוח לוגים באמצעות בינה מלאכותית, בין היתר על גבי מערכת ELK Stack. החברה מעסיקה כ-150 עובדים בתל אביב ובבוסטון, ויש לה כ-600 לקוחות ב-100 מדינות.

השניים ציינו כי המנוע של Unity מאפשר פריסת תוכן על גבי שורה של פלטפורמות, מערכות הפעלה ומכשירים, ויש לה כ-700 מיליון משתמשים.

"האתגרים שלנו בפרויקט היו העובדות שיש ל-Unity סוגי לוגים רבים ושונים, בהם בדיקה, בנייה ולוגים במכשירים; מגוון מקורות שמהם מגיעים הנתונים; כמות רבה של נתוני לוגים; ניטור של תהליכי CI/CD; וביצוע פתרון בעיות באופן ידני. זה היה תהליך מאוד איטי ומתיש", ציינו בן אריה ומסיקה.

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

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

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

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

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

תגובות

(0)

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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

אירועים קרובים