✕ סגור 
צור קשר
תודה על ההתעניינות .

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

שירותי ענן: אבולוציה ומגמות לעתיד

Eyal Estrin
|
Jan 14, 2019
alt="blogs"
alt="blogs"
Event
alt="blogs"
title="Google"
Events

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

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

:בואו נבחן אם כך את ההבדלים

בעבר נהגנו להתייחס לענן, עבור שירותי מחשוב המכילים את התכונות הבאות כהגדרה של NIST:

• On-Demand Self-Service

• Broad Network Access

• Resource Pooling

• Rapid Elasticity

• Measured service

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

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

במידה ונבחר להקים "ענן פרטי" בתוך ה-Data center הארגוני, מבוסס תשתיות דוגמת VMWARE, OpenStack או דומיהם, נצפה לכל התכונות שצוינו קודם, גם בסביבת ה-on premise.

נבחין בין הענן לבין שירות האירוח

בשוק ה-IT קיימות כיום עשרות חברות אשר מציעות שירותי מחשוב, על הטווח שבין ענן לבין Hosting.

חברות העוסקות ב-Hosting (או Managed services), לרוב מציעות ללקוח את היכולות הבאות:

• תשתיות מחשוב – דוגמת שרתים פיזיים (במקרה של דרישות חומרה מיוחדות), שרתים וירטואליים, מערכי Storage ורכיבי תקשורת (Router, Firewall, VPN Gateway וכו').

• שירותים מנוהלים – דוגמת אירוח אתרי אינטרנט שיווקיים ומסחריים, שירותי דואר, שרתי קבצים ומערכות ארגוניות דוגמת CRM as a service.

• שירותי גיבוי ו-DR as a service.

• שירותי תמיכה/IT מנוהלים.

חברות Hosting עשויות להציע ללקוח את היכולת להגדיל את כמות השרתים ולעיתים אף לבחור שרתים ב-Data center בחו"ל (במידה ומעוניינים לאפשר גישה לשרתים, קרוב ככל האפשר ללקוח), באופן שעשוי להזכיר שירותים של ספקי ענן ציבורי גדולים מחו"ל.

עבור לקוחות קטנים ובינוניים (SMB), לקוחות ארגוניים העושים את צעדיהם הראשונים בענן או לקוחות אשר מעוניינים להעביר את ניהול את מערכות ה-IT שלהם לגוף חיצוני, אין הבדל מהותי בין בחירה בספקי Hosting/Managed service לבין שירותי ענן ציבורי.

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

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

מודל זה המכונה "Cloud Native Applications” מאפשר השתחררות מכבלי ההתחייבות לכמות מסוימת של תשתיות, ניהול נקודתי, תאימות ודגימת חיים של כל שרת ועוד: מהו טיבו של שרת או פלטפורמה אם הוא יושמד או ישתנה בהינד עפעף? התשתית בתצורה זו אינה חשובה, מה שחשוב הוא השירות שהמערכת תוכננה לספק.

בניגוד לניהול קשיח של תשתיות נכנס לעולם זה מושג חדש - “התשתיות כקוד" (Infrastructure As Code), התשתיות נכתבות בתצורת "מתכונים" שנשלחים למפעיל הענן דרך ממשקים אפליקטיביים (API) והתשתיות נוצרות אך כי באופן כמעט קסום, באופן מיידי.

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

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

(תהליכי הגירת מערכות לענן (על קצה המזלג

שירותי IaaS מאפשרים לארגונים לבצע Lift & Shift ("הרם והעבר" – העתקת המערכת כפי שהיא לענן בשינויים קלים) בקלות יחסית מסביבת ה- On Premise לסביבת הענן, כחלק מתהליכי הגירת מערכות לענן.

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

בשלבים מתקדמים יותר, ארגונים אשר ביצעו הגירת מערכות לענן, מבצעים התאמה וטיוב (Fine-tuning) לתשתיות הענן ע"י מדידת השימוש במשאבים עבור השרת הווירטואלי והתאמת ה-VM instance type לצורכי העיבוד בפועל מבחינת כמות מעבדים/זיכרון/אחסון.

להלן דוגמה מתוך מצגת של חברת AWS לאבולוציה שעוברים ארגונים במעבר לענן מבחינת עלויות:

אבולוציה של ארגונים במעבר לענן מבחינת עלויות

העתיד כבר כאן

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

אם בעבר ארגונים עברו מפיתוח מערכות על שרתים פיזיים לפיתוח מערכות עבור שרתים ווירטואליים, כיום ארגונים עוברים מפיתוח monolith לפיתוח מבוסס micro-services ואף פיתוח יישומים מבוססי Serverless (קוד המופעל בתוך סביבת מחשוב מנוהלת, ללא צורך בניהול משאבי תשתית דוגמת שרתים, אחסון וכו').

השינוי של עולמות הפיתוח מהותי להבנה של מהו שירות ענן, מכיוון שכיום אנו פחות מתבססים על ההגדרה של NIST וספקים המציעים שירותי IaaS (בדומה למרבית ספקי ה-Hosting), וכיום שירות ענן מאופיין ע"י התכונות הבאות:

• אוסף של ממשקי פיתוח (API’s)

• שירותים/משאבים הניתנים לחיוב עבור השימוש בפועל

• שירותים הניתנים לניהול באמצעות API (היכולת לבצע provisioning, decommission, start/stop וכו')

בשורה התחתונה

ספקים רבים כיום נוהגים לעטוף תשתיות/ממשקים של VMWARE בממשק משתמש ידידותי המאפשר ללקוח לבחור את סוג ה-VM מבחינת כמות מעבדים/זיכרון ואת כמות השרתים שברצונו לצרוך, אך הדבר אינו מאפשר ללקוח גמישות לבצע גדילה (Scale-Up) או הקטנה (Scale-Down) לכדי מאות שרתים בצורה אוטומטית ובפרק זמן של שניות בודדות על-גבי איזורים גיאוגרפיים נרחבים.

ספק ענן התומך ב-”Cloud Native Applications" מאפשר ללקוח לחבר את מנגנוני האוטומציה, תהליכי בניית התוכנה והפצתה באמצעות API לתשתיות הספק לצורך הקמה/שינוי של סביבות מחשוב, הקמת מערכות באמצעות Micro-Services ואפילו מאפשרות ללקוח הקמת מערכות והרצת תוכנה ללא תשתיות כלל - Serverless.

בפעם הבאה שאתם מתלבטים לגבי ספק שירותים, האם מדובר בספק Hosting (מתוחכם ככל שיהיה) או בספק ענן ציבורי בעל יכולות צמיחה של מאות שרתים על גבי איזורים גיאוגרפיים נרחבים בדקות ספורות ללא מגע יד אדם, תמיכה בפיתוחים מבוססי micro-services ו-Serverless, ויכולות חיבור בממשקי API, פשוט תציגו לספק השירותים את הדרישות שלכם ותבחרו בספק העונה על הצרכים שלכם.

Cloud Security Architect ,אייל אסטרין

Application Security Architect ,ויטלי אוניק

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

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

:בואו נבחן אם כך את ההבדלים

בעבר נהגנו להתייחס לענן, עבור שירותי מחשוב המכילים את התכונות הבאות כהגדרה של NIST:

• On-Demand Self-Service

• Broad Network Access

• Resource Pooling

• Rapid Elasticity

• Measured service

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

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

במידה ונבחר להקים "ענן פרטי" בתוך ה-Data center הארגוני, מבוסס תשתיות דוגמת VMWARE, OpenStack או דומיהם, נצפה לכל התכונות שצוינו קודם, גם בסביבת ה-on premise.

נבחין בין הענן לבין שירות האירוח

בשוק ה-IT קיימות כיום עשרות חברות אשר מציעות שירותי מחשוב, על הטווח שבין ענן לבין Hosting.

חברות העוסקות ב-Hosting (או Managed services), לרוב מציעות ללקוח את היכולות הבאות:

• תשתיות מחשוב – דוגמת שרתים פיזיים (במקרה של דרישות חומרה מיוחדות), שרתים וירטואליים, מערכי Storage ורכיבי תקשורת (Router, Firewall, VPN Gateway וכו').

• שירותים מנוהלים – דוגמת אירוח אתרי אינטרנט שיווקיים ומסחריים, שירותי דואר, שרתי קבצים ומערכות ארגוניות דוגמת CRM as a service.

• שירותי גיבוי ו-DR as a service.

• שירותי תמיכה/IT מנוהלים.

חברות Hosting עשויות להציע ללקוח את היכולת להגדיל את כמות השרתים ולעיתים אף לבחור שרתים ב-Data center בחו"ל (במידה ומעוניינים לאפשר גישה לשרתים, קרוב ככל האפשר ללקוח), באופן שעשוי להזכיר שירותים של ספקי ענן ציבורי גדולים מחו"ל.

עבור לקוחות קטנים ובינוניים (SMB), לקוחות ארגוניים העושים את צעדיהם הראשונים בענן או לקוחות אשר מעוניינים להעביר את ניהול את מערכות ה-IT שלהם לגוף חיצוני, אין הבדל מהותי בין בחירה בספקי Hosting/Managed service לבין שירותי ענן ציבורי.

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

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

מודל זה המכונה "Cloud Native Applications” מאפשר השתחררות מכבלי ההתחייבות לכמות מסוימת של תשתיות, ניהול נקודתי, תאימות ודגימת חיים של כל שרת ועוד: מהו טיבו של שרת או פלטפורמה אם הוא יושמד או ישתנה בהינד עפעף? התשתית בתצורה זו אינה חשובה, מה שחשוב הוא השירות שהמערכת תוכננה לספק.

בניגוד לניהול קשיח של תשתיות נכנס לעולם זה מושג חדש - “התשתיות כקוד" (Infrastructure As Code), התשתיות נכתבות בתצורת "מתכונים" שנשלחים למפעיל הענן דרך ממשקים אפליקטיביים (API) והתשתיות נוצרות אך כי באופן כמעט קסום, באופן מיידי.

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

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

(תהליכי הגירת מערכות לענן (על קצה המזלג

שירותי IaaS מאפשרים לארגונים לבצע Lift & Shift ("הרם והעבר" – העתקת המערכת כפי שהיא לענן בשינויים קלים) בקלות יחסית מסביבת ה- On Premise לסביבת הענן, כחלק מתהליכי הגירת מערכות לענן.

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

בשלבים מתקדמים יותר, ארגונים אשר ביצעו הגירת מערכות לענן, מבצעים התאמה וטיוב (Fine-tuning) לתשתיות הענן ע"י מדידת השימוש במשאבים עבור השרת הווירטואלי והתאמת ה-VM instance type לצורכי העיבוד בפועל מבחינת כמות מעבדים/זיכרון/אחסון.

להלן דוגמה מתוך מצגת של חברת AWS לאבולוציה שעוברים ארגונים במעבר לענן מבחינת עלויות:

אבולוציה של ארגונים במעבר לענן מבחינת עלויות

העתיד כבר כאן

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

אם בעבר ארגונים עברו מפיתוח מערכות על שרתים פיזיים לפיתוח מערכות עבור שרתים ווירטואליים, כיום ארגונים עוברים מפיתוח monolith לפיתוח מבוסס micro-services ואף פיתוח יישומים מבוססי Serverless (קוד המופעל בתוך סביבת מחשוב מנוהלת, ללא צורך בניהול משאבי תשתית דוגמת שרתים, אחסון וכו').

השינוי של עולמות הפיתוח מהותי להבנה של מהו שירות ענן, מכיוון שכיום אנו פחות מתבססים על ההגדרה של NIST וספקים המציעים שירותי IaaS (בדומה למרבית ספקי ה-Hosting), וכיום שירות ענן מאופיין ע"י התכונות הבאות:

• אוסף של ממשקי פיתוח (API’s)

• שירותים/משאבים הניתנים לחיוב עבור השימוש בפועל

• שירותים הניתנים לניהול באמצעות API (היכולת לבצע provisioning, decommission, start/stop וכו')

בשורה התחתונה

ספקים רבים כיום נוהגים לעטוף תשתיות/ממשקים של VMWARE בממשק משתמש ידידותי המאפשר ללקוח לבחור את סוג ה-VM מבחינת כמות מעבדים/זיכרון ואת כמות השרתים שברצונו לצרוך, אך הדבר אינו מאפשר ללקוח גמישות לבצע גדילה (Scale-Up) או הקטנה (Scale-Down) לכדי מאות שרתים בצורה אוטומטית ובפרק זמן של שניות בודדות על-גבי איזורים גיאוגרפיים נרחבים.

ספק ענן התומך ב-”Cloud Native Applications" מאפשר ללקוח לחבר את מנגנוני האוטומציה, תהליכי בניית התוכנה והפצתה באמצעות API לתשתיות הספק לצורך הקמה/שינוי של סביבות מחשוב, הקמת מערכות באמצעות Micro-Services ואפילו מאפשרות ללקוח הקמת מערכות והרצת תוכנה ללא תשתיות כלל - Serverless.

בפעם הבאה שאתם מתלבטים לגבי ספק שירותים, האם מדובר בספק Hosting (מתוחכם ככל שיהיה) או בספק ענן ציבורי בעל יכולות צמיחה של מאות שרתים על גבי איזורים גיאוגרפיים נרחבים בדקות ספורות ללא מגע יד אדם, תמיכה בפיתוחים מבוססי micro-services ו-Serverless, ויכולות חיבור בממשקי API, פשוט תציגו לספק השירותים את הדרישות שלכם ותבחרו בספק העונה על הצרכים שלכם.

Cloud Security Architect ,אייל אסטרין

Application Security Architect ,ויטלי אוניק

לפרטים נוספים ויצירת קשר עם נציג אורקל

תודה הודעתך התקבלה

הודעתך לא התקבלה - נסה שוב מאוחר יותר

Eyal Estrin

הירשם לרשימת הדיוור של IsraelClouds

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

מילון מונחיםהשירותים שלנו תנאי שימושהרשמה לניוזלטרמדיניות פרטיות