מה זה Platform Engineering? הסבר + משרות פתוחות בישראל

זמן קריאה: 6 דקות

Platform Engineering הוא בניית פלטפורמה פנימית שמאפשרת למפתחים בארגון לפרוס, לנטר ולנהל שירותים בעצמם, בלי לפנות לצוות תשתיות בכל פעם. המוצר של הצוות הזה הוא המפתחים האחרים. בלוח HiTakeJob פתוחות כרגע 110 משרות שמזכירות Kubernetes, 47 Terraform ו-12 Helm.

למה התחום הזה נולד דווקא אחרי DevOps

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

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

מה בעצם בונה צוות פלטפורמה?

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

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

במה זה שונה מ-DevOps ומ-SRE?

שלושת התחומים חופפים בכלים ונבדלים בשאלה שהם עונים עליה:

	Platform Engineering	DevOps	SRE
מי הלקוח	המפתחים בארגון	צוות הפיתוח שלצידו	המשתמש הסופי
התוצר	מוצר פנימי לשימוש עצמי	אוטומציה ו-pipeline	SLO, ניטור ותחקירים
מדד הצלחה	כמה מהר צוות חדש עולה לאוויר לבד	תדירות ויציבות השחרורים	עמידה ביעדי אמינות
מתי זה מוצדק	מעשרות מפתחים ומעלה	כמעט בכל גודל	כשיש תנועה משמעותית

הרחבנו על ההבדל בין שני התחומים האחרים במה זה DevOps ובDevOps ו-SRE.

מה זה IDP ולמה כולם מדברים עליו?

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

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

איך נראה יום עבודה בצוות פלטפורמה

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

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

מה צריך לדעת כדי להיכנס לתחום

תחום	מה נדרש	משרות פעילות
אורקסטרציה	Kubernetes ברמת תפעול ובנייה, לא רק שימוש	107
תשתית כקוד	Terraform, כולל כתיבת מודולים לשימוש חוזר	42
אריזה ופריסה	Helm, גרסאות ותאימות לאחור	12
CI/CD	בניית pipeline שצוותים אחרים יורשים	39
תכנות	Python או Go לכלים פנימיים	Python 365, Go 56
ענן	AWS או GCP ברמת ארכיטקטורה	AWS 127, GCP 42

זהו תפקיד שמגיעים אליו מ-DevOps, מסיסטם או מפיתוח Backend - לא מקורס. את המשרות אפשר לראות במשרות Terraform ובמשרות Kubernetes.

מתי פלטפורמה הופכת לנטל

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

על מה צוות פלטפורמה נמדד

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

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

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

המיומנות שלא כתובה במודעה

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

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

שאלות נפוצות

Platform Engineering מחליף את DevOps?

לא, הוא שלב התבגרות שלו. DevOps הגדיר את העיקרון שצוות אחראי לקוד שלו מקצה לקצה; Platform Engineering מספק את הכלים שהופכים את זה לאפשרי בארגון גדול. בלוח 18 משרות מזכירות DevOps במפורש ו-110 מזכירות Kubernetes.

מאיזה גודל ארגון מצדיק צוות פלטפורמה?

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

אפשר להיכנס לתחום הזה בלי רקע בפיתוח?

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

אילו כלים הכי כדאי ללמוד קודם?

Kubernetes ו-Terraform, לפי סדר הביקוש - 107 ו-47 משרות פעילות בהתאמה. אחריהם כדאי להוסיף כלי CI/CD (47 משרות) ואת Helm לניהול פריסות. חשוב ללמוד אותם על מערכת אמיתית ולא רק בסביבת תרגול מקומית.

האם זה תפקיד שמתאים למי שאוהב לכתוב קוד?

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

מה ההבדל בין פלטפורמה פנימית לענן ציבורי?

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