למה ארגון זקוק ל-twin, ואיך Mithril מספקת אותו
הייצור הוא המקום הלא נכון ללמוד מי יכול להגיע למערכת רגישה, איך נראה סירוב, או אם האשכול שרץ תואם לזה שהוצהר. twin שומר על השמות האלה ואינו מחיל את התוצאה. Mithril הופכת את ה-twin למסמך: רכיבים בשם של דומיין הפוך מורכבים יחד, הרצה מחזירה את התגובה ואת ההחלטה, ואשכול נבדק מול תצפית בלי שיופעל.
מאמר זה תורגם במכונה.
חברה זקוקה ל-twin מפני שהשאלות שחשובות אי אפשר לשאול בייצור. מי יכול להגיע למערכת שמחזיקה נתוני לקוחות. איך נראית קריאה שנדחתה כשמכסה מוצתה. אם האשכול שרץ היום הוא האשכול שהוצהר. הייצור הוא המקום שבו לקוחות, תשלומים וזהות כבר חיים. שימוש בו כמקום ללמוד את התשובות האלה קושר סקרנות להשבתה. הקפאת כל שינוי עד שוועדה בטוחה היא הכישלון האחר: המערך ממשיך לזוז, והמודל שלו אינו זז.
twin הוא עותק שני של המערך הזה עם אותם שמות ועם כלל קשיח שדבר אינו מוחל. ה-principal, ה-bucket, התור והאשכול אמיתיים מספיק כדי לענות על השאלה. ההשפעה נעצרת בעותק. אבטחה, פלטפורמה וארכיטקטורה יכולים לתרגל התרה, סירוב, תקלה וסטייה לפני שמי מאלה מגיע לחשבון שגובה תשלום מלקוחות.
Mithril הופכת את ה-twin למסמך, לא לענן שני. כל חלק במערך הוא רכיב שנקרא על שם הדומיין ההפוך שלו, והרכיבים מורכבים זה עם זה. זהות, הרשאה, מכסה, עקביות, תקלה ו-TLS יושבים תחת השירות שזקוק להם. הרצה עוברת לאורך השרשרת הזו ומחזירה שני דברים שהמפעיל יכול לשמור: התגובה שלקוח היה רואה, וההחלטה שייצרה אותה. דגל ה-applied נשאר false. זמן הריצה אינו פותח שקע, ומסמך שנותן שם למארח חי או לסוד נדחה לפני שהוא רץ.
אותו גבול מכסה את האשכול. Docker ו-Podman עטופים כמסמך Mithril שמציין אילו שירותים צריכים להתקיים ואיך הם תלויים זה בזה. רינדור המסמך מפיק את קובץ ה-Compose. הבדיקה משווה את ההצהרה למה שנצפה בפועל. הבדיקה אינה מפעילה קונטיינרים. החברה מקבלת תרגול של המערך שלה, לצד המנועים שכבר מדברים את פרוטוקולי הענן, עם רישום של מה שהוחלט ומה שבמכוון לא הוחל.