microservices- כאילו .. מה?
- פותח הנושא TakeCtrl
- פורסם בתאריך
לא מסובך
פעם ראשונה שאני שומע על זה אבל מהתיאור של זסקה ומהכירות טובה עם ספרינג זה ברור לגמרי מה זה עושה.
בגדול זה מאפשר לכתוב תוכנית קצרה ("main") שתאזין לבקשות HTTP ותחשוף מתודות כסרביסים בפרוטוקול REST. היתרון של זה הוא שבמקום לבנות WAR שמתחיל ב20 MB ולהריץ אותו על Servlet Container שגם הוא די כבד עם זמן עליה וdeploy וזלילת זיכרון, אתה מריץ מCMD ג'אווה קטן שמריץ את הJAR שלך וזהו, הוא מאזין על פורט ומוכן לעבודה. זה המקבילה הג'אוואית לפרימוורקים שיש בשפות שהזכרתי (node, python, ruby) וזה באמת הכי מתאים למיקרו סרביסים.
זה מסביר הכל:
http://projects.spring.io/spring-boot/#quick-start
איזה עוד דרך יש לך בג'אווה להרים WS בצורה כזאת?
פעם ראשונה שאני שומע על זה אבל מהתיאור של זסקה ומהכירות טובה עם ספרינג זה ברור לגמרי מה זה עושה.
בגדול זה מאפשר לכתוב תוכנית קצרה ("main") שתאזין לבקשות HTTP ותחשוף מתודות כסרביסים בפרוטוקול REST. היתרון של זה הוא שבמקום לבנות WAR שמתחיל ב20 MB ולהריץ אותו על Servlet Container שגם הוא די כבד עם זמן עליה וdeploy וזלילת זיכרון, אתה מריץ מCMD ג'אווה קטן שמריץ את הJAR שלך וזהו, הוא מאזין על פורט ומוכן לעבודה. זה המקבילה הג'אוואית לפרימוורקים שיש בשפות שהזכרתי (node, python, ruby) וזה באמת הכי מתאים למיקרו סרביסים.
זה מסביר הכל:
http://projects.spring.io/spring-boot/#quick-start
איזה עוד דרך יש לך בג'אווה להרים WS בצורה כזאת?
דווקא ה jar מנופח ואתה מריץ עם java -jar
האריזה כוללת הכל כולל הכל, אבל באמת, למי אכפת, תן לי jar אחד שכולל הכל כולל הכל כולל השרת וועב וזהו, מה אני צריך להסתבך?
ואני מסכים, זוכר את התשדיר של חד"ש משנות ה80 - "קלילללל, קליללל" , זה בדיוק זה.
בנינו שירות בעבודה שמראה על מסכי ה jenkins שלנו סרטונים מצחיקים שקשורים לעבודה, אז אחרי שכמה חבר'ה אצלנו בנו את הסרביס הראשון הם העלו שם סרטון של ג'וני דפ מ"שודדי הקאריביים" עושה הוקוס פוקוס בידיים.
כן, יש שם לכאורה הוקוס פוקוס, אבל מי שמכיר java וחפר בקישקעס ובקרביים של פריימוורקים שונים יכול להבין לבד איך מימשו את spring boot או לקבל ניחוש מושכל.
האריזה כוללת הכל כולל הכל, אבל באמת, למי אכפת, תן לי jar אחד שכולל הכל כולל הכל כולל השרת וועב וזהו, מה אני צריך להסתבך?
ואני מסכים, זוכר את התשדיר של חד"ש משנות ה80 - "קלילללל, קליללל" , זה בדיוק זה.
בנינו שירות בעבודה שמראה על מסכי ה jenkins שלנו סרטונים מצחיקים שקשורים לעבודה, אז אחרי שכמה חבר'ה אצלנו בנו את הסרביס הראשון הם העלו שם סרטון של ג'וני דפ מ"שודדי הקאריביים" עושה הוקוס פוקוס בידיים.
כן, יש שם לכאורה הוקוס פוקוס, אבל מי שמכיר java וחפר בקישקעס ובקרביים של פריימוורקים שונים יכול להבין לבד איך מימשו את spring boot או לקבל ניחוש מושכל.
טרול המתכנן
New member
אני לא יודע מי כותב על מה ואיך קוראים לדברים ולא מעניין אותי
העובדה היא שהיום כל הקוד שאני כותב כדי לתקשר בין אפליקציות שרצות על מחשבים שונים הוא:
// host a:
subscribe some_channel
// host b:
publish some_channel something
או (single consumer):
// host a:
brpoplpush jobq todo 0
// host b:
rpush jobq "hello, world"
זהו.
העובדה היא שהיום כל הקוד שאני כותב כדי לתקשר בין אפליקציות שרצות על מחשבים שונים הוא:
// host a:
subscribe some_channel
// host b:
publish some_channel something
או (single consumer):
// host a:
brpoplpush jobq todo 0
// host b:
rpush jobq "hello, world"
זהו.
רעיון עתיק ביותר. הנה סיפור
מקום שעבדתי בו לפני 15 שנה. מיקרוסופט וwindows היו הדבר הכי חם בשוק...
מערכת ענקית שהתעקשו לפתח כל חלק בה שיהיה עצמאי לגמרי, ללא תלויות, קופסה שחורה, ניתנת להחלפה, קרא לזה איך שאתה רוצה.
בזמנו היו כותבים קבצי DLL ומשתמשים בעיקר בCOM. הרעיון היה שאתה יכול לפזר את המודולים האלה איפה שתרצה, לבזר אותם, להריץ אותם כסרביס, לעטוף אותם, מה שרק תרצה. זה היה כל כך גנרי שאפילו הקריאות לפונקציות נעשו דרך פרוטוקול שתיאורטי יכל לתמוך בכל שפה מה שהיה בזמנו נחשב למשהו די חדשני, אנחנו מדברים בשנים שלפני הWS כשהXML היה בשורה עולמית...
בסוף מה שקרה זה שכמה אלפי קומפוננטות היה צריך לפנות אליהם ולתחזק בדרך מסורבלת ומעצבנת. כמובן ש90% מהקוד היה פנימי לחלוטין וללא שום סיבה הגיונית שאי פעם יחליפו אותו או ירצו לבזר אותו.
עכשיו, אני לא בעד או נגד מיקרו שרותים או כל דבר אחר אבל זה בוודאי שלא קונספט חדש, ויותר חשוב: כמו כל ארכיטקטורה חשוב לקחת את זה בפרופורציות, להבין חסרונות ויתרונות ולנסות להשתמש בזה שיש לכך סיבה.
יש מקרים שיותר נכון לפתח חלקים שתלויים אחד בשני וחולקים משאבים משותפים ויש מקרים שבאמת זה טוב להפריד ולבזר.
הדוגמא הכי בנאלית זה כששני סרביסים לא מסתכלים על אותו מידע persistence (במילים אחרות, לא מחוברים לאותו DB). אז נכון, אפשר להגדיר קריאות ושירותים וממשק ביניהם וכל אחד שולח לשני ומה לא, אבל לפעמים יותר פשוט ונכון יהיה ששניהם כותבים וקוראים מאותו מקום למרות שזה פחות מגניב במצגות בכנסים.
מקום שעבדתי בו לפני 15 שנה. מיקרוסופט וwindows היו הדבר הכי חם בשוק...
מערכת ענקית שהתעקשו לפתח כל חלק בה שיהיה עצמאי לגמרי, ללא תלויות, קופסה שחורה, ניתנת להחלפה, קרא לזה איך שאתה רוצה.
בזמנו היו כותבים קבצי DLL ומשתמשים בעיקר בCOM. הרעיון היה שאתה יכול לפזר את המודולים האלה איפה שתרצה, לבזר אותם, להריץ אותם כסרביס, לעטוף אותם, מה שרק תרצה. זה היה כל כך גנרי שאפילו הקריאות לפונקציות נעשו דרך פרוטוקול שתיאורטי יכל לתמוך בכל שפה מה שהיה בזמנו נחשב למשהו די חדשני, אנחנו מדברים בשנים שלפני הWS כשהXML היה בשורה עולמית...
בסוף מה שקרה זה שכמה אלפי קומפוננטות היה צריך לפנות אליהם ולתחזק בדרך מסורבלת ומעצבנת. כמובן ש90% מהקוד היה פנימי לחלוטין וללא שום סיבה הגיונית שאי פעם יחליפו אותו או ירצו לבזר אותו.
עכשיו, אני לא בעד או נגד מיקרו שרותים או כל דבר אחר אבל זה בוודאי שלא קונספט חדש, ויותר חשוב: כמו כל ארכיטקטורה חשוב לקחת את זה בפרופורציות, להבין חסרונות ויתרונות ולנסות להשתמש בזה שיש לכך סיבה.
יש מקרים שיותר נכון לפתח חלקים שתלויים אחד בשני וחולקים משאבים משותפים ויש מקרים שבאמת זה טוב להפריד ולבזר.
הדוגמא הכי בנאלית זה כששני סרביסים לא מסתכלים על אותו מידע persistence (במילים אחרות, לא מחוברים לאותו DB). אז נכון, אפשר להגדיר קריאות ושירותים וממשק ביניהם וכל אחד שולח לשני ומה לא, אבל לפעמים יותר פשוט ונכון יהיה ששניהם כותבים וקוראים מאותו מקום למרות שזה פחות מגניב במצגות בכנסים.
אני לא טוען שהרעיון חדשני
אבל התעשייה כן התקדמה והשתנתה, ועובדה שהיום אף אחד לא מדבר על לממש מיקרו סרוויסים ב soap וזה לדעתי דיי ברור שהם מדברים אחד עם השני בjson׳ים. אז זה לא בדיוק אותו הדבר ואני משער שאם הייתי כותב קוד באותה תקופה הייתי מוצא הבדלים נוספים, אבל זאת ממש לא הנקודה.
 
לא ניסיתי להגיד שזה פתרון חדשני, רק ניסיתי להסביר למה הבחור פה רואה דיאגרמות ולא שמות של טכנולוגיות/שפות/פריימוורקים. מראש לא רציתי להיכנס ללמה כן לעשות מיקרוסרוויסים, כי זה ברור שזה יהפוך לדיון של ״אבל רגע כבר עשינו את זה בעבר, אז מה באמת ההבדל?״ ולא הייתי רוצה לקחת את זה לשם (ולא בגלל שאני לא מסכים איתכם).
 
לגבי זה שאפשר להגיע לאלפי סרוויסים - זה לגמרי אחד הכאבים וצריך מאוד להיזהר לא להגיע לשם. אחד הדברים הכי קשים במימוש של הארכיטקטורה (בעיניי) זה להגדיר את ה׳גבולות׳ של כל סרוויס, וברור שאין פה תשובה חד משמעית כי היא משתנה בין כל אפליקציה.
 
אני מסכים שאפשר לכתוב ולקרוא מאותו מקום (וזה הרבה יותר פשוט, בלי ספק) - אבל אני חושב שהבעיה העיקרית היא לשמור על ה׳גבולות׳ בין המודולים השונים ולוודא שקיימת הפרדה. זה כביכול מאוד ׳קל׳ כשאין לך ברירה אלא לקרוא לסרוויס אחר - אבל כשאתה יכול ממודול אחד לקרוא ולרשום לטבלה של מודול אחר (בין אם זה אותו דטהבייס ובין אם לא) - אנשים בסופו של דבר עושים את זה (אני משער שזה סוג של the path of least resistence).
 
