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

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

לעתים קרובות מתעלמים מהעלות בענן ולא מתחשבים בה בתחילת הפרויקטים של חברות. סקר HashiCorp 2021 מצא שכמעט 40% מהחברות הוציאו יתר על המידה על עלויות ענן ב-2021 [ 1 ]. בשנת 2023, כמעט כל החברות (94%) הודו שהן מבזבזות כסף על הענן [ 1 ] ולפחות 30% מעלות הענן התבזבזו [ 2 ]. הוצאות הענן היו כמעט 500 מיליארד דולר בשנת 2022 - לכן אנחנו מדברים על 150 מיליארד דולר מבוזבזים בשנה!!

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

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

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

בואו נצלול פנימה.

מה נדרש כדי להוציא מיליון דולר בעלויות ענן בשנה?

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

כדי לתת לך מושג, חשבון ענן של מיליון דולר יכול לנבוע מעבודת Spark ETL שמעבדת ~1.5Tb לשעה 24x7 במשך 365 ימים בשנה. דוגמה נוספת יכולה להיות אפליקציה שמקבלת מיליארדי בקשות ביום ממקומות רבים בעולם.

בארגון גדול, יש מאות יישומים בגודל כזה - וכתוצאה מכך חוזים של מיליארדי דולרים עם ספקי ענן. לדוגמה, ל-Airbnb הייתה התחייבות להוציא 1.2 מיליארד דולר על משאבי ענן במשך חמש שנים בסוף 2019 [3 ].

ב-Expedia קצצנו עלויות עבור ETL לעיבוד נתונים בעלות של 1.1 מיליון דולר בשנה ל-100,000 דולר בלבד בשנה על ידי הטמעת שיטות אופטימיזציה. זה הוזלה של 91% בעלויות!!

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

איך מתחילים לחסוך?

שלב 1: אתגר את הנחות העיצוב שלך

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

• האם אתה בונה אפליקציה עם זמינות של 99.999% והשהייה של תת-מילישניות, אבל באופן ריאלי המשתמשים יהיו מספיק טובים עם זמינות של 99% ומאות השהייה של אלפיות שניות?
• האם אתה יוצר מערכי נתונים עם מיליארדי שורות אבל המשתמשים ישתמשו רק בצבירה של חלק מהמדדים?
• האם אתה נוחת נתונים בזמן אמת אבל הנתונים מנותחים רק פעם ביום?
• האם אתה מרענן את המטמון כל 10 שניות אבל הוא באמת משתנה רק על פני ימים?

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

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

שלב 2: כוונן את משאבי התשתית שלך לצרכים שלך

השלב השני מורכב ממתן המשאבים הנכונים לאפליקציה וכיוונון לתשתית הנכונה.

כמהנדס, היה מודע לאופן חישוב עלויות הענן. לדוגמה, AWS מספקת מופעים נקודתיים, שבהם אתה יכול להגיש הצעת מחיר עבור מחיר האשכול - זה שימושי במיוחד אם יש לך יישומים סובלני תקלות וגמישים. השתמש בהם אם אתה יכול - AWS טוענת להפחתה של עד 90% בעלויות [ 4 ].

כמה שיקולים נוספים שאולי תרצו להתייחס אליהם הם:

• האם אתה משרת לקוחות ברחבי העולם או רק באזור גיאוגרפי אחד? האם אתה באמת צריך את התשתית שלך כדי לחיות ברחבי העולם או שאתה יכול להגדיר אותה קרוב יותר לבסיס הלקוחות שלך?
• האם אתה מקצה יתר על המידה את מופעי האשכולות שלך? נסו לוודא שיש מספיק קיבולת להתמודד עם עומסי שיא ללא עלויות מיותרות. השתמש בשינוי קנה מידה אוטומטי כדי להתאים באופן דינמי משאבים על סמך הביקוש בפועל, ולמנוע תשלום יתר עבור משאבים סרק.
• אם אתה עובד עם נתונים ו-Spark, ודא שאתה מבין את המושגים והכוונון של Spark! אם לא, עיין במשאבים הבאים [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ].

שלב 3: השתמש במופעי AWS Graviton

יש מעט חסרונות בשימוש במופעי AWS Graviton. AWS השקיעה רבות ביצירת המעבדים החסכוניים ביותר. אתה יכול לקבל עד 40% הפחתה בהוצאות הענן רק על ידי מעבר ממעבד מבוסס אינטל למעבד מבוסס ARM [ 10 ].

האזהרה היחידה לכך היא שהאפליקציה שלך צריכה להיות תואמת למעבדים מבוססי ARM שעליהם פועל Graviton. אם אתה מתמודד עם שירות מנוהל כמו RDS או OpenSearch, אין שום סיבוך במעבר - AWS עוסק במערכת ההפעלה הבסיסית ותאימות יישומים. אם אתה בונה אפליקציה משלך, ייתכן שיהיה עליך להדר מחדש את החבילה בהתאם לשפה שבה אתה משתמש - Java ושפות אחרות לא דורשות שינוי בעוד ש-Python דורשת תשומת לב מסוימת.

שלב 4: עקוב אחר הוצאות ההוצאות שלך והשכיל לגלות מודעות לעלויות

לבסוף, אל תשכח להמשיך לעקוב אחר העלויות שלך עבור שיאים והפתעות בלתי צפויות. העלות ביום 0 של האפליקציה שלך תהיה שונה מהעלות ביום 170. הקפד לעקוב אחר השינויים, ואתה מבין מדוע השינוי מתרחש: האם זה מערם עלויות אחסון s3 או שזה רק חד פעמי דָרְבָּן?

הגדר את ההתראות הנדרשות ואת ספרי ההדרכה התפעוליים !

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

מחשבות אחרונות

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

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