Podcasts about apache storm

An airhacks.fm conversation with Francesco Nigro (@forked_franz) about: JCTools as a Java concurrency utility library created by Nitsan Wakart, the history of JCTools and how Cliff Click donated his non-blocking HashMap algorithm to the project, contributions to JCTools including weight-free queue implementations, Apache Storm vs. Apache Kafka, explanation of how JCTools improves upon Java's standard concurrent queues by reducing garbage creation and optimizing memory layout, the difference between linked node implementations in standard Java collections versus array-based implementations in JCTools, detailed explanation of linearizability as a property of concurrent algorithms, the challenges of implementing concurrent data structures that maintain proper ordering guarantees, explanation of lock-free versus wait-free algorithms and their progress guarantees, discussion of the xadd instruction in x86 processors and how it's used in JCTools for atomic operations, the implementation of MessagePassingQueue API in JCTools that provides relaxed guarantees for better performance, comparison between JCTools and other solutions like Disruptor, explanation of how JCTools achieves 400 million operations per second in single-producer single-consumer scenarios, discussion of cooperative algorithms for multi-producer scenarios, the use of padding to avoid false sharing in concurrent data structures, the implementation of code generation in JCTools to create different flavors of queues, the use of Unsafe and AtomicLongFieldUpdater for low-level operations, real-world applications in high-frequency trading and medical data processing, integration of JCTools with quarkus and mutiny frameworks, the importance of proper memory layout for performance Francesco Nigro on twitter: @forked_franz

В 63 выпуске подкаста Javaswag поговорили с Тимофеем Дураковым о Джава сертификации, построении топологии сети поверх Apache Storm и графовых базах данных 00:00 Начало 02:01 Сертификация по Java 14:02 Грейды 28:18 Оркестрация и безопасность в банковских системах 35:04 Управление виртуальными машинами в OpenStack 39:43 Live Migration виртуальных машин 43:08 Архитектура OpenStack 49:17 Решение проблемы SplitBrain с помощью федерации в OpenStack 56:01 Использование оверлейных сетей в OpenStack 56:55 Виртуальные сети и технология VLAN 01:04:48 Apache Storm: система стримпроцессинга 01:10:59 Перестройка маршрутов с помощью Apache Storm 01:11:28 Граф-ориентированные базы данных и их роль в проекте 01:14:20 Использование Neo4j и OrientDB в проекте 01:27:21 Бэкбоны и мэш-сети 01:31:04 Телеметрия и аналитика 01:35:27 Построение маршрутов в графе 01:40:15 Использование time series и графов 01:44:06 Непопулярное мнение 01:58:00 Непопулярные мнение Гость - https://www.linkedin.com/in/timofei-durakov/ Ссылки: https://www.openstack.org/ https://storm.apache.org/ https://tinkerpop.apache.org/gremlin.html https://neo4j.com/ https://orientdb.org/ https://opentsdb.net/ Кип сейф! 🖖

What does it mean to change the economics of software development? Nathan Marz joins the show to share how they reduced the cost of building Mastodon at Twitter-scale by 100X and the 10 years journey to build Rama, a new programming platform that made this feat possible. Nathan is the founder of Red Planet Labs. Prior to RPL, he led engineering for BackType which was acquired by Twitter in 2011. Nathan created the Apache Storm project and wrote the book Big Data: Principles and best practices of scalable realtime data systems. Outside of working, Nathan is a private pilot, loves going to stand-up comedy shows, and is forever trying to teach his dog new tricks.   Show Notes: Nathan's Twitter: https://twitter.com/nathanmarz What is Rama? https://redplanetlabs.com/learn-rama Reducing the cost of building Mastodon at Twitter-scale by 100X: https://blog.redplanetlabs.com/2023/08/15/how-we-reduced-the-cost-of-building-twitter-at-twitter-scale-by-100x/   Stay in touch: ✉️ Subscribe to our newsletter: https://softwaremisadventures.substack.com

Abstract of the talk… Almost all applications have some kind of state. Some data processing apps and databases have huge amounts of state. How do we navigate a cloud-based world of containers where stateless and functions-as-a-service is all the rage? As a long-time architect, designer, and developer of very stateful apps (databases and data processing apps), I'd like to take you on a journey through the modern cloud world and Kubernetes, offering helpful design patterns, considerations, tips, and where things are going. How is Kubernetes shaking up stateful app design? - What kind of state is there, and what are some important characteristics? - Kubernetes, containers, and the stateless paradigm (pushing state into DBs) - Where state lives and the persistence characteristics - Stateless vs serverless - why stateless is not really stateless, but server less really is - Improving on stateless paradigm using local state pattern - Logs and event streaming for reasoning about state and failure recovery - The case for local disks: ML, Databases, etc. - Kubernetes and the Persistent Volume/StatefulSets - Leveraging Kubernetes PVs as a basis for building distributed data systems - Mapping the solution space Bio… Evan has been a distributed systems / data / software engineer for twenty years. He led a team developing FiloDB, an open source (github.com/filodb/FiloDB) distributed time series database that can process a million records per second PER NODE and simultaneously answer a large number of concurrent queries per second. He has architected, developed, and productionized large scale data and telemetry systems at companies including Apple, and loves solving the most challenging technical problems at both large and small scales, from advanced custom data structures to distributed coordination. He is an expert in bleeding edge #jvm #java #scala and #rust performance. Current interests include Rust and columnar compression. He has led the design and implementation of multiple big data platforms based on Apache Storm, Spark, Kafka, Cassandra, and Scala/Akka. He has been an active contributor to the Apache Spark project, and a two-time Datastax Cassandra MVP.

