לפני חמש שנים, מהנדס DevOps אחד יכול היה לתמוך בערך בעשרה מפתחים. היום המציאות הזו השתנתה לחלוטין. בעזרת כלי פיתוח מבוססי בינה מלאכותית כמו Cursor או סוכני AI, ארכיטקט תשתיות יחיד יכול לתת מענה לשלושים מפתחים ומעלה. מה שפעם דרש צוות שלם ושישה חודשי עבודה, אדם אחד מסוגל להקים היום תוך יום עבודה בודד. על הנייר זו מהפכה, בפועל, מדובר במלכודת, מכיוון שכאשר ניהול התשתיות הופך קל ונגיש יותר, קל מאוד ליפול למקום המסוכן ביותר עבור סטארטאפ: Over Engineering.
זהו דפוס חוזר שאני רואה בשטח. במסגרת עבודתי ב-Sela, יצא לי לעבוד עם חברה שהריצה בסך הכל כמה אפליקציות בודדות. היה להם מהנדס מוכשר שרצה לבנות מערכת בדיוק לפי הספר. הוא הקים קלאסטר מורכב של EKS קוברנטיס בשילוב רשימה ארוכה של רכיבי מערכת משלימים כמו ArgoCD או Prometheus. המערכת הייתה נראית מדהימה, תצורה מושלמת על הנייר, ממש Textbook setup שמתאים בעיקר להצגה ב LinkedIn.
שנה לאחר מכן, הוא כבר טבע בקונפליקטים של גרסאות. כדי להשתלט על האירוע, החברה גייסה מהנדס שני, ובהמשך המורכבות דרשה גם מהנדס שלישי. פתאום, צוות של שלושה אנשים בכירים שרף את רוב זמנו על שדרוגי גרסאות יומיים, מיגרציות של שרשראות דפנדנסיז ותחזוקת התשתית של המערכת עצמה, ללא שום השפעה על המוצר או על ההתקדמות העסקית.
בזמן שהחברה הפסידה כסף, המהנדסים ניהלו דיונים אסטרטגיים על Vendor Lock in. החברה שילמה משכורות עתק למחלקה שלמה שפשוט תחזקה את עצמה. העברנו אותם ל ECS Fargate. התוצאה הייתה עשרים אחוז ירידה מיידית בעלויות הענן בזכות הסרת הרכיבים המיותרים, וחיסכון של פי חמישה במאמצי התחזוקה. התשתית חזרה לחיות בתוך ה IaC הרגיל שלהם והצוות חזר לפתח את המוצר במקום לנהל מלחמות מול הארכיטקטורה. מורכבות היא לא בגרות, פשטות שיודעת לצמוח היא כן.
שש השאלות של ה- Runway
לפני שהצוות שלכם רץ להטמיע את הכלי החדש שכולם מדברים עליו ברשתות החברתיות כמו X או Reddit, תעצרו. אל תאשרו רכיבים חדשים בלי לקבל תשובות ברורות תוך פחות מיום לשש השאלות הבאות:
1.איזה פער עסקי הכלי הזה פותר ומה האלטרנטיבות שעומדות בפנינו?
2. איך נראה מודל העלות כאשר אנחנו עושים Scale למעלה או למטה?
3. מהו מאמץ ההטמעה האמיתי כולל אבטחה, מערכות SSO ו- Compliance?
4. כמה שעות תחזוקה שוטפת נדרש להשקיע בכל חודש עבור שדרוגים וגרסאות?
5. איך נראה ניתור העלות היומית של הרכיב הזה בחשבונית הענן שלי?
6. איך נראית ה- Knowledge Transfer, והאם מפתח חדש יוכל לפתור תקלה ברכיב הזה בשתיים בלילה בזמן Down בלי הבחור שבנה אותו?
אם הצוות לא יודע לענות על השאלות האלו, יש לכם פה עלות נסתרת שאף אחד לא תקצב מראש.
הכסף שנשאר על הרצפה
כאשר סטארטאפ נמצא במירוץ, הוא נוטה לבצע טעויות יקרות. דוגמה נפוצה היא חיבור שירותי בסיסי נתונים חיצוניים כמו MongoDB Atlas או Databricks דרך האינטרנט הציבורי. זו טעות של מתחילים שגוררת חשבוניות מנופחות על Data Transfer Out, אבטחה חלשה וביצועים איטיים פי שניים. פתרון פשוט כמו AWS PrivateLink סוגר את הסיפור הזה בכמה שעות עבודה, משאיר את המידע מאובטח וחוסך אלפי דולרים.
אבל הטעות הגדולה ביותר היא פשוט חוסר מודעות. תשעים וחמישה אחוזים מהחברות שאני פוגש לא יודעות מה הן יכולות לקבל מספקית הענן שלהן או מהשותף שמלווה אותן. אם אתם מבצעים מעבר לענן או שדרוג מערכות, ספקית הענן לרוב תממן עבורכם את ה- Professional Services של הפרויקט. לאחר סיום מוצלח, מגיעים לכם קרדיטים שיכולים לכסות בין שלושה לחמישה חודשי צריכה. אם אתם רוצים לבחון שירות AI חדש כמו Bedrock, קיימים תקציבים ייעודיים ל- POC. לצאת לדרך בלי לנצל את התוכניות האלו זה פשוט להשאיר כסף חי על הרצפה של ה Runway שלכם.
בשורה התחתונה, תפקידם של אנשי Software Developer או DevOps לא נעלם, הוא פשוט משתנה ועובר תהליך של תיעוש. הבינה המלאכותית תכתוב את ה Syntax ותקים את ה Terraform קוד מהר יותר ממה שאי פעם דמיינו. מה שיקבע אם הסטארטאפ שלכם ינצח זה שיקול הדעת ותחושת הבעלות על המערכת. הארכיטקטורה הטובה ביותר היא לא המתוחכמת ביותר, אלא זו שהצוות שלכם מסוגל לנהל, שהעסק שלכם יכול לממן, ושהמהנדס שלכם באון קול יכול לתקן בשתיים בלילה בזמן תקלה בלי לבכות.
איך נראית התשתית שלכם כרגע, האם בניתם חללית מורכבת או מערכת פשוטה שבאמת סוחבת בעלייה?
האזנה לפרק 
קריאת הבלוג 
צפייה בוידאו 
שאלות / פידבק
