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

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

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

זה כמו על תוכנית בנייה לעומת בנייה ידנית. תוכנית היא ניתנת לשחזור, לשיתוף ולביקורת. תנו אותה למי שהוא אחר, והוא יבנה בדיוק את אותו הדבר. כיום, כמה כלים עושים זאת? תבניות ARM, בייספ, טרפורם, פולומי. כולם מיישמים את אותו קונספט בדרכים שונות. זו הבחנה חשובה. תשתית כקוד, IAC, היא הקונספט. בייספ הוא רק כלי אחד שמיישם אותו. אבל הנה העניין. לאז'ר יש שפת IAC כבר שנים בשם תבניות ARM. ויש סיבה לכך שמייקרוסופט בנתה אחת חדשה. בעיית תבניות ה-ARM. תבניות ARM הן פורמט העיק המקורי של Azure. אלו קבצי JSON, ויש להם יתרונות רבים. כיסוי מלא של כל משאב באז'ר, ואותו מנוע פריסה שבו היא משתמשת פנימית. אם אפשר ליצור משהו בפורטל, אפשר להגדיר אותו בתבנית ARM. אז מה הבעיה? JSON מצוין למכונות, אבל נורא לבני אדם. הרשו לי להראות לכם למה אני מתכוון. חשבון יחסון בתבנית ARM דורש כף מינוס 20 שורות קוד. אותו חשבון יחסון בביספ דורש כף מינוס 10 שורות. גרסת ה-JSON גדולה בערך פי 2, וזה רק משאב פשוט. דמיינו פריסה מלאה עם רשתות, מחשוב, מסדי נתונים וכללי הבטחה.

תבנית ה-ARM הופכת לקיר של טקסט. נקודות התורפה הנפוצות צפויות מראש. סיכים חסרים, סוגריים לא תואמים, כינון מפורט מדי שמקשה להבין איפה משאב אחד נגמר והשני מתחיל. אתם מבלים יותר זמן בהיאבקות עם תחביר JSON מאשר בהגדרת התשתית שלכם. ואז ישנן התלויות. בארם, עליכם להצהיר ידנית על תלויות Depends On. אם ישב א', זקוק למשאב בית כדי שיהיה קיים קודם, עליכם לכתוב זאת במפורש. פספסתם אחד, והפריסה שלכם נכשלת. בהצלחה בלהבין איזה מהם פספסתם. אם ניסיתם אי פעם לכתוב קובץ JSON של 200 שורות ביד, זה לא כיף. אפילו לא קצת. עקומת הלמידה תלולה. חברי צוות חדשים מתקשים להבין תבניות ARM. חסם הכניסה גבוה. ומה קורה בפועל? צוותים רבים מסתיימים עם אדם אחד שמכיר את תבנית הארם. אותו אדם הופך לנקודת קשל יחידה. הם היחידים שיכולים לשנות את הפריסה והיחידים שיכולים לנפות שגיאות כשמשהו משתבש. זה לא בר קיימה. מייקרוסופט שמעה את המשוב, אז היא בנתה את בייספ כדי לפתור בדיוק את הבעיות האלה. מה זה בייספ? אז מה זה בעצם בייספ? זו שפה שנועדה לפריסת משאבי Azure, וביסודה היא מהדר Transpire.

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

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

בואו נדבר על מה באמת שונה כשכותבים בבייספ במקום ב-ARM.json. גודל הקובץ הוא הבדל מובן מאליו. קבצי בייספ הם בערך חצי מהגודל של תבניות ARM מקבילות. זו לא הגזמה. אתם מסירים את כל המרכאות, הפסיקים, הסוגריים והטקסט המיותר, ומה שנשאר זה רק הגדרת התשתית. חצי מכמות הקוד, אותה תוצאה. קריאות נובעת מכך באופן טבעי. פחות שורות, מבנה נקי יותר, וקל יותר להבנה במבט חטוף. כשפותחים קובץ בייספ, אפשר לסרוק אותו ולהבין מה נפרס. עם ARM.json צריך לעבור דרך שכבות של כינון לפני שמוצאים את הגדרת המשאב בפועל. תלויות הן דרך מצוינת לחסוך זמן. בערם, אתם מצהירים ידנית על Depends On. פספסתם אחד, והפריסה שלכם תיקשל. בביספ, עם משאב א', מתייחס למשאב בית, המערכת מטפלת בזה אוטומטית. היא מוסיפה את התלות כשהיא עוברת הידור לערם.json. אתם לא צריכים לחשוב על זה, זה פשוט עובד. וזה לבדו חוסך שעות של איתור בגים. מודולים הם הבדל מרכזי נוסף. בערם היו תבניות מקוננות, אבל היה קשה לעבוד איתן. קבצים נפרדים, קישור מורכב, קשה לנהל גרסאות. בביספ יש מודולים שהם נקיים יותר, ניתנים לניהול גרסאות וניתנים לשימוש חוזר.

