הייתה לנו בעיה מעניינת לפני כמה שנים. אנחנו חברה מרחוק לחלוטין, שכל התוכנות שלנו נמצאות בענן. והייתה לנו חבילה של יישומי 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 (הסכם רמת השירות) שלנו, אלא גם יעבור אותו. זה מעצים את צוותי ההנדסה שלנו ככל שאנו ממשיכים להתפתח עם סביבות ענן.
אודות הצוותים שלנו
האסטרטגיה הטכנולוגית שלנו שאפתנית, וזה הופך אותה למאתגרת. מהנדסים רבים לא עבדו בארכיטקטורה ללא שרתים (או ארכיטקטורה מבוזרת). המעבר לארכיטקטורה ללא שרתים אינו קל, ואנחנו מחפשים מהנדסים שמרגישים בנוח עם למידה, חשיבה בגדול והתקדמות בקצב מהיר.
חלק מהמהנדסים אינם בטוחים לגבי המונח "ללא שרת" (כן, אנחנו יודעים שיש שרתים) מכיוון שהגישה היא יותר מכתיבת קוד בפונקציות. האסטרטגיה שלנו דורשת גישה הוליסטית לעקרונות הקלאסיים של ענן.
התוצאה
עשינו התקדמות יוצאת דופן בשנתיים. ישנם יתרונות רבים למודרניזציה (ראו את המאמר שלנו על תוספת שכר שנתית / הערך העסקי הידוע של מודרניזציה בענן). באופן ספציפי, צפינו בדברים הבאים:
1. מהירות: האופן שבו פירקנו את המערכת שלנו מאפשר לצוותים ולמוצרים לחדש ולהתפתח באופן עצמאי. יש לכך השפעה עצומה על הזריזות העסקית.
2. ציות: אנו משתמשים בתוספת שכר שנתית Well-Architected Framework כדי לבחון את כל עומסי העבודה. מכיוון שאנו משתמשים בהרבה תוספת שכר שנתית Managed Services, אנו יכולים לסמוך על מצוינות התפעולית שלהם ולהתחיל ממקום של איכות גבוהה.
3. חשיבה מערכתית: היינו צריכים לתקנן רבים מהתהליכים שלנו כדי שנוכל להסיק מסקנות לגבי המערכת, האמינות והערך העסקי. אנחנו לא משקיעים זמן בעבודה על רכיבים בעלי ערך נמוך.
4. חדשנות: ללא שרת אומר שהכל הוא ממשק תכנות יישומים. מגבלה כפויה זו דורשת גישה של ממשק תכנות יישומים. כשאנחנו חושבים על עצמנו כפלטפורמה, אנחנו יכולים להגיע לרמה חדשה של חדשנות על ידי חיבור קל למערכות דרך APIs, כמו חיבור G-P Gia™ למאגר ידע חדש.
5. בעלות: תוספת שכר שנתית היא הבעלים של התשתית שלנו, אבל אנחנו הבעלים של תחום העסק שלנו. "ללא שרת קודם כל" עם עיצוב מונחה דומיין אילץ אותנו להתמקד בבעיה העסקית. זה שומר על הבעלות על היכולת ברורה.
שירות ללא שרתים (Serverless-first) לא תמיד מהיר יותר, אבל הוא מועיל יותר. אנחנו מעדיפים לבצע אופטימיזציה למהירות המערכת מאשר למהירות של מפתחים בודדים. "ללא שרת קודם" עוסק פחות בשימוש בפונקציות ויותר בחשיבה, "קוד הוא נטל." המערכת היא הנכס." ככל שנצטרך לכתוב פחות קוד, כך נוכל לשקול ולעצב יותר את מערכת העסקים שאנו בונים.
ככל שנשתף את הסיפור שלנו, יתברר המהירות בה אנו עובדים, שהיא תוצאה ישירה של "ללא שרתים" תחילה. הישארו מעודכנים.
