Yonatan

Reducing risks by taking risks

You have a hypothesis you wish to prove or refute regarding your behavior in an extreme scenario.  For example:  after restarting the DB, all services are fully functioning within X seconds. There are at least 3 approaches:

  1. Wait && See — if you wait long enough this scenario will probably happen by itself in production.
  2. Deep Learning  — put the DBA, OPS and service owner in a big room, and ask them to analyze what will happen to the services after restarting the DB. They will need to go over network configuration, analyze the connection pool and DB settings, and so on.
  3. Just Do It — deliberately create this scenario within a controlled environment:

Timing — Bases on your knowledge pick the right quarter, month, week, day and hour – so the impact on the business will be minimal.

Monitoring — make sure you have all monitoring and alerts in place. If needed, do “manual monitoring”.

Scale — If applicable do it only on portion of your production: one data center, part of the service, your own laptop, etc.

The Wait && See approach will give you the right answer, but at the wrong time. Knowing how your system behaves only after a catastrophe occurs is missing the point and could be expensive, recovery-wise.

The Deep Learning approach seems to be the safer one, but it requires a lot of effort and resources. The answer will not be accurate as it is not an easy task to analyze and predict the behaviour of a complex system. So, in practice, you haven’t resolved your initial hypothesis.

The Just Do It approach is super effective – you will get an accurate answer in a very short time, and you’re able to manage the cost of recovery. That why we picked this strategy in order to resolve the hypothesis. A few tips if you’re going down this path:

  • Internal and External Communication — because you set the date, you can send a heads up to all stakeholder and customers. We use statuspage.io for that.
  • Collaboration — set a HipChat / Slack / Hangouts room so all relevant people will be on the same page. Post when the experiment starts, finishes, and ask service owners to update their status.
  • Document the process and publish the results within your knowledge management system (wiki / whatever).
  • This approach is applicable for organisation that practice proactive risk management, have a healthy culture of learning from mistakes, and maintain a blameless atmosphere.

 

People that pick Deep Learning are often doing so because it is considered a “safer”, more  conservative approach, but that is only an illusion. There is high probability that in a real life DB restart event the system would behave differently from your analysis. This effect of surprise and its outcomes are exactly what we wanted to solve by predicting the system’s behaviour.

 

The Just Do It approach actually reduces this risk and enables you to keep it manageable. It’s a good example of when the bold approach is safer than the conservative one. So don’t hesitate to take risks in order to reduce risk, and Just Do It

Photo credit: http://www.jinxiboo.com/blog/tag/risks

כל מה שרצית לדעת על ארכיטקטורת מיקרו-אפליקציות (Micro-Apps Architecture) – ולא העזת לשאול

 פוסט זה נכתב במקור כפוסט אורח בבלוג המצויין “Software Archiblog — בלוג ארכיטקטורת תוכנה” של ליאור בר-און. 

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

כולם ימכרו לכם שלארכיטקטורה הזו יש יתרונות כמו:

* בסיס קוד קטן, פשוט וקריא. כל service מבצע מספר קטן של משימות, ויש לו אחריות מאוד מוגדרת.

* ממשק וגבולות ברורים לכל service, ולכן יש גם בעלות ברורה שעוזרת לשיפור האיכות.

* כל service נכתב בטכנולוגיה שמתאימה לו ולצוות שאחראי עליו.

* ה service עולה יורד באופן מהיר יותר, ולכן מתאים מאוד לפריסה מתמשכת (Continuous Deployment).

* משפר את יציבות מערכת – אם service אחד נפל, service-ים אחרים ממשיכים לתפקד. אם service אחד עמוס אפשר בקלות להתקין שרתים נוספים שיריצו את אותו השירות.

ה tutorials שתמצאו, כנראה ידברו על שירותי רשת (web services) – ללא UI ובעיקר ללא ניהול session. אבל מה עם אפליקציות רשת (web applications), שם ה UI, וניהול ה session של המשתמש הם החלקים המרכזים ? האם גם אותם ניתן לפצל ל ״מיקרו-אפליקציות״ ? נניח שלקחת אפליקציה אחת ובדרך קסם פיצלת אותה לשניים, איך תתמודד עם:

