Cloud Native Landscape – שימוש בשירותי הענן כמנוע צמיחה עסקי
חלק א'*
לקוחות שעברו לצרוך שירותים בענן מתארים את המעבר כמסע מעצים, בטוח ומקדם, הכולל אימוץ מודלים חדשניים:
- עושר טכנולוגי ומגוון רחב של שירותים שהענן מספק בעלי ערך לארגון.
- שימוש בתשתיות הענן מצמצם באופן משמעותי Time to Market – הארגון מקבל בענן שירותים מוכנים, ללא צורך לבנות ולהקים כאלו בארגון.
- מודל הצריכה Self Service מאפשר לספק ללקוחות הארגון תשתיות בצורה גמישה, לפי דרישה, ולאפשר לצרוך אותן עצמאית. הארגון מתחיל לשלם רק על המשאבים והשירותים שבהם הוא עושה שימוש, ולפי צריכה בפועלה.
- שימוש בתשתית הענן מאפשר לארגון לאמץ מודלים עסקיים חדשים, המהווים מרכיב מרכזי, כחלק מהטרנספורמציה הדיגיטלית של הארגון.
כך סיפר עידן גרינשפון בפתיחת דבריו, בוועידת יערות הכרמל של חברת בינת תקשורת מחשבים.
גרינשפון הוא סמנכ"ל לשירותי ענן ומנהל את פעילות החטיבה העסקית CloudHome, המספקת לחברות וארגונים שירותי ITaaS במגוון רחב של תחומים על גבי פלטפורמות ענניות, כפי שהוא מתאר.
לפי דו"חות STKI לשנת 2021, שהתפרסמו לאחרונה, חברת בינת היא ספקית שירותי הענן והשירותים המנוהלים על גבי פלטפורמות ענניות המובילה בישראל, תחת מותג CloudHome, מיד אחרי ספקיות הענן הגלובליות מיקרוסופט, אמזון, גוגל ואורקל.
ליהנות מהיתרונות של כל אחת מהפלטפורמות הענניות
גרינשפון סיפר שעם הניסיון שהצטבר בשנים האחרונות בקרב מאות הלקוחות, להם בינת מספקת שירותי ענן ומלווה במסע הטרנספורמציה הדיגיטלית, קיימת הבנה שחשוב מאוד להתייחס לעובדה שהלקוחות פוגשים מולם עולם היברידי, מורכב ומבוזר הכולל עננים פרטיים, עננים ציבוריים, שירותי SaaS, אפליקציות מודרניות לצד יישומים ישנים, אתגרי סייבר משמעותיים ועוד.
הוא המשיך ותיאר שהעולם ההיברידי, מרובה העננים, מספק היצע רחב של פלטפורמות ענניות, והדבר מאפשר ליהנות מהיתרונות של כל אחת מהפלטפורמות, או משילוב יכולות של מספר עננים. יחד עם זאת, המגוון והעושר יוצרים מציאות מורכבת. הארגון חייב לשאול את עצמו מספר שאלות:
- איך למנהל את המשאבים במספר עננים בצורה מרכזית?
- איך הלקוחות של תשתית הענן יכולים לבוא ולצרוך שירותים ולפרוס אפליקציות בצורה גמישה בענן כזה או אחר, ומחר להעביר את השירות מענן לענן?
- איך מנגישים במקום אחוד היצע רחב של שירותים ממספר עננים?
- איך מנהלים תהליכי governess ואיך עושים ניהול עלויות וגבייה, כשהתשתית פרוסות על גבי מספר עננים?
מאתגר.
מחקרים שהציג מדגימים מגמה לפיה מרבית הארגונים ימצאו את עצמם בעולם של סביבת IT היברידית, מרובת עננים. מעל 90 אחוז יעשו שימוש ביותר מענן אחד. ומעל 70 אחוז יעשו שימוש בתהליכים הפרוסים על גבי מספר עננים – המשלבים ענן פרטי של הארגון, ואחד או יותר מעננים ציבוריים, על מנת לשרת תהליך ארגוני.
להמשיך לעשות את מה שאנחנו עושים בסביבת ה-On Premise במעבר לענן היא טעות ביסודה, טען גרינשפון נחרצות, ואמר שעל מנת לנצל את מלוא הפוטנציאל שבענן נדרש לבנות יישומים בארכיטקטורת Cloud Native, תוך ניצול של כל היתרונות הטכנולוגיים שפלטפורמות הענן מספקות, ואימוץ מתודולוגיות פיתוח מודרניות בסביבת הענן.
ארכיטקטורת ה-Cloud Native מבוססת על תפישה רב-שכבתית, הכוללת רבדים ואספקטים שונים המשתלבים יחד למענה אחד שלם. החל מרובד של תשתיות ענן היברידי, דרך תהליכי האוטומציה, ממשיך עם שכבת הריצה לאפליקציות ועד לניהול תהליכי פיתוח מודרניים. כל אלו עטופים בכלים ותהליכים חוצי שכבות, כמו observability, מעטפת אבט"מ עננית ולתהליכי ניהול השירותים.
לבטל התהליכים הידניים באמצעות יישום גישת IaC
בדבריו ציין שכחלק מפעילות CloudHome הרבה מהלקוחות שהוא פוגש עדיין מנהלים תהליכי IT בצורה ידנית מסורתית, תהליכים מורכבים ומסורבלים יתר על המידה, והתייחס לכך שהדבר מייצר צווארי בקבוק בעת הצורך להתאים את משאבי הסביבה לפי עומסי הפעילות בזמן אמת. הזמן מהדרישה לתשתית ועד ליכולת להנגיש אותה הוא ארוך ואיננו משתלב עם תפישה של אפליקציות מודרניות. הסיכון בטעויות אנוש וחשיפה של הארגון הוא משמעותי, וחוסר היעילות בצריכת והנגשת התשתית, גורמים להוצאות כלכליות מיותרות.
המענה שהציע לאותם תהליכים ידניים הוא יישום גישה הנקראת IaC (ר"ת Infrastructure as Code). במסגרת תהליך זה מתרגמים את שכבות התשתית השונות לשפה, לקוד. הדבר מאפשר לפשט באופן משמעותי צריכה וניהול של תהליכים תשתיתיים ולהפוך אותם לאוטומטיים, כגון צריכת משאבי אחסון, היבטים רשתיים, משאבי מחשוב ועוד, וכל זה במודל Self Service – למשל מפתח שצריך תשתית עבור האפליקציה יכול להרים סביבה תוך דקות בודדות בצורה אוטומטית.
ברובד האפליקטיבי הוא דיבר על מעבר ל-Cloud Native Apps, הסביר שאלו אפליקציות מבוססות Microservices, הרצות בסביבות קונטיינרים. אפליקציות חדשות מפותחות מראש בארכיטקטורת Cloud Native ואפליקציות קיימות שאנו רוצים להעביר לענן דורשות לעבור תהליך מודרניזציה.
גרינשפון הדגיש שכשהארגון מתבסס יותר ויותר על אפליקציות Cloud Native, והן עוזבות את סביבות הפיתוח, הארגון חייב להבין שקיימת חשיבות קריטית לסביבת ריצה מבוססת קונטיינרים ברמת אנטרפרייז גרייד, הכוללת מנגנוני סקלאביליט, שרידות מובנת, היבטי אבט"מ, שימוש בשירותים משלימים כמו שירותי דטה, היכולת לבצע מעבר מנוהל ומדורג מגרסה לגרסה בזמן אמת, ותהליכים נוספים.
על מנת למקסם את הערך שבשימוש בתשתיות הענן נכון ליישם את הגישה platform as a service first, טען גרינשפון בדבריו ואמר שבניגוד לתפישת infrastructure as a service, הדורשת הקמת תשתית מחשוב ייעודית לאפליקציה, תפישת PAAS מאפשרת להשתמש ולהנות ממגוון רחב של שירותים מוכנים המונגשים as a service, כגון שירותי בסיסי נתונים, פלטפורמות WEB APPS, שירותי מחשוב Serverless, סביבות פיתוח מוכנות, ועוד.
ומה קורה כשמדובר בפיתוח? כשמדברים על פיתוח אפליקציות מודרניות, הוא ציין שהדבר המחייב מתודולוגיית עבודה חדשה. הארגונים נדרשים לידע, לכלים ומיומנויות חדשים בארגון, הן בתחום המעבר מפיתוח לייצור, ניהול ה-DATA, ניהול אבט"מ ותחזוקה שוטפת של השירות. כל המיומנויות האלו מלוות בידע, כלים וטכנולוגיות מודרניות, הרבה מהן מבוססות קוד פתוח. בארגוני אנטרפרייז חשוב להשתמש במוצרים מנוהלים ומתוחזקים, המפשטים את המאמץ הנדרש לתמוך במערכות. או לחילופין לצרוך שירותים של גופים מתמחים בתחזוקת מערכות קוד פתוח.
כשנשאל מה קורה בהיבטי ניטור ובקרה, התייחס גרינשפון לכך שבעבר, כשמערכות היו יותר פשוטות ופחות מבוזרות, ידענו שכדי לוודא שהמערכת בריאה וחסונה יש צורך בניטור שוטף. אם סף של ערך ניטור כלשהו נחצה, מערכת הניטור שולחת התראה למסכים בחדר הבקרה ולפעמים גם מתריעה במייל, פותחת קריאה במערכת הקריאות ודואגת שנהיה מודעים לכך שיש בעיה.
אך ביישומים מודרניים זה לא כל כך פשוט. יישומים הבנויים בטכנולוגיות כגון קונטיינרים, Function as a service, מכילים הרבה מאוד חלקים נעים. הרכיבים הללו מופעלים ומכובים לפי הצורך, זזים בין עננים וכוללים ארכיטקטורה מבוזרת. ולכן מערכות לניהול וניטור תשתיות שהיו קיימות בעבר אינן רלוונטיות עוד בעולם המודרני. נדרש לספק כלים שידעו להסתכל לתוך האפליקציה והתהליכים, לספק יכולות למפות אפליקציות בסביבה העננית, לבצע דיאגנוסטיקה של ביצועי השירות בזמן אמת, לספק נתונים אודות חוויית משתמש, להצביע על שורש הבעיה, להתניע תהליכים אוטומטיים, במקרה של זיהוי אנומליות, לשם תיקון הבעיה, ולהחזיק משוב לגופי הפיתוח בזמן אמת.
*חלק ב' יפורסם מחר