PaaS, CaaS או FaaS? איך לבחור

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

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

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

הוצג גם בסדרה זו:

  • מכולות צועדות למיינסטרים ()
  • מיכלים וקוברנטים: 3 סיפורי הצלחה טרנספורמציים (CIO)
  • קוברנטס פוגש את העולם האמיתי ()
  • דברים חיוניים שכדאי לדעת על רשת מיכלים (רשת העולם)
  • כיצד בנו ויזה פיתרון אבטחת מכולות משלה (CSO)
  • מיכלים על שולחן העבודה? אתה מהמר - ב- Windows 10X (Computerworld)

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

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

מכין את המבורגר בענן

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

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

מהנדסים יכולים לבחור באפשרות Container as-a-service (CaaS) וליישם יישומים, שווה ערך לשף שיוצר ומפעיל את הארוחה שלה דרך מעבר. אם אין להם את המומחיות הזו, אפשרויות פלטפורמה כשירות (PaaS) שוות ערך לבחירת ערכה במעבר שני ובעקבות ההוראות והאילוצים לשימוש בה.

לא CaaS ולא PaaS עונים על הצרכים שלך? ובכן, אתה יכול לבנות הכל מהיסוד (תשתית כשירות, או IaaS) או לפרוס פונקציות לסביבות ללא שרתים (לתפקד כשירות, או FaaS).

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

ברור שיש אפשרויות אדריכליות רבות לארח, להגדיר, לנהל ולפרוס קוד לענן. הדברים מסתבכים עוד יותר כאשר בוחנים את היצע המוצרים השונה. אפשרויות PaaS כוללות שירות אפליקציות של Azure, AWS Elastic Beanstalk, מנוע האפליקציות של גוגל, Red Hat OpenShift והרוקו של Salesforce, רק כדי שם כמה. אם אתה בוחן פתרונות CaaS, אז לכל אמזון, גוגל ואמזון יש שירות Kubernetes מנוהל משלהן עם ראשי תיבות משלהם (EKS, GKE ו- AKS, בהתאמה). בנוסף, ישנן אפשרויות אחרות כמו VMware, IBM, Oracle, Rackspace ואחרות.

כמובן, יש עוד אפשרויות ללא שרת. ל- Azure Serverless יש פונקציות ללא שרתים, תרמילי Kubernetes וסביבות יישומים. ל- AWS יש כיום אפשרויות רחבות יותר ללא שרת ומפרקת את השרת ללא קטגוריות פונקציונליות למחשוב, אחסון, מאגרי נתונים, פרוקסי API ועוד. Google Cloud לוקח את ההגדרה הרחבה ביותר של Serverless וכולל שירותים כגון BigQuery ו- AutoML.

שיקולי מפתח CaaS, PaaS, FaaS ושיקולי שרת

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

  • קהל יעד - אפשרויות PaaS ו- FaaS מכוונות תחילה למפתחים על ידי כך שהפיתרון קל להגדרה ושילוב עם צינורות CI / CD לפריסה. מכולות מפרמטות את סביבת ההפעלה ואת תצורת הפלטפורמה, ולכן כלים אלה מכוונים בדרך כלל למפעילים ומנהלי מערכות.
  • יכולת תצורה לעומת זריזות - באופן כללי CaaS היא האופציה הניתנת להגדרה ביותר, מה שמקנה למפעילים את הגמישות הרבה ביותר לבחור פלטפורמות ותצורות למיכל. אפשרויות PaaS ו- FaaS מתמקדות בזריזות ועוזרות למפתחים לפרוס ולבדוק קוד מהר יותר.
  • כמה פתרונות PaaS הם  דעתניים - פתרונות PaaS ו- Faas ידי עיצוב הם preselecting, כלומר, אתה כבר נעול לתוך אפשרויות הבחירה ותצורת הפלטפורמה שלהם. פתרונות אלה מתוכננים על סמך דעותיו של המעצב על מה שרוצים המפתחים, שיטות עבודה מומלצות ומאפייני ביצועים. עבור מפעילים שמעדיפים יותר גמישות או יותר בקרות, PaaS או FaaS דעתניים עשויים להיות מגבילים מדי. 
  • מיומנויות ועקומת למידה - הכללה הוגנת היא שלפתרונות CaaS יש עקומת למידה תלולה יותר ודורשים יותר מיומנויות מאשר פתרונות PaaS ו- FaaS.
  • נעילת ספק - פתרונות CaaS מפותחים בדרך כלל ב- Kubernetes וניידים באפשרויות אירוח ענן שונות. למרות שניתן לתכנן פתרונות PaaS ו- FaaS עם Kubernetes כבסיס, הם בדרך כלל לא חושפים את שכבת Kubernetes למשתמשי הקצה במקום להציג תצורות פשוטות יותר. תצורות אלה הן קנייניות של פתרון PaaS ו- FaaS, ולעתים קרובות נועדו לפעול על ענן אחד בלבד. חלק ממנהיגי ה- IT מוצאים את זה בעייתיים והם מודאגים בצדק מלהינעל בתוך ספק הענן. 

שאלות להנחיית המחקר והאב טיפוס שלך

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

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

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

  1. האם אתה צוות קטן עם מספר מועט של יישומים? במקרים אלה, עליכם לשקול את האפשרויות הפשוטות יותר של PaaS ואפשרויות ללא שרת בהן תוכלו להשיג את מרבית הפלטפורמה הנדרשת מוגדרת מראש ומבלי להשקיע זמן רב ומומחיות. DJ Navarrete, מנהל ארכיטקטורת פלטפורמות ב- AvidXchange, מציע, "עבור חברות קטנות עד בינוניות שעשויות לדרוש יותר תמיכה בניהול שינויים כדי להצליח, ואלו המעוניינים להגדיל את הבגרות, היציבות והמהירות במהירות, PaaS מושך כי הוא מציע דרך מהירה יותר ליישום ולרווחי יעילות. "
  2. האם יש לך עומסי מטען אפיזודיים, אך עדיין עליך להגדיל בעת הצורך? ההיקף יכול להיות שירות או פונקציית מיקרו אך יכול גם לגדול ליישומים ומאגרי מידע מלאים. מקרי שימוש אלה מתאימים באופן אידיאלי למחשוב ללא שרתים, שם אתה משלם רק עבור השימוש הנדרש.
  3. האם יש לך חובת תאימות או תקן רגולטורי שמאלץ אותך לדווח על אפשרויות או הגדרות בסיסיות ספציפיות במיכל הביצוע, היישום, מסד הנתונים, מערכת ההפעלה או התשתית? וויין אנדרסון, אדריכל האבטחה והתאמה של מרכז המצוינות במקום העבודה המודרני של מיקרוסופט, אומר שזו סיבה קריטית שאפשרויות של אפשרויות שרת אינן נשללות. דרישות תאימות PCI ואחרות מתפרשות בדרך כלל על ידי מחלקות משפטיות או רואי חשבון כמחייבות הוכחה של הגדרות סביבת המחשוב.
  4. האם אתה מנצל פלטפורמות מיוחדות או יישומים מדור קודם? במקרים אלה, יתכן שיהיה קשה למצוא אפשרויות PaaS מסחריות התואמות. יחד עם זאת, פיתוח מכולות עשוי לפשט את ניהול הפריסה והתלות.
  5. האם אתה ארגון או מפעל גדול הפועלים בכמה עננים ועם פלטפורמות יישומים ונתונים שונות בהפקה? ארגונים אלה עשויים לבחור לתקנן על מכולות מכיוון שהוא מספק את הגמישות הרבה ביותר בתמיכה בפלטפורמות מרובות ואפשרויות תצורה. חסר שרת עשוי עדיין להוות שיקול אם ציות אינו גורם. חברות עשויות להתרחק מאפשרויות PaaS אם יש להן מספיק מיומנות ויכולת לפתח את רוחב האפשרויות בקוברנטס. ארגונים עם כישורים בקנה מידה מספיק וכישורים טכניים, כגון Shopify, עשויים לבחור להנדס את ה- PaaS שלהם עם Kubernetes ומכולות כבסיס.
  6. האם אתה מפתח מיקרו-שירותים ומתקן על ארכיטקטורת מיקרו-שירותים מבוססת ענן? מארק הית 'מציע כי מכולות או FaaS הן אפשרויות טובות, כמו גם פונקציות אירוח במכולות. הית 'אומר כי פונקציות ללא שרת עשויות להיות קלות יותר לתצורה ולעלות פחות עלות לתמיכה, בעוד שמכולות עשויות לפשט את הפיתוח המקומי ולספק אפשרויות רבות יותר לאבטחת נקודות קצה. 
  7. יועץ הענן סרבג'ט ג'ואל אוהב לדעת אם אתה בונה פלטפורמות, יישומים או שירותים, והקהל הוא פנימי לארגון, חיצוני או פונה ללקוח או מתכלה. הכרת סוג האפליקציה וסוג משתמשי הקצה מסייעת לך לחזות את הצרכים והדרישות העתידיות. לדוגמה, Johal אומר, "עבור יישומים חיצוניים, אתה רוצה לרשום בקרת גישה הרבה יותר, נפחי הנתונים עשויים להגדיל באופן בלתי צפוי, והיישום עשוי להיות בעל אורך חיים ארוך יותר בהשוואה ליישומים פנימיים. אם שירות או פלטפורמה ניתנים לצריכה במכונה, ייתכן שתזדקק למדידה מסוימת. " חיזוי מפת הדרכים והצרכים העתידיים אמור לעזור לקדם אפשרויות מסוימות ולשלול אחרות.

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