* שמירה על חווית כניסה (login) אחת?

* מעבר חלק, ושיתוף session בין האפליקציות?

* מניעת שכפול קוד ?

בוא ניקח לדוגמה אפליקציית רשת נפוצה: אתר של חברת סטארטאפ.

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

האתר לרוב יהיה מהמערכות הוותיקות בחברה – ולכן גם עם חוב טכנולוגי גבוה / Technology Stack ישן.

לכאורה מועמד מצוין לשדרוג ולמעבר לארכיטקטורת מיקרו services, אבל אליה וקוץ בה: דווקא אפליקציית רשת קשה מאוד לפצל ויש מעט מאוד מידע ברשת כיצד לעשות זאת.

פוסט זה יתאר ארכיטקטורת מיקרו-אפליקציות (Micro-Apps Architecture) שמטרתה (בדומה ל Micro-Services Architecture) לסייע בפיצול אפליקציית רשת למיקרו אפליקציות ובכך ליהנות מהיתרונות המדוברים.

אז איך עושים את זה ?

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

כל אזור (אדום, צהוב או כתום) הוא מועמד להיות מיקרו אפליקציה עצמאית.

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

כשבאים לקבוע את הגבולות בין האפליקציות ניתן להשתמש באותם שיקולים בהם משתמשים בחלוקת service , למיקרו .services.

המיקרו אפליקציה בנויה מטכנולוגיה המתאימה לה ולצוות שלה ומותקנת על שרת ייעודי. האפליקציה יכולה להגיש גם את צד הלקוח (client side) וגם את צד השרת (server side). האפליקציה מותקנת בתוך ה firewall ולא מקבלת תעבורת רשת באופן ישיר.

micro-colored.png

נייצר service מארח (hosting service)  דרכו עוברת כל התעבורה למיקרו אפליקציות. ברוב המקרים ניתן להשתמש באפליקציה המקורית (המונוליטית) כ service מארח, כיון שאחרי שהוצאנו מתוכה את רוב הפונקציונליות כנראה שנותר שם רק התשתית של ניהול הsession, אימות המשתמש, אבטחה וכו’.

ה service המארח משמש כמעין נתב. ״נתב על סטרואידים״, אם תרצו.

למה נתב? כי ה service המארח רק מקבל את הבקשה דרך התשתיות הבסיסיות ומשמש כצינור בכדי להעביר את הבקשה למיקרו אפליקציה הרלוונטית.

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

מה עושה הפרוקסי?

* הפרוקסי הוא יחידה לוגית בתוך ה service המארח. תפקידו להוות צינור ולהעביר בקשות מהלקוח למיקרו אפליקציה עליה הוא אחראי. התקשורת בין הפרוקסי למיקרו אפליקציה באמצעות פרוטוקול HTTP. לכל מיקרו אפליקציה קיים פרוקסי משרת אותה.

* כל פרוקסי נרשם על מסלול אחר של ה URL. לדוגמה כל בקשה למשאב תחת הכתובת www.yoursite.com/app1 תופנה לפרוקסי האדום.

* כשהבקשה מגיעה לפרוקסי כבר ידוע מיהו המשתמש, ולכן הוא יכול להעביר את שם המשתמש (או כל מידע אחר עליו) למיקרו אפליקציה באמצעות HTTP Header.

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

* הפרוקסי מקבל בחזרה את התשובה מהמיקרו אפליקציה ומעביר אותה חזרה למשתמש.

יתרונות – או מה יצא לנו מכל זה?

* הפרדה ברורה בין אפליקציות: זליגת זכרון במיקרו אפליקציה אחת לא תביא לנפילה של מיקרו אפליקציה אחרת.

* ה service המארח הופך מהר מאוד לתשתית שבה אין הרבה פיצ’רים חדשים. הוא הופך לפשוט וקל יותר לתחזוקה.

* כל מיקרו service נכתב בטכנולוגיה שמתאימה לדרישותיו ולצוות שמפתח אותו.

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