אני מאמין שאם יש מוביל טכנולוגי / ארכיטקט (או כמה) שדואג שדברים כאלו לא יקרו וכן תיהיה הפרדה - לא חובה לפצל לכל כך הרבה סרוויסים. אין פה נכון או לא נכון - בעיניי כל חברה, בהתחשב בגודל הצוות פיתוח שלה, כמות הקוד, אופי האנשים והשלב בחיים שלה (סטארט אפ בתחילת הדרך או מוצר שרץ כבר כמה שנים) - צריכה למצוא מה מתאים ונכון לה.
אבל התעשייה כן התקדמה והשתנתה, ועובדה שהיום אף אחד לא מדבר על לממש מיקרו סרוויסים ב soap וזה לדעתי דיי ברור שהם מדברים אחד עם השני בjson׳ים. אז זה לא בדיוק אותו הדבר ואני משער שאם הייתי כותב קוד באותה תקופה הייתי מוצא הבדלים נוספים, אבל זאת ממש לא הנקודה.
 
לא ניסיתי להגיד שזה פתרון חדשני, רק ניסיתי להסביר למה הבחור פה רואה דיאגרמות ולא שמות של טכנולוגיות/שפות/פריימוורקים. מראש לא רציתי להיכנס ללמה כן לעשות מיקרוסרוויסים, כי זה ברור שזה יהפוך לדיון של ״אבל רגע כבר עשינו את זה בעבר, אז מה באמת ההבדל?״ ולא הייתי רוצה לקחת את זה לשם (ולא בגלל שאני לא מסכים איתכם).
 
