תשתית ענן: מה שנראה זול עולה הכי ביוקר

צוות אחד הוציא 45,000 דולר בשנה על load balancer מנוהל. כשהחליפו אותו ב-HAProxy (טכנולוגיה בת עשרות שנים), הם לא רק חסכו את הכסף, הם גם טיפלו בפי עשרה יותר תעבורה.

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

ואז יש את AWS, שנפלה בגלל כלי ה-AI שלה עצמה.

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

כאשר "נוחות" הופכת לכלא

השיחה על שירותים מנוהלים תמיד מתחילה באותו המקום: "פשוט נפעיל את זה ב-AWS, מינימום תחזוקה, שני המפתחים שלנו מתמקדים בפיצ'רים".

בשנה הראשונה זה נשמע נכון.

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

הבעיה העמוקה יותר: כשעושים lock-in לספק ספציפי, לא רק קונים תחזוקה, אלא גם את אופן החשיבה שלו. כל ה-trade-offs שהוא עשה בתכנון השירות הופכים ל-trade-offs שלכם, גם אם הם לא מתאימים לתרחיש שלכם.

הצוות שעבר מ-ALB ל-HAProxy לא עשה מהלך אמיץ. הם פשוט החליטו להבין מה הם בונים.

מסד נתונים הוא לא אתר הטמנה

יש תפיסה שמפתחים נופלים אליה כמעט בכל פרויקט בשלב מסוים: מסד הנתונים הוא "הקופסה שאליה שומרים דברים".

אוסף טבלאות. מקום לדחוף נתונים.

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

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

לא הייתם בונים אסדת נפט בלי סקרים גיאולוגיים. מדוע לתכנן סכמה בלי להבין את דפוסי השימוש?

השאלות שצריך לשאול בתחילת כל פרויקט:

• מה הנתונים שיישאלו הכי הרבה פעמים?
• איפה נדרשת עקביות חזקה, ואיפה אפשר להתפשר?
• כיצד ייראו הנתונים כשיהיו פי עשרה יותר מהיום?

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

כאשר AWS נופל בגלל הכלים שלה עצמה

לפני מספר שבועות, AWS סבלה ממספר הפסקות שנגרמו על ידי כלי ה-AI שלה עצמה. זו אותה חברה שמבטיחה 99.9% זמינות.

התגובה של אמזון: "שגיאה אנושית, לא שגיאת AI" - טכנית נכון, בני אדם הוסיפו כלי AI לתהליכי פריסה בלי שנקבעו עדיין best practices לשימוש כזה.

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

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

Takeaways

שלושת הסיפורים האלה מלמדים את אותו הדבר: בתשתית, ה-trade-off האמיתי הוא לא בין מהיר ליקר, אלא בין שליטה להקלת עבודה.

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

הצוותים שמנצחים לטווח ארוך הם אלה שמשתמשים בשירותים מנוהלים בצורה מודעת, לא כהרגל.