טרנספורמציה דיגיטלית שמשכפלת פונקציונליות קיימת כבר אינה מספיקה. כדי לכבוש את ליבם של הלקוחות, ארגונים צריכים לייצר חדשנות דיגיטלית ייחודית. לכן, חברות בכל סדר גודל, ולעיתים גם תעשיות שלמות, נדרשות להעצים את אנשי הפיתוח שלהן על מנת ליצור את השירות הדיגיטלי הגדול הבא, בין אם מדובר באפליקציה לנייד או באתר אינטרנט. לצורך כך עליהן לייצר אמון ולאפשר למפתחים קבלת החלטות אוטונומית. מפתחים חייבים להיות מסוגלים לבחור את הכלים שלהם ולבצע בחירות תכנון ושירות מרכזיות עבור יצירות המופת הדיגיטליות שלהם – כמובן בתוך מסגרת הגיונית.
למרות שהעצמת מפתחים היא המפתח להנעת חדשנות, היא עלולה גם להיות מסוכנת.
יצירת חדשנות כרוכה בעלויות
מפתחים אוהבים כלי קוד פתוח. אבל כאשר שלוש או ארבע פיסות טכנולוגיה שונות מבצעות את אותה משימה, הדבר עלול להוביל לבלבול, הופך את הארכיטקטורות למורכבות יותר ומוסיף תקורה ניהולית לצד סיכוני אבטחת מידע. המורכבות מגדילה את העלויות, על אף שכלי הקוד הפתוח חינמיים.
ככל שמשתמשים ביותר כלים, כך צוותי התשתיות והמפתחים נדרשים להשקיע זמן רב יותר בלמידה ותחזוקה של כלים אלו. בנוסף, ההכשרה של מפתחים חדשים הופכת מסובכת וגוזלת יותר זמן, מכיוון שהם חייבים להכיר את אופן השימוש של כל הכלים, על כל המורכבות שבהם.
המורכבות יכולה להוביל גם לזמן השבתה. שרשרת כלים הכוללת יותר חלקים נעים עם מודלים תפעוליים משלהם מגדילה את הסיכוי שדברים ישתבשו תחת עומס. השבתה של אפליקציות מהווה סיכון למוניטין וקיים בה גם סיכון פיננסי לאובדן הכנסה. במקום לחכות לפתרון הבעיה, משתמשים לא מרוצים עלולים לנטוש ולעבור לספקים אחרים.
אמצו ‘אמצעי זהירות’ ולא חסמים
קיימים ארבעה ‘אמצעי זהירות’ חשובים שיכולים להעצים מפתחים תוך הגנה מפני סיכוני מורכבות תפעולית, עלויות גבוהות ואבטחה:
- העבירו את האבטחה שמאלה: מפתחים רוצים לקודד. הם רוצים לספק תכונות ופונקציונליות חדשות. הם לא בהכרח רוצים לבזבז זמן ואנרגיה על אבטחת מידע. אבל אם מציגים את אבטחת המידע מוקדם יותר בשלב של פיתוח התוכנה, ניתן להפוך את האבטחה לידידותית מספיק לאנשי הפיתוח, כך שהם יהיו מוכנים להפוך אותה לחלק מתהליך הפיתוח שלהם. תהליך זה מכונה ‘הזזה שמאלה’ (shifting left).
העברה שמאלה הופכת מפתחים לאחראים להטמעת אבטחה בזמן שהם כותבים קוד – בין אם מדובר בהערכת מודל איומים, ביקורת קוד, בדיקות חדירות או החלת מדיניות אבטחה באמצעות בקרות מפצות כמו WAF. העברה שמאלה מאפשרת למפתחים לבצע את המשימות הללו באופן אינטואיטיבי יותר בתוך שטף העבודה שלהם. על פי סקר של SANS Institute – ארגון המתמחה באבטחת מידע ואבטחת סייבר, פחות מ-40% מהארגונים העבירו את נוהלי האבטחה שמאלה באופן התואם את עקרונות ה-DevSecOps.
- אמצו קוד פתוח מודרני: למפתחים יש מנטליות של קוד פתוח. אמצעי הזהירות לא יעבדו אם לא תספקו להם כלי קוד פתוח שמתאימים לאתוס ולהעדפות הטכנולוגיות שלהם. נכון לעכשיו, רוב החברות משתמשות בקוד פתוח – כאשר GitHub, Docker, Kubernetes ואלפי כלים אחרים מובילים את המשימה.
לפי דוחThe State of Enterprise Open Source של Red Hat לשנת 2021, כ-90% ממובילי ה-IT משתמשים בקוד פתוח ארגוני. עם זאת, קיים כיום מגוון עצום של אפשרויות קוד פתוח עם אלפים רבים של פרויקטים למשימות מסוגים שונים. לכן, חשוב למנוע את התרבות הכלים על ידי סטנדרטיזציה של קבוצת כלים מוגדרת – כמובן, תוך התחשבות בדרישות של המפתחים בארגון.
- פרסו תשתית כקוד: העברת אבטחת המידע שמאלה ואימוץ קוד פתוח מסתמכות רבות על ההתייחסות לתשתית שלכם כקוד. משמעות הדבר היא פריסת קוד כתוכנה או שירותים שניתן לתכנת על ידי ממשקי API.
על פי דוחState of Application Strategy in 2021 של F5 לשנת 2021, 52% מהארגונים אימצו את שיטות העבודה של תשתית כקוד (IaC). פרוש הדבר הוא שניתן להגדיל ולהקטין את התשתית לפי הצורך, ויתרה מכך היא תניע מעבר לכלי האבטחה והקוד הפתוח הקיימים. ההתייחסות לתשתיות האפליקציות המודרניות כקוד מעבירה את האחריות על הגדרת התשתיות לאלו שמכירים את האפליקציה בצורה הטובה ביותר: המפתחים וצוותי ה-DevOps. הופעת הקונטיינרים חוללה מהפכה בדרך שבה ניתן לפרוס תשתיות ואפשרה למפתחים ולצוותי ה-DevOps לתכנן ולהפעיל בקלות את התשתיות המתאימות ביותר לפריסת האפליקציות שלהם.
- אוטומציה באמצעות שירות עצמי: העברת האבטחה שמאלה, אימוץ קוד פתוח ופריסה של תשתית כקוד, תוך מתן מרחב פעולה למפתחים לעשות הכל ללא אמצעי זהירות עלול להוביל לסיכונים תפעוליים. זו הסיבה שנדרשת תשתית שירות עצמי, הן כדי להקל על מפתחים לפרוס את התשתית והשירותים הדרושים להם והן כדי להפחית את המורכבות תוך שליטה בעלויות.
דוח State of Application Strategy in 2021 לשנת 2021 חשף כי 65% מהארגונים אימצו תהליכי אוטומציה. ליתר דיוק, 68% מאמצים תהליכי אוטומציה לרשת ולאבטחה על מנת שצוותי SecOps, NetOps, DevOps ו-Platform Ops יוכלו להקל על אספקת תשתית למפתחים באמצעות קטלוגים בשירות עצמי על ידי קונטיינרים אשר נבדקו ונמצאו כבטוחים ויעילים לשימוש.
דוד עדשה, מנהל שירותי מומחה
לתחומי NGINX ו-IP-BIG ב-F5
למעשה, השילוב של שירות עצמי הפך בין היתר את העננים הציבוריים לפופולריים מאוד. הם משמשים כפורטלים בשירות עצמי עבור קטלוג של טכנולוגיות ידידותיות למפתחים, דבר שמאפשר לצוותים קטנים לבנות ולהרחיב אפליקציות שמתחרות בארגוני ענק. עם זאת, אנו יודעים שספקי ענן לא תמיד מספקים את קונפיגורציות ברירת המחדל המאובטחות ביותר. וזו הסיבה שקריטי לנהל את הפורטלים בשירות עצמי של הארגון, ולהגדיר אותם כדי להגן על התשתיות.
חידושים מניעים התקדמות ופרודוקטיביות
במהלך השנתיים האחרונות ראינו כי ארגונים שהעצימו מפתחים קטפו את פירות החדשנות. ארגונים רבים יצרו ערוצי מכירה חדשים או תכננו מחדש אפליקציות שיתאימו לעתיד של תשתיות מבוססת ענן מבוזר ושל מסגרות פריסה מבוססות שירותים. ארגונים אלה נמצאים היום במקום טוב יותר ומסתכלים אל עבר העתיד.
העברה שמאלה, הפעלת קוד פתוח, שינוי לגישה של תשתית כקוד, יצירת קטלוגים לשירות עצמי ובניית יישומים אדפטיביים על גבי טכנולוגיות התשתית המודרניות והעמידות ביותר כמו Kubernetes, כולם מובילים ליעילות וחדשנות דיגיטלית.
עידן הענן לימד אותנו שאם אבטחת המידע ופריסת התשתית נגישים יותר, צוותי הפיתוח יאמצו את הגישה. אמצעי הזהירות שציינתי חיוניים למתן חוויה מודרנית בענן בצורה מאובטחת ומאפשרת ביזור ענני. תנו למפתחים לראות את היתרונות של אמצעי הזהירות על פני החסמים ותשיגו חדשנות, אבטחה ויעילות.
