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

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

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

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

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

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

  • תקורה תפעולית נמוכה יותר על-ידי אי ניהול תשתית

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

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

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

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

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

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

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

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

היתרונות של "חסרי שירות תחילה"

Serverless הוא מונחה אירועים מטבעו.

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

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

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

פריקה של העבודה

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

עומסי עבודה אדריכליים היטב

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

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

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

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

התוצאה

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

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

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

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

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

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

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

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