איך הגענו לכאן?
כמו שכתבתי בסוף הפוסט הקודם בסדרה, הראשונים שעלו על פורמולה מנצחת לקונטיינרים הם דוקר (Docker). מעבר להוספה של היכולות הרלוונטיות לקרנל של לינוקס, נראה שקשה לערער על הטענה שהגורמים המרכזיים לפופולריזציה של קונטיינרים הם Docker. אני כותב גורמים כי יש שני Docker, האחד זה פרויקט הקוד הפתוח והמוצר המסחרי שהתפתח ממנו והשני זה החברה שעומדת מאחוריו, ולשניהם יש תרומה מרכזית לפופולריות של הטכנולוגיה.
החברה, Docker Inc., השקיעה משאבים רבים הן בשיווק והן בפיתוח. בצד השיווק החברה עשתה הרבה מאוד מאמצים לקדם את אימוץ הטכנולוגיה בתעשייה, בשנים הראשונות בעיקר אצל מפתחים ובהמשך גם בצד התשתיות. אי אפשר שלא להזכיר בהקשר הזה את העבודה המעולה של המאיירת Laurel שייצרה למותג שפה גרפית ייחודית וחביבה להפליא (מי לא אוהב את הלוויתנים של דוקר?) בצד הפיתוח, דוקר השכילו ליצור מוצר ידידותי ונוח שקרץ למפתחים רבים ולפחות בתחילת הדרך, זכה לאהבה רבה מקהילת הקוד הפתוח (קשה להאמין שרק חמש שנים עברו מאז).
הדבר הראשון שדוקר סיפקו היה מעטפת שיצרה על גבי היכולות של מערכת ההפעלה אבסטרקציה - אובייקט של קונטיינר. אמנם דוקר לא היו הראשונים שאפשרו להריץ קונטיינרים, ולמעשה בהתחלה הם בכלל התבססו על LXC לבניית קונטיינרים, אבל הם היו הראשונים שיצרו ממשק נוח למפתחים ומעבר לכך, Ecosystem שלם שמאפשר לצרוך ולשטף קונטיינרים בקלות ומספק חווית משתמש נוחה סביב הטכנולוגיה. דוקר הגדירו פורמט לקובץ אימג' של קונטיינרים והקימו מאגר אינטרנטי פתוח לאימג'ים, Docker Hub, שמאפשר לכל מי שמעוניין בכך לפרסם קוד ארוז ומוכן להרצה בקונטיינר.
הפתרון של דוקר מאפשר להפיץ אימג' של תוכנה מוכנה להרצה בקלות, בדומה לקלות של הפצת קוד מקור שמספקים שירותים כמו Github. דוקר אימצו שפה שתהייה טבעית למפתחים עם טרמינולוגיה שמתבססת על מונחים דמויי git –אפשר לעשות לאימג' push/pull, tagging and versioning. בגלל שמדובר על אימג'ים של קונטיינרים ולא על קוד, המשמעות לא תמיד זהה לגמרי אבל המונחים מקלים מאוד להשתלט על הטכנולוגיה במהירות.
וזה עבד מעולה, וזה עדיין עובד נפלא. אם פעם, לפני דוקר, הדגמה של מוצר דרשה להתקין ולהגדיר את התוכנה אצל הלקוח ולהתמודד עם תלויות ובעיות של הגדרות או להעביר אליו ג'יגות של קבצי מכונה וירטואלית ולקוות שכל העסק ינגן, כיום אפשר לשלוח ללקוח שם של אימג' של קונטיינר ההדגמה וכל מה שהלקוח צריך זה להריץ פקודה אחת כדי להוריד את האימג' ולהריץ אותו. דוקר אוהבים מאוד להדגיש את היכולת של קונטיינרים לשים סוף לסיפור של "בתחנה שלי זה עובד" (works on my machine).
ה-Runtime של דוקר הוא המוכר וככל הנראה הנפוץ ביותר, והמותג דוקר מזוהה אצל הרבה אנשים כשם גנרי לקונטיינרים, אבל קיימים בשוק מספר runtimes מתחרים בעלי תכונות שונות (כמו לדוגמה rkt). לאור קיומן של האלטרנטיבות התעורר צורך בהסכמה על סטנדרט שיאפשר למשתמשים לעבור בין runtimes שונים ולהעביר ביניהם אימג'ים בקלות. בנוסף, בגלל צרכים ובעיות שנדון בהם בהמשך, השוק אימץ פתרונות שונים לאורקסטרציה, כשהמוכר והמוביל מביניהם הוא קוברנטיס. המפתחים של קוברנטיס טענו שה-runtime של דוקר כולל תכונות שהטיפול בהן אמור להיות באחריותו של האורקסטרטור, ולכן נדרש לפתח סטנדרט שיגדיר מהן התכונות והיכולות שבאחריות ה-Runtime. על מנת לפתח סטנדרטים מוסכמים דוקר ומספר גופים נוספים הקימו גוף בשם OCI (Open Container Initiative) ובמסגרתו נכתבו במהלך 2017 סטנדרטים ל-Container Runtimes ול-Container Images. תהליך הסטנדרטיזציה מאפשר לכל Runtime שתומך בסטנדרט להוריד ולהריץ כל אימג' סטנדרטי. דוקר עצמם הוציאו runtime רזה בשם containerd במסגרת פרויקט קוד פתוח שנקרא Moby.
להצלחה של המאמץ לסטנדרטיזציה בשיתוף פעולה של השחקנים המרכזיים בשוק יש השפעה רבה הן על היצרנים והן על הצרכנים. לצורך ההשוואה, כישלון הניסיונות לסטנדרטיזציה בעולם הווירטואליזציה גורם לכך שעד היום לא ניתן להעביר מכונות וירטואליות באופן חופשי בין סביבות והיתכנות מעבר כזו תלויה בקיום כלי v2v ולמעשה ברצון הטוב או ביכולת ההנדסה לאחור של היצרנים. לעומת זאת ההכרזה על סטנדרט בתעשיית הקונטיינרים מאפשרת לשלב בין פלטפורמות ולהחליף ביניהן בקלות יחסית, ומכיוון שיצרן שלא תואם לסטנדרט נתפס כיצרן שלא תומך בקונטיינרים, התעשייה כולה מתיישרת לסטנדרט.
ההתפתחות והעלייה בפופולאריות של טכנולוגיה מובילים לעיתים קרובות לגילוי שהיתרונות שלה לא מסתכמים בפתרון הבעיות שהובילו לפיתוחה, ומתפתחים בה שימושים חדשים. עם הזמן נעשה מעבר משימוש בקונטיינרים לסביבות פיתוח ו-POC לסביבות ייצור. המעבר הזה מוליד מצד אחד אתגרים לא פשוטים ומצד שני מאפשר יכולות חדשות וסולל את הדרך ליישום ארכיטקטורת תוכנה מודרנית מבוססת Microservices. היתרונות הבולטים של הארכיטקטורה הם גמישות, יעילות, נצילות ושרידות גבוהה, וכפועל יוצא מכך בצמצום עלויות ניהול ותחזוקה. אולם מעבר לכך, השילוב בין הארכיטקטורה לטכנולוגיה של קונטיינרים מתאים במיוחד להטמעה אפקטיבית של תהליכי פיתוח והפצה מהירים שמצמצמים משמעותית את הזמן מהגיית רעיון ועד ליישומו. המגמה בתעשייה מצביעה על כך שהאימפקט שיהיה לקונטיינרים ולטכנולוגיות שהתפתחו סביבם, עולם ה-Cloud Native, עתיד לגמד את המהפכה שחוללה הווירטואליזציה.
מייסד-שותף בחברת Wizards
איך הגענו לכאן?
כמו שכתבתי בסוף הפוסט הקודם בסדרה, הראשונים שעלו על פורמולה מנצחת לקונטיינרים הם דוקר (Docker). מעבר להוספה של היכולות הרלוונטיות לקרנל של לינוקס, נראה שקשה לערער על הטענה שהגורמים המרכזיים לפופולריזציה של קונטיינרים הם Docker. אני כותב גורמים כי יש שני Docker, האחד זה פרויקט הקוד הפתוח והמוצר המסחרי שהתפתח ממנו והשני זה החברה שעומדת מאחוריו, ולשניהם יש תרומה מרכזית לפופולריות של הטכנולוגיה.
החברה, Docker Inc., השקיעה משאבים רבים הן בשיווק והן בפיתוח. בצד השיווק החברה עשתה הרבה מאוד מאמצים לקדם את אימוץ הטכנולוגיה בתעשייה, בשנים הראשונות בעיקר אצל מפתחים ובהמשך גם בצד התשתיות. אי אפשר שלא להזכיר בהקשר הזה את העבודה המעולה של המאיירת Laurel שייצרה למותג שפה גרפית ייחודית וחביבה להפליא (מי לא אוהב את הלוויתנים של דוקר?) בצד הפיתוח, דוקר השכילו ליצור מוצר ידידותי ונוח שקרץ למפתחים רבים ולפחות בתחילת הדרך, זכה לאהבה רבה מקהילת הקוד הפתוח (קשה להאמין שרק חמש שנים עברו מאז).
הדבר הראשון שדוקר סיפקו היה מעטפת שיצרה על גבי היכולות של מערכת ההפעלה אבסטרקציה - אובייקט של קונטיינר. אמנם דוקר לא היו הראשונים שאפשרו להריץ קונטיינרים, ולמעשה בהתחלה הם בכלל התבססו על LXC לבניית קונטיינרים, אבל הם היו הראשונים שיצרו ממשק נוח למפתחים ומעבר לכך, Ecosystem שלם שמאפשר לצרוך ולשטף קונטיינרים בקלות ומספק חווית משתמש נוחה סביב הטכנולוגיה. דוקר הגדירו פורמט לקובץ אימג' של קונטיינרים והקימו מאגר אינטרנטי פתוח לאימג'ים, Docker Hub, שמאפשר לכל מי שמעוניין בכך לפרסם קוד ארוז ומוכן להרצה בקונטיינר.
הפתרון של דוקר מאפשר להפיץ אימג' של תוכנה מוכנה להרצה בקלות, בדומה לקלות של הפצת קוד מקור שמספקים שירותים כמו Github. דוקר אימצו שפה שתהייה טבעית למפתחים עם טרמינולוגיה שמתבססת על מונחים דמויי git –אפשר לעשות לאימג' push/pull, tagging and versioning. בגלל שמדובר על אימג'ים של קונטיינרים ולא על קוד, המשמעות לא תמיד זהה לגמרי אבל המונחים מקלים מאוד להשתלט על הטכנולוגיה במהירות.
וזה עבד מעולה, וזה עדיין עובד נפלא. אם פעם, לפני דוקר, הדגמה של מוצר דרשה להתקין ולהגדיר את התוכנה אצל הלקוח ולהתמודד עם תלויות ובעיות של הגדרות או להעביר אליו ג'יגות של קבצי מכונה וירטואלית ולקוות שכל העסק ינגן, כיום אפשר לשלוח ללקוח שם של אימג' של קונטיינר ההדגמה וכל מה שהלקוח צריך זה להריץ פקודה אחת כדי להוריד את האימג' ולהריץ אותו. דוקר אוהבים מאוד להדגיש את היכולת של קונטיינרים לשים סוף לסיפור של "בתחנה שלי זה עובד" (works on my machine).
ה-Runtime של דוקר הוא המוכר וככל הנראה הנפוץ ביותר, והמותג דוקר מזוהה אצל הרבה אנשים כשם גנרי לקונטיינרים, אבל קיימים בשוק מספר runtimes מתחרים בעלי תכונות שונות (כמו לדוגמה rkt). לאור קיומן של האלטרנטיבות התעורר צורך בהסכמה על סטנדרט שיאפשר למשתמשים לעבור בין runtimes שונים ולהעביר ביניהם אימג'ים בקלות. בנוסף, בגלל צרכים ובעיות שנדון בהם בהמשך, השוק אימץ פתרונות שונים לאורקסטרציה, כשהמוכר והמוביל מביניהם הוא קוברנטיס. המפתחים של קוברנטיס טענו שה-runtime של דוקר כולל תכונות שהטיפול בהן אמור להיות באחריותו של האורקסטרטור, ולכן נדרש לפתח סטנדרט שיגדיר מהן התכונות והיכולות שבאחריות ה-Runtime. על מנת לפתח סטנדרטים מוסכמים דוקר ומספר גופים נוספים הקימו גוף בשם OCI (Open Container Initiative) ובמסגרתו נכתבו במהלך 2017 סטנדרטים ל-Container Runtimes ול-Container Images. תהליך הסטנדרטיזציה מאפשר לכל Runtime שתומך בסטנדרט להוריד ולהריץ כל אימג' סטנדרטי. דוקר עצמם הוציאו runtime רזה בשם containerd במסגרת פרויקט קוד פתוח שנקרא Moby.
להצלחה של המאמץ לסטנדרטיזציה בשיתוף פעולה של השחקנים המרכזיים בשוק יש השפעה רבה הן על היצרנים והן על הצרכנים. לצורך ההשוואה, כישלון הניסיונות לסטנדרטיזציה בעולם הווירטואליזציה גורם לכך שעד היום לא ניתן להעביר מכונות וירטואליות באופן חופשי בין סביבות והיתכנות מעבר כזו תלויה בקיום כלי v2v ולמעשה ברצון הטוב או ביכולת ההנדסה לאחור של היצרנים. לעומת זאת ההכרזה על סטנדרט בתעשיית הקונטיינרים מאפשרת לשלב בין פלטפורמות ולהחליף ביניהן בקלות יחסית, ומכיוון שיצרן שלא תואם לסטנדרט נתפס כיצרן שלא תומך בקונטיינרים, התעשייה כולה מתיישרת לסטנדרט.
ההתפתחות והעלייה בפופולאריות של טכנולוגיה מובילים לעיתים קרובות לגילוי שהיתרונות שלה לא מסתכמים בפתרון הבעיות שהובילו לפיתוחה, ומתפתחים בה שימושים חדשים. עם הזמן נעשה מעבר משימוש בקונטיינרים לסביבות פיתוח ו-POC לסביבות ייצור. המעבר הזה מוליד מצד אחד אתגרים לא פשוטים ומצד שני מאפשר יכולות חדשות וסולל את הדרך ליישום ארכיטקטורת תוכנה מודרנית מבוססת Microservices. היתרונות הבולטים של הארכיטקטורה הם גמישות, יעילות, נצילות ושרידות גבוהה, וכפועל יוצא מכך בצמצום עלויות ניהול ותחזוקה. אולם מעבר לכך, השילוב בין הארכיטקטורה לטכנולוגיה של קונטיינרים מתאים במיוחד להטמעה אפקטיבית של תהליכי פיתוח והפצה מהירים שמצמצמים משמעותית את הזמן מהגיית רעיון ועד ליישומו. המגמה בתעשייה מצביעה על כך שהאימפקט שיהיה לקונטיינרים ולטכנולוגיות שהתפתחו סביבם, עולם ה-Cloud Native, עתיד לגמד את המהפכה שחוללה הווירטואליזציה.
מייסד-שותף בחברת Wizards
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר