פוסט תגובה ל-"לא להינעל" (המאמר של ליאור קיסוס)

קראתי את מאמרו של ידידי היקר ליאור קיסוס באתר PC, וחשבתי להגיב לגבי הדברים.

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

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

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

את הריצה המטורפת לשימוש ב-SAAS אני רואה מכל עבר, ואני חוזר ומציין תחת כל עץ רענן כי ברוב מוחלט של המקרים, שרותי ה-SAAS הם מיותרים לחלוטין אם לא מדובר בפרודקשן שחייב להיות זמין 24/7. אדרבא, ככל שמשתמשים בכמה שיותר שרותי SAAS, האפשרות למעבר לספק ענן מתחרה הופך להיות יותר ויותר קשה, במיוחד כשרוב מוחלט של ספקי הענן הציבורי כיום כלל לא מציעים שום Migration Path נורמלי מענן אחד לשני, ואף אחד כמובן לא מוכן לממן את השינויים בסקריפטים ובמקומות אחרים שצריכים לשנות כדי לעבור ענן.

יש נקודה מסויימת שאינני מסכים עם ליאור, והיא קשורה למחיר: מחירי הענן לא עולים ועולים, ואני אומר זאת באחריות: אני משתמש בשרותי ענן של אמזון כבר 6 שנים לצרכיי האישיים, וכיועץ אני מתעדכן תדיר במחירים של הספקים השונים מבחינת מחירי תשתיות ושרותים. כמעט בכל מצב, תמיד אפשר למצוא דרכים לחסוך כספים בענן, אם מוכנים קצת, טיפה, להתאמץ: במקום להשתמש ב-RDS, תפסיקו להתעצל ותקימו בעצמכם תשתית SQL (לדוגמא). במקום להשתמש ב-CDN הסופר יקר של ספק הענן, תשתמש ב-CDN של מתחרים שאינם נופלים בביצועים ובאיכות ממה שספק הענן שלכם מציע, יש "שכבות" שונות לאחסון Object Storage כמעט אצל כל ספק ענן וניתן בעזרת סקריפט פשוט להעביר קבצים (אם לא רוצים לשלם על Tiering חכם), וזה – על קצה המזלג, כך שבעזרת תכנון נכון וניטור מתמשך, לא צריך להגיע למצב של "שריפת" תקציבים אצל ספק הענן הציבורי.

נתעכב עתה על עניין שחוזר על עצמו שוב ושוב בשיחות עם כל מיני גורמים: On Prem מול ענן, מי עולה יותר? והאם זה נכון שענן תמיד יותר יקר בהשוואה לתשתית On Prem? אם תשאלו את HPE, את DELL, לנובו, סיסקו, פוג'יטסו ושאר יצרני/משווקי שרתים – הם יהנהנו בחיוב וישמחו גם להציג לכם גרפים איך הפתרונות המקומיים שלהם זולים יותר בראיה נוכחית ועתידית. האמת היא, שבמקרים רבים זה לא נכון, ועם קצת מאמץ, אפשר לבנות מערכת בענן (תלוי איזה ספק ענן) במחיר שיכול לנצח פתרון On Prem בחישוב לשנה, שלוש וחמש שנים, כך שיכול להיות שהצבת המטוטלת באמצע הדרך – לא תמיד יהיה הפתרון הכי זול. בל נשכח, שגם על פתרון "אמצע הדרך" מישהו צריך לשלם.

לסיכום: יכול להיות שפתרון On Prem כ"מקדים ענן" הוא פתרון שיתאים לארגונים שונים, אך יחד עם זאת, כמעט כל גוף או ארגון שאני מכיר, כבר החל ללמוד ולהשתמש בתשתיות של ספקי ענן שונים (לא רק גוגל ו-AWS) ורבים מהם מעדיפים להשתמש בשרותי ה-SAAS של אותו ספק, בין אם להפעיל קונטיינרים או להריץ דברים אחרים, וברוב המקרים – לנסות לשכנע אותם עכשיו "לחזור ל-On Prem" יתקל בהתנגדות. אני לא חושב ש-On Prem הוא פתרון רע (ומי שיסתכל בערוץ היוטיוב העסקי שלי יוכל לראות הדגמות רבות על תשתית On Prem), אך אני כן חושב שבעזרת תכנון נכון, אפשר גם להרכיב פתרון טוב וזול – אצל ספקי ענן.