מגדירים מודול פעם אחת, מפרסמים אותו לרישום ומתייחסים אליו מכל מקום. אותו מודול, אותה הגדרה בכל פעם. תהליך הפריסה עצמו זהה לחלוטין. בייספ עובר הידור לערם.json, ואז Azure Resource Manager פורס אותו. אותו מנוע, אותו צינור, פייפליין. אתם לא צריכים לשנות את תהליך הפריסה שלכם, רק את הדרך שבה אתם כותבים את התבניות. What If היא תכונה שקיימת טכנית בארם, אבל בייספ הופך אותה להרבה יותר נגישה. אפשר להציג תצוגה המקדימה של שינויים לפני הפריסה ולראות בדיוק מה ייווצר, ישונה או ימחק. בלי הפתעות, בלי מחיקות בטעות. מריצים את What If, בודקים את הפלט, ואם זה נראה נכון, פורסים. עקומת הלמידה היא תכום שבו בייספ בולט. ARM-JSON מניח שאתם יודעים מה אתם עושים. הוא מיועד למכונות, לא לבני אדם. בייספ מיועד למתחילים. תחביר אינטואיטיבי, כלי עבודה שמדריכים אתכם. אפשר ללמוד אותו אחר הצהריים ולהיות פרודוקטיביים עד סוף השבוע. מייקרוסופט הפכה את בייספ לחוויית הכתיבה המומלצת. כל התכונות והשיפורים החדשים מכוונים לבייספ קודם. תבניות ARM עדיין עובדות והן לא הולכות להיעלם, אבל כנראה שלא כדאי לכם לכתוב חדשות.

אם אתם מתחילים פרויקט חדש היום, בייספ היא הדרך הנכונה. שלוש שורות של בייספ כדי לפרוס קבוצת משאבים. רק שלוש שורות. ה-ARM-JSON המקביל הוא בערך 15 שורות. אותה תוצאה, אותה פריסה, אבל אחד קריא והשני רועש. עכשיו, אולי אתם תוהים. מה לגבי טראפורם? האם עליי ללמוד בייספ או טראפורם? בייספ מול טראפורם, במי כדאי להשתמש? ברוכים השווים ל-Microsoft Knowledge Nuggets. אני מרקו פיטרס, והיום נטפל בשאלה שחוזרת על עצמה. בייספ או טראפורם? בואו נפרק את זה. טראפורם עובד על פני עננים מרובים. אפשר להשתמש בו עבור Azure, AWS, GCP, או אפילו שלושתם יחד. בייספ, לעומת זאת, בנוי עבור Azure בלבד. ההבדל המהותי הזה משפיע על כל השאר. אם אתם עובדים על פני מספר עננים, טראפורם הוא הדרך הנכונה. לומדים שפה אחת, כלי אחד, תהליך עבודה אחד, וזה עובד בכל מקום. אבל, אם אתם עובדים בעיקר ב-Azure, לבייספ יש שתרונות משמעותיים. הנה הראשון שבהם. אין קובץ מצב, State File, לניהול. טראפורם שומר קובץ מצב שעוקב אחר מה שהוא פורס, וזה קובץ קריטי. אם הוא משתבש או יוצא מסמכרון, יש לכם בעיה רצינית.

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

זה מסלול פשוט יותר כשמתחילים. לא צריך ללמוד על קבצי מצב, ספקים או הגדרות back-end. מתקינים את Azure CLI, פותחים את VS Code ומתחילים לכתוב. מספיק עם התיאוריה. בואו נדבר על מה שבאמת צריך כדי להתחיל. מתחילים. מה שבאמת צריך. צריך שני דברים כדי להתחיל. Azure CLI והרחבת בייספ עבור VS Code. זה הכל. אין צורך בהתקנת בייספ-CLI נפרד ואין כלים נוספים להגדרה. Azure CLI מגיע עם בייספ מובנה. התקנת Azure CLI היא פשוטה למדי. עברו למסמכי מייקרוסופט. מצאו את דף ההתקנה עבור מערכת ההפעלה שלכם. אם אתם במק, זו פקודה אחת. brew-install Azure CLI. בווינדוס יש מתקין MSI. הורידו, הריצו וזהו. זה עובד גם בליוקס דרך מנהל החבילות שלכם. ברגע שזה מותקן, הריצו S-Version כדי לוודא שהכל עובד. אתם אמורים לראות את גרסת Azure CLI וגם את גרסת הבספ ברשימה. עכשיו, פיתחו את VS Code, עברו ללוח ההרחבות בצד שמאל וחפשו בייספ. התקינו את זו של Microsoft, לא של צד שלישי, את הרשמי. אתם באמת צריכים את ההרחבה הזו. היא מעניקה לכם IntelliSense שמציע מאפייני משאבים בזמן ההקלדה, מדגיש תחביר כדי לזהות שגיאות במבט חטוף ובודק טעויות בזמן אמת.

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

