.jpeg)
ארגונים רבים מדברים ומאמצים מעבר של מערכות ארגוניות לסביבת הענן כאסטרטגיה לאימוץ של שירותי ענן במכלול שירותי ה-IT של הארגון.
המעבר מסביבת ה-on premise לסביבת הענן הציבורי, מאפשר לארגונים לבחור מתוך מגוון רחב של חלופות, כל אחת עם היתרונות שלה, רמת ידע שונה ושיטת תמחור שונה (ביחס למודל התמחור המוכר מסביבת ה-on premise).
במאמר זה, נסקור את החלופות הנפוצות, עם היתרונות והחסרונות וננסה להסביר למי מיועדת כל חלופה.
הגירת מערכות בשיטת Lift & Shift
בשיטה זו, הלקוח בוחר מערכת קיימת מסביבת ה-on premise, בוחן אילו משאבים נדרשים לטובת הרצת המערכת (כמות מעבדים/זיכרון ונפח דיסק), גרסת מערכת הפעלה (בהנחה שקיים image מתאים אצל ספק הענן), מוודא מול יצרן התוכנה כי ניתן להריץ את התוכנה בסביבת ענן (סוגיית רישוי) ומבצע התקנה של כלל מרכיבי התוכנה על שרת וירטואלי בסביבת הענן (או מבצע הגירה של השרת בשלמותו, במידה וקיים שירות מנוהל להגירת שרתים לענן).
לכאורה מדובר בשיטה הכי נפוצה והכי פשוטה (באופן יחסי...) למעבר לסביבות ענן וכלל ספקי הענן (Infrastructure as a Service) תומכים בשיטה זו, אך כדאי לקחת בחשבון כי מבחינת עלויות, מדובר בשיטה די יקרה ובזבזנית בהשוואה לרכישת שרתים פיזיים לתקופה של 3-5 שנים בסביבת ה-on premise.
הדרכים הנפוצות להוזיל עלויות שרתים בענן הן:
• התאמת גודל השרת (מבחינת כמות מעבדים/זיכרון) לשימוש בפועל
• רכישת התחייבות לתקופה של שנה או 3 שנים מראש מול ספק הענן (Reserved Instance)
• שימוש במודל Spot עבור שרתים אשר אינם נדרשים להיות זמינים 24x7 או עבור יישומים אשר יכולים לספוג בעיות זמינות, מבלי לפגוע בתפקוד הכולל של השירות
מעבר לשימוש ב-Micro services ו-Containers
בשיטה זו מבוצע מעבר מפיתוח מבוסס monolith (תשתית בה כלל רכיבי המערכת תלויים אחד בשני ונדרשים להיות מותקנים ביחד) לפיתוח מבוסס micro services, בו כל רכיב תוכנה רץ בצורה עצמאית (לרוב בתוך Container עצמאי) וניתן להחלפה, לשדרוג או להגדלת כמות אנכית של רכיבי התוכנה (Scale out) בהתאם לצורך ובצורה בלתי תלויה ביתר רכיבי המערכת.
ניתן להריץ Containers על גבי שרתים וירטואליים (כל נושא הניהול, עדכון ו-scale באחריות הלקוח) או כחלק משירות מנוהל (דוגמת שירותים מנוהלים להרצת Kubernetes clusters).
שיטה זו מחייבת את צוותי הפיתוח לדעת לארוז יישומים בתוך Containers, לטפל בסוגיית הגדילה (scale), לדעת לבצע ניטור על פעילות ה-containers (והתקשורת בין Containers) ולדאוג לסוגיות אבטחה (דוגמת מי יכול לפנות ל-Container, האם התקשורת בין ה-Containers מוצפנת וכו').
שיטה זו מתאימה כאשר הארגון מעוניין לשנות ארכיטקטורה של יישום קיים או לפתח יישום חדש. יישומים מודרניים מפותחים כיום בתצורת containers ומאפשרים ללקוח לבצע הגירה מסביבת ה-on premise לסביבת הענן הציבורי ובהתאם להתאמות, גם בין ספק ענן אחד למשנהו (לאחר שפתרנו את הקישור לשירותים קיימים של ספק הענן דוגמת message queuing, אחסון, logging וכו').
מעבר לשימוש ב-Serverless / Function as a Service
בשיטה זו, הלקוח אינו דואג לנושא תחזוקת מערכת ההפעלה, שרידות התשתית או ה-scale. בשל העובדה שהתשתית מנוהלת ע"י ספק הענן, הספק דואג ל-scale הנדרש מבחינת כוח המחושב בהתאם לצורך.
שיטה זו מתאימה לשירותים מבוססי events, בעלי זמן ריצה קצר (מספר שניות עד מספר דקות). כחלק ממעבר לפיתוח יישומים מודרניים, קיימים לא מעט תרחישים בהם ניתן לפתח פונקציה בשפה מסוימת, לטעון את הפונקציה לתוך סביבה מנוהלת בצד ספק הענן (Serverless), לבחור את כוח המחשוב הרצוי (כמות זיכרון, המשפיעה על כמות המעבדים) ולייצר את ה-triggers להרצת הפונקציה.
ניתן לשלב יכולות Serverless כחלק מפיתוח מודרני מבוסס Micro services.
מודל התמחור של שיטה זו מבוסס על זמן ריצת הפונקציה וכמות הזיכרון הנדרש להרצת הפונקציה.
דוגמאות לשימוש ב-Serverless – עיבוד תמונות, אנליזות של מידע משירותי IoT וכו'.
שיטה זו אינה מתאימה לכל סוג של יישום (זמני ריצה קצרים) וכן, לא כל שפת פיתוח נתמכת ע"י כלל ספקי הענן. לדוגמא:
• AWS Lambda תומכת (נכון לכתיבת מאמר זה) בצורה מובנית בשפות Java, Go, PowerShell, Node.JS, C#, Python, Ruby
• Azure Functions תומכת (נכון לכתיבת מאמר זה) בצורה מובנית בשפות C#, JavaScript, F#, Java, PowerShell, Python, TypeScript
• Google Cloud Functions תומכת (נכון לכתיבת מאמר זה) בצורה מובנית בשפות Python, Node.JS, GO
• Oracle Functions תומכת (נכון לכתיבת מאמר זה) בצורה מובנית בשפות Java, Python, Node.JS, GO, Ruby
מעבר לשימוש בשירותים מנוהלים (SaaS / PaaS)
בשיטה זו, הארגון בוחר שירות SaaS קיים (דוגמת Messaging, CRM, ERP וכו') או שירות PaaS קיים (דוגמת Database, Storage וכו').
שיטה זו מתאימה לתרחישים בהם הארגון מעוניין לצרוך שירות קיים מבלי לתחזק בצורה שוטפת את היבטי התשתית (מערכת הפעלה, אחסון, גיבויים, אבטחת מידע וכו'). לאחר בחירה בשירות קיים, הארגון מבצע הגירת נתונים לשירות המנוהל, מבצע הגדרת הרשאות גישה מתאימות, לעיתים יבצע חיבור VPN בין סביבת ה-on premise לסביבת הענן, יגדיר גיבויים (בהתאם לתמיכת השירות) ויתחיל להשתמש בו בצורה שוטפת.
מודל התמחור משתנה מספק ענן אחד למשנהו (לעיתים מחיר חודשי קבוע ולעיתים התמחור של הספק מבוסס כוח מחשוב ונפחי אחסון).
ככל שספק הענן בוגר ושקוף יותר ללקוח, הוא חושף ללקוח נתוני חיוב מדויקים אודות העלות החודשית כמו כן ספקי ענן בוגרים ידעו להתמודד עם היבטי פרטיות חוק ומשפט (דוגמת עמידה ב-GDPR ותקני פרטיות נפוצים אחרים) באמצעות Data processing agreements.
סיכום
במאמר זה סקרנו בקצרה את השיטות השונות לשימוש מושכל בשירותי ענן. כפי שניתן לראות, לא כל שיטה מתאימה לכל תרחיש או לכל ארגון, אך אין ספק שהעתיד הולך לכיוון שירותי ענן ושירותים מנוהלים.
ההמלצה לארגונים – להתמקד במה שמביא לארגון ערך עסקי (דוגמת בנקאות, תעשייה, מסחר, חינוך ועוד), להכשיר את אנשי התשתיות והפיתוח לשינויים בעולמות הטכנולוגיה ולהעביר את האחריות לתחזוקת התשתיות לספקים המתמחים בנושא.
המאמר נכתב ע"י אייל אסטרין, ארכיטקט ענן במרכז החישובים הבינאוניברסיטאי
ארגונים רבים מדברים ומאמצים מעבר של מערכות ארגוניות לסביבת הענן כאסטרטגיה לאימוץ של שירותי ענן במכלול שירותי ה-IT של הארגון.
המעבר מסביבת ה-on premise לסביבת הענן הציבורי, מאפשר לארגונים לבחור מתוך מגוון רחב של חלופות, כל אחת עם היתרונות שלה, רמת ידע שונה ושיטת תמחור שונה (ביחס למודל התמחור המוכר מסביבת ה-on premise).
במאמר זה, נסקור את החלופות הנפוצות, עם היתרונות והחסרונות וננסה להסביר למי מיועדת כל חלופה.
הגירת מערכות בשיטת Lift & Shift
בשיטה זו, הלקוח בוחר מערכת קיימת מסביבת ה-on premise, בוחן אילו משאבים נדרשים לטובת הרצת המערכת (כמות מעבדים/זיכרון ונפח דיסק), גרסת מערכת הפעלה (בהנחה שקיים image מתאים אצל ספק הענן), מוודא מול יצרן התוכנה כי ניתן להריץ את התוכנה בסביבת ענן (סוגיית רישוי) ומבצע התקנה של כלל מרכיבי התוכנה על שרת וירטואלי בסביבת הענן (או מבצע הגירה של השרת בשלמותו, במידה וקיים שירות מנוהל להגירת שרתים לענן).
לכאורה מדובר בשיטה הכי נפוצה והכי פשוטה (באופן יחסי...) למעבר לסביבות ענן וכלל ספקי הענן (Infrastructure as a Service) תומכים בשיטה זו, אך כדאי לקחת בחשבון כי מבחינת עלויות, מדובר בשיטה די יקרה ובזבזנית בהשוואה לרכישת שרתים פיזיים לתקופה של 3-5 שנים בסביבת ה-on premise.
הדרכים הנפוצות להוזיל עלויות שרתים בענן הן:
• התאמת גודל השרת (מבחינת כמות מעבדים/זיכרון) לשימוש בפועל
• רכישת התחייבות לתקופה של שנה או 3 שנים מראש מול ספק הענן (Reserved Instance)
• שימוש במודל Spot עבור שרתים אשר אינם נדרשים להיות זמינים 24x7 או עבור יישומים אשר יכולים לספוג בעיות זמינות, מבלי לפגוע בתפקוד הכולל של השירות
מעבר לשימוש ב-Micro services ו-Containers
בשיטה זו מבוצע מעבר מפיתוח מבוסס monolith (תשתית בה כלל רכיבי המערכת תלויים אחד בשני ונדרשים להיות מותקנים ביחד) לפיתוח מבוסס micro services, בו כל רכיב תוכנה רץ בצורה עצמאית (לרוב בתוך Container עצמאי) וניתן להחלפה, לשדרוג או להגדלת כמות אנכית של רכיבי התוכנה (Scale out) בהתאם לצורך ובצורה בלתי תלויה ביתר רכיבי המערכת.
ניתן להריץ Containers על גבי שרתים וירטואליים (כל נושא הניהול, עדכון ו-scale באחריות הלקוח) או כחלק משירות מנוהל (דוגמת שירותים מנוהלים להרצת Kubernetes clusters).
שיטה זו מחייבת את צוותי הפיתוח לדעת לארוז יישומים בתוך Containers, לטפל בסוגיית הגדילה (scale), לדעת לבצע ניטור על פעילות ה-containers (והתקשורת בין Containers) ולדאוג לסוגיות אבטחה (דוגמת מי יכול לפנות ל-Container, האם התקשורת בין ה-Containers מוצפנת וכו').
שיטה זו מתאימה כאשר הארגון מעוניין לשנות ארכיטקטורה של יישום קיים או לפתח יישום חדש. יישומים מודרניים מפותחים כיום בתצורת containers ומאפשרים ללקוח לבצע הגירה מסביבת ה-on premise לסביבת הענן הציבורי ובהתאם להתאמות, גם בין ספק ענן אחד למשנהו (לאחר שפתרנו את הקישור לשירותים קיימים של ספק הענן דוגמת message queuing, אחסון, logging וכו').
מעבר לשימוש ב-Serverless / Function as a Service
בשיטה זו, הלקוח אינו דואג לנושא תחזוקת מערכת ההפעלה, שרידות התשתית או ה-scale. בשל העובדה שהתשתית מנוהלת ע"י ספק הענן, הספק דואג ל-scale הנדרש מבחינת כוח המחושב בהתאם לצורך.
שיטה זו מתאימה לשירותים מבוססי events, בעלי זמן ריצה קצר (מספר שניות עד מספר דקות). כחלק ממעבר לפיתוח יישומים מודרניים, קיימים לא מעט תרחישים בהם ניתן לפתח פונקציה בשפה מסוימת, לטעון את הפונקציה לתוך סביבה מנוהלת בצד ספק הענן (Serverless), לבחור את כוח המחשוב הרצוי (כמות זיכרון, המשפיעה על כמות המעבדים) ולייצר את ה-triggers להרצת הפונקציה.
ניתן לשלב יכולות Serverless כחלק מפיתוח מודרני מבוסס Micro services.
מודל התמחור של שיטה זו מבוסס על זמן ריצת הפונקציה וכמות הזיכרון הנדרש להרצת הפונקציה.
דוגמאות לשימוש ב-Serverless – עיבוד תמונות, אנליזות של מידע משירותי IoT וכו'.
שיטה זו אינה מתאימה לכל סוג של יישום (זמני ריצה קצרים) וכן, לא כל שפת פיתוח נתמכת ע"י כלל ספקי הענן. לדוגמא:
• AWS Lambda תומכת (נכון לכתיבת מאמר זה) בצורה מובנית בשפות Java, Go, PowerShell, Node.JS, C#, Python, Ruby
• Azure Functions תומכת (נכון לכתיבת מאמר זה) בצורה מובנית בשפות C#, JavaScript, F#, Java, PowerShell, Python, TypeScript
• Google Cloud Functions תומכת (נכון לכתיבת מאמר זה) בצורה מובנית בשפות Python, Node.JS, GO
• Oracle Functions תומכת (נכון לכתיבת מאמר זה) בצורה מובנית בשפות Java, Python, Node.JS, GO, Ruby
מעבר לשימוש בשירותים מנוהלים (SaaS / PaaS)
בשיטה זו, הארגון בוחר שירות SaaS קיים (דוגמת Messaging, CRM, ERP וכו') או שירות PaaS קיים (דוגמת Database, Storage וכו').
שיטה זו מתאימה לתרחישים בהם הארגון מעוניין לצרוך שירות קיים מבלי לתחזק בצורה שוטפת את היבטי התשתית (מערכת הפעלה, אחסון, גיבויים, אבטחת מידע וכו'). לאחר בחירה בשירות קיים, הארגון מבצע הגירת נתונים לשירות המנוהל, מבצע הגדרת הרשאות גישה מתאימות, לעיתים יבצע חיבור VPN בין סביבת ה-on premise לסביבת הענן, יגדיר גיבויים (בהתאם לתמיכת השירות) ויתחיל להשתמש בו בצורה שוטפת.
מודל התמחור משתנה מספק ענן אחד למשנהו (לעיתים מחיר חודשי קבוע ולעיתים התמחור של הספק מבוסס כוח מחשוב ונפחי אחסון).
ככל שספק הענן בוגר ושקוף יותר ללקוח, הוא חושף ללקוח נתוני חיוב מדויקים אודות העלות החודשית כמו כן ספקי ענן בוגרים ידעו להתמודד עם היבטי פרטיות חוק ומשפט (דוגמת עמידה ב-GDPR ותקני פרטיות נפוצים אחרים) באמצעות Data processing agreements.
סיכום
במאמר זה סקרנו בקצרה את השיטות השונות לשימוש מושכל בשירותי ענן. כפי שניתן לראות, לא כל שיטה מתאימה לכל תרחיש או לכל ארגון, אך אין ספק שהעתיד הולך לכיוון שירותי ענן ושירותים מנוהלים.
ההמלצה לארגונים – להתמקד במה שמביא לארגון ערך עסקי (דוגמת בנקאות, תעשייה, מסחר, חינוך ועוד), להכשיר את אנשי התשתיות והפיתוח לשינויים בעולמות הטכנולוגיה ולהעביר את האחריות לתחזוקת התשתיות לספקים המתמחים בנושא.
המאמר נכתב ע"י אייל אסטרין, ארכיטקט ענן במרכז החישובים הבינאוניברסיטאי
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר