123: סדרת R&D 05 - למה בחרנו להוסיף שרתים מחוץ לארצות הברית

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

הוקמו סטנדרטים מאוד מאוד נוקשים, ובהרבה מאוד מהמקרים הדרישה אומרת שאתם חייבים להחזיק את המידע פיזית במדינה או באזור גיאוגרפי מוסכם. ופה בעצם אנחנו התחלנו להיכנס לסיפור הזה. אוקיי, אז עם הדרישות האלה החלטנו פשוט שזהו עכשיו בואו ניצור עוד סרבר שלנו באירופה? אז בגדול זה היה תהליך. שנה שעברה בעצם בסביב קיוש 2 נדמה לי, החלטנו שאנחנו קודם כל עושים איזשהו ריביואו כזה, מדברים עם לקוחות פנימיים, לקוחות חיצוניים, מנסים להבין האם זה הזמן הנכון להתחיל לבנות את האזור הגיאוגרפי הנוסף שלנו כדי לשרת לקוחות, ובכלל איזה לקוחות, באיזה אזור. אז אנחנו התחלנו בעצם תהליך של רעיונות, אפשר לקרוא להם, שאלנו ממש אנשים מסלס, מפרטנרס, פה פנימית, כי יש להם קשר עם לקוחות חיצוניים, בכלל איזה עסקאות קיימות, על מה נכשלו אם הם נכשלו על דרישות כאלה של גיאוגרפיים. להבין אם בכלל ב ת יש פה הזדמנות מספיק גדולה, שפספסנו עכשיו כמה עסקאות, כי לקוחות באו ו רו לנו, שמרו הדאטה שלכם לא נמצא באירופה, אז אנחנו לא יכולים להתקדם איתכם. בגדול כן, וזה שוב עם השנים, אנחנו כבר כמה שנים פה, אנחנו שמענו מדי פעם, פה ושם שהעסקאות נופלות על זה, אבל הרגשנו גם שפתאום יש הרבה יותר ויותר ווליום של עסקאות כאלה שמתחילות להיקשל, ורצינו להבין בכלל אם אנחנו כן רוצים לפתוח עכשיו אזור גיאוגרפי חדש, אז א', מה חשוב, וגם איזה אזור גיאוגרפי אנחנו פותחים, אנחנו פותחים אירופה, פותחים אוסטרליה או קנדה, אני לא יודע, אנחנו היינו צריכים יותר דעת מהבחינה הזאת. לפי המחקר שאתה מספר עליו, אני מבינה שזה לא משהו כל כך פשוט, זאת אומרת, זה לא פשוט מקבלים החלטה לפתוח עוד אזור, מקימים כמה שרתים ופשוט עושים copy-paste למערכת, נכון? כן, לגמרי לא פשוט, אז בגלל שאנחנו גדלנו מאזור ריקאי במשך מספר שנים, אז הכל נבנה בידיעה שיש אזור גיאוגרפי אחד שצריך לשרת ממנו ושום דבר לא נבנה לריצה במולטי ריג'ן. שיש לזה משמעות מבחינת איך שאנחנו כותבים את הקוד ברמה הזאתי? איך שאנחנו כותבים את הקוד, איך שאנחנו בונים את התשתיות שלנו, אוטומציה של דברים, אפילו סרווויסים שאנחנו משתמשים לצורך שליחה של אימיילים או אס סים או כל דבר שאנחנו משתמשים בפרודקשן צריך לוודא שאותו סרווויס ידע לרוץ גם באזור גיאוגרפי אחר ובטח אם הוא שומר מידע פי.איי.איי וכאלה של לקוחות ואם לא, אז צריך לחפש אלטרנטיב או לעשות איזושהי מיטיגציה אחרת. דברים כאלה. אוקיי, אז הבנתי שיש לזה משמעויות די רציניות על כל עניין הפיתוח בעצם בחברה. אוקיי, אז התחלנו במחקר, עשית מחקר והבנת שרוב הלקוחות שהדרישות האלה מגיעות מהם זה הם מאירופה? כן, הבנו שרוב הלקוחות הם אירופאים וגם קבוצות סלס ופרטנרס הבינו שגם הפוטנציאל גדילה הוא קודם כל באירופה והם רוצים להתמקד באזור הזה ולהתחיל ממנו. אוקיי, אז שם שווה לשים את הדגש. מה השלב הבא אחרי המחקר הזה? שלב הבא שהחלטנו שאנחנו עושים את זה, כן, זה היה לתכנן את זה. לתכנן איך אנחנו עושים את זה, כמה זמן זה ייקח לנו, באיזה פייזינג, כי גם סלס מאוד רצו לקבל איזשהו טיימליין, כן, אפילו שזה שבור בפייזינג, כל ריבון פחות או יותר, כל כמה חודשים, מה הלקוחות יכולים לקבל. כדי שהם כבר יכולו להתחיל לתקשר את זה על הלקוחות. כדי שהם יוכלו לתקשר, כדי שהם יוכלו לסגור כבר עסקאות בידיעה שהלקוח יעשה אונבורדינג בזמן שמתאים לו, אבל הוא ידע בדיוק מתי הוא יקבל כל דבר ויחליט לבד בקטע של שקיפות, כמו שאנחנו עושים כל דבר, יחליט לבד מתי זה זמן מתאים לא כחברה לעשות את האונבורדינג. אוקיי, אז אנשי המחירות אבל ממש יכולו לבוא בהבטחות ללקוחות, שמרו אנחנו יודעים שכרגע זה בעייתי עבורכם, אבל עוד ריבון שניים שלושה אנחנו מתקדמים לכיוון הזה ואתם כן תוכלו כבר לפעול על גבי הפלטפורמה. בדיוק בדיוק ובסוף שוב בנינו כזה

בריבונים, קור ריבון, מה אנחנו מתחילים? אז החלטנו בשלב ראשון זה לשפר את כל התשתיות שלנו, וקודם כל התחלנו בשלב הזה, אחר כך דיפלוימנט של אפליקציה וריפקטורינג וסגירה של עוד דברים שמיטלמן פה כבר הוביל את הפרויקט הזה טכנית, והוא יכל לספר על זה. אבל אני רוצה להתעכב עוד שנייה, כי אני בטוחה שזה פרויקט ענק. כמה הוא לקח בסך הכל? הוא לקח שנה, ואנחנו עכשיו בשלב ההסגירה. אוקיי. אז מיטלמן, אני עכשיו שמה את הספוטלייט עליך. בכיף. אתה בעצם הובלת את הביצוע של התהליך הזה? אז ב ת הפרויקט התחיל אצל דוד, מנקודה ב ת של יותר היי לבל, של להבין את הצורך, של לעבוד עם סיילס ופרטנרס, וב ת לגבש את זה כתוכנית אסטרטגית שאנחנו לוקחים. ואז ב ת כשהגענו לשלב הביצועי, אז באופן טבעי הפרויקט עבר מהגרופ ליד לטק ליד, שזה ב ת התפקיד שלו להוביל פרויקטים כאלה. שרק נגיד, זה צוות האינפרה הוביל את זה אצלנו בחברה. אז נחדד. בראש ובראשונה צריך להבין שזה פרויקט שבבסיסו הוא פרויקט תשתיתי משמעותי, בגלל שאנחנו צריכים להיכנס ולפתוח את כל מה שעשינו מהיום שהחברה התחילה לפעול בעצם, ולשבור הרבה מאוד הנחות יסוד שהרשנו לעצמנו בעצם לקחת. אם אני מסתכל על איך החברה עבדה ב-2013-2014, לא היו לה שיקולים תשתיתיים. השיקול שלה קודם כל היה שתהיה אפליקציה עובדת שתוכל לשרת לקוחות. בלי עכשיו לחשוב, טוב, מתישהו מישהו יצטרך את זה באירופה, מתישהו מישהו ירצה את זה באוסטרליה. נכון, למעשה המילה ריג'ן בכלל לא הייתה על השולחן. האפליקציה ישבה על שרתים, היו מסדי נתונים שהכנסנו את המידע של הלקוחות. ופה בעצם נגמרה כל השיחה, ועכשיו כשאנחנו מסתכלים על כל הנחות היסוד או כל הנחות הבסיס שנתנו לעצמנו לקחת במהלך השנים, אז מתחילים להיכנס לכל מיני פרטי מימוש. למשל, מסתכלים על הקוד עצמו. בקוד עצמו אנחנו מצאנו רפרנסים לריג'ן ה ריקאי. כלומר, מי שכתב את הקוד אפילו לא העלה על דעתו את האפשרות שיום אחד האפליקציה הזאת לא תרוץ בחוף המזרחי של ארה״ב. מה המשמעות של זה בפועל? כאילו אני, אוקיי, אני לא מבינה מה זה אומר אם מישהו התחשב בקוד בזה שזה בארה״ב. מה זה אומר לי עכשיו בפועל שאני רוצה עכשיו להעביר את זה לספרד? אז למעשה יש פה שני אתגרים מאוד מאוד משמעותיים בפרויקט הזה. האתגר הראשון הוא אתגר טכנולוגי. הוא אתגר שבו אנחנו מתחילים לבנות תשתית גלובלית. אנחנו לוקחים בעצם תשתית מקומית שהייתה עד עכשיו מנדידוט קום והופכים אותה לתשתית גלובלית. תשתית שיודעת להתחשב באזורים גיאוגרפיים, שיודעת לנתב אנשים מיבשת אחת ליבשת שנייה ואנחנו גם ניכנס קצת לפרטים בהמשך. אבל זה האתגר הראשון. האתגר השני הוא ב ת אתגר של education. זה להגיע למפתחים, להגיע ל-R&D שבעצם יכלו לחיות תחת אותו סט של הנחות בסיס עד עכשיו ולהגיד להם מהיום אנחנו כבר לא יכולים לעבוד בצורה הזאת אלא אנחנו צריכים להכיל על עצמנו התחשבות בשיטות פיתוח חדשות. למשל אני לא יכול לצפות שמידע מסוים יהיה בהכרח בריג'ן מסוים שאני פועל בו מכיוון שאם יש לי שני ריג'נים, שלושה ריג'נים הן למעשה יחידות תפעול נפרדות לחלוטין. הן לא מודעות אחת לשנייה אפילו לקיום שלהן. ואם אני מפתח שעובד על אפליקציה שרצה בתשתית הגלובלית של מנדיי אז למעשה האפליקציה שלי קיימת פעמיים. היא קיימת פעם אחת בארצות הברית ופעם אחת באירופה. וזה אומר שכל השיקולים הפיתוחיים שלי מהשלב של הדיזיין דרך הכתיבה של הקוד והריוויו והדיפלוימנט שקורה ב צעות צוות האינפרה כל הדברים האלה צריכים להתחשב בעובדה שהאפליקציה לא יודעת איפה היא רצה בעולם. אז לצורך העניין, כל פיצ'ר חדש שאני אפתח מעכשיו הל אני אכרחית לשחרר אותו בארצות הברית פעם אחת ופעם שנייה באירופה. נכון. יש לזה בעצם שני מנועים מאוד הגיוניים. אחד, אנחנו מתחייבים לכל הלקוחות שלנו שלא משנה באיזה אזור גיאוגרפי אתה נמצא אתה תקבל את אותה חוויה של מנדיי. אין סיבה שאם בן אדם עובד בריג'ן האירופי שלנו הוא יחווה חוויה נחותה יותר מלקוח ריקאי. כן, גם אנחנו לא יכולים למשל אנשי הסיילס לא יכולים לבוא ולהגיד לארגון שאומר טוב אני חייב שהדתה שלי יישמר באירופה הם יגידו לו אין בעיה אבל לא יעבוד לך אחד, שתיים, שלוש בפלטפורמה. בדיוק. בחברה בסדר גודל כמו מנדיי אתה לא יכול לבוא ולהגיד דבר כזה ללקוחות. דבר שני זה ב ת לעבוד עם best practices של פיתוח. אפליקציה אכן לא ורה לדעת איפה היא רצה וכל ההנחות בסיס האלה שעבדו עד עכשיו אנחנו צריכים לתקן אותם לא רק כי הם לא יעבדו מעכשיו אלא כי זה הדבר הנכון לעשות

בחברה המתפתחת. אוקיי. אז הבנתי למה זה היה מורכב, הבנתי כמה זה היה שונה לפני, איך ניגשים לזה בפועל? מה הדבר הראשון שעשית? יפה. אז הדבר הראשון זה ב ת לסרטט את המסלול שעושה לקוח מהמחשב שלו בבית או בעבודה שלו, ועד שהוא מגיע למה שאנחנו נכנה באופן כללי שרת של מנדי. ולהבין האם מה שיש לנו היום יעבוד בעולם שהוא מולטיריג'ונל, או שאני לא אוכל להביא אותו לריג'ן הנכון בהינתן זה שאני יודע אם הוא שייך לארה״ב או לאירופה. אתגר שני הוא אפילו אם אנחנו מרחיבים את הבעיה הזאת אפילו יותר, לקוח מגיע לעשות לוגין למנדי. אנחנו לא יודעים מי הלקוח הזה ואנחנו לא יודעים באיזה חשבון הוא נמצא. האם אני מכוון אותו לשרת ה ריקאי או לשרת האירופי, בהינתן זה שאני אפילו לא יודע מי זה. אוקיי ועוד שאלה אחת, כל הלקוחות האירופאים שכבר היו לי בפלטפורמה כי בטוח היו כאלה שכבר היו שם, גם אותם אני רוצה להעביר עכשיו לריג'ן השני? אחד ההגדרות לפני שהתחלנו את הפרויקט היה מה אנחנו לא עושים בכלל בפתיחה הזאת של מולטי ריג'ן, ובעיניין היה שאנחנו לא מעבירים לקוחות מריג'ן לריג'ן. כי מי שטכני יכול לדמיין עד כמה זה מהלך שהוא מאוד קשה להעביר את כל הדאטה של לקוחות, שמתפרס בין עשרות דאטאבייסים ועשרות טבלעות אם לא מאות, לריג'ן אחר שבכלל יש לו סטייט אחר והכל אחר. זה בהגדרה הגדרנו שאנחנו לא עושים את זה, אנחנו נעזור ללקוחות לפתוח ריג'ן ולהעביר מידע בצורה ידנית, אבל כרגע בשלב ראשון לפחות אנחנו בכוונה הורדנו את זה מהפרק כדי לא להתעסק בזה, כי זה פרויקט ענקי גם ככה. זהו בדיוק, זה פרויקט שהוא מסובך גם ככה, אז אני מניחה שזה להוסיף עוד אלף שכבות של סיבוכים על גביו. לגמרי. אוקיי, אז הבנתי את כל המורכבויות, איך ב ת ניגשתם לזה? יפה, אז אני כבר אגיד מראש שהפתרון עצמו הוא לא פשוט, אבל זאת דוגמה מצוינת לבעיה שאנחנו ניגשנו אליה עם מיינדסט שאנחנו לא נוכל לפתור את זה רק בתוך אינפו. וב ת הפתרון צריך להגיע משיתוף פעולה, במקרה הזה בין קבוצת האינפו לבין צוות סרב ופאונדיישנס אצלנו ב-R&D. שזהו הצוות שמתעסק בעבודות תשתיתיות. נכון, בצד האפליקטיבי, נכון. כל בקשה שנכנסת לתוך מנדי למעשה צריכה לעבור כמה בדיקות אבטחה, כי אנחנו לא מעבירים כל בקשה מהאינטרנט ישירות לאיזשהו שרת או מחזירים איזשהו מידע בחזרה, ואחת הבדיקות שכל בקשה עוברת זה בדיקה של ב ת מי אתה, האם אתה משתמש מורשה, האם ב ת עשית לוגין עם יוזר וסיסמה שהם תקינים, האם אתה לא מגיע מה-IP שהוא חסום, ובשביל זה אנחנו ב ת כתבנו פתרון שהוא אין-האוס, שהוא יודע לבצע את כל הבדיקות האלה, אנחנו יודעים להשיט עליו את כל המורכבויות שאנחנו רוצים, ומכיוון שאנחנו פיתחנו את זה אין-האוס אז אנחנו גם הרשמנו לעצמנו לבוא ולהגיד, אוקיי, מכיוון שהדבר הזה מטופל כבר בכניסה לרשת, בואו נוסיף למנוע הזה עוד תחום אחריות של סיווג לא רק של מי הבן אדם, אלא לאיזה ריג'ן הוא שייך. ואז ממש עוד לפני שהגענו לאפליקציה, ממש עוד בשכבת הרשת, אנחנו יודעים היום לסווג האם הבן אדם הזה שייך לריג'ן ה ריקאי או לריג'ן האירופי. כלומר, אנחנו יכולים להסתכל על אם אנחנו מדמים בקשות בתור כדוריתניס, אנחנו יכולים לחשוב על תותח שיורה אלפי כדוריתניס בשנייה לעבר המערכת שלנו, ובצד השני ראוטר מאוד מאוד חכם שיודע לנתב אותם ימינה או שמאלה בקצב של אלפי כדורים בשנייה. וב ת אחד הדברים שהבנו בסופו של דבר שטוב שהלכנו לכיוון הזה, זה שלא רק שהפתרון הזה סקיילבילי מבחינת נפח שאנחנו נוכל לתמוך גם בפי 10 ופי 20 ופי 50 יותר לקוחות ממה שיש לנו היום, אלא שזה שומר לנו את החירות להחליט איך הדבר הזה נר ולפתח איך ב ת המעברים האלה בין ריג'נים וב ת איך אותה הגנה על פרטיות ושמירה על אזור גיאוגרפי של לקוחות, איך היא תר בפרודקשן. זה מאפשר גמישות. גמישות כמעט אינסופית. וזה גם בעצם דרש מכם להסתכל על כל מה שעשיתם בעבר ולהגיד לא בטוח שזה מה שאנחנו רוצים לעבוד ככה יותר, נכון? זה דרש לחשוב על דברים ממש מחדש. נכון, למעשה בתור מי שיצא לו להוביל את הפרויקט הזה טכנולוגית, אני הסתכלתי על הפרויקט הזה בתור איזושהי הזדמנות שלנו לפתוח את הספרים ולהגיד אין פרות קדושות. אם עבדנו עד עכשיו בצורה מסוימת שהיא עבדה בסדר ואולי…