חדש! ביום ראשון 6.12 בשעה 13:00 נקיים ״שאל.י אותי מה שבא לך״ (AMA) עם דני, המרואיין של הפרק בערוץ הדיסקורד הבא https://discord.gg/Nzq4w7hY ההרשמה פשוטה ואין צורך בהתקנה. מוזמנים להצטרף לערוץ ולשאול שאלות (ניתן לשאול בכל עת, דני יהיה שם בשעה הנקובה בלייב)פודקאסט מספר 398 של רברס עם פלטפורמה: כבר הרבה (הרבה) זמן שלא נפגשנו ולא הקלטנו - ובקרוב אנחנו ב-400 . . עוד שניים, אלא אם כן זה בבינארי ואז זה סיפור אחר לגמרי.(אורי) ואנחנו כשבוע לאחר הכנס הוירטואלי הראשון שלנו!(רן) שבוע לאחר הכנס הוירטואלי הראשון - והוידאו כבר יצאו, בניגוד לכנסים אחרים, זה אחד היתרונות של כנסים וירטואליים . . . כמעט ולא פרסמנו את זה פה בפודקאסט כי איכשהו זה יצא, ככה, “אורגני”, לא היה CFP כמו בכל שנה - אבל הכנס התקיים בשבוע שעבר והיה מאוד מוצלח, השתתפו כמה אלפי צופים ומאזינים - והיה כיף.(אורי) וירטואלית, מבחינת השתתפות, יכולנו להגיע לקהל הרבה יותר גדול, כמעט 3,000 איש!(רן) נכוןוהדבר האחרון שלא אמרנו - אנחנו תמיד מקפידים לציין את התאריך, אז היום ה-24 בנובמבר (2020 . . .), והאורח שלנו היום הוא דני מ-Snyk. אמרנו נכון את השם? כן? - מעולה.אז כיף שבאת! יכול להיות שחלק מהמאזינים כבר מכיר - דני דיבר כבר בעבר בכנס שלנו (ב-2018 וב-2019), ואנחנו שמחים לארח שוב - היום נדבר גם על Snyk וגם על כמה ממצאים מעניינים שמצאתם אצלכם.אבל לפני הכל - ספר קצת על עצמך: מניין באת, ואולי גם לאן אתה הולך?(דני) אז דני - אחד ממקימי חברת Snyk, ברקע שלי מגיע מעולמות של מחקר ואבטחת מידע, עוד מהתקופה שלפני הצבא ואח”כ בשירות ב-8200 - ומשם דרך כמה סטארטאפים, שרובם היו סביב מוצרי Security, אבטחת מידע.לפני ההקמה של Snyk ביליתי כ-7 שנים בתפקיד CTO של חברת Gita Technologies - חברת Cyber, סביב מחקר על קריפטוגרפיה ועולמות כאלה.ב-Snyk זה כבר חמש שנים מאז שקמנו - עד לפני מספר חודשים הייתי אחראי על כל תחום ה-Security בחברה, מבחינת המוצר, מבחינת המחקר וכל הצד הזה אז גם ניהלתי את סניף ישראל.לפני שלושה חודשים יצאתי לחופשת לידה - והיום אני חוזר, בפוקוס יותר סביב מחקר וסוג הדברים שגם נדבר עליהם יותר היום.(רן) אז עבור המפתחים שעוד לא יצא להם לפגוש את Snyk - כמה מילים על החברה, מה אתם עושים?(דני) אנחנו חברה שבונה מוצרי Security למפתחיםהתחלנו מעולמות של ה-Security של ה-Open Source, של ספריות קוד פתוח 3rd-party שכולנו צורכים, כשהמוצר הראשון עזר למפתחים לתת איזושהי Visibility על אילו ספריות אנחנו בסוף מושכים לתוך הפרויקט שלנו.בדרך כלל אנחנו מכירים את הספריות המיידיות שאנחנו בוחרים - ה-1st level dependencies - אבל כל ספרייה כזו מושכת עוד, וככה ממשיכים להביא עוד ספריותובסוף יש לנו המון תוכנה שמשכנו לתוך הפרויקט שלנו, והיא הופכת להיות ממש חלק מהאפליקציה שלנו.אז אנחנו בעצם עזרנו ב (א) “להאיר בפנס” את כל העולם הזה ו(ב) בעצם להצביע על חולשות אבטחה ופגיעויות שנמצאות בגרסאות מסויימות - חולשות ידועות בדר”כ, מוכרות, שיש להן את ה-CVE, המזהה של החולשה, שנמצאות באחת הספריות שבסוף נכנסו לתוך פרויקט התוכנה.ודבר אחרון, אחד הדברים המשמעותיים ששונים ב-Snyk לעומת מוצרים אחרים זה שגם עזרנו לתקן את זה - ברמה של Pull Requests שנפתחים מול הפרויקט ה-GitHub-י ממש, למשל כדי לעדכן את הספריה לגרסא לא פגיעה.(אורי) מעניין - אתם בדרך כלל עושים את זה אקטיבית? פרו-אקטיבית? או שהפרויקטים באים אליכם ומבקשים “תסרקו לנו ותגידו לנו מה . . .”(דני) כל מה שאמרתי תקף לפרויקט “שלך”, לא לפרויקט של ה-Open Source.אם אתה למשל בונה פרויקט בNode.js, ומשכת ספרייה בשם left-pad, שמשכה ספרייה בשם אחר כלשהו - אז אני סורק בעצם את הפרוייקט שלך, וכשאני פותח Pull-Request ומתקן לך חולשה בגרסת left-pad 3 ומעדכן לגרסת left-pad 5, כי שם אין חולשה - אז זה קורה בפרויקט שלך.לנו יש את ה-Database שבעצם מכיל את כל החולשות של כל הגרסאות, כשיש המון ב-npm או כל Package manager אחר.(אורי) ויש ממש עבודה צמודה גם עם המפתחים של פרויקטי ה-Open Source?(דני) כן, חד-משמעיתזה משהו שהפך להיות ממש פעילות רחבה - כל חולשה שאנחנו מוצאים (שצוות האנליסטים שלנו מוצא), אנחנו לא רק מוסיפים ל-Database שלנו אלא אנחנו ממש גורמים לכך שתיהיה כמה שיותר מודעות לחולשה הזו, בין היתר גם ע”י להצמיד את המזהה CVE לחולשה.אנחנו היום CVE Numbering Authority -יש לנו מעיין “טווח” של Identifiers שאנחנו יכולים לשייך.אנחנו ממש כותבים את התיאור ועובדים גם עם ה-Maintainer - פונים ל-Maintainer, ולפעמים הם אפילו לא מודעים לכך שיש חולשה, כי מישהו פתח issue על הפרויקט ומישהו שלח להם מייל - לפעמים אין להם זמן לתקן את החולשה . . .אז אנחנו בעצם מדברים עם ה-Maintainers ישירות על מנת לעזור להם לעשות איזשהו Process שמקובל בעולם ה-Security, למשל לשייך את ה-Identifier לחולשה, אבל בין היתר גם ממש לעזור להם לתקן, אם הם צריכים איזשהו Expertise של Security ודברים בסגנון הזה.(רן) וכמו שרמזת, נשמע שאתם נמצאים בעולם ה-Node.js - בגדול אם אני מפתח Node.js אז הבנתי, ואם אני מפתח בטכנולוגיות אחרות אז אתם גם?(דני) לחלוטין - אנחנו תומכים היום בכל השפות - התחלנו מ-Node.js אבל מהר מאוד התרחבנו לכל ה-Ecosystem, אנחנו תומכים בכל השפותבעצם אנחנו מסתכלים על Package Managers - אז זה Maven ו-Gradle ובעצם כל ה-Ecosystems הכי גדולים.אבל מעבר למוצר של ה-3rd-party components יש לנו גם מוצרים אחרים - היום אנחנו עושים את אותו הדבר בעצם לעולם ה-Containers, מסתכלים על ה-Container ואילו רכיבים נמשכים לתוכו ומתריאים שם על חולשות, בעצם אותו הרעיון.ה-Container היום הוא הרחבה של האפליקציה, ה-Docker file יושב ב-Git וזה חלק מאותו העולם - והיום גם נכנסים לעולמות של Infrastructure-as-a-Code לא מזמן רכשנו חברה שהיא בעצם נותנת לנו גם את הכניסה לעולמות של הקוד ה-Proprietary שאתה כותב - ה10-20% של הקוד שאתה כותב - אנחנו מסתכלים גם עליהם, מה שנקרא Static Code Analysisאז אנחנו היום כבר מדברים על ארבעה מוצרים, מה שהופך אותנו לפלטפורמה של ממש כל פתרונות ה-Security שהמפתח צריך.(רן) אז אם אני מפתח, ואני כותב קוד ואולי אני חי באשליה שאני משתמש בספריות קוד פתוח אז הכל בסדר ואני יכול לקרוא את הקוד או שמישהו אחר קרא את הקוד והן Secured- אז כנראה שאני באמת חי באשליה וכדאי שאני אשתמש במוצר כמו Snyk, או מוצר דומה לו, שלפחות יעזור לי לדעת שאני בסדר, שלא שגיתי ושאני לא משתמש ב-Dependency שהוא כבר מסוכן.(אורי) אבל האם יש מצב שבו יש סכנה ב-Dependency, אבל הקוד שלי לא מפעיל אותו?(דני) שאלה מצויינת - זה מצב שקורה לא מעט . . .(אורי) אולי אני לא מכיר את האג’נדה לפני . . .(דני) זה באמת מצב שקורה לא מעט - ויש פה כמה דברים:(א) אם אנחנו מאפשרים לך לתקן את הבעיה בקלות, גם אם היא כרגע לא “בעיה” - אתה משתמש בספריה, שיש בה איזושהי חולשה אבל אתה לא משתמש עכשיו בפונקציונאליות הפגיעה - אז מצד אחד אי אפשר לתקוף את האפליקציה, אבל מצד שני אולי מחר מישהו יתחיל להשתמש בפונקציה הבעייתית, אז יש כאן איזשהו אלמנט שאם זה לא עולה לך הרבה אז אתה רוצה להיפטר ממנו ולהוריד גם את הסיכון הקטן הזה.(אורי) במיוחד אם זה בסה”כ שידרוג גרסא . . .(דני) יש מפתחים שכשאתה אומר להם “זה כולו שדרוג גרסא” יענו לך ש”בטח זה שטויות” - ב-npm למשל זה קורה כל הזמן; ב-Java המפתחים בדר”כ קצת יותר רגישים לשדרוג גרסא, אז זה יכול להיות שונה בין ה-Ecosystems - אבל בגדול . . .(רן) זה גם עניין של גיל . . .(דני) זה גם נכון . . .אז באמת מה שאנחנו שואפים אליו זה שתפתור כמה שיותר בעיות שאתה יכול, כל עוד זה קל - וכשאתה באמת צריך בסוף לבחור ואין לך את כל הזמן שבעולם לתקן ולשדרג את הספריות, אז במצב הזה כן יש לנו כל מיני תוספים שאתה יכול לנסותלמשל אנחנו יכולים גם ממש לנתח את הקוד ולהסתכל ב-Run Time מה נקרא ומה לאלמשל עם היכולות החדשות של ניתוח הקוד הסטטי של הקוד שאתה כותב - זה מאפשר לנו גם לעשות את הההצמדה הזו, של מה שאתה באמת משתמש בו ומה שלא.כל הדברים האלה יכולים לעזור, אבל בהחלט יש פה מעניין “משיכת שמיכה” כזו, של כמה אתה מוכן להשקיע ב”הגיינת ה-Security” שלך - וה-Quality בכלל, לאו דווקא Security, כי זה לא רק חולשות: יש גם באגים ודברים שמותקנים בגרסאות - לעומת כמה סיכון אתה יכול לקחת עם לשדרג דברים ולשנות ולהתעסק בזה.(אורי) לעשות Yak Shaving . . . (רפרנס ל Ren & Stimpy?!)(רן) והמוצר עצמו יושב בדר”כ ,טיפוסית, איפה - ב-CI? ב-IDE?(דני) היום האינטגרציות הן לאורך כל הדרך, החל מה-IDE ועד ל Build ,ל-CI - וחלק מהאלמנטים נמצאים גם ב-Run time.השאיפה היא תמיד לשבת כמה שיותר קרוב וכמה שיותר מוקדם - ושם Source code management כמו GitHub או GitLab אלו האיזורים שהם הכי . . . (רן) אז שתי שאלות, לפני שנמשיך - (1) מאיפה השם? (2) מאיפה הלוגו? מה זה בכלל - שועל? כלב?(דני) זה כלב, דוברמן . . .השם? זה התחיל מזה שמצאנו . . .(רן) רק נגיד איך מאייתים את זה - זה S N Y K (בטקסט זה דווקא עובד יותר טוב . . . )(דני) נכון, זה So Now You Know . . .(אורי) Domain פנוי?(דני) אכן Domain פנוי . . . זה התחיל כמובן, כמו כל סטארטאפ טוב, מ-Domain פנוי(רן) סיפור אמיתי, שמתחיל עם שתי בירות . . .(דני) אז זה Domain של ארבע אותיות, אבל מהר מאוד גילינו שזה גם “So Now You Know”, שזה בדיוק . . . אנחנו התחלנו מהמוצר של להראות לך את הספריות שאתה צורך ושאתה לרוב לא יודע שאתה צורך, וכן - משם זה תפס.הלוגו - ניסינו כמה ניסיונות עם לוגואים וכולם היו כושלים, עד שפגשנו איזשהו מעצב, שאמרנו לו שבגדול אנחנו חברת Security אבל אנחנו כלי למפתחים ואנחנו חברת Security לא קלאסית, לא “סייבר-סייבר” והפחדות וכזה, אלא שאנחנו באים באופן קונסטרוקטיבי וטוב לעזור, ושזה צריך להיות כלב עם רצינות אבל גם חמידות - ואני מקווה שזה יצא טוב . . .אבל באמת - הוא ב One shot הצליח לעשות את הלוגו, ומאז לא . . .(רן) זה דווקא אחלה סלוגן - “חברת Security, אבל באים בטוב”, זה יכול לתפוס . . . (דני) שמע, גם אני מגיע מהעולמות האלה - מהסייבר, וזה קצת כזה . . . מכירה בעולמות האלה נראית הרבה פעמים כמו פרוטקשיין - “יש לך עסק יפה, חבל שמשהו יקרה לו . . .”(אורי) “יש לך פנים יפות, חבל . . .”(דני) אז באמת זה מה שהיה שונה אצלנו כבר מ-Day one בגישה - גם מבחינת המוצר וגם מבחינת ה-DNA של החברה, שבאנו לא בהפחדות.אגב - לא היינו באף כנס Security בשלוש השנים הראשונות של החברה, הלכנו רק לכנסים של מפתחים.(רן) מצויין - אז זה אתה וזה Snyk, ועכשיו בוא נדבר על הנושא של הערב: לפני כמה חודשים . . .(דני) כן - אוגוסט . . . פרסמנו באמצע אוגוסט, אבל הפרויקט התחיל חודש אחד לפני - בעצם מצאנו ספריית תוכנה שהייתה זדונית.אז זה אחד האיומים - דיברנו על חולשות ואבטחת מידע - אבל זה לא האיום היחיד שיש בלמשוך קוד מבחוץ: איום נוסף, שממש רואים איך הוא גדל בשנים האחרונות, הוא בעצם קוד זדוני, שמגיע דרך הספריות האלה.(אורי) דרך ספריות קוד פתוח . . .(דני) ספריות קוד פתוח שמשתמשים בהן - ומעניין לראות גם את הגיוון של איך שזה מגיע - לפעמים זה קוד זדוני שממש נכתב כזדוני, שמו אותו ב-Package Manager ופשוט חיכו שמישהו ישתמש בו, ולפעמים זו השתלטות על Account של מפתח של ספריית קוד מאוד פופולארית, למשל השתלטות על Account ב-GitHub, ואז “שותלים” לשם קודלפעמים אלו טכניקות כמו Typo-squatting - נותנים שם דומה לשם הפופולארי - דוגמא קלאסית זה jQuery.js ב-npm, במקום רק jQuery - או פשוט Typo (ומכאן השם Typo squatting), כשאתה משנה איזשהו תו קטן בשם.ואז הרבה אנשים מתקינים את זה - כמו אגב ההתקפה המקורית שהיא Domain Squatting, שבה אתה במקום לכתוב למשל Google עם שני “O” אתה כותב עם אחת וכו’ומה שמצאנו זו ספריית קוד ב-Package Manager שנקרא CocoaPods - זה SDK של חברת פרסום סינית(רן) ל-iOS(דני) ל-iOS ול-Android, לשתי הסביבותובעצם מה שמצאנו שם זה שה-SDK הזה, שנועד לאפשר למפתחים לעשות מוניטיזציה (Monetization) על הפרסומות באפליקציות שלהם - ועל הדרך הוא עשה עוד מלא מלא דברים רעים . . .בהתחלה, המחקר הראשוני העלה רק ממצאים ב-iOS, ומה שמצאנו שם זה שה-SDK התלבש בעצם על כל התקשורת שהאפליקציה עושה עם ה-Backend - והזליג את זה גם חזרה לחברה סינית . . . זה היה דבר אחד.כדי שלא יזהו את זה, הם השתמשו בכמה טכניקות מאוד מעניינות, שממש מזכירות את עולם ה-Malware הקלאסי - בין היתר ניסו לזהות האם המכשיר פרוץ, ואם הוא פרוץ אז לא פעלו; אם יש Proxy שמאזין לדברים אז הם גם לא הפעילו את הפונקציונאליות הזדונית . . .(רן) רגע . . . למה שלא יפעלו על מכשיר פרוץ? מה הסכנה פה? (דני) בעולמות של iOS ואייפונים, מכשיר פרוץ זה ממש סימן למישהו שיודע מה הוא עושה . . . בהרבה פעמים את צריך לפרוץ למכשיר בכדי בכלל להתחיל לנתח שם את הדברים . . .(רן) … אז כדי לא להתגלות, הם אמרו “אוקיי, בוא לא נתעסק עם החבר’ה שמבינים עניין”?(דני) נכון - וככה הם רצו במשך שנה.אגב, מה שהיה חשוד במה שהם עשו - היו הרבה דברים - אבל קודם כל הם עשו אובפוסקציה (Obfuscation) לכל המידע - למשל כשמסתכלים על Strings של Base 64, שנראים Base 64 encoded, ועושים Base 64 Decoding - וזה פשוט יוצא ג’יבריש . . .ואז רואים ששהם עשו איזשהו variant שלהם של Base 64.אז בעצם מה שמצאנו זה שהיה קודם כל את האלמנט הזה של הזלגת מידע - הם פשוט התלבשו על ה - HTTP Request של האפליקציה ושלחו את זה בחזרה אליהם.אבל - הם גם עשו Attribution Froud - בעולמות של פרסום, כש - User צופה או מקליק על פרסומת, נשלח Event ל-MMP, ה - Mobile Measurement Provider, אני חושב שזה הפירוש . . . רן בטח מכיר מ-Appsflyer(רן) כן . . .אז ה- MMP הוא זה שאחראי בסוף להגיד למי “מגיע” ה - Attribution, וכתוצאה מזה גם התגמול הכספי - ובמקרה הזה החברה פשוט שלחה קליק נוסף, מזויף, ל-MMPהם ידעו על הפעילות כי הם מזליגים את ה-HTTP Request ובעצם את כל ה-Events שקורים באפליקציהאז בעצם ה-Event האורגני הראשון נשלח כרגיל, אבל הם מהצד שלהם שולחים עוד אחד - ואיך שזה עובד זה לפי האחרון ששלח, הוא זה שמקבל את ה-Attribution - וככה הם בעצם עשו גם Fraud מול חברות ה - Advertisement.(רן) “חטפו את הקליק”(דני) “חטפו את הקליק”, ואת זה אנחנו רואים מהדאטה - אבל מעבר לזה גם גנבו את כל המידע, ופה זה גם לא כזה ברור האם הם עשו את זה רק כדי לגנוב את הקליק או שהם עשו עוד דברים עם המידע.(רן) עד כמה זה היה נפוץ ה-SDK הזה?(דני) קודם כל, ה-SDK בסך הכל הותקן בכ-1500 אפליקציות iOS ו-2000 אפליקציות Android - שזה מרגיש אולי קצת מספר לא גבוה, אבל כשמסתכלים על מספר ההורדות, אז מדובר בסך הכל על יותר ממיליארד - 1.2 מיליארד הורדות - בחודש. אלו המספרים.(רן) מתחרים ב-Traffic של Netflix . . .(דני) ממש.כל המשחקים, ממש ברמת שני ה-Vendors הכי גדולים של חברות משחקים, השתמשו ב-SDK הזה.שוב - רוב ה-Publishers ורוב האפליקציות שנפגעו מזה הן אפליקציות משחקים, אבל יש גם כמה אפליקציות Dating ואפליקציות Chat ועוד אפליקציות שונות.אבל באמת משחקים זה העניין - כל המשחקים שאתם מכירים מהטלפונים של הילדים (לא אתם, מה פתאום)(רן) אתה, כמפתח, רוצה עכשיו להתקין איזשהו SDK למוניטיזציה (Monetization), מוצא חברה שעושה את זה - לא תגיד “הלכתי ל GitHub ולקחתי איזשהו Package רנדומלי” - הלכת לחברה, הורדת את ה-SDK שלהם, הרשמי - לך תחשוד שיש שם Malware בתוך כל הסיפור הזה . . .(דני) נכון . . . אז החברה, קוראים לה Mintegral, והיא חברת בת של MobVista - זו חברה ציבורית, נסחרת בהונג-קונג, מדובר בחברות רציניות וגדולות.למרות זאת, הן בחרו להתעסק בדברים האלה - ומה שמעניין זה שכשמסתכלים הסטורית, אז זו לא הפעם הראשונה שמוצאים חברה סינית, או איזושהי חברה אחרת, שעושה כל מיני דברים באיזורים האלה.אבל תמיד היה להם א מה שנקרא Plausible deniability - הם יכלו לבוא ולהגיד “טוב, זו ספריה שלקחנו מבחוץ, וזה בכלל לא אנחנו, וזו בכלל טעות של מפתח, והוא בינתיים גם פוטר אז הכל טוב, סליחה”.פה הקוד נמצא ממש אצלם, הם אפילו לא ממש דאגו להסתיר אותו יותר מדי - ברגע שמצאת אותו זה In your face - ומה שמעניין זה שבעצם כשגילינו את זה - ובהתחלה גילינו את זה רק ב-iOS - הסתכלנו ב-Android ולא מצאנו כלום - לא העמקנו יותר מדי, אבל בהתחלה לא מצאנו כלום - אז פרסמנו.ואז קרו שני דברים מעניינים - (א) קיבלנו טוויט ממישהו שאמר שהוא מסתכל ב-Android וגם רואה שם דברים מוזרים, אז התחלנו גם להסתכל שם, ומצאנו שבכל זאת ב-Android יש איזור חבוי ששם לא הסתכלנו קודם, ומה שהם עושים שם זה מנסים לתפוס את ה-Downloads במכשיר - וספציפית Downloads שמגיעים מ-Google - וכשחושבים על זה מבינים שאלו Downloads שמגיעים מ-Google Play, ושככה הם מנסים לתפוס הורדות של משחקים ושוב - לדווח את זה על עצמם וכנראה, פה אנחנו לא יכולנו לוודא ולסגור את המעגל השלם ולראות שהם גם עושים את ה-Fraud.אבל ב-Downloads האלה הם, בטעות או שלא, תפסו גם Downloads של Google Spreadsheets ו-Google Drive ו-Google Docs וכאלה, אז בעצם אם אני שולח היום הודעת WhatsApp או email עם איזה לינק ל-Google Drive או ל-Google Docs - ואיך שזה עובד ב-Android, בגלל שזה גם גלובאלי, האינטנטים (Intents) נשלחים במכשיר, וכל אפליקציה, במקרה הזה ה-SDK, יכול היה להירשם לאינטנטים של הורדות גלובאלית - מספיק שיש לי אפליקציה אחת שהתקנתי ככה לילד שלי (נניח) ולא פתחתי כבר תקופה (נניח) - היא תתפוס את כל ההורדות Google Docs שלי מהמכשיר, זה - בשונה מ-iOS, ששם זה רק בקונטקסט של האפליקציה, כלומר - “רק” ה-Traffic של האפליקציה באמת זלג. עדיין חמור, אבל שונה מ-Google.(ב) דבר נוסף שקרה זה שהחברה, כדי כנראה להציל את ה-Reputation שלהם, שחררו את הקוד כ-Open Source, את ה-SDK - ואמרו ש”אנחנו בעד Transparency, ואנחנו מבקשים מכל התעשייה שככה תעשה את זה” . . .גם כאן(רן) זה היה לפני הגילוי או אחרי?(דני) אחרי . . . (אורי) וכאילו - “אנחנו משחררים אותו כ-Open Source - כדי שתורידו יותר” . . .(דני) כן - תורידו יותר . . אגב, הם לא התייחסו לעובדה שאת ה-Fraud הם עשו ב-Backend, אז זה שהם משחררים את הקוד כ-Open Source זה לא בדיוק פותח את כל הקלפים, אבל עדיין - זה היה צעד מעניין. מה שאנחנו עשינו . . .(רן) רגע, הם שחררו ממש את הגרסא שהכילה את הקוד הזדוני?(דני) לא, הם ניקו, הוציאו גרסא חדשה - ומה שאתה חושב עליו, זה בדיוק מה שעשינו: אמרנו “רגע, בואו נשווה את מה שהם שיחררו, ונשווה את הגרסא החדשה אל מול הישנה”.ראינו שהם באמת העיפו את כל מה שהצבענו עליו - את כל הדברים הרעים.אגב - הם גם פרסמו פוסט שאמר שהם גם ככה תכננו להוריד את הטכנולוגיה הזאת, ושבגדול - “אתם לא מבינים את הטכנולוגיה המדהימה הזאת, כל זה נועד לפרסומות מדהימות ו-Monetization מדהים ובגלל זה אנחנו המובילים בתחום” וכו’ . . .בכל מקרה - הסתכלנו, והם הורידו באמת את כל הפונקציונאליות שאמרנו שהיא זדונית - אבל היה שם עוד איזשהו קטע קוד, שלא היכרנו, וגם הוא ירד . . . שזה באותה נקודה פשוט זעק ”בואו נסתכל על הקוד הזה” . . .(רן) בטח פיספסנו פה משהו . . .(דני) לחלוטין פיספסנו - כי הקוד הזה בעצם היה Backdoor - דלת אחורית להרצת כל קוד על המכשיר, דרך פרסומת . . . צריך רגע לפרק את זה - קודם כל, Mintegral יכלו . . . נניח שאני פיתחתי אפקליציה והכנסתי את ה-SDK הזה לתוך המשחק שלי, עם הצגת פרסומות, הכל טוב ויפה.האפליקציה עברה Review של Apple, ולא אמור להיות שם קוד דינאמי - Apple “חתמו” על הקוד שסיפקתי להם, כולל ה-SDK הזדוני הזה, שלא הסתכלתי עליו בתור מפתח אבל זה המצב.עכשיו, Mintegral יכולים לשלוח קוד JavaScript ככה “מהונדס” ,שבסופו של דבר יריץ קוד Native-י כרצונם על המכשיראנחנו הדגמנו קוד פשוט שגונב את הClippboard, רק לשם המחשה - אבל זה יכול להיות כל קוד שהם רוצים.אבל יותר חמור מזה - כל Publisher וכל מפרסם . . . אנחנו יכולים עכשיו ללכת ולקנות פרסומות, לעשות Bid אפילו על פרופיל מסויים, למשל אנשים בגיל מסויים שגרים באיזור מסויים בעולם, וממש לדלוור (Deliver) איזשהו Exploit שממש יריץ קוד Native על המכשיר . . .(רן) זאת אומרת שלא רק יראו את ה-Image ואת ה-Creative - אלא גם תוכל להזריק לשם קוד, ובקוד הזה תוכל לעשות מה שאתה רוצה.(דני) נכון . . .(אורי) זה מה שקרה לנו בפריצה של . . .(רן) אתה רואה - זו חשיבה על Scale! אנחנו לא מספיק יצרתיים, אז ניתן לצד השלישי להיות יותר יצירתי!(דני) כן - זה ממש Code Execution as a Service . . . ממש.כשמסתכלים על הכמויות של האפליקציות ועל כמה שה-SDK הזה פופלארי, ובסופו של דבר מה הוא פתח באפליקציות האלה - זה די מטורף.(רן) אז מה - בנאדם קם בבוקר, שותה קפה ואומר - “אוקיי, עכשיו אני הולך למצוא Exploit”? כאילו - איך זה קורה?(דני) אז קודם כל, בצוות המחקר אנחנו עשים את זה כבר שנים, כלומר - אנחנו חוקרים את העולמות של ה-Open Source ואנחנו מחפשים חולשותוכשאנחנו מחפשים חולשות, אנחנו לא מחפשים במוצר מסויים, לא קמים בבוקר ואומרים “בוא נחפש חולשה ב - Apache Storm” ככה, כי זה מעניין אותנו, אלא בדרך כלל מסתכלים על ממש חיפוש ב-Scale.האנלוגיה שאני אוהב לתת היא שאנחנו “זורקים רשת אל הים” והרשת היא כזו שאנחנו בונים אותה ככה שתתפוש דברים מסויימים. ובמקרה הזה זרקנו את הרשת לים של CocoaPods, על כל הספריות שיש ב - CocoaPods, וחיפשנו כל דבר שעושה Method swizzlingאז Method swizzling זה ביטוי מעולם ה-iOS ל - Function Hooking, ל-Interception, ל- Instrumentation של פונקציה - כל אפליקציה שבאה “ומתלבשת” על פונקציית מערכת הפעלה ומנסה להיות “באמצע”, בין האפליקציה שקוראת לה לבין מערכת ההפעלה.וזה משהו שקודם כל לא אמור לקרות הרבה - זה באמת קורה לא מעט בעולם הפרסום, לפעמים SDK-ים מנסים לראות אם האוריינציה של המכשיר היא ככה או ככה ולהציג ולהתאים את הדברים, אבל בגדול זה משהו די חריג - ובמקרה הזה זה מה שעשה ה-SDK.וכשאנחנו “מושכים את הרשת מהים”, אז יש שם כל מיני ג’אנק ובקבוקי פלסטיק ודברים מוזרים - אבל לפעמים גם יש דגים, שאנחנו מסתכלים עליהם - במקרה הזה דג זהב ממש.אם אנחנו מסתכלים על ההיסטוריה אז ממש בצורה דומה מצאנו חולשות - אגב ההרצאה שהצגנו ברברסים על Zip Slip, איזושהי חולשה בת 30 שנה שעד היום קיימת בעולם ה-Java, שפשוט לא מצליחים להיפטר ממנה, וגם אז באותה צורה עשינו חיפוש על כל GitHub ומצאנו אלפי חולשות(רן) טוב, נו - מפתחי Java כבר 30 שנה לא משדרגים גרסא, לך תיפטר מזה . . .(רן) אוקיי - אז הרגשתם שיש פה משהו, ראיתם הרבה מופעים כאלו של Method swizzling, אם הצלחתי להגיד את זה נכון (לכתוב יותר קל) - ואז מה? אמרתם “בואו נתפקס”, ועכשיו איך בודקים? מה אתה מוצא שם? אתה מתחיל לקרוא קוד, לעשות Reverse Engineering לקוד? מתחילים להריץ? מה?(דני) שאלה מעולה - אז זה לא היה בהרבה מופעים, ממש הרצנו את זה שוב כדי לראות אם מישהו . . . אם Mintegral, כל השינויים שהם עשו עדיין נתפסים אצלנו - והם לא נתפסו וזה אומר שהם באמת הם ניקו.בכל מקרה, היו עשרות תוצאות, שמהר מאוד אנחנו עברנו על רובן - וזה הספציפי באמת התחיל להרגיש כמו משהו חריג.בדיוק סיפרתי על ה - Base 64 המוזר שהם קצת שינו אותובסוף אפילו לא עשינו Reverse Engineering ל - Base 64, פשוט השתמשנו בפונקציה שלהם לזה, היינו עצלנים . . .אבל לשאלתך - באמת הספרייה הזו היא Closed Source - אין לה Open Sourceהם פתחו אותה ל - Open source אחר כך, אבל זה לא היה ככה קודםזו באמת פעם ראשונה ב-Snyk שלי יצא ממש לעשות Reverse Engineering, כי בדר”כ זה Reverse Engineering לקוד, לא יודע אם זה נחשב כ- Reverse Engineering, ואלו דווקא עולמות שעסקתי בהם הרבה לפני.וכן - זה ממש להסתכל על האפליקציה, על קוד ה - iOS ו . . .(רן) זאת אומרת שעשיתם לו דה-קומפילציה (De-compilation) . . .(דני) כן, אז דה-קומפילציה זה אפילו ה - Luxury . . . עושים Diss-Assembly מסתכלים על קוד Assembly, והיום יש De-compliers ממש טובים, שלא מחזירים את זה לקוד מקור אבל בקירוב די . . .(רן) לא צריך לזכור בעל פה את המספרים של הריגיסטרים (Registers) . . .(דני) לא . . . אז עלינו לא מעט דברים מעניינים - כמו שאמרתי, את חלקם לא מצאנו; מצאנו כל מיני חריגות, אבל למשל את ה-Backdoor הזה לא מצאנו, מצאנו רק כעשינו . . .(רן) כמה זמן לוקח מחקר כזה? כמה זמן לקח?(דני) אגב, צריך לציין שגם במהלך המחקר התחלנו להתחבר עם חברות, עבדנו גם עם Appsflyer למשל.צד הדאטה למשל - לא היה לנו Visibility אליו: כל הקליקים, מה קורה בצד ה-MMP? -על כל זה עבדנו עם שחקנים בתעשייה.אבל המחקר שלנו, אם אני מזקק את זה לנטו-עבודה, זה ממש עניין של אולי שבוע.מהרגע שהתחלנו את הפרויקט עד הרגע שפרסמנו לקח חודש - אבל אז, ככה, באו הגלגולים הנוספים של הפרויקט.(אורי) זה כי אתם לפעמים מפרסמים עוד לפני שאתם מבינים את כל התמונה?(דני) לא - אני אישית משתדל לכתוב . . . כשאנחנו מדברים על פרסום אז זה בדרך כלל על לכתוב בלוג-פוסט, וכשזה משהו די גדול אז עושים קצת PR ומדברים עם Outlets וכזה.במקרה הזה, בדרך כלל אנחנו שואפים לכתוב משהו כשאנחנו מרגישים בטוחים לגבי כל הפרטים - אז גם עשינו את זה פה.לצורך העניין, לא שינינו שום דבר ממה שפרסמנו, אז כן - השאיפה היא לתת כמה שיותר מידע מהפרסום הראשון.(רן) בדרך כלל, לפחות כשמדובר לא בקוד זדוני אלא מדובר בבאגים נגיד - הדוגמא הקלאסית של Stack Overflow וכו’ - סליחה - Buffer overflow - אז יש את העניין הזה של “גילוי אחראי”, נכון? אתה לא הולך וישר מפרסם, אלא קודם כל מגיע ליצרן של הקוד ונותן לו איזשהו Heads-up וזמן לתקן את זה - ורק אחרי שהוא הבטיח שהכל מתוקן ויש כבר גרסא חדשה, רק אז אתה מפרסם.פה המקרה שונה - פה, מדובר על יצרן זדוני.אז איך פועלים? מה הפרוטוקול במקרה כזה?(דני) אז באמת ה - Responsible disclosure לא תקף פה . . הוא בעצם תקף, אבל לא על השחקן עצמו, כלומר - לא באנו בשום שלב לחברה . . . זה מעניין, אגב - הם פנו אלינו אחרי שפרסמנו, והציעו לנו . . רצו לקנות את Snyk בתמורה לכך שנעזור להם לטפל באירוע הזה . . .כלומר - לקנות את המוצר של Snyk, לא את החברה.אבל כן ה - Responsible disclosure תקף לשחקניות הגדולות - לGoogle ול-Apple - כי הן בעצם מחזיקות ב-Marketplace, ולהן יש גם את האפשרות לתקן - זה שאנחנו נותנים להן Heads-up - יש להן מה לעשות, וזה מה שעשינו.זה מעניין - ל-Apple בהתחלה, כנראה שהדבר הזה לא בא להם כל כך בטוב, כי אנחנו קצת ה - Bad news Messenger, כאילו . . .(אורי) אתם חושפים גם חולשה שלהם.(דני) זה בדיוק בא - איכשהו בלי שתזמנו את זה ככה - אבל זה בדיוק בא בזמן שהיה את הבלגן עם Epic Games והייתה הרבה ביקורת על כל מה שקורה שם עם ה-30% . . .מלא שיח על זה - ופתאום אנחנו באים ואומרים: “טוב, חבר’ה, כאילו יש פה כמה מאות אפליקציות מה-Top-500 שיש בהן דברים רעים ממש” . . .(אורי) כמה מאות מה-Top-500 . . .(דני) כן, קרוב ל-200 מה-Top-500, זה אחוז מאוד גבוהבכל מקרה - הם בהתחלה ניסו . . . לא היו פעילים מדי, אפילו לא הודיעו למפתחי האפליקציות - אז בחרנו לעשות את זה בעצמנו.מן הסתם זה משהו שיותר קל ל-Apple לעשות, יש להם את האי-מיילים של כולם וכו’.אבל מה שמעניין זה של-Google דווקא הייתה את התגובה ההפוכה - הם פשוט קפצו לשיחה, הביאו את כל האנשים הרלוונטיים - חוקרים ואנשי Legal וכו’, וגם אמרו לנו שהם מכירים את . . לא את המקרה הזה, אבל את ההיסטוריה עם השחקניות האלה, וממש הגיבו מהר.כן צריך לציין שברגע שמצאנו את ה-Backdoor, אז בעצם ל-Apple זה כבר . . . זה לא היה רק עצם בגרון, הם ממש היו צריכים לפעול, כי זה משהו שהוא . . . מקודם הם אמרו ש”זו אחריות של המפתחים”, בגדול הם שמו את האחריות על המפתחים - “הם בחרו את ה-SDK, הם שמו את זה באפליקציה - אז שיתמודדו עם זה”.אבל כשיש ממש המון משתמשים שחשופים עכשיו להרצת קוד, אז פה הם כבר נאלצו לשלוח הוראות . . .(רן) זו “פצצה מתקתקת”, שגם אם הם יכולים איכשהו להכחיש שזו אשמתם, זה עדיין הולך לפגוע להם ב-PR(אורי) זה מעניין, כי גם Apple לוקחת Stand בעולם של Privacy - ואם יש להם Backdoor כזה . . .(דני) נכון - ועדיין אני מרגיש ש . . כלומר, בסוף הם פעלו ואז שלחו לכל המפתחים את הבקשה להוריד את ה-SDK הבעייתי, אבל עדיין - התגובה שלהם, לפחות הראשונית, הייתה די חלשההם בעצם בחרו ככה לשים את האחריות על המפתחים, שזה . . . יש בזה משהו חשוב, במסר - אבל הם עצמם יכלו לפתור את הבעיה בעצמם מיד, ולא לחכות עד שמפתחים יתחילו . . . עד שאנחנו (Snyk) נפנה אליהם קודם כל, וזה לוקח המון זמן, ולהסביר להם מה קורה וכו’אז במקרה הזה באמת ה - Responsible disclosure היה לדבר עם החברות הגדולות.אגב - כן פנינו לעשרת ה-Publishers הכי גדולים בצורה ישירה, פשוט כי הם ממש . . .זה כזה Pareto Distribution - עשרה מה-Publishers שולטים ב-90% מהשוק, אז זה כיסה לנו ממש את רוב ה . . .(רן) איך אתה יודע מי הם עשרת ה-Publishers הגדולים?(דני) אז יש דאטה . . .(רן) אה - הכוונה באופן כללי, לא לאותו ה-SDK, עשרת ה-Publishers הגדולים בעולם?(דני) על זה ספציפית יש גם דאטה על SDK - שירותים שנותנים ממש סטטיסטיקות . . .Apple ו-Google לא מפרסמים את זה בעצמם, אבל יש שירותים שנותנים את המספרים האלה, כולל גם איזה SDK נמצא באיזו אפליקציה.(אוקי) כמו . . . טוב, זה יותר ל-Open Source בכלל אבל WhiteSource וכאלה?(דני) WhiteSource היא מתחרה של Snyk אז . . .(אורי) WhiteSource נכנסת לעולם של Security ספציפית?(דני) בעצם היא התחילה מעולמות של Legal, אבל איפשהו כשאנחנו קמנו, אז הם עשו Shift, ואני חושב שהיום הם רואים את עצמם כחברת Security ומשווקים את עצמם כחברת Security - אגב, ככה עשו גם כל השחקניות האחרות, למשל BlackDuck, שהתחילה מעולמות ה-Legal וה-Complience והפכה לחברת Security, ונמכרה אח”כ כחברת Security.(רן) טוב, אז קודם כל זה היה סיפור מתח בשלוש מערכות . . .(אורי) חשבתי שתביא לנו משהו איראני כזה . . .(דני) כן מדובר בחברה סינית . . .(אורי) תמר רביניאן עובדת אצלכם?(רן) כן . . . אז יש עוד, ככה, אנקדוטות או חומרים עסיסיים שלא פורסמו שאתה יכול לחלוק עם המאזינים שלנו בקשר לסיפור הזה?(דני) אני חושב שבאמת העניין הזה של זה שפנה אלינו בכיר מהחברה . . . הוא כתב מייל מאוד נחמד שבו הוא . . .קודם כל - זאת הייתה הפעם הראשונה ששמענו משהו מהחברה, הוא שלח מייל “אישי”, מייל ארוך, שבו הוא אומר “תודה על העבודה שלכם, מאוד חשוב לנו לתקן את הדברים, ואנחנו עובדים על זה” - ומבקש מאיתנו לעזור להם בזה- בתמורה לזה שכל הקבוצה - לא רק החברה, זו קבוצה גדולה - שתשמח לאמץ את מוצרי Snyk . . .אנחנו סירבנו להצעה אז - אבל מה שגילינו ממש אחרי שבוע, בשיחות עם אחד ה-Publishers, זה שהם ממשיכים ומספרים את הסיפור של “Snyk בעצם כן עוזרת להם”, שהם כבר משתפים איתנו פעולה ושהכל מאחוריהם.אז כן - זה קצת העולם שאנחנו . . .(רן) תבדוק אם הלוגו שלך נמצא שם, באתר שלהם . . .(אורי) סוג של אמינות סינית?(רן) חבל, אם זה לא היה קורונה עכשיו היו שולחים לך כרטיס לסין, לעשות לך קצת Good time ושתשכח מכל הסיפור הזה . . .טוב, אחלה - סיפור מאוד מרתק, ודרך אגב - אני מניח שעד היום יש אפליקציות שרצות עם הפגיעות הזאת, זה לא נעלם ביום . . .(דני) נכון . . .(רן) איך עוקבים אחרי דבר כזה? עכשיו זה כבר תפקיד של Apple?(דני) אני חושב ש-Apple במקרה הזה … יש פה שאלה באמת של אפליקציות ומכשירים שפשוט לא מעדכנים את האפליקציות, אז גם אם יש גרסא חדשה, ומישהו פשוט לא דואג לעדכן . . .יהיה מעניין לראות האם Apple יחליטו פשוט להוריד את זה - יש להם את היכולת להוריד את האפליקציות האלה, גם Remotely, אבל הם עוד לא עשו את זה.אני חושב שאחד הדברים המעניינים לראות מכל האירוע הזה זה באמת העלאת המודעות לתופעות האלה בקהילת ה-Mobile, כי היא קצת שונה מה-Ecosystems האחרים.כשמסתכלים באמת על . . . יש פה שני (סוגים של) קורבנות באירוע הזה - יש את המפתחים עצמם, שפשוט משכו איזשהו SDK ורצו להרוויח על האפליקציה שלהם - ובעצם הכניסו משהו שהם לא ידעו . . . אגב, שה-Terms of Service שם כמובן שלא אמר להם את כל מה שהם עושים, ה-SDK, ו . . .(רן) למה, אתה יודע סינית?(דני) כן, אז היה להם . . .(אורי) זה סינית בשבילו . . . (דני) הם, אגב, עידכנו מיד אחרי הפרסום, יום אחרי הפרסום, את כל ה-Terms of Service שלהם, Heavy edits - והוסיפו את כל מה שהיה חסר שם, כולל HTTP Request interception ודברים כאלה . . .(רן) אז תבדוק את ה-Diff-ים, אולי תגלה עוד משהו . . .(דני) אז באמת אלו המפתחים - והקבוצה השנייה הם בעצם הצרכנים - אנחנו, אלו שיש להם ומי שהתקין את כל האפליקציות האלה.ואני חושב שממש היה יפה לראות, לפחות בקבוצה הראשונה, איך המודעות שם עולה, ואיך מבחינת השיח והעניין להכיר בכלל בבעיה הזאת . . . זה, אני חושב, היה הדבר הכי משמעותי שיצא מהפרסום, כי לצערי עדיין יהיו חברות שיעשו את הדברים הרעים האלה ועדיין יהיו לנו את העולמות האלה של ריגול - אבל אני ממש שמח לראות את המודעות עולה לבעיות האלה.(אורי) אז רגע, יש לי שאלה - היום, כל Vulnerability, פגיעות . . .(דני) חולשה(אורי) . . . חולשה שאתם מגלים - אתם מפרסמים בבלוג-פוסט?(דני) לא, ממש לא . . .(אורי) רק את המעניינות?(דני) כן, אני חושב . . כפי שאמרתי, אנחנו מסתכלים על דברים ב-Scaleלמשל, אם אנחנו מוצאים חולשה שנמצאת באלפי פרויקטים, אני חושב שזה סיפור מעניין, וזה סיפור מעניין לא רק עבור ה-Publicity שלנו - זה סיפור מעניין באמת למודעות בקרב הקהילה.אז אותה דוגמא שקראנו לה Zip Slip, אותה חולשה של 30 שנה, ממש חולשה עתיקהאגב - כזו שאני יכול להסביר במשפט וכל המאזינים יבינואותה חולשה עדיין נמצאת . . .כשמצאנו אותה אז מצאנו אותה באלפי פרוייקטי Open Source, ממש פרויקטים של אלפי Stars ב-GitHub, וזו תופעה שאני חושב שהיא מעניינת לדווח עליה.אבל אנחנו כל יום מוצאים חולשות, וזה מתווסף ל-Database שלנו שם באתר, אבל לא בלוג-פוסט . . .(אורי) אמרת “ה-Database שלנו באתר” - זה נגיש? אתה יכול להכניס מספר גרסא של SDK שאתה משתמש בו, או Open Source . . .?(דני) חד משמעית כן - זה קליק שאתה יכול לעשות באתרקודם כל - המוצר שלנו הוא חינמי ל-Open Source, והוא גם חינמי עד Usage מסוייםאז כן - אתה יכול גם פשוט לסרוק את הפרויקט שלך בפקודה אחת: npm install snyk ו - snyk test וזהו.(רן) מעולה - תודה דני, אחלה סיפור, נשמע כמו מוצר באמת מעניין לכל מי שאכפת לו מ-Security .תודה שבאת, היה מאוד מעניין. תודה.הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

This conversation covers: The value that Forter provides, and the types of companies that they work with. Iftah also explains what makes Forter so unique.  The underlying technology that Forter is using, and how they quickly process hundreds of complex backend workflows. Iftah also talks about some of the tools that they are using, including AWS and Apache Storm. How Forter approaches the cloud, and how it's helping them concentrate on the business of detecting fraud. In addition, talks about the types of cloud services that Forter is using. Forter's ability to scale — including how they responded to increased customer demand during COVID-19. Forter's biggest technical challenge that they are currently working through. Iftah's thoughts on the security- speed tradeoff. Links: Forter Forter on Twitter Connect with Iftah on LinkedIn Iftah's email: iftah@forter.com Transcript:Emily: Hi everyone. I'm Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product's value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn't talk about them. Instead, we talk a lot about technical reasons. I'm hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you'll join me.Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I'm chatting with Iftah Gideoni. Iftah is the CTO at Forter. Iftah, first of all, thank you so much for joining me.Iftah: Very glad to be here.Emily: So, I wanted to have you start by introducing yourself and what you do, and then also what Forter does.Iftah: Hi, I'm Iftah. I'm a physicist of education, and in the last 20 years, a CTO of several companies, mostly [00:01:11 unintelligible] governmental companies, and companies that I founded. In the last six and a half years, I'm with Forter. And what Forter started to do from 2014 is to provide what was, at the time, very bold vision of fully automated, fully cloud-based decisions about whether to allow or decline e-commerce transactions. Now, from that time we actually implemented and executed that, we decide very many more than 3 million transactions every day, today, all in real-time without a human in the loop. And we expanded into being a fully-fledged trust engine that gives decisions not only about transactions, but about many other points of interaction with the consumer, for example, in their login time, and in other points where trust decision is needed.Emily: So, just because I think it might be interesting to listeners, give me some examples of, like, when somebody might interact with Forter or have some sort of action approved or declined by Forter.Iftah: Right. The prime customers of Forter are the big e-commerce enterprises. Think about the [00:02:42 Sephoras], the Nordstroms, the Home Depots, and this kind of companies. And whenever you press the button of requesting to committing to the purchase and you see this small things rounding on the screen, then it is sent to Forter and Forter within, usually, half a second returns a decision. Now, Forter does not act as an additional data point, or input, or score into some system of the merchant. It actually answer whether to approve or decline the transaction. In very many—and most of the revenue of Forter comes from a covered transaction that, if this transaction was fraud, it's on Forter. Forter will guarantee it. And we were pioneering this model to putting our mouth where our money is.Emily: Tell me just a little bit about why this is so difficult. What makes what Forter does unique?Iftah: What Forter does is unique because it tells the human story, and takes it all the way to the decision itself. For example, it's very easy to approve the fourth transaction of a person that is sitting at home, browsing from home, making the purchase on the same desktop they made at previous times, and sending the shipment to the same home. That's very easy. But we want to be able to approve the traveler, the person that is sending a gift to a third party, or a person that is sending a gift to another state while not browsing from home and not from his common device. We want to be able to approve those transactions that are checking out as guests from a new device and that's the first time this person ever appeared on our radar. And the ability to do that and to take the calculated risks and to look at the behavior, the cyber clues, and still be able to tell that this is indeed a new person and not someone that visited before and is trying now to hide. That's what makes what we do very difficult and complex.Emily: So, tell me a bit about the technology story. What technology do you use to accomplish this, and how does it work? What does your stack look like?Iftah: When I came to—from 2014, I looked at the system and what is actually needed in order to cater to such a complex story? And I thought to myself—and we'll talk about maybe a bit later about how all this is excellently suited for the Cloud, but what I found that throughput and big data is not the problem. First, it's more or less solved, but it is the e-commerce business; it's not Facebook scale throughput. And on the other hand, it's not hardcore real-time, right? We're talking about tens of milliseconds, not the microseconds domain. What is extreme about what we do is the complexity of the flow. We have hundreds of processes that are needed to be ran within that half a second in order to test, and check, and infer, and decide on many aspects of this transaction and of this person. So, first, we started from Amazon Web Services, and we started with, actually, Apache Storm. And why we decided that because we wanted to have something that enables first, a lot of parallelism—doing many things in parallel—with smart joins, that is with processes that takes information from other processes that executed in parallel, and can decide whether what they have so far from these processes is enough. Because we are very high availability, we didn't lose more than 10 seconds straight in the last four years. We are very high availability, but a lot of our sub-processes are not. So, you need such a machine that will be able to infer about whether the information at hand is good enough and to move forward and still give, after half a second, the answer. We also wanted to have within this high availability system, we wanted to have the domain experts, the analysts, and the fraud researchers, we wanted to give them a very direct access to the code and each insight that they get, in close to real-time, maybe in 10 or 15 minutes from the time that they understood that there is a new wave of attacks or a new fraudster in action in a particular store or across stores. We wanted all these insights to be manifested in the system within 10 or 15 minutes without these people needing any engineering in order to do that. So, we created incubators within these Apache Storm processes that enable them to write, in Python, their wisdom into the system without being technologists or engineers. So, this was the basic. Then we went on to see how we do the best similarity in the world. That is the understanding of whether we already saw a person, even if this person exhibits a new persona and is trying to hide. That is, they didn't give us the same phone number or email, it's not the same cookie, or the same IP, or the same credit card, and they don't use the same account, and we still want to know that this is the same person. This is a big part of what makes us efficient in exterminated fraud rings and enabling us to increase the cost of doing business for the sophisticated fraudsters. These are the prime building blocks and the last very important building block is the way we represent the world. Usually and traditionally, world was represented by the transaction. The transaction was the building block. But we represent the world as people. We know more than 700 million people and of their interactions and their browsing, in many stores. These 700 million people include most of the people that interact online in the US. And the same is for the IPs, and the addresses, and the devices in the US. The US is where our coverage is best. And all what we do revolves around the person because we believe that the person is what is actually persisting in the world with persistence reputation. That is a person is a legitimate person, they will stay legitimate. Usually, they won't flip on us. And if they are fraudsters, they will stay fraudsters. Not the same for IPs, for addresses, and for all other entities, you can think of. I hope this, it answered to a degree what you are asking about.Emily: Yeah. And I'm going to go into some more questions, but it's it's really interesting that what you're combining is both this sophisticated technology as well as sort of an understanding of—almost like a law enforcement understanding of how fraud works. Or how—like, a anthropological investigation of how fraud rings work.Iftah: Yes. And we found that there is a lot of—and I think our main asset is the ability to combine what analysts understand about the spoofing of the device, and how you detect that it's not really a mobile phone, it's an emulator on a desktop? And how can you tell that someone is trying to mess with an application that you protect? And what are the ways in which you can approve a transaction that looks very fishy to begin with, but it has some hints of legitimacy. How we combine this with a very robust, high availability and very secure machine because it needs to be secure. We touch a lot of personal, identifiable information in our regular course of business, and we need the system to be ultra-secure while it is on the Cloud. And our booklet, actually, of 101, how to secure your startup [00:12:45 unintelligible] usage on the Cloud was actually trending number one on GitHub for months in 2017 when we issued it. [laughs].Emily: That's excellent. Well, let me ask some more technology-specific questions. One is, just—you sort of alluded to this, but how is the Cloud important—and in fact, I believe you said critical to your business? Would Forter even be possible without the Cloud?Iftah: Forter would be possible with an on-prem cloud, right, because when we say Cloud, it could be Amazon, or Azure, or GCP, but it also could be in a cloud that we built somewhere. This would be possible. We didn't go there, and most of e-commerce companies would not go there, and we'll dive into this in a minute why it's not wise to go there. But Forter is heavily relying on knowledge of the people, regardless of which merchant they visited. So, if we see a person in the Forter, it could be their first time Nordstrom sees them, but we already know them, and we can project the reputation of the person from previous interactions with other customers of ours. We don't share any customer data, of course, with any of our customers, but we can share parts of reputation, especially for people where this is the first time they visited a particular merchant. Now, this is a prime reason why it cannot be on-prem of the customer. And several customer—and I will not mention name, but huge conglomerates of carmakers, actually, asked us to be on their Cloud. And we refused and we let go of the business because that's not how we do, and the best value for them would be to share the data. And so far, all the customers that we have so far actually agreed to share the usage of reputation with all the rest of the network of customers that we have. This is something that they cannot do in-house, and this is something, per your question, that cannot be done if we are not in the Cloud, but on their premises farm.Emily: And so are you operating in all public clouds, or do you have your main technology running in one?Iftah: We have our technology running in a few regions of AWS. And we are now deploying a few regions in Azure, too.Emily: And so it doesn't matter if your customer, which public cloud. So, if you have a customer that uses GCP, doesn't matter, right?Iftah: It doesn't matter. And most of them are [00:16:01 naturally] aware where we are. Bear in mind that we are serving companies—I mentioned the names—which are inherently not technology companies. And it doesn't matter where they sit; we are a full SaaS company for them. They send us the request, the transaction, and we give them a decision within this half a second, and that's the core of the business. Doesn't matter for them. As [00:16:36 unintelligible] to say earlier, the concept of the public cloud and using other people's cloud infrastructure, be it GCP, or Azure, or AWS or others, is very suited for the e-commerce because of these two prime characteristics of the e-commerce: first, you don't need it to be very hard real-time, you're talking about tens of milliseconds, and giving answers in hundreds of milliseconds, ultimately; and second, unlike the Twitters, and the WhatsApps, and the Facebooks, and the Googles, the e-commerce is not big data in the sense that every transaction of e-commerce is, on average, a very high monetization. So, the ultra cost of using public cloud is definitely worth it for the e-commerce entity, comparing to creating your own farm. It is good for their flexibility and it's good for the focus and attention on their core business, where if you run your own farm, you are into a lot of domains of expertise which are far away from selling whatever you sell.Emily: And tell me, also, a bit about, sort of, your own technology. Things like how you manage scalability. How important is it for Forter's bottom line, the ability to have a scalable system?Iftah: We are running from 2014—from day one, actually, from 2013, we have to be scaled out. We can't scale up. We don't have anything that is done by a single computer. All the transactions are on what are called brains that are a scaled out on both redundancy and scalability. All our data stores are scaled out. All the data stores that are storing the transactions, and the logging, and the entities that we talked about are scaled out and they are replicated, and the transactions that are dealing with our hundreds of thousands of browsing events that we receive and analyze every second, of course, they are scaled out. So, from day one, from 2014, everything that we do is scaled out. In the first two months, it was for redundancy in different availability zones of different regions, but from then on, it's all scaled out. And I will be very happy to dive into the particulars of the technologies, but what is important in the context of this podcast, I believe, is that doing it on the Cloud using the cloud infrastructure is actually enabling us to concentrate on the business of detecting fraud and business of these massive topologies of hundreds of processes that are both in Java and Kotlin and Python, and have very complex acyclic graphs connecting them. And we just do it in parallel on very many servers that we can scale up and out as we wish. And this is something that helped us focus our core business: understanding fraud.Emily: Going back, actually, to this idea of scalability, I know over the past six, eight months because of COVID, e-commerce has gone through the roof. And I'm assuming, in fact, I read that Forter's business has also been going through the roof. How have you managed scaling?Iftah: Yes. Forter business went through the roof with their several verticals: with food deliveries, of course; and we the big department stores, which COVID accelerated their digital transformation; it did dive with the travel business, of course, right? Few things happen to our customers, and for Forter, scaling was natural. If we have 20 minutes warning scaling is a natural to us, and here we had about 10 days of warning. Easy, right? For our customers, it was a bit different. First, a lot of them came to us, actually had to eliminate all their manual processes. And Forter was there for them. Now, what Forter did for them beyond eliminating any manual fraud-related tasks and loads was to reduce substantially the hike in the customer success load. Because Forter is able to be more accurate and to decline less legitimate customers, you don't have that many calls to the customer success centers. And these are two bottlenecks for our big merchants: the customer success, and fraud and fulfillment. And the fulfillment, that is being able to capture the money and to send the goods is also streamlined by the fact that it's all done in real time. These are the direct effect, but there are additional phenomenon that happened. One of them is that suddenly, in COVID, a lot of customers that didn't usually do things online started to buy online. And we saw that the amount—or the percentage of new buyers, in many of our customers, suddenly jumped. And when you have new buyers, you need a very sophisticated system to be able to allow them in, to approve their transaction, and to allow them to build their reputation; so this happened. The spikes in throughput happened; every day in the last four months is like a Good Friday and Cyber Monday combined for us. And that's good. We didn't lose any availability, and with the current technology, it wasn't that problem from the scalability aspects. And indeed, have we been on private, or our on-prem, this would be much harder.Emily: And now tell me a little bit more about the technology required. We talked a little bit about it not being exactly a throughput problem, but you do have hundreds of processes that you have to run in, you know, several seconds, what technology do you need to leverage in order to make that happen?Iftah: Everything that we run is on flash disks; we don't have rotating disks anymore. We do run low CPU and low memory on all—low memory usage and low percentage of CPU on every [00:24:30 unintelligible] that we run, to accommodate and reduce a spike pickups. We do use the Apache Storm for our base; it is the base of our topology of these processes that we talked about, and hundreds of them in each topology. And we have several topologies for both the transaction time and what we call the visit time, the browsing time. And we run—we are a big customer of Elasticsearch, we run Elastic from the very early days, and we use them for sophisticated queries in their own annoying language. [laughs]. And we have one of the largest clusters. We have about 15 clusters of Elasticsearch that serve our entities that we talked about, our mapping of people to these entities, our logging, and our real-time matching between the current transaction and all the hundreds of millions of people we already know that acted online previously. These are the core technologies in our stack, and on top of that, we use several other technologies: Spark and our wrappers over Spark for the MapReduce work of our machine learning processes, and we use Kafka for persistent distribution of our data among regions, and among availability zones.Emily: What would you say is your biggest technical challenge? And by this, I mean, like, something that you're perhaps still working on, you don't feel like you've totally figured it out yet.Iftah: I think we are very advanced in our matching, the similarity problem. That is something that we think is a pillar of our superiority in this field, but it's a never-ending story. The ability to detect relevant anomalies in the behavior of the crowd is something that we work very hard on, and we expect a lot from these technologies because they have the potential to help us mitigate threats which are new to us; zero-hour threats of modus operandi, of MOs that we did not encounter earlier. These are the main issues. One issue that is mundane and prosaic is the cost of transaction. We do a lot of processing and we start, in our scale, to feel the heat of the cost of serving all these transactions. Nothing that will take us out of the Cloud, but it's something that we need to work hard on. Last, but definitely not least, is security. We think we turned our emphasis on security to our unfair advantage in this field, but still, hardening your systems and thinking about the possible attack vectors on your systems and on your merchant's system is something that I lose sleep at night over, and it is something that we can never say that we are done with.Emily: What do you think about the security-speed trade-off? Do you think it's real? Or do you think you can move just as fast and be secure?Iftah: We can move with negligible sacrifices for the security. Again, if you are talking about real-time systems where the microseconds count, then it's a different story. But for us, having everything encrypted both at rest and at motion is something that does not need to come at the expense of security. What is very interesting in this trade-offs of security and speed is the trade off, not of the real-time speed and the processing speed, but of the engineering development speed. And here, the magic is in the automation, every security aspect, and with your ability to mask all these security aspects from your engineers, and giving them the right APIs so they can develop the application itself. Which is developed to our domain in the same speed, while still being totally secured without them needing to take care of the plumbing. And that's something that we invested a lot in, and it's a never-ending game. I think we're good at it, but never good enough.Emily: And do you rely primarily on the Cloud service providers? So, on AWS's native services, or do you tend to find additional out-of-the-box services, or build your own? Do you have, sort of, a philosophy on that?Iftah: You know, philosophy is one thing, and then what you're doing practice sometimes need to be traded off with reality. But we are currently running on both AWS and starting to run on Azure, so we are making our processes agnostic to the particular cloud that we run on. It is interesting to do when you come to security configuration because you need to create abstraction layers over the particular security mechanisms in AWS and Azure, which are quite different. And that's where we are now. So, we are moving to be totally agnostic. So far, we did use occasionally, not—we weren't a heavy users of AWS services, but we did use a analytic databases; we did use Kinesis, but we moved now to Kafka, and so on. And we did use very cloud-specific queues, but we're moving out of this now.Emily: Why do you think it's important to be cloud-agnostic?Iftah: Because we run on two different clouds. We run on two clouds because of the very high availability requirement that we have. First, we need to be totally available to our merchants. Second, we need not only to be totally available to merchants, we also need to be very, very accurate, always. So, it's not that I can degrade gracefully and say, “Okay, I always answer approve in certain occasions,” because the fraudsters will very quickly understand that. So, we need to be with full brain capacity, always on. And if we are not, we started within tens of minutes or a hour or two, to be very susceptible to great losses. So, that's the reason we need to be with multiple regions, and we need to be with both clouds. It does take a heavy penalty, and we do think about how to reduce the penalty of working with two clouds, but that's what we currently do.Emily: Can you tell me how much your technology stack has changed since 2014?Iftah: We did change a lot in the representation of the world, and this was big. We did move into a Elastic from more traditional NoSQL and SQL [00:33:20 unintelligible] BMS. And we move now, again, to new high throughput databases for our browsing events, the ones that do get hundreds of thousands of events per second. And we do move slowly [00:33:40 unintelligible] many more items or small stack items like queues, and data distribution channels that are no longer serving us well as we scale out, and as we move to being cloud-agnostic. For example, we move now our analytics database from AWS's Redshift to a cloud-agnostic database.Emily: Excellent. I'm going to wrap up pretty soon; this has been really interesting. But a couple, sort of, last questions I wanted to ask. One is, can you describe what a day looks like for you? What does the day for the CTO of a Forter, of a cloud-based SaaS fraud prevention company—what do you actually do?Iftah: First, I am looking at what may endanger our business in the next year and in the next three years. The reason why we are [00:34:42 unintelligible], we call this process internally, the ‘what can kill us?' process. Is mainly because we are in a good shape, and when you're in a good shape you need to look at the threats and how to protect the business from them, and what new business you need to do. Then I'm looking at the health of our precision teams. And our precision teams are both the data science team, the cyber R&D teams, the fraud researchers teams, and the engineering teams that are supporting them. All these are—we need to see that we maintain our superiority. We so far never lost a QC or a bakeoff on any performance issues, and it's a tall order to keep it that way. So, this is the second task that keeps me up. And the last is to see that, indeed we have all what we need in order to enable the spear of development and for the new products. Companies in their seventh year, as we are, are in an inflection point between the startup and the enterprise, and that's where you need to make sure that we stay agile. We stay agile, it depends on the agility of the organization. How can you scale? Or do you rely on several heroes? And the agility of the development itself that relies, to a great degree, on the tech debt kept low enough.Emily: Fabulous. And what is a tool or platform that you think is sort of essential to functioning?Iftah: I think that we built a very robust, extensive monitoring and alerting infrastructure, and this monitoring and alerting infrastructure enables us to understand quickly whether something has happened in the world. And I must say that most of the time that something is happening in the world, it's not something that we need to do something about manually, but sometimes it's something that the merchants need to do. We discovered, for example, that one of our online travel agencies customers started to issue flight tickets for one percent of their price; for three and four bucks instead of four hundred bucks. And we detected it not by looking at the prices, but by seeing spikes of purchases from this OTA in Malaysia and Vietnam, and we were able to tell this to our merchant, to the customer, and the whole thing was rectified about 14 minutes from the time it started. So, our alerting and monitoring systems, which is both on the application level, on the business level on them, and on the other end, on the machine levels, this is very, very important, and pays for itself handsomely.Emily: I think I've read accounts in the newspaper of travel agents, or airlines having that type of mistake.Iftah: Yes.Emily: It tends to get some publicity. Last question is, how can listeners connect with you or follow you?Iftah: Well, iftah@forter.com. Look us up in forter.com, and we will be very happy to talk to you.Emily: Excellent. Thank you so much, Iftah, this was really fascinating.Iftah: Thank you very much for having me.Emily: Thanks for listening. I hope you've learned just a little bit more about The Business of Cloud Native. If you'd like to connect with me or learn more about my positioning services, look me up on LinkedIn: I'm Emily Omier—that's O-M-I-E-R—or visit my website which is emilyomier.com. Thank you, and until next time.Announcer: This has been a HumblePod production. Stay humble.

In this episode, Rosalie Bartlett, Sr. Open Source Community Manager, interviews Kishor Patil, Sr. Principal Software Systems Engineer on the Verizon Media team. Kishor shares what’s new in Storm 2.0, an open source distributed real-time computation system, as well as, how Verizon Media uses and contributes to Storm.

In this episode of the ARCHITECHT Show, Stephan Ewen discusses the open source stream-processing system Apache Flink (which he helped create) and the commercial platform data Artisans (of which he's co-founder and CTO) is building around it. Ewan covers some of the major use cases for stream processing and some of Flink's biggest users -- including Alibaba -- and the challenges of standing out against, and sometimes working alongside, established projects such as Apache Spark, Apache Storm and Apache Kafka.

Batch and stream processing systems have been evolving for the past decade. From MapReduce to Apache Storm to Dataflow, the best practices for large volume data processing have become more sophisticated as the industry and open source communities have iterated on them.   Dataflow and Apache Beam are projects that present a unified batch and The post Cloud Dataflow with Eric Anderson appeared first on Software Engineering Daily.

This week's guest is Mike Anderson from Echosec, a location-based social media search platform. We start the show with a review of last week's and an outlook to next week's tech meetups around town.

Nathan Marz is the creator of Apache Storm, a real-time streaming application. Storm does for stream processing what Hadoop does for batch processing. The project began when Nathan was working on aggregating Twitter data using a queue-and-worker system he had designed. Many companies use Storm, including Spotify, Yelp, WebMD, and many others. Jeff and Nathan […]

Dans cet épisose, on discute avec Sam Bessalah de ce “nouveau” métier qu’est le data scientist. On explore aussi l’univers Apache Hadoop et l’univers Apache Mesos. Ces endroits sont pleins de projets aux noms bizarres, cette interview permet de s’y retrouver un peu dans cette mythologie. Enregistré le 16 decembre 2014 Téléchargement de l’épisode LesCastCodeurs-Episode–115.mp3 Interview Ta vie, ton oeuvre @samklr Ses présentations, encore ici et là Data scientist Kesako ?! C’est nouveau ? On a toujours eu des données pourtant dans nos S.I. ?! Le job le plus sexy du 21eme siecle ? Drew conway’s Data Science Venn diagram Traiter les données, les plateformes MapR, Hadoop, … C’est Quoi ? C’est nouveau ? Ca vient d’où ? Comment ça marche ? A quoi ça sert ? Ca s’intègre à tout ? Et nos sources de données legacy (Mon bon vieux mainframe et son EBCDIC) ? Où sont passés mes EAI, ETL, et autres outils d’intégration B2C/B2B ? EAI ETL EBCDIC BI (Business Intelligence) Hadoop MapReduce Doug Cutting Apache Lucene - moteur de recherche full-text Apache Hadoop - platforme de process distribués et scalables HDFS - système de fichier distribué Apache Hive - datawarehouse au dessus d’Hadoop offrant du SQL-like Terradata Impala - database analytique (“real time”) SQL queries etc Apache Tez - directed-acyclic-graph of tasks Apache Shark remplacé par Spark SQL Apache Spark - Spark has an advanced DAG execution engine that supports cyclic data flow and in-memory computing Apache Storm - process de flux de données de manière scalable et distribuée Data Flow Machine Learning - apprendre de la donnée Graph Lab Et l’infrastructure dans tout ça ? De nos bons vieux serveurs qui remplissent les salles machines au cloud (IAAS, PAAS), en passant par la virtualisation (), les conteneurs (XLC, Docker, …) …. Des ressources à gogo c’est bien mais comment les gérer ? YARN Apache Mesos Apache Mesos Comment démarrer Mesos Tutoriaux Data Center OS de Mesosphere Presentation de Same à Devoxx sur Mesos Mesos et les container docker Cluster Management and Containerization by Benjamin Hindman Integration continue avec Mesos par EBays Docker Docker Démarrer un cluster Spark avec Docker Shell Spark dans Docker Docker et Kubernetes dans Apache Hadoop YARN Cluster Hadoop sur Docker Docker, Kubernetes and Mesos cgroups LXC Docker vs LXC Marathon Chronos Code de Chronos Aurora Kubernetes Kubernetes workshop Oscar Boykin Scalding Présentation Scala + BigData et une autre Apache Ambari Comment je m’y mets ? Comment devient-on data scientist ? (se former, ouvrages de références, sources d’infos, …) Mesosphere Cours de Andrew Ng sur le Machine Learning Introduction to data science sur Coursera Kaggle MLlib Mahoot R Scikit-learn (Python) Machine Learning pour Hackers (livre) Scala TypeSafe Activator iPython NoteBooks Autres référence iPython NoteBooks Notebooks temporaires en line - démarre un container docker sur rackspace gratuitement (pour vous) Des notebooks Parallel Machine Learning with scikit-learn and IPython Visualiser les notebooks en ligne sans les télécharger Spark / Scala notebooks for web based spark development http://zeppelin-project.org/ Spark et Scala avec un notebook ipython Nous contacter Contactez-nous via twitter http://twitter.com/lescastcodeurs sur le groupe Google http://groups.google.com/group/lescastcodeurs ou sur le site web http://lescastcodeurs.com/ Flattr-ez nous (dons) sur http://lescastcodeurs.com/ En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

More CDI suckage. OSGi - class loading / reloading. JSR-330 - Dependency Injection for Java JSR-346 - Contexts and Dependency Injection for Java EE Nathan Marz - History of Apache Storm and lessons learned Front End Teams + Back End Teams vs Product Feature Teams Contract First REST APIs with RAML Neal Ford - Functional Thinking Angular 2.0 Core by Igor Minar & Tobias Bosch at ng-europe 2014