ראשית, מגדירים את טווח היד כמנוי, ואז מגדירים את המשאב, קבוצת משאבים עם שם ומיקום. זה הכל, שלוש שורות. השבו זאת ל-Arm.json המקביל, שזה בערך 15 שורות של סוגריים וגרשים. כדי לפרוס, משתמשים ב-Azure CLI. מכיוון שאתם פורסים בטווח המנוי, הפקודה היא S-Deployment Sub-Create. אתם מעבירים מיקום עבור מתא נתוני הפריסה ומפנים לקובץ ה-Bicep שלכם. זו הדרך בשורת הפקודה, אבל יש גם חוויה מודרכת. ב-VS Code, לחצו לחיצה ימנית על קובץ ה-Bicep ובחרו Deploy Bicep File. זה מלווה אתכם לאורך כל התהליך. זה מבקש שם לפריסה, לבחור את המנוי שלכם, ליצור או לבחור קבוצת משאבים, ושואל אם יש לכם קובץ פרמטרים. אתם אומרים לא, וזה פורס. התוצאה מופיעה בפורטל האז'ר שלכם. זההלי לחיצות בפורטל, אבל עכשיו יש לכם קובץ שניתן לעשות בו שימוש חוזר. אתם יכולים להוסיף אותו למאגר שלכם, לשתף עם הצוות ולהריץ שוב מחר. וכאן מגיע החלק הקסום. הריצו את אותה פריסה שוב וראו מה קורה. הכוח של אידמפוטנטיות. זה העניין לגבי הרצת פריסות. אתם רוצים להיות מסוגלים להריץ אותן שוב ושוב מבלי לשבור כלום.

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

כך בונים ביטחון בתשתית שלכם. הקובץ הוא מקור האמת. לא הזיכרון שלכם, לא מסמך וורד, לא סרטון יוטיוב מלפני חצי שנה, אלא הקובץ. אז איפה בייספ משתלב בתמונה הגדולה של Azure? התמונה הגדולה, איפה בייספ משתלב? בייספ חי בתוך המערכת האקולוגית של Azure Resource Manager. זה לא כלי נפרד. רבים חושבים כך, אבל למעשה זו פשוט דרך טובה יותר לכתוב תבניות ARM. מתחת למכסה המנוע, זה עדיין ARM. אותו מנוע פריסה, אותו API, הכל אותו דבר. ההבדל היחיד הוא איך שכותבים את זה. ומכיוון שבייספ עובר קומפילציה ל-ARM, כל מה שעובד עם ARM עובד עם בייספ. Azure Policy עוכף ציות על הפריסות שלכם. RBSC שולט במי יכול לפרוס מה. Cost Management עוקב אחר ההוצאות על המשאבים שלכם. Azure DevOps ו-Github Actions פורסים את קבצי הבייספ שלכם דרך צינורות עיבוד. הכל עובד בצורה מושלמת כי בייספ מייצר ג'ייסן בטקן ARM. אתם לא מאבדים כלום במעבר. למעשה, אתם מרוויחים בהירות. מייקרוסופט בנתה מערכת אקולוגית שלמה סביב בייספ. Azure Verified Modules או AVM, הן ספריות מנוהלות של מודולי בייספ וטרפורם שעומדות בשיטות העבודה המומלצות.

אתם לא חייבים לכתוב הכל מאפס. ניתן להשתמש במודולים מוכנים מראש לדפוסים נפוצים כמו רשתות וירטואליות, חשבונות איחסון ושירותי אפליקציה. הם נבדקים, מתוחזקים ומיושרים עם ה-Well-Architected Framework. ה-Cloud Adoption Framework כולל מימושי עזר של בייספ עבור ארכיטקטורות ארגוניות סטנדרטיות. אם אתם בונים לנדינג זון, יש תבנית בייספ מוכנה לכך. Deployment Stacks מעניקים לכם ניהול מחזור חיים עבור קבוצות של משאבים. ניתן לפרוס ערמה, סטאק, ואם תסירו משאב מקובץ הבייספ שלכם, הערמה תוכל לנקות אותו עבורכם, או להגן עליו ממחיקה מקרית. אתם מחליטים. ה-Core System ממשיך לצמוח עם עוד מודולים, כלים טובים יותר ואינטגרציה עמוקה עם AI ו-G-Thub Copilot. ניתן לתאר מה אתם רוצים בשפה פשוטה, וקופילות ייצר את קוד הבייספ עבורכם. מייקרוסופט ממשיכה להשקיע בבייספ כחוויית העריכה העיקרית עבור Azure. לכן, פיצ'רים חדשים מכוונים קודם כל לבייספ. תבניות ARM עדיין עובדות, אבל החדשנות קורית בבייספ. אז, הנה השורה התחתונה. אם אתם עובדים באז'ר, בייספ הוא הצעד הטבעי הבא מעבר ללחיצות בפורטל.

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

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