זה יעבוד בסדר גם במולטי ריג'ן, אבל זה לא יהיה נכון שאנחנו נמשיך לעבוד ככה שנים קדימה. זאת הייתה הנקודה בדיוק להקות בברזל החם ולהגיד אנחנו משנים את איך שאנחנו עובדים, כי אם אני מסתכל עכשיו שלוש שנים, חמש שנים, שמונה שנים קדימה, אני ארצה לעבוד ככה לא רק שיהיו לי שני ריג'נים, אלא שיהיו לי ארבעה ריג'נים, אם יהיה מצב כזה יום אחד בעתיד. כן, אנחנו לא יודעים אם מתישהו בהמשך לא יגיעו אלינו לקוחות ב ת מאוסטרליה או מאפריקה ויגידו אנחנו רוצים שהנת שלנו יישמר מקומית. נכון, וב ת דוד הזכיר מקודם את העקרון של Infrastructure as Code, שזה אחד העקרונות הכי חשובים שצריך לשמר בתהליך הזה. זה שכשאנחנו הרמנו את הריג'ן באירופה, אנחנו עשינו את זה מלכתחילה בצורה שהיא reproducible. אוקיי, אז אם אני ב ת מבינה נכון, זה לא שעכשיו רק יצרתם תוכנית לאיך להרים את מנדיי באירופה, אלא יצרתם תוכנית לאיך עכשיו להרים את מנדיי מקומית בכל מקום שתרצו. נכון, נכון, זאת הייתה גם אחת ההגדרות בהתחלה של הפרויקט, כמו שביטולמן ר, אנחנו רצינו לקחת את זה לשלב הבא של תשתיות ואפליקציות שלנו, שנוכל לא לחשוב על זה, כן? על עוד כמה ריג'נים אנחנו נתמוך, ובטח שהריג'ן הבא שאנחנו מקימים משמעותית ייקצר את פרק זמן של הקמה שלו, ומכל אחד אנחנו נלמד עוד יותר ונשתפר עוד יותר. אז אם איתן ר שזה כל התהליך לקח תשעה חודשים, כמה אתם צופים שהתהליך הבא ייקח, למשל? מקווים שלושה חודשים. אוקיי, אז סיימתם את התהליך הזה, בעצם בניתם את כל המתכון החדש הזה, ואז מה, פשוט מהרגע הזה כל הכוח שנכנס עבר אוטומטית לאירופה? אז ב ת בגלל שזה שינוי משמעותי, אז גם בתהליך של הפריסה אנחנו לקחנו קצת את הזמן, אז הדבר הראשון שעשינו זה ב ת עבדנו עם צוות הפרטנרס אצלנו, ומצאנו לקוח אחד משמעותי מאוד שהיה לו מאוד מאוד חשוב ברמה של זה או אירופה או שאני הולך למתחרים שלכם, ובאנו והצאנו לו את ההצעה הב . אנחנו נאחסן את החשבון שלכם על השרתים האירופיים החדשים שלנו, אנחנו רוצים שתבינו שאנחנו נמצאים באיזושהי תקופת הרצה ראשונית, המערכת הולכת לעבוד לכם והיא הולכת לעבוד טוב. אבל אתם תשימו לב שיש פיצ'רים מסוימים שעדיין לא עובדים מהאחוז או עדיין לא נמצאים שם, אנחנו נעדכן אתכם בפריסה של הריג'ן, אתם תראו שפיצ'רים שלא הופיעו לכם עד עכשיו יופיעו לאט לאט, ואנחנו גם נלווה אתכם ממש בקפפות משי. אז בעצם הייתה לנו תקופה של שישה שבועות ראשונים, שבהם הם הבינו שהתפקיד שלהם זה לשקף לנו כמה שיותר ובצורה שהיא ב ת מאוד מאוד שקופה את מה עובד טוב בריג'ן, מה לא עובד להם, מה איטי, מה נתקע, מה חסר להם. וב ת הייתה לנו אינטראקציה כמעט יומיומית עם הלקוח הזה. זה שישה שבועות, שבהם אתם בצוות האינפרה מקבלים פידבק שוטף ועושים תיקונים ממש בלייב, ברגע שאתם מקבלים אותם? בסדר גודל של ימים, בדיוק. וב ת יכולנו לראות איך התהליך של הכנסה של חשבון אירופי חדש נר לא רק מהצד שלנו של המדדים והגרפים, אלא ממש מהצד של לקוח גדול ומשמעותי שמ ץ לחיקו את המערכת הזאת בהינתן א', כל הדברים הטובים שמגיעים עם אנדיי, אבל ב ת כל המגבלות שקיימות עכשיו, וב ת לראות את ההבנה שלו של אנחנו הולכים איתכם ביחד, אנחנו פותרים את זה, כרגע המצב הוא עדיין קצת חלקי, אבל בסופו של דבר עוד כמה חודשים אתם הולכים לקבל חוויה מל של מאנדי, ואנחנו מאוד רוצים שתעשו את זה איתנו ביחד. ואנחנו בעצם הגענו למצב שבו בתשעה חודשים אנחנו בנינו את מאנדי מאפס באזור חדש לחלוטין, למעשה לקחנו את כל העבודה מ-2012 עד 2020, ועשינו אותה מחדש בתשעה חודשים. וכל ההבנה של איך הדבר הזה מתנהג באזור גיאוגרפי אחר, עם התפלגות קצת שונה של לקוחות, עם שימושיות קצת שונה, זה היה מאוד חסר לנו, וב ת הפידבק הזה מלקוח יתי שב ת מרגיש את המערכת בידיים יום-יום, אפשר לנו ב ת לאפטם ולהגיע למספרים שהם הרבה יותר מתאימים. אני יכול להוסיף שגם לשחרר ריליס כזה לכולם וזהו ולקוות לטוב זה לא הדרך שלנו.

במנדי אנחנו משתדלים לעשות הכל הדרגתי ועם בדיקות, עם פיצ'ר טאגלים ולקבל את הפידבק הזה, כי אנחנו מבינים שאנחנו לא מושלמים ובטוח שכחנו דברים, בטח בפרויקט בסדר גודל כזה, וזה כלי מעולה לבדוק את עצמנו ועל הדרך למדנו המון ושיפרנו דברים. היו אתגרים בדרך שלא צפינו או איזושהי מסיכונים שהיינו צריכים לקחת בחשבון? כן, בעיקר גם סביב third party services שגילינו פתאום סרוויס אחד שאנחנו הסתמכנו בו מאוד בארצות הברית, הוא לא נתמך באירופה. אוקיי, זו נקודה מעולה. בעצם מנדי, יש להם אינטגרציות עם הרבה כלים חיצוניים, נכון? אז אנחנו צריכים שגם הם כולם יתמכו באירופה. כן, למשל, באופן שליחת מיילים טרנסקציוניים, כשלכוח נרשם הוא צריך לקבל אימייל שנרשמתי, הכל טוב, תאשר את האימייל שלך. אז אנחנו במקרה הזה משתמשים בסנדגריד בארצות הברית, כן, והם תומכים, הם בעצמם רצים בארצות הברית, ואימייל זה גם פיסת מידע של לקוח בסופו של דבר, מזה ייחודי. גילינו על הדרך שאין להם אפשרות להרים שרתים שלהם באירופה. אז היינו צריכים פה לעשות מיתיגציה ולהתאים את מיילגן באירופה לריצה באירופה. אז יש לנו איזשהו שוני בסרוויסים, והיו עוד דוגמאות כאלה. עוד אתגר שיש לנו כרגע וזה מתמשך, למרות שכל הפרויקט הזה התחיל לא בסיילו, לא שאנחנו התחלנו אותו ולא דיברנו עם אף אחד, דיברנו עם כולם, עם R&D בעיקר, כי היינו צריכים להפעיל את כמעט כל הצוותים, הייתי לא כמעט כל הצוותים. כן, זה משמעות כמעט על כל מפתח. נכון, אז ניסינו לחבר את כולם מאוד מההתחלה מה זה אומר ואיך, ושלב ראשון בכל מקרה היה של תשתיות, והיינו צריכים להבין שריג'ן נוסף זה עוד רובד של מורכבות. אם להוריד את זה קצת לקרקע, אז נגיד אם אפליקציה שלכם תומכת רק באנגלית, אז זה פשוט. ומה אם צריכים לתמוך בעוד עשר שפות? אז כל סטרינג שמשנים צריך לבדוק אותו שהוא יעבוד גם בשפה מסוימת וצריך לתרגם אותו. אז תחשבו שמוסיפים עוד מספר ריג'נים שצריך לתמוך בהם, ופה התמיכה היא לא רק אפליקטיבית, היא גם תשתיתית. כי כל אפליקציה צריכה גם דאטאבייס נוסף. אז זה ממש משהו שכל מפתח צריך עכשיו שיהיה לו כזה בבקוויז מיינד, ולהתחשב בזה בעבודה שלו. אז איך עושים את זה ב ת? איך מזכירים להם, איך דואגים שהם כן יעבדו נכון? אז ניסינו למצוא דרכים ויותר בקטע של טסטים או כלים שאנחנו מכניסים, שעוזרים למפתחים ממש לגלות את אירופה. לבדוק את עצמם למשל. לבדוק את עצמם, נגיד הוספנו עוד רובד בדיפלוימנט פייפליין שלנו, שהדיפלוימנט יהיה עושה אוטומטית גם לאירופה, וגם כל מיני נוטיפיקציות שהם פתח כשהוא עושה דיפלוימנט, הוא יקבל שהנה, האפליקציה שלך, הגרסה החדשה נפרסה בארצות הברית, וגם נפרסה עכשיו באירופה. אז בן אדם צריך לחשוב, באירופה? אז מה אני עושה? האם זה הצליח, לא הצליח? אולי שכחתי להריץ איזושהי מגרצה, או שכחתי להוסיף קונפיגרציה, והיו לנו מקרים שדיפלוימנט לאירופה פתאום נכשל, כי על הדרך הוסיפו עוד איזושהי קונפיגרציה בארצות הברית, כי זה ההרגל, ושכחו להוסיף את זה שם. אז גם כל הכלים שעוזרים למפתחים להוסיף קונפיגרציות, אז עכשיו הם גם מזכירים לאנשים, האם הוספת קונפיגרציה בארצות הברית, אולי אתה רוצה להוסיף גם בריג'ן אחר. תגידו, מנדיי קיימת מ-2012, לקחתם דאטה וקוד שנבנה במשך 8 שנים, הרמתם אותם במקום אחר, לא היה דרך לעשות את זה קצת אחרת, מההתחלה להגיד, אוקיי, אולי אנחנו בעתיד נרצה להתפתח לעוד ריג'נז? זה פשוט רובד של מורכבות במולטי ריג'ן, שלא כדאי להיכנס אליו בשלב הראשון, כשאנחנו עוד לא שם ואין לנו לקוחות, או שיש לנו בקושי קצת לקוחות, זה פשוט הדברים שהם גורמים להיות out of focus בשלבים הראשונים, ועדיף לדחות את זה לאחר כך, כשחברה תהיה יותר בוגרת, כבר עם טרק רקורד.

