בתור CTO בחברת SaaS, סביבת העבודה שלי דומה לזו של רבים בחברות הייטק בישראל. אלה מפתחות מוצר שמורכב מהרבה מאוד חלקים טכנולוגיים והרבה מהן עם קטעי קוד ואפליקציות שרצים במקומות שונים בענן.
כדי להגיע לשוק כמה שיותר מהר, אנחנו המפתחים מנצלים חבילות תוכנה, קטעי קוד קיימים וגם תוכנות של גורמי צד שלישי. זאת כדי לא להמציא את הגלגל מחדש בכל פעם, לחסוך זמן או עבודת פיתוח שמתגלה כמיותרת, ולצמצם אוטומטית הרבה מאוד באגים בקוד. לכן, אנחנו משתדלים לחבר כמה שיותר דברים מוכנים מראש - כאלה שנבדקו ופשוט עובדים, ובונים פתרון שייתן ערך ללקוחות.
רבים מכלי העזר למפתחים, המשמשים אותנו בתהליך הפיתוח הם בתשלום. חלק מהם חינמי או Open Source, אך לא תמיד הם נגישים או מוכרים. לשם כך ריכזתי כלי פיתוח שנוצרו על ידי סטארט אפים ישראליים, הניתנים לשימוש ללא תשלום ויוכלו להקל על עבודתם של העוסקים בפיתוח.
Permit.io: ניהול ההרשאות מקצה לקצה
ניהול הרשאות הוא דבר בסיסי שקיים בכל מוצר ובמיוחד במוצרי B2B. כל מי שמשתמש בתוכנה ראה את זה אינספור פעמים, חוויות כמו: ניהול משתמשים עם תפקידים (RBAC), ניהול מפתחות API, אודיט (audit-logs), התחזות, גישה בחירום ועוד. מה שעצוב בסיפור הוא שכל פעם שראיתם חוויה קלאסית כזו - מאחורי הקלעים איזה מפתח מסכן נאלץ לבנות אותה מאפס.
אנחנו בעצמנו לאורך הקריירה שלנו בנינו חוויות כאלו אלפי פעמים, ולצערנו גם הרבה יותר מפעם אחת עשינו את העבודה שוב במסגרת חברה אחת. עם המורכבות ההולכת וגוברת של אפליקציות, עם הדרישות הגוברות לחוקים יותר ויותר מורכבים לניהול גישה, וכמובן עם המעבר למיקרו-סרוויסים - תהליך הפיתוח הזה נעשה הרבה יותר קשה, וגרוע מכך - הוא לא מסתיים. דרישות חדשות מגיעות כל הזמן מהלקוחות, ממנהלי המוצר, ממנהלי האבטחה ומכל יתר השחקנים סביב השולחן, מכיוון שגישה וחיבור של אנשים לתוכנה זו חוויה קריטית שמשפיעה על כולם.
אך האירוניה הגדולה ביותר היא שמפתחים משקיעים חודשים רבים בפיתוח היכולות הללו וזה כלל לא בראש מעייניהם. לרוב הם מעדיפים להתמקד בבניית החלקים הייחודיים של המוצר שלהם. בדיוק כפי שמפתחים לא מעוניינים לפתח אותנטיקציה (login) מאפס, או בסיס נתונים מאפס, אין סיבה או עניין לפתח ניהול הרשאות מאפס. במיוחד כי זה תחום מורכב שכשלים בו יכולים להוביל לפריצות ולדליפות של מידע רגיש. לפי ההערכות, כ-94% מהיישומים מכילים כשלים מסוכנים במערכות בקרת הגישה.
מה הפתרון של פרמיט?
הרעיון מאחורי פרמיט (Permit.io) הוא ניהול ההרשאות מקצה לקצה. לא רק תשתיות ולא רק API, אלא חוויות שלמות שמוכנות להטמעה בכל מוצר. למשל: ייצור חוקים, אכיפה, ניהול מפתחות, ניהול משתמשים. הרעיון הוא שלמפתחים תמיד תהיה את האופציה לבנות ולהתאים כל רכיב כרצונם אבל הם לא חייבים לבנות אותם אלא אם הם רוצים. שתמיד תהיה להם את היכולת בקלות לשדרג אותם מול צרכים עתידיים.
דוגמה בולטת לחוויית קצה אל קצה בפרמיט היא ממשק עריכת החוקים (Policy Editor), המאפשר למפתחים ולאנשים לא טכניים כמו מנהלי מוצר ואבטחה להגדיר את התפקידים ואת חוקי הגישה למערכת. הממשק מייצר קוד בשפת Rego על בסיס פרויקט הקוד הפתוח Open Policy Agent, שאותו המפתחים יכולים לבדוק, לנהל, ולהוסיף לו במסגרת Git, אך הדגש הוא שהם אינם חייבים.
חוויות low-code כמו זו מאפשרות לכל השחקנים בארגון (ואף ללקוחות עצמם) להשתתף באופן פעיל בשיחה ובכך לייצר תהליכים ארגוניים טובים יותר. ולא פחות חשוב מכך, עומס רב יורד מהמפתחים עצמם.
פרמיט היא פלטפורמת SaaS המבוססת על קוד פתוח וזמינה לכולם בשירות עצמי ובחינם.
Komodor: קבלו את הקונטקסט הדרוש כדי לפתור תקלות בקוברנטיס
מפתחים רבים חווים על בשרם את האתגרים המיוחדים של פיתוח עם טכנולוגיות ענן, ובמיוחד עם קוברנטיס. למשל, קיים פער עצום בידע ובכישורים הנדרשים כדי לנהל אופרציה יציבה ורציפה עם קוברנטיס ביום שאחרי ההטמעה. כמו כן, התעשייה עדיין לא הבשילה מספיק בשביל לתת כלים אמינים שיספקו שקיפות וניטור ברמה שתאפשר מעקב אחר כל אותם שינויים ואירועים במערכת. כאשר צצות תקלות, והן תמיד יקרו ותמיד בזמנים הכי לא נוחים, זה כמעט בלתי אפשרי להבין מי שינה מה במערכת ומתי על מנת לאתר את שורש התקלה. מפתחים ברחבי העולם מבזבזים כיום שעות ארוכות ולעיתים ימים שלמים בניסיון לפתור תקלות בקוברנטיס, בזמן שמשתמשי הקצה חווים באגים או חוסר זמינות מוחלט.
הפתרון של קומודור
קומודור (Komodor) נוצרה כדי לספק למפתחים את הקונטקסט הדרוש כדי לפתור תקלות בקוברנטיס באופן עצמאי. המצב הקיים ברוב הארגונים הוא שמצופה ממפתחים לקחת בעלות על הקוד שלהם, אך כשזה מגיע לפתרון תקלות אין להם מספיק ידע והיכרות עם המערכת ברמת התשתית כדי לאתר את שורש הבעיה. לכן הם נאלצים לפנות לדבאופס או SRE, מה שמייצר צוואר בקבוק ומסרבל תהליכים.
כדי לגשר על הפער הזה, הפלטפורמה של קומודור מציגה על ציר זמן שינויים ואירועים עבור כל משאב בקוברנטיס, ואת ההשלכות של כל שינוי על כלל המערכת. נוסף על כך, קומודור מתריעה על תקלות בהתהוות, חושפת במדויק את מקור הבעיה ומספקת הוראות פשוטות לתיקונה באופן שכל מפתח יכול להבין. למעשה, הידע והניסיון שהוטמעו אל תוך קומודור הופכים כל מהנדס שעובד עם המערכת למומחה לקוברנטיס.
קישור לשימוש חינמי במוצר: https://app.komodor.com/#mode=signUp
פרויקט קוד-פתוח של קומודור לוולידציה של קבצי יאמל: www.validkube.com
כדי להגיע לשוק כמה שיותר מהר, מפתחים מנצלים חבילות תוכנה, קטעי קוד קיימים וגם תוכנות של גורמי צד שלישי. אנחנו משתדלים לחבר כמה שיותר דברים מוכנים מראש - כאלה שנבדקו ופשוט עובדים, ובונים פתרון שייתן ערך ללקוחות
Rookout: דיבאגינג בסביבות ענן מבוזרות
ארגונים שמחפשים להוריד עלויות העבירו את התשתיות ואת האפליקציות שלהם לענן. כתיבת הקוד נעשית ב-microservices, קטעי תוכנה קטנים ממלאי פונקציה או פעולה בודדת ולא כיחידת monolith. אריטקטורות מבוזרות ואבסטרקטיות כמו Containers ו- Serverless תופסות נפח גדול יותר בשוק.
ארגונים שחיפשו דרך להוריד עלויות ולמצוא גמישות גילו מספר קשיים הנלווים למעבר שלהם לענן: מודרניזציית הקוד למיקרוסרוויסים, אימוץ מתודות וכלי עבודה המתאימים לסביבות החדשות, ולבסוף גם הבעיה החריפה ב-Observability בכלל ובדיבאגינג בפרט. פתרונות הדיבאגינג לא עברו מהפך דומה למהפכת הקוד. היכולת של המפתחים להבין מה מצב הקוד והאפליקציה בזמן אמת ולפתור באגים במהירות ובקלות נשארה תלויה בכלים לוקליים ומסורתיים. יתר על כן, היא הפכה למאתגרת ביותר בסביבות המתקדמות הללו.
מה הפתרון של רוקאאוט
רוקאאוט (Rookout) נענים לאתגרי הדיבאגינג וסוגרים את הפער בין עולם הפיתוח, בעל הטכנולוגיות המתקדמות, ובין הצורך בכלי דיבאגינג ו-Observability. הפלטפורמה מבוססת על Live Debugging - הבאה בזמן אמת של לוגים, מטריקות וטרייסים מהאפליקציה, למפתחים הזקוקים למידע זה על מנת לדבג אותה ולהבין את הקוד שלהם בסביבת פרודקשן רצה. כל זאת בלי לעצור ולפגוע בביצועים או באבטחת האפליקציה, דבר שחוסך עד 80% מזמן ניטור ופתרון בעיות דיבאגינג. הורדת הכלי היא חינמית ומאפשרת גישה מיידית למידע ולפתרון באגים קל ומהיר.
Swimm: שימור והעברת ידע בצוותים
אחת הבעיות המוכרות והכואבות בתהליכי פיתוח היא שימור והעברת ידע בצוותים גדולים וקטנים. מפתחים נכנסים לקוד שהם לא מכירים כל הזמן: כשמתחילים עבודה חדשה; כשעוברים צוות; כשנכנסים לפרויקט ובעצם בכל CR או פיצ'ר שמצריך הכרות עם קוד שלא אנחנו כתבנו. להיכנס לבד לקוד זה אפשרי, אבל זה לוקח הרבה זמן ומאמץ. פתרון קלאסי להקלה על המפתח הוא דוקומנטציה, אבל בפועל זה לרוב פתרון בעייתי. הבעיה הבסיסית בדוקומנטציה היא שהמסמכים מנותקים מהקוד, אז הקוד משתנה ומתפתח והמסמכים נשארים לא מעודכנים מאחור. לכן גם אין מוטיבציה לרוב המפתחים לכתוב דוקומנטציה ולהעביר ידע בצורה מאורגנת, והמפתחים שנכנסים לבד לקוד חדש ממשיכים לשלם את המחיר בזמן ומאמץ.
הפתרון של סווים
סווים (Swimm) מאפשרים למפתחים ולצוותים לייצר מסמכים שכוללים רפרנסים לקוד, סניפטים (מקטעים עם שורות מהקוד עצמו), Tokens (למשל שם של פונקציה, שם של קלאס), pathים לקבצים וכדומה. התוצאה היא מסמך שמיועד למפתחים ועוזר להם להיכנס לקוד.
בזכות החיבור בין המסמך לקוד, סווים גם דואגים לשמור את המסמך עדכני על ידי אינטגרציה ל-CI ובאמצעות GitHub App שמוודאת את עדכניות המסמכים בכל PR, ומציעה עדכונים אוטומטיים למסמכים במקרה הצורך. כיוון שהדוקומטנציה קשורה לקוד, סווים יכולים גם לעשות את החיבור ההפוך ולקשר בין שורות קוד למסמכים הרלבנטיים אליהם. לשם כך משולבים במערכת plugins ל-IDEs פופולריים שמראים לצד שורות קוד רלוונטיות שיש מסמך בסווים שמתעד אותן. המערכת הופכת לחלק מתהליך הפיתוח ומאפשרת יצירה ותחזוקה של תיעוד תהליך הפיתוח המתעדכן כשהקוד משתנה. כך אפשר לנהל את שימור הידע בתוך סביבת הפיתוח עצמה, ופעולת תיעוד הקוד הופכת מתהליך מייגע לפשוט ואוטומטי.
סווים מציעה גרסה חינמית לכל צוות שרוצה להתחיל לתעד את הקוד בעזרתה: https://swimm.io
Helios: פתרון בעיות למפתחים בסביבת microservices
אפליקציות ענן מודרניות מורכבות מעשרות או מאות microservices, רכיבי ענן ו-3rd Party APIs. קריאת API ראשונית אחת יכולה להשפיע על מאות שירותים שונים כשהיא מסתעפת בתוך המערכת. כתוצאה מכך, המפתחים מתקשים להבין איך מתנהגת האפליקציה אותה הם בונים בשלבי האינטגרציה השונים: החל מסביבת הפיתוח המקומית שלהם כשהם כותבים פיצ׳רים חדשים, דרך יצירת ותחזוקת בדיקות אוטומציה מורכבות ועד הריצה ב-production.
ככל שמתווספים יותר microservices ושירותי צד-שלישי לאפליקציה - המצב מחמיר: שינוי קטן ב-microservice או ב-API יכול לחלחל לעומק המערכת ולהשפיע על מקומות בלתי צפויים. כתוצאה מכך, מפתחים מבלים יותר ויותר זמן בלנסות להבין את המערכת שלהם ולחפור בלוגים ובשרתים, ופחות זמן במה שהם רוצים לעשות - פיתוח פיצ׳רים חדשים.
חברות ואפליקציות ענן גדלות והופכות מורכבות יותר, בסיסי הנתונים וצוותי הפיתוח מתרחבים והאתגרים הללו מחריפים. לצוותי ה-DevOps וה-SRE יש היום כלים מתקדמים לניטור של סביבת ה-production, אבל יש מחסור בכלים שמלווים את המפתחים במשימות הפיתוח השוטפות.
מה הפתרון של הליוס
הפלטפורמה של הליוס (Helios) נבנתה במיוחד לפיתוח אפליקציות cloud native ופותרת בעיות אינהרנטיות שמפתחים בסביבות microservices נתקלים בהם על בסיס יום יומי. המערכת מאפשרת למפתחים הבנה מלאה של האופן שבו ה-microservices שהם מפתחים מקיימים אינטראקציה עם הרכיבים השונים באפליקציה. כך הם יכולים לאתר, לשחזר ולפתור בעיות במהירות, לייצר בדיקות ביתר קלות, ולהגדיל משמעותית את מהירות הפיתוח. צוותי פיתוח שמשתמשים בפלטפורמה יכולים לעקוב בקלות אחר האופן שבו בקשה (API request) מתנהגת באפליקציה שלהם, לנגן מחדש קלט באופן אוטומטי בכל נקודה בריצת האפליקציה ולשחזר את הבעיה.
למעשה, המערכת מספקת את המידע, ההקשר, והפעולות הדרושות כדי לפתור את הבעיות הרלוונטיות במהירות בצורה ויזואלית, מהירה, וידידותית למשתמש. ישנה גם אפשרות לעבודה משותפת, כך שמפתחים שמשתמשים בפלטפורמה יכולים לתקשר ולשתף פעולה בזמן שהם עובדים, כותבים קוד, ומשנים חלקים שונים של האפליקציה.
הליוס היא פלטפורמת SaaS וזמינה לכולם בשירות עצמי ובחינם.
הכותב: דמי בן ארי, מייסד-שותף ו-CTO בחברת Panorays