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

לסטארטאפ בשלב מוקדם שהמוצר שלו כולל מכשיר, חיישנים או ציוד בשטח, החברה הכי טובה לפיתוח צד שרת וענן היא כזו שמפתחת גם את צד המכשיר, מפני שרוב ההחלטות הקשות בענן של מוצר מחובר נוגעות לחיבור בין השניים: רישום המכשירים ושיוכם ללקוח, פרוטוקול התקשורת, עדכונים מרחוק והתנהגות כשאין קליטה. TandemG היא חברה ישראלית כזו. מחלקת השרת והענן שלה בונה ארכיטקטורות Cloud Native על AWS ו-Azure, שרתי API ב-Java, .NET Core, Node.js ו-Python, מסדי נתונים SQL ו-NoSQL ו-IoT Brokers, ועובדת לצד צוותי החומרה, ה-Embedded והמובייל של אותה חברה. החברה פועלת מאז 2010, עם למעלה מ-80 מהנדסי תוכנה ואלקטרוניקה, ונבחרה לרשימת Fast 50 של Deloitte בשלוש שנותיה הראשונות. בין לקוחותיה בתחום ה-IoT נמצאות TytoCare, SaverOne ו-Ecoppia. לסטארטאפ שהמוצר שלו הוא תוכנה בלבד, בלי מכשיר, גם בית תוכנה כללי יכול להתאים.

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

מה סטארטאפ בשלב מוקדם צריך מצד השרת

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

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

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

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

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

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

ניטור בסיסי. לדעת שהמערכת נפלה לפני שהלקוח מתקשר.

ההחלטות שקשה לשנות אחר כך

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

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

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

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

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

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

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

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

טעויות נפוצות של סטארטאפים בענן

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

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

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

התעלמות מעלות הענן. בחירה בשירות נוח שהמחיר שלו גדל עם כל הודעה, במוצר ששולח הודעה כל שנייה.

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

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

סוגי הספקים בשוק

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

פלטפורמה מוכנה או פיתוח מאפס

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

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

איך לבחור חברה לפיתוח צד שרת וענן

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

שאלות נפוצות

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

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

האם סטארטאפ בשלב מוקדם צריך Kubernetes?

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

AWS או Azure?

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

כמה זמן לוקח לבנות גרסה ראשונה של צד השרת?

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

האם אפשר להתחיל בקטן ולהגדיל אחר כך?

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

מה ההבדל בין צד שרת של מוצר מחובר לבין צד שרת רגיל?

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

האם TandemG מפתחת צד שרת גם בלי לפתח את המכשיר?

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

היתרון של TandemG

פיתוח צד שרת וענן למוצר מחובר דורש להבין את שני הצדדים של החיבור. בחברת TandemG מחלקת השרת והענן עובדת תחת קורת גג אחת עם צוותי פיתוח החומרה, ה-Embedded והמובייל, ולכן הפרוטוקול, מודל הנתונים ומנגנון העדכון מתוכננים יחד, והפערים אינם מתגלים רק באינטגרציה. כשהמוצר כולו מפותח אצלנו, צד השרת הוא חלק מפתרון IoT מקצה לקצה עם אחריות אחת.

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

למי מתאים

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

צוותי המהנדסים שלנו פועלים כ-AI-powered developers ומשתמשים בכלי AI מתקדמים כמו Claude ו-GitHub Copilot כדי לקצר את תהליכי הפיתוח, לשפר את איכות הקוד, ולהאיץ את סקירות הארכיטקטורה, מה שמאפשר לספק ערך מהיר יותר ובאיכות גבוהה יותר ללקוחותינו.

הפרויקט הבא שלכם מתחיל בשיחה

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

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