שברור שיש פה את ה-product market feed, יש לקוחות שאוהבים את המוצר, וכבר לקוחות הם אלה שדרשו שיהיה להם פתרון מולטי-ריג'ני כזה, אבל שוב, זה מאוד תלוי, יכול להיות מאוד תלוי בביזנס הספציפי. כמו ש רנו, ב ת זה נושא שהוא הלך ותפס תאוצה רק בעשור האחרון. אם היום היינו מנהלים את השיחה הזאת בתור סטארט-אפ חדש, אני הייתי אומר שזה לא הדבר הראשון שצריך להתחיל איתו, אבל זה כן משהו שצריך להיות במיינדסט של כל סטארט-אפ, כל חברה, שהמיין ביזנס שלה זה להחזיק דאטה על אנשים או דאטה של אנשים. ואני אגיד אפילו שחברה שמתחילה לבחון את השוק שלה מסביבה, ויודעת כבר להגיד היום באיזה מדינות היא צפויה לפעול בהן בצורה משמעותית, כדאי לפחות להסתכל ולזכור את חקיקת הפרטיות במדינות האלה. אם זה אוסטרליה ואם זה ברזיל, ובאופן כללי כל האיחוד האירופי שהיום מוביל מגמה מאוד משמעותית בכיוון הזה, ואפילו קליפורניה שיש לה חקיקה ספציפית לה שנקראת CCPA. אני לא חושב שסטארט-אפים בשלב הזה צריכים ממש להתחיל להכין את התשתית לתמוך במולטי-ריג'ן, אבל כן צריך להתחשב בדבר הזה בכל שורת קוד שכותבים, בכל אינטגרציה שעושים, ולזכור לפחות, in the back of their minds, שיכול להיות שיבוא יום ובוא ב ת הם יצטרכו להתחיל לעשות את ההפרדה הזאת. גם להבין את הדרישה הספציפית ממולטי-ריג'ן, האם מעניין אתכם שהדאטה של לקוחות יישמר בריג'ן מסוים, או שהתקשורת תעבור דרך ריג'ן. כי נגיד בשלב של מחקר בכלל, ואם אנחנו רוצים לגשת לזה, ואיך אנחנו רוצים, אנחנו גם התייעצנו עם חברות אחרות, ואיך הן עשו את זה, וכל אחד תלוי בביזנס שלו, יש כאלה שבחרו לשמור רק את הדאטה בריג'ן מסוים, אבל להשאיר את כל השרתים וכל התקשורת עדיין מתבצעת מארצות הברית לריג'ן אירופאי, נגיד, כן? יש כל מיני ארכיטקטורות, צריך להבין מה נכון לכם כחברה. טוב, אנחנו מתקרבים לסיום, אז לפני השאלה האחרונה, אני רק אזכיר למאזינים שלנו שאם יש לכם עוד שאלות לדוד או למיטלמן, אתם מוזמנים לשאול אותם דרך האתר שלנו, startuprorsturptup.com, או דרך קבוצת הפייסבוק. אז שאלה האחרונה שלי, אם יש לכם איזה שהם טיפים למי שניגש עכשיו לתהליך דומה, או רוצה להתחיל ליצור איזושהי תשתית לתהליך כזה? תשקיעו בלתכנן את הפרויקט הזה, לנסות לשבור את זה לכמה שיותר חתיכות עצמאיות, לראות מה תלוי במה, מה אפשר למגבל, להוריד מהשולחן, מה אנחנו לא עושים, כמו ש רנו, שאנחנו לא מתעסקים עם מיגרצה של לקוחות מריג'ן לריג'ן, אפשר להגדיר עוד דברים כאלה שהם חתיכות די גדולות, יסיתו אותנו מהפוקוס, ואפשר לעשות אותם אחרת או בזמן יותר מאוחר, וזה בסדר, כן? זאת אומרת, כי פרויקט גם ככה מאוד גדול, צריך להבין איך אנחנו מגיעים בסוף לדדליין, שהקצבנו לעצמנו ותקשרנו ללקוחות. יש ארגונים שב ת הולכים למהלכים כאלה, מהלך של לפתוח ריג'ן נוסף, יש ב ת הרבה מאוד חברות שעושות עכשיו את הפרויקט הענק הזה שנקרא מעבר לענן, שללהעביר את כל השרתים שיש להם אונד פרמיס ממש במשרדים של חברה, להעביר אותם לקלאוד, ואתה רו ב ת את ההבדל בין חברות שבחרו להתמקד בזה כפרויקט ליבה שלהם, והם שמו על זה כוח אדם וזמן וכסף, וב ת הריצו את הפרויקט הזה בפרק זמן מוגדר, לבין חברות שהגדירו להם את זה בתור איזשהו יעד עליון כזה, ואז לוקח להם שלוש, ארבע, חמש שנים לעשות את זה, ובזמן הזה קורות כל כך הרבה תמורות, שכשאתה כבר בשנה הרביעית של הפרויקט, דברים שעשית בשנה הראשונה כבר לא רלוונטיים, ואז אתה צריך לחזור אליהם עוד פעם. וזה משהו שממשיך וממשיך, ובאיזשהו אופן לא מפסיקים לעבוד עליו. נכון. אחלה. אז המון המון תודה. תודה, מיטלמן. תודה לך. תודה, דוד. תודה רבה. ואני אזכיר שאם יש לכם שאלות לדוד ומיטלמן בנוגע לנושא הזה, או באופן כללי, אתם מוזמנים להיכנס לאתר סטארטאפ פור סטארטאפ נקודה קום, ולשלוח לנו שאלה, או דרך קבוצת הפייסבוק. תודה שהזנתם. ביי. ביי ביי. סטארטאפ פור סטארטאפ

Start up.