הרגל השלישית שנשכחת בתקציב

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

מה השרת בעצם עושה

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

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

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

העלות שצומחת עם ההצלחה

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

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

מה קורה כשאין רשת – וכשאתם נעלמים

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

איפה הנתונים גרים – שאלה משפטית

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

מי בונה את זה

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

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.