ארכיטקטורת Micro-Services (בעברית: “מיקרו-שירותים”) נחשבת לטרנד החם של העשור האחרון ועושה רושם שהיא לא תיעלם מהמפה בזמן הקרוב. יותר ויותר ארגונים מייצרים את המוצרים שלהן על סמך הגישה הזו, וגם לא מעט חברות ותיקות דואגות להעביר את הקוד המפלצתי שלהן למיקרוסרביסים.
במובן מסויים, רבים חושבים שמדובר באיזשהו פתרון קסם שבלחיצת כפתור יפתור את כל הבעיות שלהם בקוד. במציאות, זה לא תמיד כזה פשוט וחשוב להבין לאן אתם נכנסים. אז מה זה אומר, מי משתמש בזה, ולמה כולם עובדים ככה היום?
תוכן עניינים
מה זה מיקרו-שירותים?
מיקרו-שירותים (Micro-Services) היא גישה ארכיטקטונית לפיתוח תוכנה, כאשר הרעיון המרכזי מאחוריה הוא לבנות אפליקציה אחת שמחולקת להמון שירותים קטנים. כל אחד מהשירותים ממוקד במטרה אחת ויחידה, והקשר בין הסרביסים חלש ככל האפשר, ואם אפשר אז אפילו ללא תלות בכלל.
רוברט מרטין (המוכר גם בשם Uncle Bob) טבע את המונח SRP (עקרון אחריות יחידה – Single-responsibility principle) כחלק מעקרונות SOLID. העקרון אומר שכל פונקציה וכל מחלקה צריכים להיות אחראים על דבר אחד בלבד וכך גם מיקרו-שירותים. ולמה בעצם?
לכל שירות יש את מערך הקוד שלו, הטסטים שלו, התלות שלו בספריות אחרות, ובעצם הוא מתפקד לגמרי כמו התוכנה שאתם מכירים. רק שבמקרה הזה היא תהיה עם פונקציונאליות קטנה, קלילה, פשוטה, טסטבילית (נו, אתם מתחילים כבר להבין את היתרונות?).
השירותים יודעים לתקשר אחד עם השני באמצעות ממשקי API פשוטים, וכך כולם יחד מתעסקים בפתירה ופירוק של בעיה עסקית מורכבת ולפעמים מורכבת מאוד.
מה היה כאן לפני תקופת
המיקרו-שירותים?
אם לא בחרתם בגישת המיקרו-שירותים אז כנראה שבחרתם בארכיטקטורת השכבות או המונוליט.
ההגיון של השיטות הללו מסתכם במשפט- כל הלוגיקה שלנו נמצאת במקום אחד, על שרת אחד. אם אתם חברת סטארט-אפ חדשה או חברה קטנה, כמעט בטוח שגם בשנת 2022 תבחרו לעבוד בגישה הזו. קל להרים מונוליט מאפס ואנו מקבלים בגישה הזו ערך יחסית מהר.
אבל מה עם כל שאר היתרונות והחסרונות?
חסרונות
בהתחשב בעלייה של טכנולוגיות חדשות שהופכות את ניהול המיקרו-שירותים לקל עוד יותר, רשימת היתרונות הולכת ומתעצמת על פני החסרונות – אבל בכל זאת הם קייימים. בעוד שחלק גדול מתהליך הפיתוח מפושט בזכות מיקרו-שירותים, ישנם כמה תחומים שבהם מיקרו-שירותים יכולים למעשה לגרום למורכבות חדשה.
-
תפעול מאתגר
אחד החסרונות הבולטים של מיקרו-שירותים הוא העובדה שיש הרבה יותר “חלקים נעים” מאשר ביישומים מסורתיים – הדבר הזה דורש מאמץ עצום של תכנון קפדני ואוטומציות מיושמות אסטרטגית, כדי להבטיח שתהליכי תקשורת, ניטור, בדיקות ופריסה יתנהלו בצורה חלקה. - שינויי תרבותי
כל יוזמה של שירותי מיקרו מחייבת את הארגון שלכם לבצע שינויים בתרבות הפנימית שלהם. לפני שהם יכולים בכלל להתחיל את תהליך ההגירה, חייבת להיות תרבות Agile ו-DevOps פעילה ובוגרת במקום. - עלויות
חיסרון פוטנציאלי נוסף של ארכיטקטורת שירותי מיקרו הוא העלות.
השירותים יצטרכו לתקשר זה עם זה, מה שמביא לנפח עצום של קריאות API. זה יכול להשפיע על עלויות העיבוד, מעבר למה שאתם עשוי רגילים לשלם בשימוש בארכיטקטורות מסורתיות.
יתרונות (או למה כולם עובדים ככה היום?)
- דרושים פחות מאמצי פיתוח כדי לגדול
דרושים פחות מאמצי פיתוח כדי לגדול בשל האופי העצמאי של מיקרו-שירותים, צוותי פיתוח קטנים יותר יכולים לעבוד במקביל על רכיבים שונים. זה מקל באופן משמעותי על תהליך הפיתוח ועל תחזוק האפליקציה בכללותה. - ניתן לפריסה עצמאית
דיברנו על זה שכל שירות הוא יחידה מתפקדת ועצמאית, מה שנותן לנו את האפשרות לפרוס את השירות בכל מקום שרק נרצה, והכי חשוב – תחזוקה ותיקון שגיאות. נוכל לבצע שינויים בקוד ולפרוס מחדש את המיקרו שירות מבלי לפרוס ולבצע עדכון גרסה באפליקציה כולה. - בידוד תקלות/באגים משופר
אם יש לכם באג כשאתם עובדים בשיטת מונוליט, גם כישלון של רכיב קטן מהאפליקציה הגדולה הזו יכול להיות בעייתי ובלתי נגיש בכללותו. במקרים מסוימים, מציאת השגיאה עלולה להיות גם מייגעת ולשרוף לכם המון זמן.
תחשבו על זה – בארכיטקטורה הזו קל לבודד את הרכיב הגורם לבעיה, מכיוון שהאפליקציה כולה מחולקת ליחידות תוכנה עצמאיות ומתפקדות במלואן. אם מתרחשות שגיאות, יחידות אחרות שאינן קשורות עדיין ימשיכו לפעול ולא תפספסו את היחידה שצועקת לעזרתכם. - גמישות רבותיי – גמישות!
את הסעיף הזה אני יכול לפרוט לארבעה סעיפים שונים, אך אתמצת אותו לשני חלקים כדי לא לאכול לכולנו את הראש:- גמישות טכנולוגית
תחשבו על זה רגע – הרי אם כל השירותים שאנו בונים הם עצמאיים ולא תלויים אחד בשני, אז בתכלס אם כתבנו עד עכשיו בNET. מה זה משנה אם את השירות הבא נפתח בשימוש בשפת תכנות אחרת לגמרי?
האם זה יפריע לנו לממש את השירות החדש בפייתון? NodeJs? כמובן שלא! זה כשלעצמו מדהים בעיני, מכיוון שזה מאפשר גמישות לא רק למתכנתים אלא גם למגייסים. - גמישות באחסון
עוד יתרון הוא היכולת לאחסן שירותים שונים במגוון מקומות, וכך לחלק עומסים על השרתים ולפצל במקרה הצורך – ותמיד מגיע צורך כזה.
לעומת זאת, ארכיטקטורות מונוליטיות ו-SOA מגבילות את אפשרויות אחסון הנתונים למיקום אחד בלבד. אמנם הגישה הזו עובדת מצוין עבור אפליקציות קטנות, אבל זה לא בדיוק פתרון שניתן לשדרוג.
- גמישות טכנולוגית
- פיתוח מקבילי
מיקרו-שירותים מאפשר לכל צוות את היכולת לעבוד באופן עצמאי ובלתי תלוי מצוותים אחרים.
מבוסס על סיפור אמיתי
בשנת 2022 כמות הדוגמאות לחברות שמשתמשות בגישה הזו היא באמת אינסופית,
אך אתרכז ב3 חברות שכולנו מכירים היטב, בעיקר כי בעיניי הן היו החלוצות בתחום.
- Netflix
נטפליקס היא אחת החברות המדוברת ביותר בהקשר של מיקרו-שירותים.
הסיפור של נטפליקס שפונה למהפך הזה מתחיל ב-2009, כאשר גישה זו לא הייתה ידועה כלל.
הם הקימו את ארכיטקטורת המיקרו-שירותים שלהם ב-AWS.תהליך המעבר שלהם התקדם בשלבים: ראשית הם העבירו קידוד סרטים ויישומים אחרים שאינם פונים ללקוח. לאחר מכן הם ניתקו אלמנטים מול לקוחות, כמו הרשמות לחשבון, בחירת סרטים, בחירת מכשיר ותצורה.
לנטפליקס נדרשו שנתיים כדי לפצל את המונוליט שלהם לשירותי מיקרו, ובשנת 2011 הכריזה על סיום התכנון מחדש של המבנה שלהם וארגונו באמצעות ארכיטקטורת שירות מיקרו. - Spotify
לחברה היו יותר מ-75 מיליון משתמשים פעילים מדי חודש, היא חיפשה פתרון שיתאים לכל כך הרבה משתמשים, יתמוך במספר פלטפורמות ויטפל באופן כללי בבעיות מורכבות.
הם רצו להיות תחרותיים בשוק שנע במהירות על ידי היותם מהירים.
צוותי הטכנולוגיה שלהם מצאו דרך לעמוד בדרישות הנ”ל על ידי השקת שירותי מיקרו המנוהלים על ידי לא פחות מ-90 צוותים אוטונומיים. - Amazon
אתר האינטרנט הקמעונאי של אמזון התחיל כמו כולם מאפליקציה מונוליטית אחת.
כך תיאר מנהל המוצר הבכיר של אמזון את המצב: “אם תחזרו לשנת 2001”, אמר רוב בריגהם, מנהל בכיר לניהול מוצר של אמזון AWS, “האתר הקמעונאי של Amazon.com היה מונוליט ארכיטקטוני אחד גדול”.בשנת 2001 המדוברת – עיכובים בפיתוח, אתגרי הקוד ואיסוף תלויות בשירותי החברה עצרו את יכולתה של אמזון לעמוד בדרישות קנה המידה של עצמה ושל בסיס הלקוחות הגדל במהירות.
לנוכח הצורך לשחזר את המערכת שלהם מאפס, אמזון פיצלה את היישומים המונוליטיים שלה ליישומים קטנים, הפועלים באופן עצמאי וספציפיים לשירות.לדוגמה: הם פיתחו שירות יחיד עבור כפתור הקנייה בדף מוצר, שירות יחיד עבור פונקציית מחשבון המס וכו’.
אמזון הקצתה את הבעלות על כל שירות עצמאי לצוות מפתחים. זה איפשר לצוותים לראות את צווארי הבקבוק בפיתוח בצורה מפורטת יותר ולפתור אתגרים בצורה יעילה יותר מכיוון שמספר קטן של מפתחים יכלו להפנות את כל תשומת הלב שלהם לשירות יחיד.בשנת 2022, כ20 שנה מאז הסיפור הזה אמזון הפכה ליצרנית המובילה בעולם בפתרונות לתמיכה במיקרו-שירותים וביננו אין היום כמעט ארגון שלא משתמש בשירותי AWS.
כמה מילות סיכום
לאחר שקלול היתרונות והחסרונות של הארכיטקטורה הזו, ברור מדוע חברות רבות בוחרות לנתק מונוליטים סוררים ממכונות ההנשמה ולשנות הרגלים. הרבה הבינו כי יש השפעה ענקית שהשינוי הזה מביא איתו ברמת הביצועים, היעילות והשינוי הארגוני שמאפשרים חווית פיתוח ושימוש יעילות יותר.
עם זאת, לפני שאתם דוחפים לשינוי כזה בחברה שלכם, חשוב להבין את האתגרים והסיכונים הקשורים ליוזמה כה מורכבת, ואם בא לכם לבחון את זה – תמיד אפשר להתחיל מפירוק של חתיכה אחת מהקוד הגדול.
[…] נוחה יותר עם ארכיטקטורת Micro-Services –מה זה Micro-Services / מיקרו-שירותים? כתבתי על זה כאן.באופן כללי בעת שכל המוצר חי על הענן, זה […]