ארכיטקטורה של פלטפורמות פיתוח פנימיות ב-Azure: בניית היסוד

By Mirko Peters · 2026-08-13

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

Automatically translated with AI from the original post. Read the English original

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

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

מבוא לפלטפורמות פיתוח פנימיות ב-Azure

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

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

ארבעת העמודים המרכזיים של IDP מודרני

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

שירות עצמי בלי עומס תפעולי

שירות עצמי הוא לב הפועם של כל IDP. במבנה מסורתי, כשמפתח צריך סביבת בדיקות חדשה או מופע של Cosmos DB, הוא פותח כרטיס ב-Jira, ממתין לצוות הפלטפורמה שיבדוק אותו, ממתין לצוות התפעול שיקים את המשאב, ומקווה שהתצורה תתאים לסביבת הייצור. IDP ב-Azure מאוטומט את כל מחזור החיים הזה. דרך פורטל מרכזי, מפתחים יכולים להפעיל תהליכי שירות עצמי שמקימים משאבים תוך דקות, ומצמצמים באופן משמעותי את זמן ההמתנה לשינויים.

נתיבי זהב ושכבות הפשטה

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

מינוף שירותי Azure לתשתית מקורית

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

ניהול זהויות והרשאות עם Microsoft Entra ID

אבטחה מתחילה בזהות. Microsoft Entra ID (שנקרא בעבר Azure Active Directory) משמש כעמוד השדרה של האבטחה ב-IDP שלכם. על ידי שילוב פורטל הפלטפורמה עם Entra ID תוכלו לאכוף Single Sign-On (SSO) ולמפות קבוצות מפתחים ליכולות ספציפיות של הפלטפורמה. באמצעות Azure Managed Identities, היישומים שאתם מפיצים יכולים לגשת בצורה מאובטחת למשאבי Azure אחרים – כמו Azure Key Vault או Azure SQL – בלי להטמיע אישורי גישה בקובצי התצורה או במאגרי הקוד.

הפשטות לנתונים ולאחסון

ליישומים נדרשים נתונים, אבל צוותי הפלטפורמה לא צריכים להקים ידנית מסדי נתונים בכל פעם שצוות מתחיל פרויקט חדש. אפשר להשתמש ב-Azure Service Operator for Kubernetes או בתבניות Azure Resource Manager (ARM) העטופות בתהליכי עבודה של שירות עצמי, כדי להקים לפי דרישה שירותים מנוהלים כמו Azure Database for PostgreSQL, Azure Cosmos DB או Azure Cache for Redis. ה-IDP מבטיח שמסדי הנתונים האלה יוקמו עם הצפנה במנוחה, כללי חומת אש מתאימים וגיבויים אוטומטיים שמופעלים כברירת מחדל.

אסטרטגיות קונטיינריזציה ותזמור

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

Azure Kubernetes Service כמנוע המחשוב

עבור רוב הארגונים המודרניים, Azure Kubernetes Service (AKS) משמש כמנוע המחשוב המרכזי של ה-IDP. AKS מספק את יכולות ההרחבה, הניידות והתזמור הנדרשות להפעלת מיקרו-שירותים בקנה מידה גדול. עם זאת, מפתחים לא צריכים לכתוב מניפסטים גולמיים של YAML עבור Kubernetes. ה-IDP שלכם צריך להסתיר את המורכבות של בקרי Ingress, מדיניות רשת ו-Persistent Volume Claims מאחורי הפשטות עומסי עבודה ברמה גבוהה.

רישום קונטיינרים ואבטחת שרשרת האספקה

Azure Container Registry (ACR) משתלב בצורה חלקה עם AKS ומהווה חלק קריטי באסטרטגיית הקונטיינרים שלכם. ה-IDP צריך להפוך לאוטומטי את הצינור שמוביל מ-commit של הקוד ועד בניית תמונת הקונטיינר, ולהשתמש בכלים כמו Microsoft Defender for Containers כדי לסרוק תמונות לאיתור פגיעויות לפני שהן מגיעות בכלל לאשכול. על ידי הטמעת ACR בתהליכי העבודה של הפלטפורמה, אתם מבטיחים שרק תמונות מהימנות ונסרקות יוכלו להיפרס לסביבות הייצור.

