יהיו כאלה שיתייחסו לתקופת המחשוב הפיזי כחשכת ימי הביניים. אם היינו רוצים להפעיל שירות מסוים, נדרשנו לרכוש שרתים פיזיים. אפילו עבור התקנה של אפליקציה פנים ארגונית, מילאנו דרישה למחלקת הרכש, פירטנו את החומרה המבוקשת ברמת מעבדים, זיכרונות, ערכת שבבים וסוג מארז - ותוך מספר שבועות החומרה הייתה מתייצבת אצלנו ארוזה בקרטון. פתחנו את האריזה, מיקמנו את החומרה בחדר השרתים הקפוא, התקנו מערכת הפעלה, הרצנו עדכונים, התקנו את כל הספריות והרכיבים האפליקטיביים הנדרשים עבור האפליקציה, ורק אז היינו יכולים להתחיל לעבוד עליה ולפתח. זה היה תהליך ארוך, מתסכל ויקר.
עולם וירטואלי מופלא
התקופה הווירטואלית נכנסה לחיינו בסערה, עם תשתיות שאפשרו הדמיה של שרתים על גבי שכבת מכונות פיזיות, מבוססת יחידות עיבוד וזיכרון. התאפשר לנו להקצות משאבים הרבה יותר מהר בהתאם לצרכי היישומים שלנו.
עם זאת, האצת קצב הפיתוח וריבוי האפליקציות גרמו לתשתית לצבור חסרונות. ראשית, עדיין נדרשנו לבצע התקנות ועדכוני תוכנה רבים על גבי המכונות כדי לשמר את יציבותן לאורך זמן. שנית, החיסרון הגדול התבלט בהמשך, בהיבט התאימות האפליקטיבית. יישום שעבד על גבי מכונה אחת, עלול היה שלא לתפקד על גבי מכונה אחרת. הדבר שלל את מידת הניידות והגמישות מהיישומים השונים.
תורה של המכולה
שחר חדש בעולם הפיתוח הפציע עם חברות דוגמת Docker, שביקשו לטפל במגבלות הללו, באמצעות שימוש בפתרון ייחודי - המכולה (Container). מדובר ביחידת תוכנה סטנדרטית קלה ועצמאית, שאורזת בתוכה את הקוד, מודל ההרצה ((Runtime, ספריות המערכת והגדרות. התהליך מאפשר ליישומים המצויים במכולות לפעול בכל סביבה ללא תלות בתשתית.
כוח המכולה טמון בסטנדרטיזציה, ממש כמו בספינת שינוע מכולות: אם נרצה לייבא מוצר, נדאג להשיג כמות מבוקשת שלו, נאתר מכולה ונתאים את המוצר למכולה הזו. השלב הבא בתהליך יהיה למצוא ספינת משא, ואז המכולה תשונע לצד מכולות רבות אחרות באותו הגודל, אם כי בתכולות שונות ומגוונות.
השילוב בין פיתוח ותפעול IT מצריך שינויים מהירים ותדירים תוך שמירה על עלות שינוי נמוכה. הסקוואדים עובדים בקצב גבוה יותר, ומפתחים לאור תרבות המבוססת על שיתופי פעולה ושקיפות. ביחד, הם יכולים לזהות יעילות אפליקטיבית לקויה ולשנות סדרי עדיפויות מהר יותר. על כן, מכולות אפליקטיביות מהוות מרכיב יסודי בתהליכי DevOps עם קלילות ויכולת פריסה עקבית במספר סביבות בו זמנית.
נושא נוסף שמקבל מענה הוא עיקרון ה-Shift Left המבקש להקדים משימות במחזור חיי הפיתוח שעל בסיס מסורתי היו מטופלות בשלב מאוחר יותר. סוגית הבדיקות היא דוגמה לכך. שימוש במכולות מספק מענה לעקרון, היות והוא תומך בארכיטקטורת ה-Microservices, אותם קל יותר לבדוק ולתקן במסגרת תהליכי הפיתוח. מודל המכולות מאפשר תיקון בעיות מבלי לשנות ארכיטקטורה או לפרוס מחדש יישומים - תהליכים מסובכים שצורכים המון משאבים עבור מתודולוגיות פיתוח אג'יליות.
הדבר הגדול הבא?
ומה לגבי העתיד? יהיה יומרני מדי להכריז "כבשנו את פסגת תשתיות המחשוב", במיוחד נוכח העובדה שאמזון כבר החלה בפיתוח תחום תשתיתי חדש הקרוי Serverless Computing עם שירות "למבדה". השירות מאפשר הפעלת קוד, מבלי להקצות או לנהל אף אחד מרכיבי התשתית הבסיסית. האם זהו הדבר הגדול הבא? נחכה ונראה.