הייתה לנו בעיה מעניינת לפני כמה שנים. אנחנו חברה מרחוק לחלוטין, שכל התוכנות שלנו נמצאות בענן. והייתה לנו חבילה של יישומי Spring Boot שרצו על מכולות עם Infrastructure as Code. אבל היינו צריכים גמישות עסקית.

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

אנחנו חברת טכנולוגיה עם אסטרטגיה נועזת

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

בואו נסביר קודם כמה מונחים

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

  • הפחתת תקורות תפעוליות על ידי אי ניהול תשתיות

  • קנה מידה לפי הצורך, כולל קנה מידה לאפס כדי להפוך אותם לגמישים לחלוטין

  • תמחור גמיש (אתם משלמים רק על מה שאתם משתמשים בו) 

ב-G-P, "שרת-ללא-שרת" מתייחס לשימוש שלנו ב-AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, ממשק תכנות יישומים Gateway, S3, DynamoDB ואחרים.

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

"מכולות לפי הצורך" מבהיר ש-serverless-first לא אומר serverless בלבד. ישנם מקרים בהם אנו זקוקים לקונטיינרים (למשל, התקנת תוכנת COTS) - וזה בסדר.

אסטרטגיית טכנולוגיה שמעניקה עדיפות ללקוחות

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

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

יתרונות של "ללא שרת קודם"

שרתים ללא שרתים מונעים על ידי אירועים מטבעם.

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

אילוצי הפעלת אמצעים

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

הפחיתו את העבודה

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

עומסי עבודה מתוכננים היטב

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

אודות הצוותים שלנו

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

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

התוצאה

עשינו התקדמות יוצאת דופן בשנתיים. ישנם יתרונות רבים למודרניזציה (ראו את המאמר שלנו בנושא AWS / הערך העסקי הידוע של מודרניזציה בענן). באופן ספציפי, צפינו בדברים הבאים:

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

2. תאימות: אנו משתמשים ב-AWS Well-Architected Framework כדי לסקור את כל עומסי העבודה. מכיוון שאנו משתמשים בשירותים מנוהלים רבים של AWS, אנו יכולים לסמוך על המצוינות התפעולית שלהם ולהתחיל ממקום של איכות גבוהה.

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

4. חדשנות: ללא שרתים פירושו שהכל הוא ממשק תכנות יישומים. אילוץ כפוי זה דורש גישת ממשק תכנות יישומים-תחילה. כשאנחנו חושבים על עצמנו כפלטפורמה, אנחנו יכולים להגיע לרמה חדשה של חדשנות על ידי חיבור קל של מערכות באמצעות ממשקי API, כמו חיבור G-P Gia™ לבסיס ידע חדש.

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

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

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