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

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

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

הסיבות העיקריות לכך שצוותי DevOps רוצים להתחיל להשתמש בקונטיינרים הן:

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

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

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

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

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

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

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

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

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

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

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

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

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