* לייצר מיקרו אפליקציה שתגיש רק את קוד הלקוח שנכתב בטכנולוגיה חדשה, נניח ב AngualrJS, ולהשאיר את קוד השרת ב service המארח.

* לייצר מיקרו אפליקציה חדש שיגיש קוד שרת בלבד. ניתן להחליט שלא מעבירים קוד ישן אלא רק קוד חדש של פיצ’רים חדשים. וכך לבצע החלפה אטית אך שיטתית ומדורגת מתשתית שרת ישנה לתשתית שרת מודרנית יותר.

* ניטור — כל פרוקסי מדווח על כמות הכישלונות, הצלחות, מספר החיבורים התפוסים וכו’.

* רישום בקבצים – ה service המארח אחראי על כתיבת קבצי הגישה access log עבור כל המיקרו אפליקציות.

* אבטחה — ה service המארח מבצע את כל מנגנוני האימות של כניסת משתמשים ו CAPTCHA.

* אפליקציות חדשות — נניח שאתה רוצה לפתח אפליקציית-רשת חדשה. תוכל לממש אותה כמיקרו אפליקציה בתוך ה service המארח. כך תחסוך בפיתוח מנגנוני אבטחה, רישום וכניסה, כתיבת קבצי גישה וכו’, כל מה שתדרש זה להוסיף עוד חוק ניתוב service המארח. בנוסף לא תצטרך את עזרת אנשי ה OPS. גישה זו היא מיושרת עם רעיון ה DEVOPS.

כמובן שאין ארוחות חינם. אז מה אנחנו מפסידים?

* עוד תחנה במסלול — טיפול בבקשה של משתמש לוקחת זמן ארוך יותר.

* שיתוף קוד לקוח — כבר לא תוכל לשנות בקלות את ה JS/CSS שמשותפים עבור כל המיקרו אפליקציות. בכדי לשתף קוד לקוח (למשל ניווט בתוך האפליקציה), תצטרך להתייחס אל הקוד כאל ספרית צד שלישי. תוכל להשתמש ב bower בכדי לנהל את הגרסאות ולהעלות את הקוד ל repository. דרך נוספת תהיה להעלות קבצים משותפים ל CDN.

* הגדל הקושי בתחזוקה ובמציאת תקלות – כל תוספת של חלק נע במערכת מקשה על מציאת באגים. עוד קבצי לוג שצריך לבדוק כמשנסים לאתר תקלה. נניח שמשתמש מנסה לגשת למיקרו אפליקציה ומקבל HTTP CODE 403. יהיה עליכם לבדוק האם ה service המארח חסם את הגישה, או אולי האבטחה של המיקרו אפליקציה חסמה את הבקשה.

* הפרוקסים הם פשוטים ולא משוכללים כמו HAProxy.

הניסיון שלנו באאוטברין:

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

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

* התחלנו עם מיקרו אפליקציה אחת, ועכשיו יש לנו 4 מיקרו אפליקציות שמגישות גם צד שרת וגם צד לקוח. הנה דוגמה ל Stack הטכנולוגי של 3 מארבעת מיקרו אפליקציות בתשתית של אאוטברין:

* לכל מיקרו אפליקציה יש מערכת בדיקות עצמאית וההחלטה האם אפשר לעשות Deploy ל production נמצאת בידי הצוות שמפתח את האפליקציה.

* לכל מיקרו אפליקציה יש ניטור משלה וההתראות מגיעות לצוות הרלוונטי.

* הוספנו ניטור ל service המארח בכדי לוודא שכמות החיבורים לכל מיקרו אפליקציה לא עוברת ערך מקסימלי וכמות השגיאות וההצלחות.

* קובץ הגישה ב service המארח חושף את כל הפעילות של המשתמש בכל המיקרו אפליקציות השונות ונותן מבט אחד על פעולות המשתמש.

* הוספת מיקרו אפליקציה נוספת היא מאמץ קטן של מספר שעות פיתוח.

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

איכות מעל הכל

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

העיתוי לא מקרי — סוף השנה האזרחית, האמריקאים נחים (אם לעשות שופיניג במינוס 15° נקרא לנוח), הלקוחות בחופשה, ואנחנו בזמן איכות.

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

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