לגבי זה שאפשר להגיע לאלפי סרוויסים - זה לגמרי אחד הכאבים וצריך מאוד להיזהר לא להגיע לשם. אחד הדברים הכי קשים במימוש של הארכיטקטורה (בעיניי) זה להגדיר את ה׳גבולות׳ של כל סרוויס, וברור שאין פה תשובה חד משמעית כי היא משתנה בין כל אפליקציה.
 
אני מסכים שאפשר לכתוב ולקרוא מאותו מקום (וזה הרבה יותר פשוט, בלי ספק) - אבל אני חושב שהבעיה העיקרית היא לשמור על ה׳גבולות׳ בין המודולים השונים ולוודא שקיימת הפרדה. זה כביכול מאוד ׳קל׳ כשאין לך ברירה אלא לקרוא לסרוויס אחר - אבל כשאתה יכול ממודול אחד לקרוא ולרשום לטבלה של מודול אחר (בין אם זה אותו דטהבייס ובין אם לא) - אנשים בסופו של דבר עושים את זה (אני משער שזה סוג של the path of least resistence).
 
אני מאמין שאם יש מוביל טכנולוגי / ארכיטקט (או כמה) שדואג שדברים כאלו לא יקרו וכן תיהיה הפרדה - לא חובה לפצל לכל כך הרבה סרוויסים. אין פה נכון או לא נכון - בעיניי כל חברה, בהתחשב בגודל הצוות פיתוח שלה, כמות הקוד, אופי האנשים והשלב בחיים שלה (סטארט אפ בתחילת הדרך או מוצר שרץ כבר כמה שנים) - צריכה למצוא מה מתאים ונכון לה.
טרול המתכנן
New member
סיפור מסוג "קנינו גמל צולע => גמל זה לא טוב. תשתמש בחמור".
Not that there's anythong wrong with that
Not that there's anythong wrong with that
מהנסיון המאוד חדש שלי בתחום
use case :
קוד בן 15, יש נכונות לשפר ולשפץ איפה שצריך.
פיצ'ר חדש, ברור כבר שהקוד לא מספיק סקלבילי (הקוד של מוצר הליבה, שעליו אני עובד).
משתדלים לבנות סרביסים (אפשר להתווכח אם השימוש במילה "מיקרו" הוא נכון) עבור הפיצ'רים החדשים.
במקרה זה, ישות שאמורה לשרת את מוצר הליבה בכמה פיצ'רים ישנים וחדשים, וגם מוצרי לוויין אחרים שנמכרים ללקוחות.
עובדים agile . יש כבר זוג שעשה איזו גרסת spike לגואי.
אני העדפתי הפעם לקחת את עבודת התשתית וה dev ops נקרא לזה כך.
יצרנו פרוייקט חדש לסרביס ב git repo a של החברה.
משתמשים ב gradle, spring boot , pgsql, angular.js + bootstrap
משתמשים ב vagrant כדי להרים את הטופולוגיה הרצויה ומשם הסקריפט של הגריידל מריץ עוד כמה דברים דרך ansible כשאנחנו עושים deploy (למשל מתקין את ה RPM הרלוונטי במכונות היעד וכו').
יש מכונה לדטה בייס, מכונה ל load balancer שתי מכונות של הסרביס עצמו.
אם נרצה נוכל בקלות להוסיף עוד מכונות, הן לדטה בייס (נצטרך לעשות רפליקציה כנראה )והן ל"שרתי האפליקציה".
"שמות המכונות" (קרי , כפי שמוגדר ב dns
זה תוצר של קונבנציה שתלויה באיזור הגיאוגרפי בו מותקנת המערכת, וככה אנחנו לא צריכים איזה שירות דיסקאברי או שקר כלשהו שכזה.
ראית את הספר של או'ריילי על מיקרו סרביסים? שמעתי את כותב הספר בהרצאה.
use case :
קוד בן 15, יש נכונות לשפר ולשפץ איפה שצריך.
פיצ'ר חדש, ברור כבר שהקוד לא מספיק סקלבילי (הקוד של מוצר הליבה, שעליו אני עובד).
משתדלים לבנות סרביסים (אפשר להתווכח אם השימוש במילה "מיקרו" הוא נכון) עבור הפיצ'רים החדשים.
במקרה זה, ישות שאמורה לשרת את מוצר הליבה בכמה פיצ'רים ישנים וחדשים, וגם מוצרי לוויין אחרים שנמכרים ללקוחות.
עובדים agile . יש כבר זוג שעשה איזו גרסת spike לגואי.
אני העדפתי הפעם לקחת את עבודת התשתית וה dev ops נקרא לזה כך.
יצרנו פרוייקט חדש לסרביס ב git repo a של החברה.
משתמשים ב gradle, spring boot , pgsql, angular.js + bootstrap
משתמשים ב vagrant כדי להרים את הטופולוגיה הרצויה ומשם הסקריפט של הגריידל מריץ עוד כמה דברים דרך ansible כשאנחנו עושים deploy (למשל מתקין את ה RPM הרלוונטי במכונות היעד וכו').
יש מכונה לדטה בייס, מכונה ל load balancer שתי מכונות של הסרביס עצמו.
אם נרצה נוכל בקלות להוסיף עוד מכונות, הן לדטה בייס (נצטרך לעשות רפליקציה כנראה )והן ל"שרתי האפליקציה".
"שמות המכונות" (קרי , כפי שמוגדר ב dns
זה תוצר של קונבנציה שתלויה באיזור הגיאוגרפי בו מותקנת המערכת, וככה אנחנו לא צריכים איזה שירות דיסקאברי או שקר כלשהו שכזה.
ראית את הספר של או'ריילי על מיקרו סרביסים? שמעתי את כותב הספר בהרצאה.
מסתבר שהזמנתי אותו לפני חצי שנה...
זה היה לאחר ההרצאה אצלנו על storm ונראה היה כאילו יש סיכוי לעשות כזה דבר (במיוחד כשהצוותים השכנים כבר נכנסו לזה...) אבל כשדחו (שוב) את הקטע של להכניס DB במקום קובץ xml שלנו שיכול להגיע ל5MB, אבל מצד שני פיתחו אפשרות לשנות אותו באופן מקבילי, די זנחתי את הרעיון.
כאילו מה הטעם... יש המון מקומות אצלנו לשיפורים טכנולוגיים (הכנסת spring אפילו, כיום יש משהו מאוד מאוד דומה אבל על פיתוח עצמאי)
 
שמעתי על חצי מהדברים שדיברת עליהם , gradel, ,angular ..אבל כל אחד מהם עומד לבדו, אין משהו שמייחד אותם לMicroservices.
זה היה לאחר ההרצאה אצלנו על storm ונראה היה כאילו יש סיכוי לעשות כזה דבר (במיוחד כשהצוותים השכנים כבר נכנסו לזה...) אבל כשדחו (שוב) את הקטע של להכניס DB במקום קובץ xml שלנו שיכול להגיע ל5MB, אבל מצד שני פיתחו אפשרות לשנות אותו באופן מקבילי, די זנחתי את הרעיון.
כאילו מה הטעם... יש המון מקומות אצלנו לשיפורים טכנולוגיים (הכנסת spring אפילו, כיום יש משהו מאוד מאוד דומה אבל על פיתוח עצמאי) 
שמעתי על חצי מהדברים שדיברת עליהם , gradel, ,angular ..אבל כל אחד מהם עומד לבדו, אין משהו שמייחד אותם לMicroservices.
ומה זה rest או ajax עם כל הכבוד?
הרי כל הטכנולוגיות של rest זה שום דבר מעניין ומיוחד.
אל תגיד לי שאתה מתלהב מהאנוטציות של ספרינג בנושא.
אני אתן לך טיפ - אני רואה את את ההודעות שלך , ולפעמים אתה חושב יותר מדי כמתכנת, וזו הבעיה שלך, מיקרו סרביסים זה ארכיקטורה, וזו הסיבה שאתה רואה הרבה חומר של חצים ודיאגרמות כפי שכתבת.
המימושים עצמם? כפי שהטרול (לא אני, השני) כתב לך - היום הרבה יותר קל לבנות מיקרו סרביסים מבעבר. אתה צריך ללמוד את הטכנולוגיות ככלי לארכיקטורה, ואם אתה תשתמש בתשתית ה pub/sub של אמאזון או בקפקא או ב rabbit mq ואולי ברדיס או לא יודע מה -
זה בהחלט up to you
הרי כל הטכנולוגיות של rest זה שום דבר מעניין ומיוחד.
אל תגיד לי שאתה מתלהב מהאנוטציות של ספרינג בנושא.
אני אתן לך טיפ - אני רואה את את ההודעות שלך , ולפעמים אתה חושב יותר מדי כמתכנת, וזו הבעיה שלך, מיקרו סרביסים זה ארכיקטורה, וזו הסיבה שאתה רואה הרבה חומר של חצים ודיאגרמות כפי שכתבת.
המימושים עצמם? כפי שהטרול (לא אני, השני) כתב לך - היום הרבה יותר קל לבנות מיקרו סרביסים מבעבר. אתה צריך ללמוד את הטכנולוגיות ככלי לארכיקטורה, ואם אתה תשתמש בתשתית ה pub/sub של אמאזון או בקפקא או ב rabbit mq ואולי ברדיס או לא יודע מה -
זה בהחלט up to you
טוב, תמיד אמרו לי להפסיק לקמפל דברים בראש כשמדברים אלי
לא ידעתי שיש לspring אנוטציות.. לנו יש פרוייקט שאחד המודולים שלו יש 2 קבצי xml שאחד מהם מכיל מספר נומרי ושם class שהוא בעצם יורש מAbstract class שמקבל custom xml, מבצע פעולה מחזיר custom xml , וכל הclasses האלה נקראים בreflection לפי מספר הקוד שנשלח בxml, (שאגב אמור להיות לפי schema). הxml השני, הוא בעצם רשימת מאפיינים כגון האם או אמור לרוץ בצורה אסיכרונית, האם הוא אמור לעבור להרשם ללוג, ומה ההרשאות שלו.
 
נשמע מוכר? , לא אין לנו spring.
 
השאלה התחתונה היא באמת המימושים , כשאתה אומר לי על קפקא, ו rabiit mq, זה כמו לדעת רטרואקטיבית את המספרים הזוכים בלוטו, מישהו השתמש וידע שצריך להשתמש בהם לצורך microservices, בדרך כלל שכמשתמשים בארכיטקטורה מסויימת למשהו ישנו סחף לעבר קבוצת כלים ש"בדרך כלל" משתמשים בה...
לא ידעתי שיש לspring אנוטציות.. לנו יש פרוייקט שאחד המודולים שלו יש 2 קבצי xml שאחד מהם מכיל מספר נומרי ושם class שהוא בעצם יורש מAbstract class שמקבל custom xml, מבצע פעולה מחזיר custom xml , וכל הclasses האלה נקראים בreflection לפי מספר הקוד שנשלח בxml, (שאגב אמור להיות לפי schema). הxml השני, הוא בעצם רשימת מאפיינים כגון האם או אמור לרוץ בצורה אסיכרונית, האם הוא אמור לעבור להרשם ללוג, ומה ההרשאות שלו.
 
נשמע מוכר?
, לא אין לנו spring. 
השאלה התחתונה היא באמת המימושים , כשאתה אומר לי על קפקא, ו rabiit mq, זה כמו לדעת רטרואקטיבית את המספרים הזוכים בלוטו, מישהו השתמש וידע שצריך להשתמש בהם לצורך microservices, בדרך כלל שכמשתמשים בארכיטקטורה מסויימת למשהו ישנו סחף לעבר קבוצת כלים ש"בדרך כלל" משתמשים בה...
שוב אתה טועה, זו לא השורה התחתונה כמו שהיא לא השורה התחתונה
לא ב ajax ולא ב rest .
כפי שכתבתי לך - אני לקחתי את המשימות של הקמת התשתית ולא הקידוד.
מה, לא יכולתי לכתוב סקריפטים ב bash שירוצו ויפנו ל qemu ישר?
לא יכולתי להשתמש ב chef/puppet ?
הלכנו על vagrant ועל ansible .
eveik נתן לך תשובה מצויינת, גם אנחנו מבינים אצלנו שאנחנו חייבים לעשות templating של יצירת סרביס חדש.
אני גם בטוח שיש כלים כאלה, אם לא , יאללה אולי כמה מחכמי הפורום צריכים לעשות כלי כזה, ולעשות אקזיט של מאות מליונים.
לא ב ajax ולא ב rest .
כפי שכתבתי לך - אני לקחתי את המשימות של הקמת התשתית ולא הקידוד.
מה, לא יכולתי לכתוב סקריפטים ב bash שירוצו ויפנו ל qemu ישר?
לא יכולתי להשתמש ב chef/puppet ?
הלכנו על vagrant ועל ansible .
eveik נתן לך תשובה מצויינת, גם אנחנו מבינים אצלנו שאנחנו חייבים לעשות templating של יצירת סרביס חדש.
אני גם בטוח שיש כלים כאלה, אם לא , יאללה אולי כמה מחכמי הפורום צריכים לעשות כלי כזה, ולעשות אקזיט של מאות מליונים.
מהדורת הpreview החינמית של הספר שהזכרתי
https://www.nginx.com/wp-content/uploads/2015/01/Building_Microservices_Nginx.pdf
ואגב, יצא לי להיות בהרצאה של מי שכתב את הספר בכנס מפתחים במלבורן, אבל מה - רק אחרי ההרצאה נודע לי שהוא כתב את הספר
https://www.nginx.com/wp-content/uploads/2015/01/Building_Microservices_Nginx.pdf
ואגב, יצא לי להיות בהרצאה של מי שכתב את הספר בכנס מפתחים במלבורן, אבל מה - רק אחרי ההרצאה נודע לי שהוא כתב את הספר
אני מתייחס לזה אחרת
כן, זה באז-וורד, אבל זה גם כלי עיצובי שיש לו ערך וכדאי להשתמש בו כשצריך. לדוגמא, הכריחו אותנו לדחוף לסרבר שאנחנו מפתחים כל מני פונקצונליות שלא קשורות לתפקיד המקורי שלו מכל מני סיבות לא טכניות. עכשיו, כשכולם מדברים "מיקרו סרביסים" - אפשר להעיף את כל הזבל.
חוץ מזה, דיון שלם על MS ואף אחד עוד לא הזכיר Docker? נו, באמת!
כן, זה באז-וורד, אבל זה גם כלי עיצובי שיש לו ערך וכדאי להשתמש בו כשצריך. לדוגמא, הכריחו אותנו לדחוף לסרבר שאנחנו מפתחים כל מני פונקצונליות שלא קשורות לתפקיד המקורי שלו מכל מני סיבות לא טכניות. עכשיו, כשכולם מדברים "מיקרו סרביסים" - אפשר להעיף את כל הזבל.
חוץ מזה, דיון שלם על MS ואף אחד עוד לא הזכיר Docker? נו, באמת!
docker הוא סיפור אחר, שעד היום אני בכלל לא סגור עליו...
מישהו העביר עליו הרצאה במשך שעתיים שאעני לא בטוח שמישהו הבין משהו משם.. החברה שלנו מבססת את גרסת המוצר שלנו שעובדת על Linux על ova.. שזה אגב לאחרונה גרם ברוך לא קטן. כיוון שאנו משתמשים בvmware studio ליצור appliance של ubuntu שמריץ את האפליקציה שלנו והדרעק הקטן הזה כבר לא נתמך שנתיים, לאחרונה הייתי חייב לעבור לexplorer כי הchrome גרם בעיות הזויות בממשק משתמש שלו (מבוסס GWT).
מישהו העביר עליו הרצאה במשך שעתיים שאעני לא בטוח שמישהו הבין משהו משם.. החברה שלנו מבססת את גרסת המוצר שלנו שעובדת על Linux על ova.. שזה אגב לאחרונה גרם ברוך לא קטן. כיוון שאנו משתמשים בvmware studio ליצור appliance של ubuntu שמריץ את האפליקציה שלנו והדרעק הקטן הזה כבר לא נתמך שנתיים, לאחרונה הייתי חייב לעבור לexplorer כי הchrome גרם בעיות הזויות בממשק משתמש שלו (מבוסס GWT).
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.