2 תגובות בנושא “פוסט תגובה ל-"לא להינעל" (המאמר של ליאור קיסוס)”

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

  2. בנוגע לשירותי SAAS, מניסיוני האישי אני יכול להגיד לך שזה באמת נחמד, בקליק אתה מקבל Connection String ואיזה כיף יש לי Mongo או SQL או כל שירותי כזה או אחר שלא אני מנהל אותו. אבל בדיוק כאן נגמר החלק הכיפי. הבעיות מתחילות כשאתה רוצה לקבל Performance מתאים, או כשהשירותים לא עונים לצריכך מבחינת Latency או כיוצב. אז אתה נפגש עם ארכיטקט\מהנדסים מגוגל, או מיקרוסופט (שני הספקיות שלי יצא בעיקר לעבוד מולן) ואין להם מושג מה לעשות עם זה. מה גם לך אין יותר מדי איך להשפיע.אז אני מוצא את עצמי, חוזר אחורה בסוף ל"קרקע היציבה", ל – VM's, כותב אוטומציות מספיק טובות, עושה המון המון Tunning בעצמי, ומקבל גם ביצועים טובים ויותר, וגם באופן מפתיע חוסך לחברה המון כסף. שיטת התמחור על השירותים הללו היא הזויה למדי, מי שצורך שירותים כאלו ב – SCALE ימצא את עצמו משלם Per Query המון המון כסף, הרבה מעבר למצב שבו תנהל את השירותים הללו בעצמך(וכן גם כאן אפשר לחסוך, אפשר לעשות Autoscaling למכונות, לכבות\או להקטין אותן ב – Utilisation נמוך בצורה אוטומטית, ושאר הירקות).בנוגע ל – On-Prem, אני נוטה להסכים איתך באופן חלקי, אינני חושב שהסיבה שמה שמחזיק את הלקוחות הללו בענן הם דווקא שירותי ה – SAAS, אני חושב שבחברות גדולות, עם מוצר בשל, אתה עדיין תמצא מעט מאוד כאלו שמסתמכות בעיקר על שירותי ה – SAAS לצד האפליקציה שלהן. אני חושב שזה יותר עניין של ניהול\תחזוקה\תמיכה\כוח אדם וכו' אני רואה את זה הלכה למעשה. דרך אגב, אני חושב שזו טעות, לכל חברה, קטנה או גדולה, להתבסס על שירותים כאלו או אחרים בענן כבסיס להפעלת המוצר שהיא מפתחת, זה פשוט הופך אותה ללקוח שבוי, ולצאת מזה אחריכן יכול להיות עסק מאוד מורכב טכנית, וזה יכול לגרום להפסדים כספיים עצומים, זמני פיתוח הולכים וגדלים וכו'. אני חושב שנכון לתכנן את המוצר\מערכת שהחברה מפתחת בראיה כזאת שהוא ירוץ בכל תשתית ענן\On-Prem, ללא תלות בשירות ענן כזה או אחר, או שאם כן, אז להשקיע באוטומציה מספיק גנרית וטובה כך שיוכל יחסית בפשטות להיפרס ולהיתמך בכל ענן – מה שלא קורה ברוב החברות ומצריך המון המון עבודה מצד אנשי ה – DevOps והמפתחים.לשם ההבנה, אתן דוגמה, נניח ואתה מפתח מוצר שמבוסס על X מיקרוסרביסים, אז במקום להרים אותו על ECS ולהיות כבול ב – Terraform ל – Amazon, אז לצורך העניין לפרוס אותו מעל Kubernetes, ולכתוב לו בצורה חכמה Helm Charts, ואז ניתן למעשה יחסית בקלות להעביר אותו לכל סביבת ענן כזו או אחרת. 

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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

Exit mobile version