אז מה היה לנו?

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

* הורדת עלויות — הורדת עלויות של מערכות המחשוב ע”י שיפור היעילות של השירותים. בפעילות זו הצלחנו להוריד בעשרות אחוזים את העלויות של המערכות שמגישות את המלצות של אאוטברין.

* מיזעור הזמן הממוצע לתיקון בעיות ( Mean Time to Repair/MTTR)  — הקטנת הזמן  שלוקח לנו להתגבר על תקלות. בשנה זו שיפרנו את מערכות הניטור וההתראה שלנו בצורה משמעותית, וגם החלפה של מנגנונים שבירים במנגנונים יציבים שיכולים להתמודד עם הגידול של אאוטברין.

* איך לעשות את החיים שלנו (המפתחים) לנוחים יותר — מהנדסים מסתבר הם די עצלנים, במיוחד כשמדובר בביצוע ידני של אותן המשימות שוב ושוב. בשנה זו פיתחנו כלים פנימיים ותשתיות אוטומציה לייעול העבודה שלנו וכך לפנות זמן לדברים חשובים יותר , שיפור המערכת החיסונית שלנו ע”י הגדלת אחוז הכיסוי של הבדיקות האוטומטיות’ “הוצאה לפנסיה מוקדמת” של שירותים שלא בשימוש,  פעילות גיבוש מחוץ למשרד, והקאת’ון של יומיים.

* פריסה מתמשכת (Continuous Deployment) — מעבר משחרור גרסאות  כל מספר שבועות, לפריסה רציפה של קוד (עשרות פעמים ביום) לסביבה המבצעית.

והשנה – השנה זמן האיכות היה בסימן למידה.

מה לומדים ?

היו לנו קורסים מובנים ומקיפים עם מרצים מקצועיים בתחומים מגוונים כמו: AngularJS,  Spark, “מה חדש ב Java 8” ,”איך לכתוב שיפורי ביצועים ל Java“, “הנחיות לבניית חווית משתמש (UX) נכונה

שקט – לומדים !

היו גם לא מעט הרצאות שהועברו על ידי המומחים של אאוטברין כמו: “למד איך להגן על התוכנה, באמצעות Hacking“, “סדנת code retreat“, “עקרונות בתכנות א-סינכרוני“, “HAPproxy – למה ומדוע“, ועוד ועוד.

זה יהיה במבחן ?

 

קינוח

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

גם כאן, כמו בתוכנית ריאליטי טובה, הסוד טמון בפורמט. והפורמט פשוט:

1. מצא נושא שמדליק אותך

2. ארגן צוות מגוון (מי שעובד לבד – עובד קשה)

3. צא לדרך

** אל תאכל ארוחת צהריים גדולה, כדי שישאר מקום לפיצות (בכל הקאת’ון טוב חייבות להיות פיצות)

הזמן היה קצר, העבודה  היתה אינטנסיבית, האווירה מלאת אדרנלין, והחדר — מלא מוצרלה.

צילום אילוסטרציה

הצוותים לקחו את ההקאת’ון ברצינות, והצליחו להרים תוך שלושה ימים, פרויקטים מרשימים ביותר.

בסוף היום השלישי נפגשנו כולנו באולם ההרצאות ולכל צוות ניתנו 5 דקות להציג את הפרויקט שלו.

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

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

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

דוגמאות ? בבקשה:

* אפלקציה לאיתור עובדים באאוטברין על פי המיומניות שלהם כמו שמופיע בפרופיל שלהם ב Linked-In

* אפליקציה עבור רשת חברתית מבוססת מיקום

* איפה הבוס / איפה העובדים – אפליקציה שמאתרת אנשים בתוך הבניין ומציגה על מפת המשרד איפה הם נמצאים

* מכונת זמן

* ניתוח אלגוריתמי של תכנים ברשת של אאוטברין

* מערכת ניטור גלובלית לשירותי ה IT של אאוטברין

* מערכת לניהול DNS

ועוד ועוד

ועכשיו ?

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