מראה שחורה ב-DevOps: הקהל קובע את ארכיטקטורת הענן

ארכיטקטורת ענן לא נשברת כי מישהו בחר כלי לא נכון. היא נשברת כשבוחרים כלי נכון בלי להבין על מה משלמים אחר כך. הקהל בחר כאן את המסלול: Monorepo, Continuous Deployment, Kubernetes, Terraform, multi-tenant ו-Argo CD מנוהל. ואז ניב יונגלסון וסתיו אוצ׳קובסקי עושות את החלק שרוב הדיונים מדלגים עליו - מפרקות את המחיר של כל בחירה.

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

תמיד, תמיד, תמיד יש טרייד אופים.

Monorepo: שיתוף קוד בלי חומות, ועם רדיוס פיצוץ גדול יותר

נקודת הפתיחה היא codebase. ב-Monorepo כל המיקרו-שירותים נמצאים באותו repository. נוח לשתף קוד, לנהל תלויות בין שירותים, לסנכרן גרסאות ולעשות commit שחוצה כמה פרויקטים. לא צריך לפצל שינוי לכמה repositories ולרדוף אחר גרסאות תואמות.

אבל הנוחות הזו לא חינם. יותר קוד נכנס לחישוב של ה-build וה-CI/CD, ולכן התהליך יכול להתארך. מפתח חדש לא נכנס ל-repository קטן ומבודד, אלא צריך להתמצא במערכת רחבה יותר. ובמקום שבו הכול מחובר, שינוי שבור יכול להפוך ל-single point of failure עבור כולם.

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

Continuous Deployment: קוד ירוק הוא לא אישור אוטומטי

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

אלא ש-CD משנה את definition of done. הוא לא יכול להיות החלטה של אנשי DevOps בלבד. הטסטים חייבים להיות חלק מהעבודה, גם אם AI עזר לכתוב אותם. בלי test coverage אמיתי, באגים מגיעים לפרודקשן מהר יותר. בלי observability טובה, הם גם נשארים שם יותר מדי זמן כי אין דרך להבין מה נשבר.

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

Kubernetes על EKS: גמישות שמגיעה עם מערכת שלמה לנהל

בצומת של סביבת הריצה הקהל בחר Kubernetes על EKS ולא serverless. Kubernetes נותן קונטיינרים, orchestration, scheduling, self-healing ו-scaling ברמת ה-nodes וה-pods. הוא גם platform-agnostic: אפשר לעבוד על AWS, Azure, GCP ואפילו on-prem.

זו יכולת אמיתית. זו גם עקומת למידה. הצטרפות של אנשים חדשים לצוות אינה פשוטה כשצריך להבין ecosystem שלם. גיוס מומחים קשה יותר, הסטאפ עשוי לעלות יותר, ולפתרון פשוט Kubernetes עלול להיות over-engineering. לא כל שירות צריך cluster כדי להיות “רציני”.

אחרי הבחירה, התרשים כבר מכתיב מציאות: AWS account, VPC, EKS cluster, node groups והאפליקציה שרצה בתוכם. הארכיטקטורה נראית מסודרת על הלוח. בפרודקשן מישהו צריך להפעיל אותה, לשדרג אותה ולדעת להחזיר אותה לפעולה.

Terraform: Infrastructure as Code לא מבטל את המציאות

כעת הקהל בוחר Terraform על פני CloudFormation. הרעיון של Infrastructure as Code פשוט: לקחת שיטות מוכרות מניהול קוד - version control, היסטוריית שינויים ובדיקת מי שינה מה - ולהחיל אותן על תשתית. במקום ליצור bucket או security group ידנית, מגדירים resource בקוד.

Terraform מוסיף יתרונות מעשיים: אפשר לעבוד מול ספקים שונים, להשתמש ב-providers למערכות נוספות ולמחזר modules. אבל הוא מחזיק state, וה-state הזה פוגש מהר מאוד את המציאות. שינוי ידני בענן, apply שלא בוצע, או state שנפגע יוצרים drift: הקוד מתאר עולם אחד והענן נראה אחרת.

כלומר, אני הייתי רוצה את הרצוי ככה והמצוי הוא אחרת.

זה לא באג של Terraform. זה מחיר של ניהול תשתית חיה. ככל שהתשתית גדולה יותר, גם planning ו-apply יכולים לקחת יותר זמן. IaC מאפשר משמעת. הוא לא מחליף אותה.

multi-tenant ו-Argo CD: פחות תפעול, יותר תלות

בניהול הדאטה, הבחירה היא multi-tenant. במקום cluster, database או משאבים נפרדים לכל לקוח, משתמשים במשאבים משותפים. לסטארטאפ SaaS זו התחלה הגיונית: פחות resources להקים, פחות תפעול, וניצול טוב יותר של מה שכבר רץ. הבחירה גם מתיישבת עם Kubernetes אחד ולא cluster לכל לקוח.

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

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

ה-region נפל. הארכיטקטורה נשארה עם ההחלטות שלה

בסוף מגיעה התקלה המדומה: region של AWS נופל. ה-cluster נבנה ב-region אחד, ולא הוקם cluster נוסף באזור אחר. שום בחירה קודמת לא הייתה “טעות” בפני עצמה. אבל יחד הן יצרו מערכת עם גבולות ברורים.

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

אל תפרידו את מה אתם בונים, מאיפה אתם בונים אותו.

השורה התחתונה

• Monorepo ו-CD מגדילים מהירות, אבל מחייבים איכות בדיקות ו-observability ברמה ארגונית.
• Kubernetes נותן orchestration וניידות, אך מביא עקומת למידה ועלות תפעולית.
• Terraform מכניס תשתית ל-version control, אבל לא פותר drift או את זמני העבודה של תשתית גדולה.
• multi-tenant ושירותים מנוהלים מפשטים את ההווה, ויכולים להגביל את העתיד.
• ארכיטקטורת ענן טובה אינה אוסף כלים פופולריים. היא אוסף tradeoffs שמתאים למוצר האמיתי שלכם.