AWS בנתה מחדש את Elastic Beanstalk כשירות לניהול אפליקציות

מאמר ממומן של AWS שפורסם ב-The New Stack ב-22 בספטמבר טוען שהבעיה הקשה של פלטפורמות ענן אינה מורכבות אלא אחריות תפעולית. את המאמר כתבו מנהלת השיווק המוצרי ב-AWS סבארי סאוואנט והאנליסט ג'נאקירם MSV, והוא מתאר כיצד AWS בנתה מחדש את Elastic Beanstalk כשירות לניהול אפליקציות שלוקח אחריות על כל מה שמתחת לאפליקציה.

מבחן שלוש לפנות בוקר

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

הם משווים שני מודלים: שליטה מלאה — תשתית כקוד, service mesh וצינורות פריסה מותאמים — ופשטות של אפליקציה אחת: דוחפים קוד ומקבלים כתובת URL. החברה האילוסטרטיבית שלהם היא חברת ביניים עם ארבעים מהנדסים, שמונה אפליקציות ייצור, איש SRE אחד שהוא למעשה מפתח בכיר בתורנות שאיש לא רוצה, וביקורת ציות שאיש לא החל להתכונן אליה.

ארבעה דפוסי כשל

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

ג'נאקירם MSV טוען שהפער מבני: cloud native תיקנן את שכבת התשתית סביב קונטיינרים ו-Kubernetes, אך לא תיקנן את הגבול התפעולי בין צוות האפליקציה לתשתית שמתחתיו. מחקר של CNCF עם SlashData מצא ש-28% מהארגונים מחזיקים צוות platform engineering ייעודי, 41% מפזרים את היכולות בין כמה צוותים ול-3% אין גישה פורמלית כלל — ושם, לפי המאמר, נמצאות רוב ארגוני ההנדסה בשוק הביניים.

מצבי Standard ו-Cluster

Elastic Beanstalk פועל כעת בשני מצבים, שינוי מארכיטקטורת הסביבה הבודדת הקודמת. מצב Standard מעניק בעלות תפעולית מלאה לאפליקציה אחת, כולל עומסי Windows ו-.NET Framework. מצב Cluster מרחיב את אותו מודל לכל תיק העבודות עם תשתית משותפת ופריסה מהקוד לייצור, כך שהאפליקציה השמינית חולקת עלויות עם שבע הראשונות.

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