עקרונות Infrastructure-as-Code לפיתוח פלטפורמות

Infrastructure-as-Code (IaC) אינו אופציונלי כשבונים IDP. כל רכיב תשתית שהפלטפורמה מנהלת חייב להיות מוגדר, מנוהל בגרסאות ומופץ באמצעות צינורות אוטומטיים.

בחירת כלי ה-IaC במערכת האקולוגית של Azure

Azure תומך במגוון רחב של כלי IaC. Bicep היא שפת הדומיין הספציפית של Microsoft לפריסת משאבי Azure בצורה דקלרטיבית, והיא מציעה תחביר נקי יותר מתבניות ARM מסורתיות, עם תמיכה מובנית ביכולות של Azure. לחלופין, Terraform (או OpenTofu) מאומץ נרחב בסביבות מרובות ענני ציבור ובארגונים גדולים. לא משנה באיזה כלי תבחרו, ה-IDP שלכם צריך להסתיר את הסקריפטים האלה מהמפתח ולהריץ אותם מאחורי הקלעים כשבקשת ההקמה מאושרת.

ניהול מצב ועיצוב מודולרי

כדי לשמור על יכולת תחזוקה של הפלטפורמה, בנו ספרייה של מודולי תשתית לשימוש חוזר. לדוגמה, צרו מודול סטנדרטי בשם "web-api-module" שמאגד פריסה של App Service או AKS עם מסד נתונים וייעוד ניטור מתאים. שמרו את מצב ה-IaC שלכם בצורה מאובטחת בחשבונות Azure Storage עם הפעלה של blob versioning, כך שצוות הנדסת הפלטפורמה יחזיק נתיב ביקורת אמין של כל שינויי התשתית בכל המנויים.

הטמעת מעקות בטיחות לאבטחה וציות

חשש נפוץ של ההנהלה כשמאמצים פלטפורמות שירות עצמי הוא אובדן השליטה באבטחה ובציות. IDP אפקטיבי הופך את הנרטיב הזה על ידי הזזת האבטחה שמאלה (shift security left) והטמעת מעקות בטיחות ישירות בתהליכי העבודה של הפלטפורמה.

Azure Policy כמאכף אוטומטי

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

ניהול סודות ואינטגרציה עם Key Vault

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

בניית פורטל מפתחים לשירות עצמי

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

אימוץ Backstage לפורטלים מבוססי Azure

מסגרות קוד פתוח כמו Backstage של Spotify הפכו לתקן דה facto לבניית פורטלים למפתחים. ב-Backstage אפשר ליצור קטלוג תוכנה, לנהל תבניות (הנקראות software templates) ולשלב תוספים. אפשר לבנות תוספי Backstage מותאמים אישית שמתקשרים ישירות עם ממשקי ה-API של Azure, ומאפשרים למפתחים להקים משאבי Azure, לצפות בבריאות השירותים ולעקוב אחר צינורות הפריסה, הכול מלוח מחוונים אחד.

עיצוב חוויית מפתח אינטואיטיבית

בעת עיצוב הפורטל, התייחסו למפתחים כאל לקוחות. חוויית המשתמש חייבת להיות חלקה ונטולת חיכוכים. מפתח צריך להיכנס לפורטל, לבחור בתבנית "Microservice with SQL Backend", למלא טופס פשוט עם שם השירות וצוות הבעלים, וללחוץ על שליחה. תוך דקות בודדות, ה-IDP אמור להקים את תשתית Azure, ליצור מאגר GitHub עם קוד בסיסי (boilerplate), להגדיר את צינור ה-CI/CD ולרשום את השירות בקטלוג הפנימי.

מדידת הצלחה והצעדים הבאים

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

מדדי מפתח למעקב

התמקדו במדדים שמשקפים את מהירות הפיתוח ואת יציבות הפלטפורמה. עקבו אחר הזמן עד ה-hello world הראשון של מפתחים חדשים בחברה, תדירות הפריסות, שיעור כישלונות השינוי וזמן השחזור הממוצע (MTTR). בנוסף, הפעילו סקרי שביעות רצון קבועים בקרב המפתחים, כדי להבין היכן נמצאים עדיין נקודות החיכוך בתהליכי העבודה בפלטפורמה.

מה הלאה

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

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