שמי גיל ואני עובד היום כ-Cloud business manager בחברת DoiT International. בתפקידי הקודם שימשתי כ- DevOps Technical Lead ולפני זה הספקתי לעבוד במגוון תפקידי רוחב כמו פיתוח, DBA, Data Analyst, מנהל פרויקטים ויועץ. את ההתחלה שלי זכיתי לעשות בצה״ל כשהייתי SysAdmin של מערכות VAX.
ב-2013 התחלתי לעבוד בחברת SysAid. כל תשתית הענן הוקמה ותופעלה על ידי בן אדם אחד (בן אדם מדהים) באמצעות כלים שהיום כבר נתפסים כהכרחיים. היכולת הזאת, עם כל ההשלכות העסקיות שלה, הראתה שהענן לא ״מגיע״, הוא כבר כאן מזמן.
הקושי הגדול היה להתגבר על הצורך בשליטה על כל הגורמים הקטנים. אני אתן דוגמא, לקח לי זמן לפני שהתחלתי להשתמש ב-Docker Images שלא אני או מישהו מהצוות שלי יצר. השינוי מגיע ברגע שלא מנסים ללמוד כל דבר קטן אלא משחררים ולומדים ב- Scope הנדרש להשגת היעדים הנוכחיים.
לפי דעתי, קיימת חשיבות ליכולת למידת שירותים ברמה שטחית, לפחות ברמת היכרות הראשונית, על מנת להבין את האפשרויות הקיימות. בנוסף, יכולת למידה לעומק של השירותים הנבחרים חייבת לעמוד לצד היכולת לוותר על שירותים שכבר אינם מתאימים לארגון. היכולת לנוע בצורה מהירה ויעילה מותנית בגמישות של החלפת פתרון ללא מטען רגשי. היום אסור להתאהב בפתרון שכן פתרון טוב יותר תמיד נמצא מעבר לפינה.
העתיד כבר כאן. ספקיות הענן הגדולות מתחילות ליצור שירותים שאין להם תחרות בעולם ה-On Prem. כל ספקית יודעת לתת את הפתרון לחוות השרתים הווירטואלית שהיא המקבילה ל-On Prem. הקסם האמיתי מתחיל בשירותים מנוהלים. אם ניקח לדוגמא את ה-GKE של Google או את DynamoDB של AWS, אנחנו כבר רואים אותם זמינים להתקנה On-prem. האם השירותים שמנוהלים על ידי הלקוח טובים כמו השירותים המנוהלים בענן? אין לזה תשובה פשוטה.
לחלק מהפתרונות היו חלופות, וחלקם היו ייחודיים לספק מסויים. אני חושב שהיום אין כבר את הפריווילגיה של לבחור רק ספק אחד. לכל אחד משלושת הספקים הגדולים יש היום פתרונות לבעיות שהשניים האחרים לא מספיק מתמקדים בהם. השאלה היא פשוטה - מהו הצורך העסקי? כאשר יש צורך בשירות מסוים שיש לספק שלא עובדים איתו, זה הרגע להתחיל בפעילות מול אותו ספק, במיוחד כאשר גרסת ה-Self Hosted עדיין רחוקה.
החששות שנמצאים על פני השטח, כמו אבטחת מידע או החשש מתלות בספק מסוים, הם ולידיים אך מסתירים את החששות האמיתיים. מעבר לענן טומן בחובו משקל רגשי שלא מספיק מדברים עליו. לדוגמא, הפחד מאבדן ההשקעה בתשתיות פיזיות או אי הרצון להגיד - ״מה שעשינו עד עכשיו לא טוב מספיק״. יש עוד מרכיבים רגשיים רבים וככל שהארגון ותיק יותר ונחל הצלחה רבה יותר יש יותר מהם.
אני רואה שלושה שלבים עיקריים במוכנות הארגון לענן:
1. קיים צורך עסקי אמיתי בבסיס המעבר לענן.
אם אין צורך לעבור לענן ורוצים לעשות את זה רק ״כדי לנסות״, המעבר כמעט תמיד נדון מראש לכישלון. לגופו של עניין, גם רצון לחסוך על סבב הרכישה הבא של השרתים הוא צורך עסקי.
2. הארגון מוכן לשנות תהליכים פנים-ארגוניים על מנת להתאים את עצמו לזריזות שמאפשר הענן.
הענן מאפשר לארכיטקטים, מפתחים ויזמים לזוז במהירות מדהימה. הארגון חייב לתת לצוותים לעבוד במהירות הזאת ללא הוספת בירוקרטיה שתאיט את העבודה. ניקח דוגמא קיצונית - מילוי טופס והחתמה של גורם ממונה בכל פעם שמעלים מכונה חדשה.
3. הצלחת המעבר לענן נמדדת בתוצאות עסקיות ולא בהצלחות טכניות.
הענן נותן לארגון אפשרות לקחת רעיון מסוים ולהביא אותו לידי בדיקה אמיתית בשטח הרבה יותר מהר מבעבר. שימוש בשירותים מנוהלים הופכים צוותים קטנים ליעילים. אם הארגון שם חסמים ברמת השירותים, הטכנולוגיות או המתודולוגיות בפני הצוותים הללו, היתרונות הללו הולכים לאיבוד. כמובן שהיבט אבטחת המידע יוצא מן הכלל ועליו אסור בשום אופן לוותר.
בנשמה שלי אני ילד קטן. אני אוהב את הצעצועים שלי ואוהב להראות אותם ולדבר עליהם. יחד עם זאת, כדאי לפעמים לשים את הצעצועים (כלים, שירותים, טכנולוגיות וכו׳) בצד. הענן טומן בתוכו פוטנציאל ענק ולפעמים צריך להעלות את המתודולוגיות והעקרונות לקדמת הבמה. אשמח אם יהיה יותר תוכן כזה נגיש לחברי הקהילה.
