אחרי התצוגה המרשימה של החיים ב-Serverless שראיתי באוקטובר, החלטתי שהחברה שלי הולכת להצטרף למגמה. ביליתי את החודשים הראשונים בדפיקת הראש בקיר כאשר ניסיתי להטמיע מערכת פייטון Flask בלמבדה – ואותם מאמצים עזרו לי למצוא דרך טובה יותר.
כחצי שנה לאחר מכן, אנחנו כבר שולחים את הפרויקט הרביעי העיקרי שלנו בשימוש ב-Serverless. עכשיו אני רוצה לספר לכם כיצד עשיתי זאת, כולל מה למדתי בדרך (ומספר דעות מוצקות בנושא).
תפטרו מפייטון
Flask היא ללא ספק שלדה קטנה ונחמדה לרעיון הישן של אתרי אינטרנט (מבוססי בקשה ותגובה) עם הליכים שמנוהלים על ידי השרת. אין צל של ספק שמדובר במשהו ראוי, אבל בעולם החדש של הרשת האינטראקטיבית, העניין משול לבניה של בית עם גומיה ומגב לרכב.
ככל שתתחילו להזיז יותר עבודה לצד הלקוח כדי לתמוך באינטראקציות, לא תהיה לכם ברירה אלא להשתמש בג'אווה סקריפט. לרוב, פעולה זו תוביל אתכם לפנות לשבלונות הפייתון, זאת בזמן שאתם משלמים סכומי עתק למומחים בתחום.
עם הזמן, פתרונות Flask נהפכו פשוט לערבוביה של שפות תכנות שונות. די מהר הבנתי ששימוש בגישה זו הוא לא יותר מבלאגן אחד גדול – ולא הבנתי למה אני בכלל משתמש בפייתון.
לאחר שהחלפת ל-Node, הכל פתאום נהיה הרבה יותר קל ולוגי. לא היה צורך להשתמש ביותר משפה אחת, וקונפיגרציה פשוטה של Node/Express על גבי ה-Webpack יכלתי להשתמש גם ב-ES6 כדי לבטל את מגבלות הג'אווה סקריפט הנוראיות, שהן נושא רגיש אצל מפתחי פייתון.
כאשר ניסיתי לעשות את אותו הדבר בזאפה או ב-Flask, הרגשתי יותר גרוע מהרגעים בהם אני מחשב את המיסים שלי. אבל לאחר 5 דקות, ניתן לבנות אפליקציה מבוססת Node/Express שעובדת על למבדה כאילו מדובר ב-1040EZ ולא במשהו אחר – ולכן אין פה בעיה. לכן, זנחנו את פייתון והצטרפנו לחבר'ה "המגניבים" במחנה הג'אווה סקריפט.
על מה ויתרנו? מעריצי השפה כנראה יגידו שוויתרנו על כל הפיצ'רים המגניבים של השפה, אך בפועל מדובר בלא יותר משעשועים נחמדים בהשוואה לפרקטיקות המדהימות שג'אווה סקריפט מציע. בנוסף, אנחנו כבר לא צריכים לדאוג יותר לגבי גרסא 2 או 3 של פייתון (האם זה אי פעם משתדרג), מדובר היה בחילוף פשוט מאוד.
אז נכון, יש אנשים בתעשייה שיטענו את ההפך הגמור לגבי Serverless, אבל כל אחד ודיעותיו שלו.
אמרו לא למתווכים ולצד השלישי
לקח לנו זמן רב למדי כדי להבין יתרון מוחלט של Serverless, כנראה מפני שבנינו אפליקציות רשת מאז ומעולם, או שפשוט הזדקנתי.
חלק מאפליקציות הרשת הראשונות שלנו עדיין הגיעו עם שכבה ש"זכרה" את מצב הסשן בין אם א. תקווה שגויה שהמשתמש ישתמש בקונטיינר הלמבדה שוב ושוב או ב. טעות עיצובית בה ניצלנו את DynamoDB עד תום כדי לגרום לו לזכור את מספר הסשן. מה לעזאזל עשינו כדי להגיע למצב הזה? אנחנו לא יודעים.
בשלב הראשון בתהליך, המתווך שלנו פעל כמו שרת רשת על למבדה, ופעולה כזו היא לא פחות משגויה ונוראית. בסוף סיימנו עם דפי HTML מפוצצים בג'אווה סקריפט הקוראים ל-REST API. גישה זו הייתה מאוד לא בשלה, בקושי יכלנו לשלוט בה ומהר מאוד היא נהפכה לשברירית – אבל בסופו של יום, הרגנו את הגורם המתווך. בעידן ה-Serverless, אין מקום למתווכים.
תתחילו להשתמש ב-Vew
זה נחמד לשים הכל בחלקים הקשורים לממשק המשתמש, אבל הנושא יכול להפוך בקלות לבלאגן של ממש. בסופו של דבר, אתם תפסיקו לבדוק את הקוד מפני שאתם עלולים להרגיש נבוכים בכל הנוגע לשיתופו, וכולנו יודעים איך מצבים בהם לא בודקים את הקוד מסתיימים.
כניסה לעולם האפליקציות מבוססות עמוד יחיד (SPA) חשפה אותי ל-React, הלא היא הגישה הפופולארית לבניית ממשקי משתמש. מדובר בכלי נהדר שמגיע עם עקומת למידה חכמה, המון סטאפים של Webpack/Babel והיכרות עם JSX. בו בזמן שמדובר במשהו שכנראה נשתמש בו, היה מדובר במשהו כבד יחסית לצרכים המיידים שלנו, שהתבססו על הרצון לחקור את האלטרנטיבות.
למזלנו, גיליתי מהר מאוד את Vue.js, ומאז חיי ב-Serverless נהפכו לברכה של ממש. איך? אתם יכולים ללמוד להשתמש בו תוך יום אחד!
הגישה של Vue לגבי העיצוב מתאימה מאוד למודל שלנו בתחום – הכל שם הוא פשוט רכיב שמנהל את התוכן, עיצוב והקוד שלו עצמו. כל זאת הופך את ניהול פרויקטי הלקוח הרבים שלנו והצוותים המפוזרים שלנו לקל מאוד, ועבד מצוין עם המיינדסט Serverless שלנו.
שלדת הקוד הפתוח של הג'אווה סקריפט מעניקה לכל כלי דיבאג חזקים, ארגון נהדר ובילד Webpack היישר מהקופסא שיחסוך לכם שעות רבות. שימו תוספי ניהול על הראוטר שלכם ותוכלו לייצר אפליקציות זמן אמת כאילו הייתם מהנדסים בפייסבוק. מי ידע שאפליקציות מבוססות עמוד אחד יכולות להיות כל כך קלות להכנה?
מנקודת מבט של Serverless, Vue מקמפל את כל הטוב שיצרתם היישר אל קבצי index.html ו-bundle.js, מושלמים כדי להעלות אל S3. הקימפול כאן הפך לפקודה פשוטה של npm run build.
קחו רגע לשקול את הרעיון הבא – בעולם הישן, שילחנו אפליקציות באמצעות כלים מיושנים ופיקוח על ניצול התועלת, ביחד עם סקאלות אוטומטיות במידת הצורך, וניהול של חלק נכבד מהתשתית.
הקסם האמיתי של אפליקציות מבוססות עמוד אחד היא שכשאתם "משלחים" אפליקציה, אתם פשוט מעתיקים את קבצי ה-index.html וה-bundle.js ביחד עם אוסף תלותיות קבצים היישר אל דלי S3 עם ממשק הפצה המנוהל ב-CloudFront. כל זאת נותן לכם יכולת הפצה והתנהגות טעינה יציבים במיוחד, וגם מאפשרת לכם ניהול גרסאות מרובות לכל מתודולוגיית הפצה שאתם מעדיפים – רק באמצעות ניהול קבצי טקסט.
כך יצרנו מצב שבו יש לנו סקאלה אינסופית ואנו משלמים רק עבור מה שאנחנו באמת משתמשים בו – ואין שום ניהול תשתית אפליקציה כלשהו.
Vue מאפשר לכם לבנות אפליקציית דסקטופ בתוך הדפדפן עצמו – מה שאומר שאתם יכולים לשפר את חוויית המשתמש בצורה משמעותית. כל המצב הזה יוכל להיות מנוהל כאן ללא אינספור בקשות ותגובות, ואתם יכולים לבטל את הדיליי עם טריקי ממשק פשוטים, וכך האפליקציה שלכם תתפקד כמו שצריך.
למדו לאהוב את DynamoDB
עם כל הכבוד, החלק הקשה ביותר במעבר לגישת Serverless היא ללא ספק להגיע להבנה עם DynamoDB. בצעדים הראשונים, אתם תעשו לא מעט טעויות, ואתם תתפתו לא פעם ולא פעמיים לזנוח את הכל ולחזור ל-RDS בו הכל ידוע ונוח.
SQL היה האויב שלי למשך זמן רב, ואני מודה ששמתי יותר מדי לוגיקת עסקים לתוך מאגרי המידע. אבל כשמדובר במערכות RDMS, מדובר בעוד נושא מיושן, כזה שכושל בהתאמה נבונה וללא תמיכה ברעיון של מערכות מהירות שמתפתחות בעצמן.
DynamoDB הוא חיה שונה לגמרי. כאשר אתם מבינים אותה נכון, מאגר ה-NoSQl מקנה לכם ביצועים מדהימים, סקאלה מאסיבית ושום תקורה ניהולית כלשהי. אבל אתם חייבים להשקיע את הזמן כדי ללמוד איך הכל עובד – והשלבים הראשונים לא הולכים להיות קלים.
שדות הטבלה ב-DDB לא יכולים להכיל מחרוזות ריקות. הגיבויים אינם אוטומטיים. אם אתם טועים במחיצה ובנקודות המיון, אתם חייבים להתחיל את הטבלאות שלכם מהתחלה. אתם יכולים להגיע ממצב של "מעט מדי טבלאות" ל"יותר מדי טבלאות" אם אתם מנסים לדמות שאילתות SQL עד הסוף, כל זאת בזמן שהכל מרגיש לכם מאוד שונה ומאוד מוזר.
לאחר מדריכים רבים, ניסיונות, כישלונות ולבסוף הצלחה עם DDB, למדתי את הדברים הבאים
אתם צריכים להבין את הדרך שבה הוא עובד, לבלות זמן בהבנה של אסטרטגיות האינדוקס, ואיך אתם יכולים לכוון שאילתה במידע. זה מאוד קל לקפוץ למים מבלי לדעת כל מה שצריך, ולכן הרבה אנשים נכווים וחוזרים ל-RDMS בדיוק ברגע הלא נכון. אין בעיה שתטעו – רק תמשיכו הלאה.
אחד מהנושאים הכי משמחים ב-DDB הוא הדרך בו ניתן לצרף קוד לטבלת אירועים באמצעות שידורים – למשל טריגרSQL שיכול לעשות הכל. אלו כלים מאוד חזקים – דוגמא פשוטה שאנו עושים היא תמיד להזיז עדכוני טבלאות אל נושא SNS בו השינויים יכולים להתעכל על ידי קוד נטול שרת אחר שאולי עוד לא כתבתם.
אל תשכחו ש-DDB יכול לקבל מידע ממערכות אחסון אחרון (RDMS, Redshift או פשוט קבצי טקסט) ואתם יכולים להשתמש בהם כדי לרכך את הספייקים של התנועה או כדי להגן על מאגרי המידע שלכם מכמויות עצומות של מידע. DDB כוללת פיצ'ר TTL שמאפשר לכם להפוך שורות ללא רלוונטיות – כלי נהדר בכדי לארגון מידע שאתם רוצים להזיז אל מקום אחר.
שלדת Serverless – מדהים!
הניסוי המוקדם שלי עם למבדה היה רומן קצר וגרוע של קידוד היישר לתוך קונסולת ה-AWS ביחד עם תסכול עמוק שלקח הרבה עבודה והודעות שגיאה כדי לעשות מספר דברים טריוויאליים - הגשר שמקשר את ה-IDE אל סביבת הפיתוח חסר.
ובכן, הוא חסר עד שאתם מגלים שלדות Serverless שמבחינתי הן באמת הדבר הכי מרגש שמצאתי מזה דורות.
פקודה פשוטה כמו sls deploy מכילה פתאום כוח עצום, מאגדת את הקוד היקר שלכם ושולחת אותו היישר אל המוח הענק של אמזון. אם אתם צריכים לבדוק לוגים מפני שהקוד שלכם פועל מוזר, פשוט הקלידו sls logs -f functionname -t ומיד תוכלו לעקוב אחרי הלוגים שלכם ב-CloudWatch מבלי שאפילו תצטרכו לפתוח דפדפן.
זה פשוט משנה הכל. האנשים בתחום צריכים להישטף עם צל"שים ועיטורי כבוד עבור זה שהם עושים משהו שכל ספק ענן צריך להציע כבר מהיום הראשון – זה פשוט גאוני, ולא פחות ממדהים.
מערכות זיהוי הן הדבר החדש
באפליקציות מסורתיות, אימות המשתמש הוא הליך חד פעמי שבו עוקבים אחרי מספר הסשן היישר לאחר הזיהוי הראשוני. אנחנו אוהבים את השיטה הזו מפני שאנחנו צריכים לעשות את העבודה הקשה רק פעם אחת, ולאחר מכן ניתן "לרמות" לתקופת הזמן שבא לנו.
אבל בגישה זו יש לא מעט בעיות. היא רק עובדת אם יש לכם שרת באמצע, והרגע שרפנו את האופציה הזו. השרת הזה גם חושף אותך לאופציות תקיפה בעייתיות (כמו CSRF) ולא נותן לך להעביר פרטי זהות בקלות – מה שהופך את הגישה הזו למיושנת
.
אנחנו כידוע, שונאים גישות מיושנות ותקיפות סייבר, אבל אנחנו אוהבים את החבר החדש בשוק – טוקן JWT. כאשר למדתי את הכלי המדהים הזה, פשוט קיבלתי רגע של הארה.
זה באמת פשוט – אתם יכולים לתקשר באמצעותו עם כל שירות שאתם כותבים, וכל בקשה מקבלת זיהוי. הלקוח יכול אפילו לתקשר עם מספר פעולות נטולות שרת – זה מאובטח, חדשני ולא ניתן אפילו לתקוף בשיטת CSRF כש-JWT בשטח. כל מה שנדרש מקוד ה-Serverless שלכם הוא שימוש במזהה מותאם כדי לבדוק אם ה-JWT בהדר הוא תקין (באמצעות קוד boilerplate), וזהו!
זה כל כך קל, שכל הדרכים האחרות נראות מסובכות. מהרגע שעברנו אליו, לא הסתכלנו אחורה – פשוט מצאנו את מה שרצינו. זיהוי נטול שרת הוא גם פשוט וגם אפקטיבי משמעותית – וזה כל מה שאנחנו צריכים
.
זה עולם חדש לגמרי
למרות שעבדתי בעבר עם AWS למשך זמן רב, אף פעם לא הייתי כל כך קרוב לתעשייה. רק לאחר שהייתי בכנס על הנושא, הרגשתי שאני מתקרב לטריטוריה חדשה שעליי לגלות.
בניסויים הראשונים שלנו, היו לנו מספר טעויות כאשר ניסינו להשתמש בכלים ושיטות קיימים, והתוצאות לא היו טובות. לאחר מספר חודשים של ניסיון, התחלנו להקים פרויקטים שהיו 100% ב-Serverless בצורה רשמית. לאחר התוצאה הסופית, אני בטוח שהבעיות בהתחלה היו שוות את זה.
אנחנו בונים אפליקציות SPA איכותיות ויציבות בזמן שמשתמשות אך ורק בשלדת Serverless, עם אפשרויות סקאלה קלות לתפעול ובעלויות נמוכות עד 70-90%. אני גם גאה וגם נדהם מהתוצאות, ומעולם לא הייתי משוכנע יותר שטכנולוגיה זו הולכת להוות לא פחות ממהפכה בכל הקשור לשליחת אפליקציות בענן. אין לי מה להגיד חוץ מלהזמין אתכם לעבור שינויים אמיתיים בעסק שלכם.
מאת: מערכת IsraelClouds
אחרי התצוגה המרשימה של החיים ב-Serverless שראיתי באוקטובר, החלטתי שהחברה שלי הולכת להצטרף למגמה. ביליתי את החודשים הראשונים בדפיקת הראש בקיר כאשר ניסיתי להטמיע מערכת פייטון Flask בלמבדה – ואותם מאמצים עזרו לי למצוא דרך טובה יותר.
כחצי שנה לאחר מכן, אנחנו כבר שולחים את הפרויקט הרביעי העיקרי שלנו בשימוש ב-Serverless. עכשיו אני רוצה לספר לכם כיצד עשיתי זאת, כולל מה למדתי בדרך (ומספר דעות מוצקות בנושא).
תפטרו מפייטון
Flask היא ללא ספק שלדה קטנה ונחמדה לרעיון הישן של אתרי אינטרנט (מבוססי בקשה ותגובה) עם הליכים שמנוהלים על ידי השרת. אין צל של ספק שמדובר במשהו ראוי, אבל בעולם החדש של הרשת האינטראקטיבית, העניין משול לבניה של בית עם גומיה ומגב לרכב.
ככל שתתחילו להזיז יותר עבודה לצד הלקוח כדי לתמוך באינטראקציות, לא תהיה לכם ברירה אלא להשתמש בג'אווה סקריפט. לרוב, פעולה זו תוביל אתכם לפנות לשבלונות הפייתון, זאת בזמן שאתם משלמים סכומי עתק למומחים בתחום.
עם הזמן, פתרונות Flask נהפכו פשוט לערבוביה של שפות תכנות שונות. די מהר הבנתי ששימוש בגישה זו הוא לא יותר מבלאגן אחד גדול – ולא הבנתי למה אני בכלל משתמש בפייתון.
לאחר שהחלפת ל-Node, הכל פתאום נהיה הרבה יותר קל ולוגי. לא היה צורך להשתמש ביותר משפה אחת, וקונפיגרציה פשוטה של Node/Express על גבי ה-Webpack יכלתי להשתמש גם ב-ES6 כדי לבטל את מגבלות הג'אווה סקריפט הנוראיות, שהן נושא רגיש אצל מפתחי פייתון.
כאשר ניסיתי לעשות את אותו הדבר בזאפה או ב-Flask, הרגשתי יותר גרוע מהרגעים בהם אני מחשב את המיסים שלי. אבל לאחר 5 דקות, ניתן לבנות אפליקציה מבוססת Node/Express שעובדת על למבדה כאילו מדובר ב-1040EZ ולא במשהו אחר – ולכן אין פה בעיה. לכן, זנחנו את פייתון והצטרפנו לחבר'ה "המגניבים" במחנה הג'אווה סקריפט.
על מה ויתרנו? מעריצי השפה כנראה יגידו שוויתרנו על כל הפיצ'רים המגניבים של השפה, אך בפועל מדובר בלא יותר משעשועים נחמדים בהשוואה לפרקטיקות המדהימות שג'אווה סקריפט מציע. בנוסף, אנחנו כבר לא צריכים לדאוג יותר לגבי גרסא 2 או 3 של פייתון (האם זה אי פעם משתדרג), מדובר היה בחילוף פשוט מאוד.
אז נכון, יש אנשים בתעשייה שיטענו את ההפך הגמור לגבי Serverless, אבל כל אחד ודיעותיו שלו.
אמרו לא למתווכים ולצד השלישי
לקח לנו זמן רב למדי כדי להבין יתרון מוחלט של Serverless, כנראה מפני שבנינו אפליקציות רשת מאז ומעולם, או שפשוט הזדקנתי.
חלק מאפליקציות הרשת הראשונות שלנו עדיין הגיעו עם שכבה ש"זכרה" את מצב הסשן בין אם א. תקווה שגויה שהמשתמש ישתמש בקונטיינר הלמבדה שוב ושוב או ב. טעות עיצובית בה ניצלנו את DynamoDB עד תום כדי לגרום לו לזכור את מספר הסשן. מה לעזאזל עשינו כדי להגיע למצב הזה? אנחנו לא יודעים.
בשלב הראשון בתהליך, המתווך שלנו פעל כמו שרת רשת על למבדה, ופעולה כזו היא לא פחות משגויה ונוראית. בסוף סיימנו עם דפי HTML מפוצצים בג'אווה סקריפט הקוראים ל-REST API. גישה זו הייתה מאוד לא בשלה, בקושי יכלנו לשלוט בה ומהר מאוד היא נהפכה לשברירית – אבל בסופו של יום, הרגנו את הגורם המתווך. בעידן ה-Serverless, אין מקום למתווכים.
תתחילו להשתמש ב-Vew
זה נחמד לשים הכל בחלקים הקשורים לממשק המשתמש, אבל הנושא יכול להפוך בקלות לבלאגן של ממש. בסופו של דבר, אתם תפסיקו לבדוק את הקוד מפני שאתם עלולים להרגיש נבוכים בכל הנוגע לשיתופו, וכולנו יודעים איך מצבים בהם לא בודקים את הקוד מסתיימים.
כניסה לעולם האפליקציות מבוססות עמוד יחיד (SPA) חשפה אותי ל-React, הלא היא הגישה הפופולארית לבניית ממשקי משתמש. מדובר בכלי נהדר שמגיע עם עקומת למידה חכמה, המון סטאפים של Webpack/Babel והיכרות עם JSX. בו בזמן שמדובר במשהו שכנראה נשתמש בו, היה מדובר במשהו כבד יחסית לצרכים המיידים שלנו, שהתבססו על הרצון לחקור את האלטרנטיבות.
למזלנו, גיליתי מהר מאוד את Vue.js, ומאז חיי ב-Serverless נהפכו לברכה של ממש. איך? אתם יכולים ללמוד להשתמש בו תוך יום אחד!
הגישה של Vue לגבי העיצוב מתאימה מאוד למודל שלנו בתחום – הכל שם הוא פשוט רכיב שמנהל את התוכן, עיצוב והקוד שלו עצמו. כל זאת הופך את ניהול פרויקטי הלקוח הרבים שלנו והצוותים המפוזרים שלנו לקל מאוד, ועבד מצוין עם המיינדסט Serverless שלנו.
שלדת הקוד הפתוח של הג'אווה סקריפט מעניקה לכל כלי דיבאג חזקים, ארגון נהדר ובילד Webpack היישר מהקופסא שיחסוך לכם שעות רבות. שימו תוספי ניהול על הראוטר שלכם ותוכלו לייצר אפליקציות זמן אמת כאילו הייתם מהנדסים בפייסבוק. מי ידע שאפליקציות מבוססות עמוד אחד יכולות להיות כל כך קלות להכנה?
מנקודת מבט של Serverless, Vue מקמפל את כל הטוב שיצרתם היישר אל קבצי index.html ו-bundle.js, מושלמים כדי להעלות אל S3. הקימפול כאן הפך לפקודה פשוטה של npm run build.
קחו רגע לשקול את הרעיון הבא – בעולם הישן, שילחנו אפליקציות באמצעות כלים מיושנים ופיקוח על ניצול התועלת, ביחד עם סקאלות אוטומטיות במידת הצורך, וניהול של חלק נכבד מהתשתית.
הקסם האמיתי של אפליקציות מבוססות עמוד אחד היא שכשאתם "משלחים" אפליקציה, אתם פשוט מעתיקים את קבצי ה-index.html וה-bundle.js ביחד עם אוסף תלותיות קבצים היישר אל דלי S3 עם ממשק הפצה המנוהל ב-CloudFront. כל זאת נותן לכם יכולת הפצה והתנהגות טעינה יציבים במיוחד, וגם מאפשרת לכם ניהול גרסאות מרובות לכל מתודולוגיית הפצה שאתם מעדיפים – רק באמצעות ניהול קבצי טקסט.
כך יצרנו מצב שבו יש לנו סקאלה אינסופית ואנו משלמים רק עבור מה שאנחנו באמת משתמשים בו – ואין שום ניהול תשתית אפליקציה כלשהו.
Vue מאפשר לכם לבנות אפליקציית דסקטופ בתוך הדפדפן עצמו – מה שאומר שאתם יכולים לשפר את חוויית המשתמש בצורה משמעותית. כל המצב הזה יוכל להיות מנוהל כאן ללא אינספור בקשות ותגובות, ואתם יכולים לבטל את הדיליי עם טריקי ממשק פשוטים, וכך האפליקציה שלכם תתפקד כמו שצריך.
למדו לאהוב את DynamoDB
עם כל הכבוד, החלק הקשה ביותר במעבר לגישת Serverless היא ללא ספק להגיע להבנה עם DynamoDB. בצעדים הראשונים, אתם תעשו לא מעט טעויות, ואתם תתפתו לא פעם ולא פעמיים לזנוח את הכל ולחזור ל-RDS בו הכל ידוע ונוח.
SQL היה האויב שלי למשך זמן רב, ואני מודה ששמתי יותר מדי לוגיקת עסקים לתוך מאגרי המידע. אבל כשמדובר במערכות RDMS, מדובר בעוד נושא מיושן, כזה שכושל בהתאמה נבונה וללא תמיכה ברעיון של מערכות מהירות שמתפתחות בעצמן.
DynamoDB הוא חיה שונה לגמרי. כאשר אתם מבינים אותה נכון, מאגר ה-NoSQl מקנה לכם ביצועים מדהימים, סקאלה מאסיבית ושום תקורה ניהולית כלשהי. אבל אתם חייבים להשקיע את הזמן כדי ללמוד איך הכל עובד – והשלבים הראשונים לא הולכים להיות קלים.
שדות הטבלה ב-DDB לא יכולים להכיל מחרוזות ריקות. הגיבויים אינם אוטומטיים. אם אתם טועים במחיצה ובנקודות המיון, אתם חייבים להתחיל את הטבלאות שלכם מהתחלה. אתם יכולים להגיע ממצב של "מעט מדי טבלאות" ל"יותר מדי טבלאות" אם אתם מנסים לדמות שאילתות SQL עד הסוף, כל זאת בזמן שהכל מרגיש לכם מאוד שונה ומאוד מוזר.
לאחר מדריכים רבים, ניסיונות, כישלונות ולבסוף הצלחה עם DDB, למדתי את הדברים הבאים
אתם צריכים להבין את הדרך שבה הוא עובד, לבלות זמן בהבנה של אסטרטגיות האינדוקס, ואיך אתם יכולים לכוון שאילתה במידע. זה מאוד קל לקפוץ למים מבלי לדעת כל מה שצריך, ולכן הרבה אנשים נכווים וחוזרים ל-RDMS בדיוק ברגע הלא נכון. אין בעיה שתטעו – רק תמשיכו הלאה.
אחד מהנושאים הכי משמחים ב-DDB הוא הדרך בו ניתן לצרף קוד לטבלת אירועים באמצעות שידורים – למשל טריגרSQL שיכול לעשות הכל. אלו כלים מאוד חזקים – דוגמא פשוטה שאנו עושים היא תמיד להזיז עדכוני טבלאות אל נושא SNS בו השינויים יכולים להתעכל על ידי קוד נטול שרת אחר שאולי עוד לא כתבתם.
אל תשכחו ש-DDB יכול לקבל מידע ממערכות אחסון אחרון (RDMS, Redshift או פשוט קבצי טקסט) ואתם יכולים להשתמש בהם כדי לרכך את הספייקים של התנועה או כדי להגן על מאגרי המידע שלכם מכמויות עצומות של מידע. DDB כוללת פיצ'ר TTL שמאפשר לכם להפוך שורות ללא רלוונטיות – כלי נהדר בכדי לארגון מידע שאתם רוצים להזיז אל מקום אחר.
שלדת Serverless – מדהים!
הניסוי המוקדם שלי עם למבדה היה רומן קצר וגרוע של קידוד היישר לתוך קונסולת ה-AWS ביחד עם תסכול עמוק שלקח הרבה עבודה והודעות שגיאה כדי לעשות מספר דברים טריוויאליים - הגשר שמקשר את ה-IDE אל סביבת הפיתוח חסר.
ובכן, הוא חסר עד שאתם מגלים שלדות Serverless שמבחינתי הן באמת הדבר הכי מרגש שמצאתי מזה דורות.
פקודה פשוטה כמו sls deploy מכילה פתאום כוח עצום, מאגדת את הקוד היקר שלכם ושולחת אותו היישר אל המוח הענק של אמזון. אם אתם צריכים לבדוק לוגים מפני שהקוד שלכם פועל מוזר, פשוט הקלידו sls logs -f functionname -t ומיד תוכלו לעקוב אחרי הלוגים שלכם ב-CloudWatch מבלי שאפילו תצטרכו לפתוח דפדפן.
זה פשוט משנה הכל. האנשים בתחום צריכים להישטף עם צל"שים ועיטורי כבוד עבור זה שהם עושים משהו שכל ספק ענן צריך להציע כבר מהיום הראשון – זה פשוט גאוני, ולא פחות ממדהים.
מערכות זיהוי הן הדבר החדש
באפליקציות מסורתיות, אימות המשתמש הוא הליך חד פעמי שבו עוקבים אחרי מספר הסשן היישר לאחר הזיהוי הראשוני. אנחנו אוהבים את השיטה הזו מפני שאנחנו צריכים לעשות את העבודה הקשה רק פעם אחת, ולאחר מכן ניתן "לרמות" לתקופת הזמן שבא לנו.
אבל בגישה זו יש לא מעט בעיות. היא רק עובדת אם יש לכם שרת באמצע, והרגע שרפנו את האופציה הזו. השרת הזה גם חושף אותך לאופציות תקיפה בעייתיות (כמו CSRF) ולא נותן לך להעביר פרטי זהות בקלות – מה שהופך את הגישה הזו למיושנת
.
אנחנו כידוע, שונאים גישות מיושנות ותקיפות סייבר, אבל אנחנו אוהבים את החבר החדש בשוק – טוקן JWT. כאשר למדתי את הכלי המדהים הזה, פשוט קיבלתי רגע של הארה.
זה באמת פשוט – אתם יכולים לתקשר באמצעותו עם כל שירות שאתם כותבים, וכל בקשה מקבלת זיהוי. הלקוח יכול אפילו לתקשר עם מספר פעולות נטולות שרת – זה מאובטח, חדשני ולא ניתן אפילו לתקוף בשיטת CSRF כש-JWT בשטח. כל מה שנדרש מקוד ה-Serverless שלכם הוא שימוש במזהה מותאם כדי לבדוק אם ה-JWT בהדר הוא תקין (באמצעות קוד boilerplate), וזהו!
זה כל כך קל, שכל הדרכים האחרות נראות מסובכות. מהרגע שעברנו אליו, לא הסתכלנו אחורה – פשוט מצאנו את מה שרצינו. זיהוי נטול שרת הוא גם פשוט וגם אפקטיבי משמעותית – וזה כל מה שאנחנו צריכים
.
זה עולם חדש לגמרי
למרות שעבדתי בעבר עם AWS למשך זמן רב, אף פעם לא הייתי כל כך קרוב לתעשייה. רק לאחר שהייתי בכנס על הנושא, הרגשתי שאני מתקרב לטריטוריה חדשה שעליי לגלות.
בניסויים הראשונים שלנו, היו לנו מספר טעויות כאשר ניסינו להשתמש בכלים ושיטות קיימים, והתוצאות לא היו טובות. לאחר מספר חודשים של ניסיון, התחלנו להקים פרויקטים שהיו 100% ב-Serverless בצורה רשמית. לאחר התוצאה הסופית, אני בטוח שהבעיות בהתחלה היו שוות את זה.
אנחנו בונים אפליקציות SPA איכותיות ויציבות בזמן שמשתמשות אך ורק בשלדת Serverless, עם אפשרויות סקאלה קלות לתפעול ובעלויות נמוכות עד 70-90%. אני גם גאה וגם נדהם מהתוצאות, ומעולם לא הייתי משוכנע יותר שטכנולוגיה זו הולכת להוות לא פחות ממהפכה בכל הקשור לשליחת אפליקציות בענן. אין לי מה להגיד חוץ מלהזמין אתכם לעבור שינויים אמיתיים בעסק שלכם.
מאת: מערכת IsraelClouds
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר