שירותי מיקרוסופט: מה הם ולמה אכפת לעסק שלך

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

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

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

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

מה באמת שירותי מיקרוסופט?

הילווה חיבר דוח IDC משנת 2015 שכותרתו, "הופעת שירותי מיקרוסופט כגישה אדריכלית חדשה לבניית מערכות תוכנה חדשות." בדו"ח הוא מגדיר את שירותי המיקרו כארכיטקטורת תוכנה גרגרית בה רכיבי האפליקציה מתוכננים ומתפתחים באופן עצמאי כדי לעמוד בדרישות ההפעלה של יכולת פעולה הדדית (כלומר, קשורה לאפליקציה כולה). שירותי מיקרוסופט לא קיימים בוואקום. ארכיטקטורה חדשה דורשת תמיכה ארגונית חזקה ושינוי בתרבות ה- IT.

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

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

על ידי "תרבות פנימית" Hilwa מתייחס במידה רבה ל- DevOps, פילוסופיה המשלבת פיתוח תוכנה, פעולות IT ואבטחת איכות (QA) לזרימת עבודה יחידה ושיתופית. הפעלת תוכנת DevOps HashiCorp ומייסדיה הם כבר מזמן תומכים בשירותי מיקרו. החברה, שהבטיחה לאחרונה גיוס של סדרה B בסך 24 מיליון דולר, מונה חברות כמו סיסקו, DigitalOcean, Mozilla ו- Stripe בקרב משתמשי הקוד הפתוח ולקוחות הארגוניים שלה.

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

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

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

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

"איביי נקטה בגישה המונוליטית; הם בנו את כל eBay כקו ארוך של 50 מיליון שורות של אפליקציות קוד", אמר דדגר. "גישת שירותי המיקרו כואבת יותר בהתחלה מכיוון שבעיות המודולריות וההפעלה הדדית הן כאלה שאינן קיימות במונוליט. אך הדברים מתחילים להתפרק כאשר האפליקציה גדלה מדי. במונולית אין פירוק.

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

מכולות ושירותי מיקרוסופט בעולם DevOps

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

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

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

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

מכולות, הפופולריות על ידי פיצוץ הקוד הפתוח של דוקר, רחוקות מלהיות כלי הכלים היחיד שיכולים להשתמש בהן כדי להקל על שירותי מיקרו. ההילווה של IDC מסר כי מכולות משמשות באפליקציות מודרניות כחלק מזרימות העבודה של CI / CD ובמקרים מסוימים תוך כדי פריסה לייצור. אך לדבריו, שירותי מיקרו יכולים למנף מכונות וירטואליות (VMs) גם ללא צורך במכולות.

עם זאת, כשמדובר בדרכים בהן מתפתחות העננים העסקיים, מכולות Docker ושירותי מיקרו הם שילוב כלים עוצמתי שמחבק על ידי עסקים מכל הצורות והגדלים - החל מסטארט-אפים כמו HashiCorp ועד ענקיות ארגוניות כמו אורקל. מהדאגאר של HashiCorp נמסר כי מכולות הן האמצעי הנוח שבאמצעותן Dev ו- Ops (וגם, בהתאחדות, צוותים ושירותים שונים) מתקשרים זה עם זה.

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

DevOps ושירותי מיקרו עדיין רחוקים מאימוץ ארגוני נרחב אך השוק רק צומח. על פי דוח ה- IDC, ארכיטקטורת שירותי המיקרו תיכנס לשלב התבגרות בחמש השנים הבאות. בגרות זו תתרחש בעקבים של תרבות DevOps שתגיע ל 50 אחוז מהארגונים עד 2020, המשך ההתפתחות של כלי אוטומציה לתוכנה והשליטה על תשתית ענן זולה וניתנת להרחבה הניתנת על ידי אוהדי Amazon Web Services (AWS) ו- Microsoft Azure.

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

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

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