Podcasts about Kibana

Latest Google Chrome Update Encourages UBlock Origin Removal The latest update to Google Chrome not only disabled the UBlock Origin ad blocker, but also guides users to uninstall the extension instead of re-enabling it. https://chromereleases.googleblog.com/2025/03/stable-channel-update-for-desktop.html https://www.reddit.com/r/youtube/comments/1j2ec76/ublock_origin_is_gone/ Critical Kibana Update Elastic published a critical Kibana update patching a prototype polution vulnerability that would allow arbitrary code execution for users with the "Viewer" role. https://discuss.elastic.co/t/kibana-8-17-3-security-update-esa-2025-06/375441 Certified PrePw0n3d Android TV Sticks Wired is reporting of over a million Android TV sticks that were found to be pre-infected with adware https://www.wired.com/story/android-tv-streaming-boxes-china-backdoor/ SANS.edu Research Paper Advanced Persistent Threats (APTs) are among the most challenging to detect in enterprise environments, often mimicking authorized privileged access prior to their actions on objectives. https://www.sans.edu/cyber-research/identifying-advanced-persistent-threat-activity-through-threat-informed-detection-engineering-enhancing-alert-visibility-enterprises/

Using ES|QL In Kibana to Query DShield Honeypot Logs Using the "Elastic Search Piped Query Language" to query DShield honeypot logs https://isc.sans.edu/diary/Using%20ES%7CQL%20in%20Kibana%20to%20Queries%20DShield%20Honeypot%20Logs/31704 Mongoose Flaws Put MongoDB at risk The Object Direct Mapping library Mongoose suffers from an injection vulnerability leading to the potenitial of remote code exeuction in MongoDB https://www.theregister.com/2025/02/20/mongoose_flaws_mongodb/ U-Boot Vulnerabilities The open source boot loader U-Boot does suffer from a number of issues allowing the bypass of its integrity checks. This may lead to the execution of malicious code on boot. https://www.openwall.com/lists/oss-security/2025/02/17/2 Unifi Protect Camera Update https://community.ui.com/releases/Security-Advisory-Bulletin-046-046/9649ea8f-93db-4713-a875-c3fd7614943f

rustpad es un estupendo servicio #selfhosted para alojar en tu #vps o en un servidor #linux con #docker y que te permite editar un documento entre varios Esta última semana asistí a un curso muy interesante sobre Kibana. En el curso se utilizó una herramienta que desconocía por completo y que era, ni mas ni menos, que un editor colaborativo. Una herramienta que permitía compartir con otras personas de forma sencilla texto. Y esto, como te puedes imaginar, me llamó mucho la atención y me hizo buscar una alternativa que pudiera hospedar en mi propio servidor. Y te preguntarás para que quiero esto, pues muy sencillo, algo que seguro que tu has hecho en mas de una ocasión, para copiar texto entre diferentes dispositivos de forma sencilla. Por ejemplo, pasar una contraseña, el nombre de un usuario, o cualquier cosa. Esto me llevó a revisar algunos de otros servicios similares que tengo, como puede ser pastebin o opengist de los que te hablaré también en este episodio. Más información, enlaces y notas en https://atareao.es/podcast/644

rustpad es un estupendo servicio #selfhosted para alojar en tu #vps o en un servidor #linux con #docker y que te permite editar un documento entre varios Esta última semana asistí a un curso muy interesante sobre Kibana. En el curso se utilizó una herramienta que desconocía por completo y que era, ni mas ni menos, que un editor colaborativo. Una herramienta que permitía compartir con otras personas de forma sencilla texto. Y esto, como te puedes imaginar, me llamó mucho la atención y me hizo buscar una alternativa que pudiera hospedar en mi propio servidor. Y te preguntarás para que quiero esto, pues muy sencillo, algo que seguro que tu has hecho en mas de una ocasión, para copiar texto entre diferentes dispositivos de forma sencilla. Por ejemplo, pasar una contraseña, el nombre de un usuario, o cualquier cosa. Esto me llevó a revisar algunos de otros servicios similares que tengo, como puede ser pastebin o opengist de los que te hablaré también en este episodio. Más información, enlaces y notas en https://atareao.es/podcast/644

JVM summit, virtual threads, stacks applicatives, licences, déterminisme et LLMs, quantification, deux outils de l'épisode et bien plus encore. Enregistré le 13 septembre 2024 Téléchargement de l'épisode LesCastCodeurs-Episode–315.mp3 News Langages Netflix utilise énormément Java et a rencontré un problème avec les Virtual Thread dans Java 21. Les ingénieurs de Netflix analysent ce problème dans cet article : https://netflixtechblog.com/java–21-virtual-threads-dude-wheres-my-lock–3052540e231d Les threads virtuels peuvent améliorer les performances mais posent des défis. Un problème de locking a été identifié : les threads virtuels se bloquent mutuellement. Cela entraîne des performances dégradées et des instabilités. Netflix travaille à résoudre ces problèmes et à tirer pleinement parti des threads virtuels. Une syntax pour indiquer qu'un type est nullable ou null-restricted arriverait dans Java https://bugs.openjdk.org/browse/JDK–8303099 Foo! interdirait null Foo? indiquerait que null est accepté Foo?[]! serait un tableau non-null de valeur nullable Il y a aussi des idées de syntaxe pour initialiser les tableaux null-restricted JEP: https://openjdk.org/jeps/8303099 Les vidéos du JVM Language Summit 2024 sont en ligne https://www.youtube.com/watch?v=OOPSU4LnKg0&list=PLX8CzqL3ArzUEYnTa6KYORRbP3nhsK0L1 Project Leyden Update Project Babylon - Code Reflection Valhalla - Where Are We? An Opinionated Overview on Static Analysis for Java Rethinking Java String Concatenation Code Reflection in Action - Translating Java to SPIR-V Java in 2024 Type Specialization of Java Generics - What If Casts Have Teeth ? (avec notre Rémi Forax national !) aussi tip or tail pour tout l'ecosysteme quelques liens sur Babylon: Code reflection pour exprimer des langages etranger (SQL) dans Java: https://openjdk.org/projects/babylon/ et sont example en emulation de LINQ https://openjdk.org/projects/babylon/articles/linq Librairies Micronaut sort sa version 4.6 https://micronaut.io/2024/08/26/micronaut-framework–4–6–0-released/ essentiellement une grosse mise à jour de tonnes de modules avec les dernières versions des dépendances Microprofile 7 faire quelques changements et evolution incompatibles https://microprofile.io/2024/08/22/microprofile–7–0-release/#general enleve Metrics et remplace avec Telemetry (metrics, log et tracing) Metrics reste une spec mais standalone Microprofile 7 depende de Jakarta Core profile et ne le package plus Microprofile OpenAPI 4 et Telemetry 2 amenent des changements incompatibles Quarkus 3.14 avec LetsEncrypt et des serialiseurs JAckson sans reflection https://quarkus.io/blog/quarkus–3–14–1-released/ Hibernate ORM 6.6 Serialisateurs JAckson sans reflection installer des certificats letsencrypt simplement (notamment avec la ligne de commande qui aide sympa notamment avec ngrok pour faire un tunnel vers son localhost retropedalage sur @QuarkusTestResource vs @WithTestResource suite aux retour de OOME et lenteur des tests mieux isolés Les logs structurées dans Spring Boot 3.4 https://spring.io/blog/2024/08/23/structured-logging-in-spring-boot–3–4 Les logs structurées (souvent en JSON) vous permettent de les envoyer facilement vers des backends comme Elastic, AWS CloudWatch… Vous pouvez les lier à du reporting et de l'alerting. Spring Boot 3.4 prend en charge la journalisation structurée par défaut. Il prend en charge les formats Elastic Common Schema (ECS) et Logstash, mais il est également possible de l'étendre avec vos propres formats. Vous pouvez également activer la journalisation structurée dans un fichier. Cela peut être utilisé, par exemple, pour imprimer des journaux lisibles par l'homme sur la console et écrire des journaux structurés dans un fichier pour l'ingestion par machine. Infrastructure CockroachDB qui avait une approche Business Software License (source available puis ALS 3 ans apres), passe maintenant en license proprietaire avec source available https://www.cockroachlabs.com/blog/enterprise-license-announcement/ Polyform project offre des licences standardisees selon les besoins de gratuit vs payant https://polyformproject.org/ Cloud Azure fonctions, comment le demarrage a froid est optimisé https://www.infoq.com/articles/azure-functions-cold-starts/?utm_campaign=infoq_content&utm_source=twitter&utm_medium=feed&utm_term=Cloud fonctions ont une latence naturelle forte toutes les lantences longues ne sont aps impactantes pour le business les demarrages a froid peuvent etre mesures avec les outils du cloud provider donc faites en usage faites des decentilers de latences experience 381 ms cold et 10ms apres tracing pour end to end latence les strategies keep alive pings: reveiller la fonctione a intervalles reguliers pour rester “warm” dans le code de la fonction: initialiser les connections et le chargement des assemblies dans l'initialization configurer dans host.json le batching, desactiver file system logging etc deployer les fonctions as zips reduire al taille du code et des fichiers (qui sont copies sur le serveur froid) sur .net activer ready to run qui aide le JIT compiler instances azure avec plus de CPU et memoire sont plus cher amis baissent le cold start dedicated azure instances pour vos fonctions (pas aprtage avec les autres tenants) ensuite montre des exemples concrets Web Sortie de Vue.js 3.5 https://blog.vuejs.org/posts/vue–3–5 Vue.JS 3.5: Nouveautés clés Optimisations de performance et de mémoire: Réduction significative de la consommation de mémoire (–56%). Amélioration des performances pour les tableaux réactifs de grande taille. Résolution des problèmes de valeurs calculées obsolètes et de fuites de mémoire. Nouvelles fonctionnalités: Reactive Props Destructure: Simplification de la déclaration des props avec des valeurs par défaut. Lazy Hydration: Contrôle de l'hydratation des composants asynchrones. useId(): Génération d'ID uniques stables pour les applications SSR. data-allow-mismatch: Suppression des avertissements de désynchronisation d'hydratation. Améliorations des éléments personnalisés: Prise en charge de configurations d'application, d'API pour accéder à l'hôte et au shadow root, de montage sans Shadow DOM, et de nonce pour les balises. useTemplateRef(): Obtention de références de modèle via l'API useTemplateRef(). Teleport différé: Téléportation de contenu vers des éléments rendus après le montage du composant. onWatcherCleanup(): Enregistrement de callbacks de nettoyage dans les watchers. Data et Intelligence Artificielle On entend souvent parler de Large Language Model quantisés, c'est à dire qu'on utilise par exemple des entiers sur 8 bits plutôt que des floatants sur 32 bits, pour réduire les besoins mémoire des GPU tout en gardant une précision proche de l'original. Cet article explique très visuellement et intuitivement ce processus de quantisation : https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-quantization Guillaume continue de partager ses aventures avec le framework LangChain4j. Comment effectuer de la classification de texte : https://glaforge.dev/posts/2024/07/11/text-classification-with-gemini-and-langchain4j/ en utilisant la classe TextClassification de LangChain4j, qui utilise une approche basée sur les vector embeddings pour comparer des textes similaires en utilisant du few-shot prompting, sous différentes variantes, dans cet autre article : https://glaforge.dev/posts/2024/07/30/sentiment-analysis-with-few-shots-prompting/ et aussi comment faire du multimodal avec LangChain4j (avec le modèle Gemini) pour analyser des textes, des images, mais également des vidéos, du contenu audio, ou bien des fichiers PDFs : https://glaforge.dev/posts/2024/07/25/analyzing-videos-audios-and-pdfs-with-gemini-in-langchain4j/ Pour faire varier la prédictibilité ou la créativité des LLMs, certains hyperparamètres peuvent être ajustés, comme la température, le top-k et le top-p. Mais est-ce que vous savez vraiment comment fonctionnent ces paramètres ? Deux articles très clairs et intuitifs expliquent leur fonctionnement : https://medium.com/google-cloud/is-a-zero-temperature-deterministic-c4a7faef4d20 https://medium.com/google-cloud/beyond-temperature-tuning-llm-output-with-top-k-and-top-p–24c2de5c3b16 la tempoerature va ecraser la probabilite du prochain token mais il reste des variables: approximnation des calculs flottants, stacks differentes effectuants ces choix differemment, que faire en cas d'egalité de probabilité entre deux tokens mais il y a d'atures apporoches de configuiration des reaction du LLM: top-k (qui evite les tokens peu frequents), top-p pour avoir les n des tokens qui totalient p% des probabilités temperature d'abord puis top-k puis top-p explique quoi utiliser quand OSI propose une definition de l'IA open source https://www.technologyreview.com/2024/08/22/1097224/we-finally-have-a-definition-for-open-source-ai/ gros debats ces derniers mois utilisable pour tous usages sans besoin de permission chercheurs peuvent inspecter les components et etudier comment le system fonctionne systeme modifiable pour tout objectif y compris chager son comportement et paratger avec d'autres avec ou sans modification quelque soit l'usage Definit des niveaux de transparence (donnees d'entranement, code source, poids) Une longue rétrospective de PostgreSQL a des volumes de malades et les problèmes de lock https://ardentperf.com/2024/03/03/postgres-indexes-partitioning-and-lwlocklockmanager-scalability/ un article pour vous rassurer que vous n'aurez probablement jamais le problème histoire sous forme de post mortem des conseils pour éviter ces falaises Outillage Un premier coup d'oeil à la future notation déclarative de Gradle https://blog.gradle.org/declarative-gradle-first-eap un article qui explique à quoi ressemble cette nouvelle syntaxe déclarative de Gradle (en plus de Groovy et Kotlin) Quelques vidéos montrent le support dans Android Studio, pour le moment, ainsi que dans un outil expérimental, en attendant le support dans tous les IDEs L'idée est d'éviter le scripting et d'avoir vraiment qu'une description de son build Cela devrait améliorer la prise en charge de Gradle dans les IDEs et permettre d'avoir de la complétion rapide, etc c'est moi on on a Maven là? Support de Firefox dans Puppeteer https://hacks.mozilla.org/2024/08/puppeteer-support-for-firefox/ Puppeteer, la bibliothèque d'automatisation de navigateur, supporte désormais officiellement Firefox dès la version 23. Cette avancée permet aux développeurs d'écrire des scripts d'automatisation et d'effectuer des tests de bout en bout sur Chrome et Firefox de manière interchangeable. L'intégration de Firefox dans Puppeteer repose sur WebDriver BiDi, un protocole inter-navigateurs en cours de standardisation au W3C. WebDriver BiDi facilite la prise en charge de plusieurs navigateurs et ouvre la voie à une automatisation plus simple et plus efficace. Les principales fonctionnalités de Puppeteer, telles que la capture de journaux, l'émulation de périphériques, l'interception réseau et le préchargement de scripts, sont désormais disponibles pour Firefox. Mozilla considère WebDriver BiDi comme une étape importante vers une meilleure expérience de test inter-navigateurs. La prise en charge expérimentale de CDP (Chrome DevTools Protocol) dans Firefox sera supprimée fin 2024 au profit de WebDriver BiDi. Bien que Firefox soit officiellement pris en charge, certaines API restent non prises en charge et feront l'objet de travaux futurs. Guillaume a créé une annotation @Retry pour JUnit 5, pour retenter l'exécution d'un test qui est “flaky” https://glaforge.dev/posts/2024/09/01/a-retryable-junit–5-extension/ Guillaume n'avait pas trouvé d'extension par défaut dans JUnit 5 pour remplacer les Retry rules de JUnit 4 Mais sur les réseaux sociaux, une discussion intéressante s'ensuit avec des liens sur des extensions qui implémentent cette approche Comme JUnit Pioneer qui propose plein d'extensions utiles https://junit-pioneer.org/docs/retrying-test/ Ou l'extension rerunner https://github.com/artsok/rerunner-jupiter Arnaud a aussi suggéré la configuration de Maven Surefire pour relancer automatiquement les tests qui ont échoué https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html la question philosophique est: est-ce que c'est tolerable les tests qui ecouent de façon intermitente Architecture Un ancien fan de GraphQL en a fini avec la technologie GraphQL et réfléchit aux alternatives https://bessey.dev/blog/2024/05/24/why-im-over-graphql/ Problèmes de GraphQL: Sécurité: Attaques d'autorisation Difficulté de limitation de débit Analyse de requêtes malveillantes Performance: Problème N+1 (récupération de données et autorisation) Impact sur la mémoire lors de l'analyse de requêtes invalides Complexité accrue: Couplage entre logique métier et couche de transport Difficulté de maintenance et de tests Solutions envisagées: Adoption d'API REST conformes à OpenAPI 3.0+ Meilleure documentation et sécurité des types Outils pour générer du code client/serveur typé Deux approches de mise en œuvre d'OpenAPI: “Implementation first” (génération de la spécification à partir du code) “Specification first” (génération du code à partir de la spécification) retour interessant de quelqu'un qui n'utilise pas GraphQL au quotidien. C'était des problemes qui devaient etre corrigés avec la maturité de l'ecosysteme et des outils mais ca a montré ces limites pour cette personne. Prensentation de Grace Hoper en 1980 sur le future des ordinateurs. https://youtu.be/AW7ZHpKuqZg?si=w_o5_DtqllVTYZwt c'est fou la modernité de ce qu'elle décrit Des problèmes qu'on a encore aujourd'hui positive leadership Elle décrit l'avantage de systèmes fait de plusieurs ordinateurs récemment declassifié Leader election avec les conditional writes sur les buckets S3/GCS/Azure https://www.morling.dev/blog/leader-election-with-s3-conditional-writes/ L'élection de leader est le processus de choisir un nœud parmi plusieurs pour effectuer une tâche. Traditionnellement, l'élection de leader se fait avec un service de verrouillage distribué comme ZooKeeper. Amazon S3 a récemment ajouté le support des écritures conditionnelles, ce qui permet l'élection de leader sans service séparé. L'algorithme d'élection de leader fonctionne en faisant concourir les nœuds pour créer un fichier de verrouillage dans S3. Le fichier de verrouillage inclut un numéro d'époque, qui est incrémenté à chaque fois qu'un nouveau leader est élu. Les nœuds peuvent déterminer s'ils sont le leader en listant les fichiers de verrouillage et en vérifiant le numéro d'époque. attention il peut y avoir plusieurs leaders élus (horloges qui ont dérivé) donc c'est à gérer aussi Méthodologies Guillaume Laforge interviewé par Sfeir, où il parle de l'importance de la curiosité, du partage, de l'importance de la qualité du code, et parsemé de quelques photos des Cast Codeurs ! https://www.sfeir.dev/success-story/guillaume-laforge-maestro-de-java-et-esthete-du-code-propre/ Sécurité Comment crowdstrike met a genoux windows et de nombreuses entreprises https://next.ink/144464/crowdstrike-donne-des-details-techniques-sur-son-fiasco/ l'incident vient de la mise à jour de la configuration de Falcon l'EDR de crowdstrike https://www.crowdstrike.com/blog/falcon-update-for-windows-hosts-technical-details/ qu'est ce qu'un EDR? Un système Endpoint Detection and Response a pour but de surveiller votre machine ( access réseaux, logs, …) pour detecter des usages non habituels. Cet espion doit interagir avec les couches basses du système (réseau, sockets, logs systems) et se greffe donc au niveau du noyau du système d'exploitation. Il remonte les informations en live à une plateforme qui peut ensuite adapter les réponse en live si l'incident a duré moins de 1h30 coté crowdstrike plus de 8 millions de machines se sont retrouvées hors service bloquées sur le Blue Screen Of Death selon Microsoft https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/ cela n'est pas la première fois et était déjà arrivé il y a quelques mois sur Linux. Comme il s'agissait d'une incompatibilité de kernel il avait été moins important car les services ITs gèrent mieux ces problèmes sous Linux https://stackdiary.com/crowdstrike-took-down-debian-and-rocky-linux-a-few-months-ago-and-no-one-noticed/ Les benchmarks CIS, un pilier pour la sécurité de nos environnements cloud, et pas que ! (Katia HIMEUR TALHI) https://blog.cockpitio.com/security/cis-benchmarks/ Le CIS est un organisme à but non lucratif qui élabore des normes pour améliorer la cybersécurité. Les référentiels CIS sont un ensemble de recommandations et de bonnes pratiques pour sécuriser les systèmes informatiques. Ils peuvent être utilisés pour renforcer la sécurité, se conformer aux réglementations et normaliser les pratiques. Loi, société et organisation Microsoft signe un accord avec OVHCloud pour qu'il arretent leur plaine d'antitrust https://www.politico.eu/article/microsoft-signs-antitrust-truce-with-ovhcloud/ la plainte était en Europe mermet a des clients de plus facilement deployer les solutions Microsoft dans le fournisseur de cloud de leur choix la plainte avait ete posé à l'été 2021 ca rendait faire tourner les solutions MS plus cheres et non competitives vs MS ElasticSearch et Kibana sont de nouveau Open Source, en ajoutant la license AGPL à ses autres licences existantes https://www.elastic.co/fr/blog/elasticsearch-is-open-source-again le marché d'il y a trois ans et maintenant a changé AWS est une bon partenaire le flou Elasticsearch vs le produit d'AWS s'est clarifié donc retour a l'open source via AGPL Affero GPL Elastic n'a jamais cessé de croire en l'open source d'après Shay Banon son fondateur Le changement vers l'AGPL est une option supplémentaire, pas un remplacement d'une des autres licences existantes et juste apres, Elastic annonce des resultants decevants faisant plonger l'action de 25% https://siliconangle.com/2024/08/29/elastic-shares-plunge–25-lower-revenue-projections-amid-slower-customer-commitments/ https://unrollnow.com/status/1832187019235397785 et https://www.elastic.co/pricing/faq/licensing pour un résumé des licenses chez elastic Outils de l'épisode MailMate un client email Markdown et qui gere beaucoup d'emails https://medium.com/@nicfab/mailmate-a-powerful-client-email-for-macos-markdown-integrated-email-composition-e218fe2accf3 Emmanuel l'utilise sur les boites email secondaires un peu lent a demarrer (synchro) et le reste est rapide boites virtuelles (par requete) SpamSieve Que macOS je crois Trippy, un analyseur de réseau https://github.com/fujiapple852/trippy Il regroupe dans une CLI traceroute et ping Conférences La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 17 septembre 2024 : We Love Speed - Nantes (France) 17–18 septembre 2024 : Agile en Seine 2024 - Issy-les-Moulineaux (France) 19–20 septembre 2024 : API Platform Conference - Lille (France) & Online 20–21 septembre 2024 : Toulouse Game Dev - Toulouse (France) 25–26 septembre 2024 : PyData Paris - Paris (France) 26 septembre 2024 : Agile Tour Sophia-Antipolis 2024 - Biot (France) 2–4 octobre 2024 : Devoxx Morocco - Marrakech (Morocco) 3 octobre 2024 : VMUG Montpellier - Montpellier (France) 7–11 octobre 2024 : Devoxx Belgium - Antwerp (Belgium) 8 octobre 2024 : Red Hat Summit: Connect 2024 - Paris (France) 10 octobre 2024 : Cloud Nord - Lille (France) 10–11 octobre 2024 : Volcamp - Clermont-Ferrand (France) 10–11 octobre 2024 : Forum PHP - Marne-la-Vallée (France) 11–12 octobre 2024 : SecSea2k24 - La Ciotat (France) 15–16 octobre 2024 : Malt Tech Days 2024 - Paris (France) 16 octobre 2024 : DotPy - Paris (France) 16–17 octobre 2024 : NoCode Summit 2024 - Paris (France) 17–18 octobre 2024 : DevFest Nantes - Nantes (France) 17–18 octobre 2024 : DotAI - Paris (France) 30–31 octobre 2024 : Agile Tour Nantais 2024 - Nantes (France) 30–31 octobre 2024 : Agile Tour Bordeaux 2024 - Bordeaux (France) 31 octobre 2024–3 novembre 2024 : PyCon.FR - Strasbourg (France) 6 novembre 2024 : Master Dev De France - Paris (France) 7 novembre 2024 : DevFest Toulouse - Toulouse (France) 8 novembre 2024 : BDX I/O - Bordeaux (France) 13–14 novembre 2024 : Agile Tour Rennes 2024 - Rennes (France) 16–17 novembre 2024 : Capitole Du Libre - Toulouse (France) 20–22 novembre 2024 : Agile Grenoble 2024 - Grenoble (France) 21 novembre 2024 : DevFest Strasbourg - Strasbourg (France) 21 novembre 2024 : Codeurs en Seine - Rouen (France) 27–28 novembre 2024 : Cloud Expo Europe - Paris (France) 28 novembre 2024 : Who Run The Tech ? - Rennes (France) 2–3 décembre 2024 : Tech Rocks Summit - Paris (France) 3 décembre 2024 : Generation AI - Paris (France) 3–5 décembre 2024 : APIdays Paris - Paris (France) 4–5 décembre 2024 : DevOpsRex - Paris (France) 4–5 décembre 2024 : Open Source Experience - Paris (France) 5 décembre 2024 : GraphQL Day Europe - Paris (France) 6 décembre 2024 : DevFest Dijon - Dijon (France) 22–25 janvier 2025 : SnowCamp 2025 - Grenoble (France) 30 janvier 2025 : DevOps D-Day #9 - Marseille (France) 6–7 février 2025 : Touraine Tech - Tours (France) 3 avril 2025 : DotJS - Paris (France) 16–18 avril 2025 : Devoxx France - Paris (France) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

Welcome to episode 274 of The Cloud Pod, where the forecast is always cloudy! Justin, Ryan and Matthew are your hosts this week as we explore the world of SnapShots, Maia, Open Source, and VMware – just to name a few of the topics. And stay tuned for an installment of our continuing Cloud Journey Series to explore ways to decrease tech debt, all this week on The Cloud Pod.   Titles we almost went with this week: The Cloud Pod in Parallel Cluster The Cloud Pod cringes at managing 1000 aws accounts The Cloud Pod welcomes Imagen 3 with less Wokeness The Cloud Pod wants to be instantly snapshotted The Cloud pod hates tech debt A big thanks to this week's sponsor: We're sponsorless! Want to get your brand, company, or service in front of a very enthusiastic group of cloud news seekers? You've come to the right place! Send us an email or hit us up on our slack channel for more info.  General News 00:32 Elasticsearch is Open Source, Again Shay Banon is pleased to call ElasticSearch and Kibana “open source” again.  He says everyone at Elastic is ecstatic to be open source again, it’s part of his and “Elastics DNA.”  They’re doing this by adding AGPL as another license option next to ELv2 and SSPL in the coming weeks.  They never stopped believing or behaving like an OSS company after they changed the license, but by being able to use the term open source and by using AGPL – an OSI approved license – removes any questions or fud people might have.  Shay says the change 3 years ago was because they had issues with AWS and the market confusion their offering was causing.  So, after trying all the other options, changing the license – all while knowing it would result in a fork with a different name – was the path they took.  While it was painful, they said it worked.  3 years later, Amazon is fully invested in their OpenSearch fork, the market confusion has mostly gone, and their partnership with AWS is stronger than ever. They are even being named partner of the year with AWS.  They want to “make life of our users as simple as possible,” so if you’re ok with the ELv2 or the SSPL, then you can keep using that license. They aren't removing anything, just giving you another option with AGPL. He calls out trolls and people who will pick at this announcement, so they are attempting to address the trolls in advance.  “Changing the license was a mistake, and Elastic now backtracks from it”. We removed a lot of market confusion when we changed our license 3 years ago. And because of our actions, a lot has changed. It's an entirely different landscape now. We aren't living in the past. We want to build a better future for our users. It's because we took action then, that we are in a position to take action now. “AGPL i

This week we dig back into home automation, we talk a bit about choosing cameras for a large camera system, and of course we answer your questions! -- During The Show -- 00:52 Intro Home automation Weekend of learning 03:48 Monitoring Remote Location (Cameras) - Rob Powerline adapters might work Ubiquiti Nano Beam Synology Surveillance Station (https://www.synology.com/en-global/surveillance) Frigate Do not put the NVR on the internet Privacy File server upload Home Assistant events 17:18 Camera Systems for Tribal Lands - William NDAA compliant cameras and NVRs ReoLink NVR banned ReoLink Cameras depends - bad idea NDAA compliant brands 360 Vision Technology (360 VTL) Avigilon Axis Communications BCD International Commend FLIR Geutebrück iryx JCI/Tyco Security Mobotix Pelco Rhombus Systems Seek Thermal Solink Vaion/Ava WatchGuard Main 3 NVR in use Exac Vision Avigilon Milestone NDAA conversation Noah's favorites Axis FLIR #### 25:09 Charlie Finds e-ink android - Charlie Boox Palma (https://shop.boox.com/products/palma) Why a camera? Nice for reading Lineage or Graphene will NOT work 27:57 ESPDevices for Light Switches - Avri Shelly's are ESP32 devices Devices can talk to each other 30:00 Beaming podcasts to Volumio and Roku - Tiny Pulse Audio Write in! 31:40 News Wire 4M Linux 46 - opensourcefeed.org (https://www.opensourcefeed.org/4mlinux-46-release/) Debain Bookwork 12.7 - debian.org (https://www.debian.org/News/2024/20240831) Porteus 1.6 - porteus.org (https://forum.porteus.org/viewtopic.php?t=11426) Rhino Linux 2nd Release - itsfoss.com (https://news.itsfoss.com/rhino-linux-2024-2-release/) GNU Screen 5 - theregister.com (https://www.theregister.com/2024/09/03/gnu_screen_5/) Wireshark 4.4 - wireshark.org (https://www.wireshark.org/docs/relnotes/wireshark-4.4.0) Bugzilla releases - bugzilla.org (https://www.bugzilla.org/blog/2024/09/03/release-of-bugzilla-5.2-5.0.4.1-and-4.4.14/) Armbian 24.8 - armbian.com (https://www.armbian.com/newsflash/armbian-24-8-yelt/) Elasticsearch and Kibana licensing - businesswire.com (https://www.businesswire.com/news/home/20240829537786/en/Elastic-Announces-Open-Source-License-for-Elasticsearch-and-Kibana-Source-Code) Xe2 Linux Support - wccftech.com (https://wccftech.com/intel-push-out-xe2-graphics-enablement-linux-6-12-kernel/) Cicada3301 - thehackernews.com (https://thehackernews.com/2024/09/new-rust-based-ransomware-cicada3301.html) New Phi-3.5 AI Models - infoq.com (https://www.infoq.com/news/2024/08/microsoft-phi-3-5/) Open-Source, EU AI Act Compliant LLMs - techzine.eu (https://www.techzine.eu/blogs/privacy-compliance/123863/aleph-alphas-open-source-llms-fully-comply-with-the-ai-act/) View on Why AI Models Should be Open and Free for All - businessinsider.com (https://www.businessinsider.com/anima-anandkumar-ai-climate-change-open-source-caltech-nvidia-2024-8) 33:53 Hoptodesk Comparison to Team Viewer Hoptodesk (https://www.hoptodesk.com/) Free & Open Source Cross platform E2E Encryption Can self host the server Wayland is not officially supported 38:05 EmuDeck ArsTechnica (https://arstechnica.com/gaming/2024/08/emudeck-machines-pack-popular-emulation-suite-in-linux-powered-plug-and-play-pc/) Seeking funding Already been doing this on the steamdeck For retro games Drawing unwanted attention Powered by Bazzite 41:05 Home Automation Zwave Great for nerds/tinkering Not for professional installs RadioRA 2 Licensed dedicated frequency Central planning Never had a failure Designed to be integrated Orbit Panels and Shelly Pro Line Game changer 100% reliable People don't want a wall of dimmers Seeed Studio mmWave Sensor (https://wiki.seeedstudio.com/mmwave_human_detection_kit/) I don't like WiFi for automation Steve's experience -- The Extra Credit Section -- For links to the articles and material referenced in this week's episode check out this week's page from our podcast dashboard! This Episode's Podcast Dashboard (http://podcast.asknoahshow.com/406) Phone Systems for Ask Noah provided by Voxtelesys (http://www.voxtelesys.com/asknoah) Join us in our dedicated chatroom #GeekLab:linuxdelta.com on Matrix (https://element.linuxdelta.com/#/room/#geeklab:linuxdelta.com) -- Stay In Touch -- Find all the resources for this show on the Ask Noah Dashboard Ask Noah Dashboard (http://www.asknoahshow.com) Need more help than a radio show can offer? Altispeed provides commercial IT services and they're excited to offer you a great deal for listening to the Ask Noah Show. Call today and ask about the discount for listeners of the Ask Noah Show! Altispeed Technologies (http://www.altispeed.com/) Contact Noah live [at] asknoahshow.com -- Twitter -- Noah - Kernellinux (https://twitter.com/kernellinux) Ask Noah Show (https://twitter.com/asknoahshow) Altispeed Technologies (https://twitter.com/altispeed)

Redis is no longer open source. Just a few months ago, in March 2024, the project was relicensed, leaving its vast community confused. But the community did not give up, and started work to fork Redis to keep it open.  In this episode, we delve into the Valkey project, a prominent fork of Redis, established under the Linux Foundation, which brought together important figures from the Redis community, as well as leading industry giants including AWS, Google Cloud, Oracle and others. Valkey has rapidly gained momentum and just reached General Availability (GA).  Join us as we explore the motivations behind Valkey's creation, hear first-hand stories on its foundation and journey to GA, and learn of its Redis compatibility, roadmap and implications for the open-source community.  Valkey's first Contributor Summit is taking place June 5-6 in Seattle and we will bring you announcements and updates hot off the summit. Our guest is Kyle Davis, the Senior Developer Advocate on the Valkey project, and a past contributor for Redis.  Kyle currently works at AWS, a founding member of Valkey, and has a long history with open source and with forks. He was a founding contributor to the OpenSearch project, which started as a fork of Elasticsearch and Kibana after the latter's relicensing off OSS. Most recently Kyle worked to build a community around Bottlerocket OSS project.   The episode was live-streamed on 10 June 2024 and the video is available at youtube.com/live/HQ7TAdQpxu4 OpenObservability Talks episodes are released monthly, on the last Thursday of each month and are available for listening on your favorite podcast app and on YouTube. We live-stream the episodes on Twitch and YouTube Live - tune in to see us live, and chime in with your comments and questions on the live chat. ⁠⁠https://www.youtube.com/@openobservabilitytalks⁠   https://www.twitch.tv/openobservability⁠ Show Notes: 01:12 - Episode intro, Kyle Davis' Redis background  05:43 - Redis relicensing off open source  10:10 - Valkey vs. other Redis open source forks 16:50 - drop-in replacement of Redis 19:35 - Redis user experience during the relicensing 28:50 - From fork to GA in less than a month 34:00 - Valkey roadmap and Contributor Summit updates 40:00 - Valkey's Technical Steering Committee and leadership 44:14 - what Valkey latest GA is about  Resources: Valkey announced: https://www.linkedin.com/posts/horovits_redis-opensource-activity-7179186700470861824-Gghq Valkey first GA and new member companies: https://www.linkedin.com/posts/horovits_redis-valkey-valkey-activity-7186263342041198593-fsY3 Announcements from Valkey's first Contributor Summit: https://www.linkedin.com/posts/horovits_valkey-welcomes-new-partners-amid-growing-activity-7209084153718362112-OfdI/ For Kubernetes 10th anniversary - special episode with Kelsey Hightower: https://logz.io/blog/kubernetes-and-beyond-2023-reflection/?utm_source=devrel&utm_medium=devrel Socials: Twitter:⁠ https://twitter.com/OpenObserv⁠ YouTube: ⁠https://www.youtube.com/@openobservabilitytalks⁠ Dotan Horovits ============ Twitter: @horovits LinkedIn: in/horovits Mastodon: @horovits@fosstodon Kyle Davis ======== LinkedIn: linkedin.com/in/kyle-davis-linux/ Mastodon: @linux_mclinuxface@fosstodon.org

.

On ne présente plus la fameuse stack «ELK» (Elasticsearch, Logstash, Kibana). Né au début des années 2010, Elasticsearch a connu un rapide essor, qui s'est accéléré avec la création de la société Elastic NV qui en finance le développement à l'aide d'un ensemble de services payants. Après avoir traversé quelques transformations du monde de la Tech (le passage au Cloud, la création des «as a Service», et l'émergence des I.A.), où en est Elastic ? Vers où se dirige Elasticsearch ? Avec David Pilato, Developer Evangelist chez Elastic, prenons le temps de faire le point sur cette solution qui a su se réinventer régulièrement tout en gardant son esprit originel.   Tu likes/aimes/partage: Le podcast de musique de David: https://podcasts.apple.com/fr/podcast/dj-dadoo-net-mixes/id505824965 Et son site (qui diffuse le podcast directement): https://djdadoo.pilato.fr/

CHAOSScast – Episode 74 On this episode, our host Georg Link kicks off the discussion, introducing a stellar lineup of panelists including Sean Goggins, Yehui Wang, Mike Nolan, and Cali Dolfi. The topics discussed today are the CHAOSS software, Augur, and GrimoireLab, and the different applications built on top of this software. The panel members discuss the projects they are involved in, such as the Augur project, OSS Compass, and Project Aspen's 8Knot. Then, we'll delve into Mystic's prototype software, aiming to transform how academic contributions are recognized and valued. The discussion dives deep into the role of CHAOSS software in open source and community health, talks about Augur and GrimoireLab projects, ecosystem-level analysis, and data visualization. Press download now to hear more! [00:00:58] The panelists each introduce themselves. [00:03:03] Georg explains the origins of CHAOSS software, particularly Augur and Grimoire Lab, and their development. He dives into Grimoire Lab's focus on data quality, flexibility, and its identity management tool, Sorting Hat. [00:05:55] Sean details Augur's inception, its focus on a relational database, and its capabilities in data collection and validation. Georg and Sean recall Augur's early days, focusing on GitHub archive data, and its evolution into a comprehensive system. [00:09:28] Yehui discusses OSS Compass, its goals, the integration of metrics models, and the choice of using Grimoire Lab as a backend. He elaborates on OSS Compass's ease of use and the adoption of new data sources like Gitee. [00:14:16] Mike inquires about the handling of the vast number of repositories on Gitee, and Yehui explains using a message bus and RabbitMQ for both data handling and parallel processing. Sean clarifies that Gitee is a Git platform similar to GitHub and GitLab, and OSS Compass is the metrics and modeling tool. [00:15:29] Cali asks about the visualization tool used, and Yehui mentions moving away from Kibana to front-end technologies and libraries like ECharts for creating visualizations, which is an Apache open source project. [00:16:29] Cali describes 8Knot under Project Aspen built in Plotly Dash and Repel, focusing on mapping open source ecosystems using Augur data. She emphasizes the data science approach to analyzing open source communities and the templated nature of 8Knot for easy visualization creation by data scientists. [00:20:19] Sean comments on the ease of adding new visualizations with Dash Plotly technology in 8Knot. Cali adds that new visualizations can be easily made an that 8Knot is connected to a maintained Augur database but can also be forked for specific community and company needs. [00:2342] Georg underlines the importance of ecosystem-level analysis, especially for software supply chain security. Cali shares the goals of analyzing ecosystems to understand relationships between projects, influenced by Red Hat's interests in investing in interconnected communities. [00:26:30] The conversation shifts to Mystic, and Mike describes it as a prototype software integrating both GrimoireLab and Augur, with the goal of better integrating these projects through development. [00:27:30] Mike outlines Mystic's goal to serve as a front-end to date collection systems, with a specific focus on the academic community's contributions to technology research. He envisions Mystic as a tool for academics to measure community health and impact of their projects, aiding in tenure and promotion cases. [00:30:52] Yehui asks about integration of Grimoire Lab and Augur within Mystic and the selection of components for the solution. Mike explains the early stages of integration and the plan to combine data collection services from GrimoireLab into Augur to support undergraduate student development. [00:32:30] Mike details research on Mystic, including interviews with faculty from various departments to understand their digital collaboration and artifact creation. He aims to develop generalized models of collaboration applicable to multiple data sources, allowing systems like Mystic to support diverse academic disciplines. Value Adds (Picks) of the week: [00:36:26] Georg's pick is focusing on the slogan, “One day at a time.” [00:37:12] Cali's pick is doing a Friendsgiving this week. [00:38:08] Sean's pick is the launch of the tv show ‘Moonlighting' from the 80's. [00:38:49] Yehui's pick is riding his bike to work which is peaceful for him. [00:39:52] Mike's pick is attending The Turing Way Book Dash. Panelists: Georg Link Sean Goggins Michael Nolan Cali Dolfi Yehui Wang Links: CHAOSS (https://chaoss.community/) CHAOSS Project X/Twitter (https://twitter.com/chaossproj?lang=en) CHAOSScast Podcast (https://podcast.chaoss.community/) podcast@chaoss.community (mailto:podcast@chaoss.community) Ford Foundation (https://www.fordfoundation.org/) Georg Link Website (https://georg.link/) Sean Goggins Website (https://www.seangoggins.net/) Mike Nolan LinkedIn (https://www.linkedin.com/in/mikenolansoftware/?originalSubdomain=uk) Cali Dolfi LinkedIn (https://www.linkedin.com/in/calidolfi/) Yehui Wang GitHub (https://github.com/eyehwan) Augur (https://github.com/chaoss/augur) GrimoireLab (https://chaoss.github.io/grimoirelab/) Perceval-GitHub (https://github.com/chaoss/grimoirelab-perceval) Gitee (https://gitee.com/) RabbitMQ (https://www.rabbitmq.com/) OSS Compass-GitHub (https://github.com/oss-compass) Kibana (https://www.elastic.co/kibana) Apache ECharts (https://echarts.apache.org/en/index.html) 8Knot (https://eightknot.osci.io/) Building an open source community health analytics platform (Mystic) (https://opensource.com/article/21/9/openrit-mystic) The Turing Way Book Dashes (https://the-turing-way.netlify.app/community-handbook/bookdash.html) Special Guests: Cali Dolfi, Mike Nolan, and Yehui Wang.

Victoria is joined by guest co-host Joe Ferris, CTO at thoughtbot, and Seif Lotfy, the CTO and Co-Founder of Axiom. Seif discusses the journey, challenges, and strategies behind his data analytics and observability platform. Seif, who has a background in robotics and was a 2008 Sony AIBO robotic soccer world champion, shares that Axiom pivoted from being a Datadog competitor to focusing on logs and event data. The company even built its own logs database to provide a cost-effective solution for large-scale analytics. Seif is driven by his passion for his team and the invaluable feedback from the community, emphasizing that sales validate the effectiveness of a product. The conversation also delves into Axiom's shift in focus towards developers to address their need for better and more affordable observability tools. On the business front, Seif reveals the company's challenges in scaling across multiple domains without compromising its core offerings. He discusses the importance of internal values like moving with urgency and high velocity to guide the company's future. Furthermore, he touches on the challenges and strategies of open-sourcing projects and advises avoiding platforms like Reddit and Hacker News to maintain focus. Axiom (https://axiom.co/) Follow Axiom on LinkedIn (https://www.linkedin.com/company/axiomhq/), X (https://twitter.com/AxiomFM), GitHub (https://github.com/axiomhq), or Discord (https://discord.com/invite/axiom-co). Follow Seif Lotfy on LinkedIn (https://www.linkedin.com/in/seiflotfy/) or X (https://twitter.com/seiflotfy). Visit his website at seif.codes (https://seif.codes/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido, and with me today is Seif Lotfy, CTO and Co-Founder of Axiom, the best home for your event data. Seif, thank you for joining me. SEIF: Hey, everybody. Thanks for having me. This is awesome. I love the name of the podcast, given that I used to compete in robotics. VICTORIA: What? All right, we're going to have to talk about that. And I also want to introduce a guest co-host today. Since we're talking about cloud, and observability, and data, I invited Joe Ferris, thoughtbot CTO and Director of Development of our platform engineering team, Mission Control. Welcome, Joe. How are you? JOE: Good, thanks. Good to be back again. VICTORIA: Okay. I am excited to talk to you all about observability. But I need to go back to Seif's comment on competing with robots. Can you tell me a little bit more about what robots you've built in the past? SEIF: I didn't build robots; I used to program them. Remember the Sony AIBOs, where Sony made these dog robots? And we would make them compete. There was an international competition where we made them play soccer, and they had to be completely autonomous. They only communicate via Bluetooth or via wireless protocols. And you only have the camera as your sensor as well as...a chest sensor throws the ball near you, and then yeah, you make them play football against each other, four versus four with a goalkeeper and everything. Just look it up: RoboCup AIBO. Look it up on YouTube. And I...2008 world champion with the German team. VICTORIA: That sounds incredible. What kind of crowds are you drawing out for a robot soccer match? Is that a lot of people involved with that? SEIF: You would be surprised how big the RoboCup competition is. It's ridiculous. VICTORIA: I want to go. I'm ready. I want to, like, I'll look it up and find out when the next one is. SEIF: No more Sony robots but other robots. Now, there's two-legged robots. So, they make them play as two-legged robots, much slower than four-legged robots, but works. VICTORIA: Wait. So, the robots you were playing soccer with had four legs they were running around on? SEIF: Yeah, they were dogs [laughter]. VICTORIA: That's awesome. SEIF: We all get the same robot. It's just a competition on software, right? On a software level. And some other competitions within the RoboCup actually use...you build your own robot and stuff like that. But this one was...it's called the Standard League, where we all have a robot, and we have to program it. JOE: And the standard robot was a dog. SEIF: Yeah, I think back then...we're talking...it's been a long time. I think it started in 2001 or something. I think the competition started in 2001 or 2002. And I compete from 2006 to 2008. Robots back then were just, you know, simple. VICTORIA: Robots today are way too complicated [laughs]. SEIF: Even AI is more complicated. VICTORIA: That's right. Yeah, everything has gotten a lot more complicated [laughs]. I'm so curious how you went from being a world-champion robot dog soccer player [laughs] programmer [laughs] to where you are today with Axiom. Can you tell me a little bit more about your journey? SEIF: The journey is interesting because it came from open source. I used to do open source on the side a lot–part of the GNOME Project. That's where I met Neil and the rest of my team, Mikkel Kamstrup, the whole crowd, basically. We worked on GNOME. We worked on Ubuntu. Like, most of them were working professionally on it. I was working for another company, but we worked on the same project. We ended up at Xamarin, which was bought by Microsoft. And then we ended up doing Axiom. But we've been around each other professionally since 2009, most of us. It's like a little family. But how we ended up exactly in observability, I think it's just trying to fix pain points in my life. VICTORIA: Yeah, I was reading through the docs on Axiom. And there's an interesting point you make about organizations having to choose between how much data they have and how much they want to spend on it. So, maybe you can tell me a little bit more about that pain point and what you really found in the early stages that you wanted to solve. SEIF: So, the early stages of what we wanted to solve we were mainly dealing with...so, the early, early stage, we were actually trying to be a Datadog competitor, where we were going to be self-hosted. Eventually, we focused on logs because we found out that's what was a big problem for most people, just event data, not just metric but generally event data, so logs, traces, et cetera. We built out our own logs database completely from scratch. And one of the things we stumbled upon was; basically, you have three things when it comes to logging, which is low cost, low latency, and large scale. That's what everybody wants. But you can't get all three of them; you can only get two of them. And we opted...like, we chose large scale and low cost. And when it comes to latency, we say it should be just fast enough, right? And that's where we focused on, and this is how we started building it. And with that, this is how we managed to stand out by just having way lower cost than anybody else in the industry and dealing with large scale. VICTORIA: That's really interesting. And how did you approach making the ingestion pipeline for masses amount of data more efficient? SEIF: Just make it coordination-free as possible, right? And get rid of Kafka because Kafka just, you know, drains your...it's where you throw in money. Like maintaining Kafka...it's like back then Elasticsearch, right? Elasticsearch was the biggest part of your infrastructure that would cost money. Now, it's also Kafka. So, we found a way to have our own internal way of queueing things without having to rely on Kafka. As I said, we wrote everything from scratch to make it work. Like, every now and then, I think that we can spin this out of the company and make it a new product. But now, eyes on the prize, right? JOE: It's interesting to hear that somebody who spent so much time in the open-source community ended up rolling their own solution to so many problems. Do you feel like you had some lessons learned from open source that led you to reject solutions like Kafka, or how did that journey go? SEIF: I don't think I'm rejecting Kafka. The problem is how Kafka is built, right? Kafka is still...you have to set up all these servers. They have to communicate, et cetera, etcetera. They didn't build it in a way where it's stateless, and that's what we're trying to go to. We're trying to make things as stateless as possible. So, Kafka was never built for the cloud-native era. And you can't really rely on SQS or something like that because it won't deal with this high throughput. So, that's why I said, like, we will sacrifice some latency, but at least the cost is low. So, if messages show after half a second or a second, I'm good. It doesn't have to be real-time for me. So, I had to write a couple of these things. But also, it doesn't mean that we reject open source. Like, we actually do like open source. We open-source a couple of libraries. We contribute back to open source, right? We needed a solution back then for that problem, and we couldn't find any. And maybe one day, open source will have, right? JOE: Yeah. I was going to ask if you considered open-sourcing any of your high latency, high throughput solutions. SEIF: Not high latency. You make it sound bad. JOE: [laughs] SEIF: You make it sound bad. It's, like, fast enough, right? I'm not going to compete on milliseconds because, also, I'm competing with ClickHouse. I don't want to compete with ClickHouse. ClickHouse is low latency and large scale, right? But then the cost is, you know, off the charts a bit sometimes. I'm going the other route. Like, you know, it's fast enough. Like, how, you know, if it's under two, three seconds, everybody's happy, right? If the results come within two, three seconds, everybody is happy. If you're going to build a real-time trading system on top of it, I'll strongly advise against that. But if you're building, you know, you're looking at dashboards, you're more in the observability field, yeah, we're good. VICTORIA: Yeah, I'm curious what you found, like, which customer personas that market really resonated with. Like, is there a particular, like, industry type where you're noticing they really want to lower their cost, and they're okay with this just fast enough latency? SEIF: Honestly, with the current recession, everybody is okay with giving up some of the speed to reduce the money because I think it's not linear reduction. It's more exponential reduction at this point, right? You give up a second, and you're saving 30%. You give up two seconds, all of a sudden, you're saving 80%. So, I'd say in the beginning, everybody thought they need everything to be very, very fast. And now they're realizing, you know, with limitations you have around your budget and spending, you're like, okay, I'm okay with the speed. And, again, we're not slow. I'm just saying people realize they don't need everything under a second. They're okay with waiting for two seconds. VICTORIA: That totally resonates with me. And I'm curious if you can add maybe a non-technical or a real-life example of, like, how this impacts the operations of a company or organization, like, if you can give us, like, a business-y example of how this impacts how people work. SEIF: I don't know how, like, how do people work on that? Nothing changed, really. They're still doing the, like...really nothing because...and that aspect is you run a query, and, again, as I said, you're not getting the result in a second. You're just waiting two seconds or three seconds, and it's there. So, nothing really changed. I think people can wait three seconds. And we're still like–when I say this, we're still faster than most others. We're just not as fast as people who are trying to compete on a millisecond level. VICTORIA: Yeah, that's okay. Maybe I'll take it back even, like, a step further, right? Like, our audience is really sometimes just founders who almost have no formal technical training or background. So, when we talk about observability, sometimes people who work in DevOps and operations all understand it and kind of know why it's important [laughs] and what we're talking about. So, maybe you could, like, go back to -- SEIF: Oh, if you're asking about new types of people who've been using it -- VICTORIA: Yeah. Like, if you're going to explain to, like, a non-technical founder, like, why your product is important, or, like, how people in their organization might use it, what would you say? SEIF: Oh, okay, if you put it like that. It's more of if you have data, timestamp data, and you want to run analytics on top of it, so that could be transactions, that could be web vitals, rather than count every time somebody visits, you have a timestamp. So, you can count, like, how many visitors visited the website and what, you know, all these kinds of things. That's where you want to use something like Axiom. That's outside the DevOps space, of course. And in DevOps space, there's so many other things you use Axiom for, but that's outside the DevOps space. And we actually...we implemented as zero-config integration with Vercel that kind of went viral. And we were, for a while, the number one enterprise for self-integration because so many people were using it. So, Vercel users are usually not necessarily writing the most complex backends, but a lot of things are happening on the front-end side of things. And we would be giving them dashboards, automated dashboards about, you know, latencies, and how long a request took, and how long the response took, and the content type, and the status codes, et cetera, et cetera. And there's a huge user base around that. VICTORIA: I like that. And it's something, for me, you know, as a managing director of our platform engineering team, I want to talk more to founders about. It's great that you put this product and this app out into the world. But how do you know that people are actually using it? How do you know that people, like, maybe, are they all quitting after the first day and not coming back to your app? Or maybe, like, the page isn't loading or, like, it's not working as they expected it to. And, like, if you don't have anything observing what users are doing in your app, then it's going to be hard to show that you're getting any traction and know where you need to go in and make corrections and adjust. SEIF: We have two ways of doing this. Right now, internally, we use our own tools to see, like, who is sending us data. We have a deployment that's monitoring production deployment. And we're just, you know, seeing how people are using it, how much data they're sending every day, who stopped sending data, who spiked in sending data sets, et cetera. But we're using Mixpanel, and Dominic, our Head of Product, implemented a couple of key metrics to that for that specifically. So, we know, like, what's the average time until somebody starts going from building its own queries with the builder to writing APL, or how long it takes them from, you know, running two queries to five queries. And, you know, we just start measuring these things now. And it's been going...we've been growing healthy around that. So, we tend to measure user interaction, but also, we tend to measure how much data is being sent. Because let's keep in mind, usually, people go in and check for things if there's a problem. So, if there's no problem, the user won't interact with us much unless there's a notification that kicks off. We also just check, like, how much data is being sent to us the whole time. VICTORIA: That makes sense. Like, you can't just rely on, like, well, if it was broken, they would write a [chuckles], like, a question or something. So, how do you get those metrics and that data around their interactions? So, that's really interesting. So, I wonder if we can go back and talk about, you know, we already mentioned a little bit about, like, the early days of Axiom and how you got started. Was there anything that you found in the early discovery process that was surprising and made you pivot strategy? SEIF: A couple of things. Basically, people don't really care about the tech as much as they care [inaudible 12:51] and the packaging, so that's something that we had to learn. And number two, continuous feedback. Continuous feedback changed the way we worked completely, right? And, you know, after that, we had a Slack channel, then we opened a Discord channel. And, like, this continuous feedback coming in just helps with iterating, helps us with prioritizing, et cetera. And that changed the way we actually developed product. VICTORIA: You use Slack and Discord? SEIF: No. No Slack anymore. We had a community Slack. We had a community [inaudible 13:19] Slack. Now, there's no community Slack. We only have a community Discord. And the community Slack is...sorry, internally, we use Slack, but there's a community Discord for the community. JOE: But how do you keep that staffed? Is it, like, everybody is in the Discord during working hours? Is it somebody's job to watch out for community questions? SEIF: I think everybody gets involved now just...and you can see it. If you go on our Discord, you will just see it. Just everyone just gets involved. I think just people are passionate about what they're doing. At least most people are involved on Discord, right? Because there's, like, Discord the help sections, and people are just asking questions and other people answering. And now, we reached a point where people in the community start answering the questions for other people in the community. So, that's how we see it's starting to become a healthy community, et cetera. But that is one of my favorite things: when I see somebody from the community answering somebody else, that's a highlight for me. Actually, we hired somebody from that community because they were so active. JOE: Yeah, I think one of the biggest signs that a product is healthy is when there's a healthy ecosystem building up around it. SEIF: Yeah, and Discord reminds me of the old days of open sources like IRC, just with memes now. But because all of us come from the old IRC days, being on Discord and chatting around, et cetera, et cetera, just gives us this momentum back, gave us this momentum back, whereas Slack always felt a bit too businessy to me. JOE: Slack is like IRC with emoji. Discord is IRC with memes. SEIF: I would say Slack reminds me somehow of MSN Messenger, right? JOE: I feel like there's a huge slam on MSN Messenger here. SEIF: [laughs] What do you guys use internally, Slack or? I think you're using Slack, right? Or Teams. Don't tell me you're using Teams. JOE: No, we're using Slack. SEIF: Okay, good, because I shit talk. Like, there is this, I'll sh*t talk here–when I start talking about Teams, so...I remember that one thing Google did once, and that failed miserably. JOE: Google still has, like, seven active chat products. SEIF: Like, I think every department or every, like, group of engineers just uses one of them internally. I'm not sure. Never got to that point. But hey, who am I to judge? VICTORIA: I just feel like I end up using all of them, and then I'm just rotating between different tabs all day long. You maybe talked me into using Discord. I feel like I've been resisting it, but you got me with the memes. SEIF: Yeah, it's definitely worth it. It's more entertaining. More noise, but more entertaining. You feel it's alive, whereas Slack is...also because there's no, like, history is forever. So, you always go back, and you're like, oh my God, what the hell is this? VICTORIA: Yeah, I have, like, all of them. I'll do anything. SEIF: They should be using Axiom in the background. Just send data to Axiom; we can keep your chat history. VICTORIA: Yeah, maybe. I'm so curious because, you know, you mentioned something about how you realized that it didn't matter really how cool the tech was if the product packaging wasn't also appealing to people. Because you seem really excited about what you've built. So, I'm curious, so just tell us a little bit more about how you went about trying to, like, promote this thing you built. Or was, like, the continuous feedback really early on, or how did that all kind of come together? SEIF: The continuous feedback helped us with performance, but actually getting people to sign up and pay money it started early on. But with Vercel, it kind of skyrocketed, right? And that's mostly because we went with the whole zero-config approach where it's just literally two clicks. And all of a sudden, Vercel is sending your data to Axiom, and that's it. We will create [inaudible 16:33]. And we worked very closely with Vercel to do this, to make this happen, which was awesome. Like, yeah, hats off to them. They were fantastic. And just two clicks, three clicks away, and all of a sudden, we created Axiom organization for you, the data set for you. And then we're sending it...and the data from Vercel is being forwarded to it. I think that packaging was so simple that it made people try it out quickly. And then, the experience of actually using Axiom was sticky, so they continued using it. And then the price was so low because we give 500 gigs for free, right? You send us 500 gigs a month of logs for free, and we don't care. And you can start off here with one terabyte for 25 bucks. So, people just start signing up. Now, before that, it was five terabytes a month for $99, and then we changed the plan. But yeah, it was cheap enough, so people just start sending us more and more and more data eventually. They weren't thinking...we changed the way people start thinking of “what am I going to send to Axiom” or “what am I going to send to my logs provider or log storage?” To how much more can I send? And I think that's what we wanted to reach. We wanted people to think, how much more can I send? JOE: You mentioned latency and cost. I'm curious about...the other big challenge we've seen with observability platforms, including logs, is cardinality of labels. Was there anything you had to sacrifice upfront in terms of cardinality to manage either cost or volume? SEIF: No, not really. Because the way we designed it was that we should be able to deal with high cardinality from scratch, right? I mean, there's open-source ways of doing, like, if you look at how, like, a column store, if you look at a column store and every dimension is its own column, it's just that becomes, like, you can limit on the amount of columns you're creating, but you should never limit on the amount of different values in a column could be. So, if you're having something like stat tags, right? Let's say hosting, like, hostname should be a column, but then the different hostnames you have, we never limit that. So, the cardinality on a value is something that is unlimited for us, and we don't really see it in cost. It doesn't really hit us on cost. It reflects a bit on compression if you get into technical details of that because, you know, high cardinality means a lot of different data. So, compression is harder, but it's not repetitive. But then if you look at, you know, oh, I want to send a lot of different types of fields, not values with fields, so you have hostname, and latency, and whatnot, et cetera, et cetera, yeah, that's where limitation starts because then they have...it's like you're going to a wide range of...and a wider dimension. But even that, we, yeah, we can deal with thousands at this point. And we realize, like, most people will not need more than three or four. It's like a Postgres table. You don't need more than 3,000 to 4000 columns; else, you know, you're doing a lot. JOE: I think it's actually pretty compelling in terms of cost, though. Like, that's one of the things we've had to be most careful about in terms of containing cost for metrics and logs is, a lot of providers will...they'll either charge you based on the number of unique metric combinations or the performance suffers greatly. Like, we've used a lot of Prometheus-based solutions. And so, when we're working with developers, even though they don't need more than, you know, a few dozen metric combinations most of the time, it's hard for people to think of what they need upfront. It's much easier after you deploy it to be able to query your data and slice it retroactively based on what you're seeing. SEIF: That's the detail. When you say we're using Prometheus, a lot of the metrics tools out there are using, just like Prometheus, are using the Gorilla data structure. And the real data structure was never designed to deal with high cardinality labels. So, basically, to put it in a simple way, every combination of tags you send for metrics is its own file on disk. That's, like, the very simple way of explaining this. And then, when you're trying to search through everything, right? And you have a lot of these combinations. I actually have to get all these files from this conversion back together, you know, and then they're chunked, et cetera. So, it's a problem. Generally, how metrics are doing it...most metrics products are using it, even VictoriaMetrics, et cetera. What they're doing is they're using either the Prometheus TSDB data structure, which is based on Gorilla. Influx was doing the same thing. They pivoted to using more and more like the ones we use, and Honeycomb uses, right? So, we might not be as fast on metrics side as these highly optimized. But then when it comes to high [inaudible 20:49], once we start dealing with high cardinality, we will be faster than those solutions. And that's on a very technical level. JOE: That's pretty cool. I realize we're getting pretty technical here. Maybe it's worth defining cardinality for the audience. SEIF: Defining cardinality to the...I mean, we just did that, right? JOE: What do you think, Victoria? Do you know what cardinality is now? [laughs] VICTORIA: All right. Now I'm like, do I know? I was like, I think I know what it means. Cardinality is, like, let's say you have a piece of data like an event or a transaction. SEIF: It's like the distinct count on a property that gives you the cardinality of a property. VICTORIA: Right. It's like how many pieces of information you have about that one event, basically, yeah. JOE: But with some traditional metrics stores, it's easy to make mistakes. For example, you could have unbounded cardinality by including response time as one of the labels -- SEIF: Tags. JOE: And then it's just going to -- SEIF: Oh, no, no. Let me give you a better one. I put in timestamp at some point in my life. JOE: Yeah, I feel like everybody has done that one. [laughter] SEIF: I've put a system timestamp at some point in my life. There was the actual timestamp, and there was a system timestamp that I would put because I wanted to know when the...because I couldn't control the timestamp, and the only timestamp I had was a system timestamp. I would always add the actual timestamp of when that event actually happened into a metric, and yeah, that did not scale. MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you're tight on time and investment, which is why we've created targeted 1-hour remote workshops to help you develop a concrete plan for your product's next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at tbot.io/entrepreneurs. VICTORIA: Yeah. I wonder if you could maybe share, like, a story about when it's gone wrong, and you've suddenly charged a lot of money [laughs] just to get information about what's happening in the system. Any, like, personal experiences with observability that kind of informed what you did with Axiom? SEIF: Oof, I have a very bad one, like, a very, very bad one. I used to work for a company. We had to deploy Elasticsearch on Windows Servers, and it was US-East-1. So, just a combination of Elasticsearch back in 2013, 2014 together with Azure and Windows Server was not a good idea. So, you see where this is going, right? JOE: I see where it's going. SEIF: Eventually, we had, like, we get all these problems because we used Elasticsearch and Kibana as our, you know, observability platform to measure everything around the product we were building. And funny enough, it cost us more than actually maintaining the infrastructure of the product. But not just that, it also kept me up longer because most of the downtimes I would get were not because of the product going down. It's because my Elasticsearch cluster started going down, and there's reasons for that. Because back then, Microsoft Azure thought that it's okay for any VM to lose connection with the rest of the VMs for 30 seconds per day. And then, all of a sudden, you have Elasticsearch with a split-brain problem. And there was a phase where I started getting alerted so much that back then, my partner threatened to leave me. So I bought a...what I think was a shock bracelet or a shock collar via Bluetooth, and I connected it to phone for any notification. And I bought that off Alibaba, by the way. And I would charge it at night, put it on my wrist, and go to sleep. And then, when alert happens, it will fully discharge the battery on me every time. JOE: Okay, I have to admit, I did not see where that was going. SEIF: Yeah, did that for a while; definitely did not save my relationship either. But eventually, that was the point where, you know, we started looking into other observability tools like Datadog, et cetera, et cetera, et cetera. And that's where the actual journey began, where we moved away from Elasticsearch and Kibana to look for something, okay, that we don't have to maintain ourselves and we can use, et cetera. So, it's not about the costs as much; it was just pain. VICTORIA: Yeah, pain is a real pain point, actual physical [chuckles] and emotional pain point [laughter]. What, like, motivates you to keep going with Axiom and to keep, like, the wind in your sails to keep working on it? SEIF: There's a couple of things. I love working with my team. So, honestly, I just wake up, and I compliment my team. I just love working with them. They're a lot of fun to work with. And they challenge me, and I challenge them back. And I upset them a lot. And they can't upset me, but I upset them. But I love working with them, and I love working with that team. And the other thing is getting, like, having this constant feedback from customers just makes you want to do more and, you know, close sales, et cetera. It's interesting, like, how I'm a very technical person, and I'm more interested in sales because sales means your product works, the product, the technical parts, et cetera. Because if technically it's not working, you can't build a product on top of it. And if you're not selling it, then what's the point? You only sell when the product is good, more or less, unless you're Oracle. VICTORIA: I had someone ask me about Oracle recently, actually. They're like, "Are you considering going back to it?" And I'm maybe a little allergic to it from having a federal consulting background [laughs]. But maybe they'll come back around. I don't know. We'll see. SEIF: Did you sell your soul back then? VICTORIA: You know, I feel like I just grew up in a place where that's what everyone did was all. SEIF: It was Oracle, IBM, or HP back in the day. VICTORIA: Yeah. Well, basically, when you're working on applications that were built in, like, the '80s, Oracle was, like, this hot, new database technology [laughs] that they just got five years ago. So, that's just, yeah, interesting. SEIF: Although, from a database perspective, they did a lot of the innovations. A lot of first innovations could have come from Oracle. From a technical perspective, they're ridiculous. I'm not sure from a product perspective how good they are. But I know their sales team is so big, so huge. They don't care about the product anymore. They can still sell. VICTORIA: I think, you know, everything in tech is cyclical. So, you know, if they have the right strategy and they're making some interesting changes over there, there's always a chance [laughs]. Certain use cases, I mean, I think that's the interesting point about working in technology is that you know, every company is a tech company. And so, there's just a lot of different types of people, personas, and use cases for different types of products. So, I wonder, you know, you kind of mentioned earlier that, like, everyone is interested in Axiom. But, you know, I don't know, are you narrowing the market? Or, like, how are you trying to kind of focus your messaging and your sales for Axiom? SEIF: I'm trying to focus on developers. So, we're really trying to focus on developers because the experience around observability is crap. It's stupid expensive. Sorry for being straightforward, right? And that's what we're trying to change. And we're targeting developers mainly. We want developers to like us. And we'll find all these different types of developers who are using it, and that's the interesting thing. And because of them, we start adding more and more features, like, you know, we added tracing, and now that enables, like, billions of events pushed through for, you know, again, for almost no money, again, $25 a month for a terabyte of data. And we're doing this with metrics next. And that's just to address the developers who have been giving us feedback and the market demand. I will sum it up, again, like, the experience is crap, and it's stupid expensive. I think that's the [inaudible 28:07] of observability is just that's how I would sum it up. VICTORIA: If you could go back in time and talk to yourself when you were still a developer, now that you're CTO, what advice would you give yourself? JOE: Besides avoiding shock collars. VICTORIA: [laughs] Yes. SEIF: Get people's feedback quickly so you know you're on the right track. I think that's very, very, very, very important. Don't just work in the dark, or don't go too long into stealth mode because, eventually, people catch up. Also, ship when you're 80% ready because 100% is too late. I think it's the same thing here. JOE: Ship often and early. SEIF: Yeah, even if it's not fully ready, it's still feedback. VICTORIA: Ship often and early and talk to people [laughs]. Just, do you feel like, as a developer, did you have the skills you needed to be able to get the most out of those feedback and out of those conversations you were having with people around your product? SEIF: I still don't think I'm good enough. You're just constantly learning, right? I just accepted I'm part of a team, and I have my contributions. But as an individual, I still don't think I know enough. I think there's more I need to learn at this point. VICTORIA: I wonder, what questions do you have for me or Joe? SEIF: How did you start your podcast, and why the name? VICTORIA: Oh, man, I hope I can answer. So, the podcast was started...I think it's, like, we're actually about to be at our 500th Episode. So, I've only been a host for the last year. Maybe Joe even knows more than I do. But what I recall is that one person at thoughtbot thought it would be a great idea to start a podcast, and then they did it. And it seems like the whole company is obsessed with robots. I'm not really sure where that came from. There used to be a tiny robot in the office, is what I remember. And people started using that as, like, the mascot. And then, yeah, that's it, that's the whole thing. SEIF: Was the robot doing anything useful or just being cute? JOE: It was just cute, and it's hard to make a robot cute. SEIF: Was it a real robot, or was it like a -- JOE: No, there was, at one point, a toy robot. The name...I actually forget the origin–origin of the name, but the name Giant Robots comes from our blog. So, we named the podcast the same as the blog: Giant Robots Smashing Into Other Giant Robots. SEIF: Yes, it's called transformers. VICTORIA: Yeah, I like it. It's, I mean, now I feel like -- SEIF: [laughs] VICTORIA: We got to get more, like, robot dogs involved [laughs] in the podcast. SEIF: Like, I wanted to add one thing when we talked about, you know, what gets me going. And I want to mention that I have a six-month-old son now. He definitely adds a lot of motivation for me to wake up in the morning and work. But he also makes me wake up regardless if I want to or not. VICTORIA: Yeah, you said you had invented an alarm clock that never turns off. Never snoozes [laughs]. SEIF: Yes, absolutely. VICTORIA: I have the same thing, but it's my dog. But he does snooze, actually. He'll just, like, get tired and go back to sleep [laughs]. SEIF: Oh, I have a question. Do dogs have a Tamagotchi phase? Because, like, my son, the first three months was like a Tamagotchi. It was easy to read him. VICTORIA: Oh yeah, uh-huh. SEIF: Noisy but easy. VICTORIA: Yes, yes. SEIF: Now, it's just like, yeah, I don't know, like, the last month he has opinions at six months. I think it's because I raised him in Europe. I should take him back to the Middle East [laughs]. No opinions. VICTORIA: No, dogs totally have, like, a communication style, you know, I pretty much know what he, I mean, I can read his mind, obviously [laughs]. SEIF: Sure, but that's when they grow a bit. But what when they were very...when the dog was very young? VICTORIA: Yeah, they, I mean, they also learn, like, your stuff, too. So, they, like, learn how to get you to do stuff or, like, I know she'll feed me if I'm sitting here [laughs]. SEIF: And how much is one dog year, seven years? VICTORIA: Seven years. SEIF: Seven years? VICTORIA: Yeah, seven years? SEIF: Yeah. So, basically, in one year, like, three months, he's already...in one month, he's, you know, seven months old. He's like, yeah. VICTORIA: Yeah. In a year, they're, like, teenagers. And then, in two years, they're, like, full adults. SEIF: Yeah. So, the first month is basically going through the first six months of a human being. So yeah, you pass...the first two days or three days are the Tamagotchi phase that I'm talking about. VICTORIA: [chuckles] I read this book, and it was, like, to understand dogs, it's like, they're just like humans that are trying to, like, maximize the number of positive experiences that they have. So, like, if you think about that framing around all your interactions about, like, maybe you're trying to get your son to do something, you can be like, okay, how do I, like, I don't know, train him that good things happen when he does the things I want him to do? [laughs] That's kind of maybe manipulative but effective. So, you're not learning baby sign language? You're just, like, going off facial expressions? SEIF: I started. I know how Mama looks like. I know how Dada looks like. I know how more looks like, slowly. And he already does this thing that I know that when he's uncomfortable, he starts opening and closing his hands. And when he's completely uncomfortable and basically that he needs to go sleep, he starts pulling his own hair. VICTORIA: [laughs] I do the same thing [laughs]. SEIF: You pull your own hair when you go to sleep? I don't have that. I don't have hair. VICTORIA: I think I do start, like, touching my head though, yeah [inaudible 33:04]. SEIF: Azure took the last bit of hair I had! Went away with Azure, Elasticsearch, and the shock collar. VICTORIA: [laughs] SEIF: I have none of them left. Absolutely nothing. I should sue Elasticsearch for this shit. VICTORIA: [laughs] Let me know how that goes. Maybe there's more people who could join your lawsuit, you know, with a class action. SEIF: [laughs] Yeah. Well, one thing I wanted to also just highlight is, right now, one of the things that also makes the company move forward is we realized that in a single domain, we proved ourselves very valuable to specific companies, right? So, that was a big, big thing, milestone for us. And now we're trying to move into a handful of domains and see which one of those work out the best for us. Does that make sense? VICTORIA: Yeah. And I'm curious: what are the biggest challenges or hurdles that you associate with that? SEIF: At this point, you don't want just feedback. You want constructive criticism. Like, you want to work with people who will criticize the applic...and you iterate with them based on this criticism, right? They're just not happy about you and trying to create design partners. So, for us, it was very important to have these small design partners who can work with us to actually prove ourselves as valuable in a single domain. Right now, we need to find a way to scale this across several domains. And how do you do that without sacrificing? Like, how do you open into other domains without sacrificing the original domain you came from? So, there's a lot of things [inaudible 34:28]. And we are in the middle of this. Honestly, I Forrest Gumped my way through half of this, right? Like, I didn't know what I was doing. I had ideas. I think it's more of luck at this point. And I had luck. No, we did work. We did work a lot. We did sleepless nights and everything. But I think, in the last three years, we became more mature and started thinking more about product. And as I said, like, our CEO, Neil, and Dominic, our head of product, are putting everything behind being a product-led organization, not just a tech-led organization. VICTORIA: That's super interesting. I love to hear that that's the way you're thinking about it. JOE: I was just curious what other domains you're looking at pushing into if you can say. SEIF: So, we are going to start moving into ETL a bit more. We're trying to see how we can fit in specific ML scenarios. I can't say more about the other, though. JOE: Do you think you'll take the same approaches in terms of value proposition, like, low cost, good enough latency? SEIF: Yes, that's definitely one thing. But there's also...so, this is the values we're bringing to the customer. But also, now, our internal values are different. Now it's more of move with urgency and high velocity, as we said before, right? Think big, work small. The values in terms of values we're going to take to the customers it's the same ones. And maybe we'll add some more, but it's still going to be low-cost and large-scale. And, internally, we're just becoming more, excuse my French, agile. I hate that word so much. Should be good with Scrum. VICTORIA: It's painful, but everyone knows what you're talking about [laughs], you know, like -- SEIF: See, I have opinions here about Scrum. I think Scrum should be only used in terms of iceScrum [inaudible 36:04], or something like that. VICTORIA: Oh no [laughter]. Well, it's a Rugby term, right? Like, that's where it should probably stay. SEIF: I did not know it's a rugby term. VICTORIA: Yeah, so it should stay there, but -- SEIF: Yes [laughs]. VICTORIA: Yeah, I think it's interesting. Yeah, I like the being flexible. I like the just, like, continuous feedback and how you all have set up to, like, talk with your customers. Because you mentioned earlier that, like, you might open source some of your projects. And I'm just curious, like, what goes into that decision for you when you're going to do that? Like, what makes you think this project would be good for open source or when you think, actually, we need to, like, keep it? SEIF: So, we open source libraries, right? We actually do that already. And some other big organizations use our libraries; even our competitors use our libraries, that we do. The whole product itself or at least a big part of the product, like database, I'm not sure we're going to open source that, at least not anytime soon. And if we open source, it's going to be at a point where the value-add it brings is nothing compared to how well our product is, right? So, if we can replace whatever's at the back with...the storage engine we have in the back with something else and the product doesn't get affected, that's when we open source it. VICTORIA: That's interesting. That makes sense to me. But yeah, thank you for clarifying that. I just wanted to make sure to circle back. Since you have this big history in open source, yeah, I'm curious if you see... SEIF: Burning me out? VICTORIA: Burning you out, yeah [laughter]. Oh, that's a good question. Yeah, like, because, you know, we're about to be in October here. Do you have any advice or strategies as a maintainer for not getting burned out during the next couple of weeks besides, like, hide in a cave and without internet access [laughs]? SEIF: Stay away from Reddit and Hacker News. That's my goal for October now because I'm always afraid of getting too attached to an idea, or too motivated, or excited by an idea that I drift away from what I am actually supposed to be doing. VICTORIA: Last question is, is there anything else you would like to promote? SEIF: Yeah, check out our website; I think it's at axiom.co. Check it out. Sign up. And comment on Discord and talk to me. I don't bite, sometimes grumpy, but that's just because of lack of sleep in the morning. But, you know, around midday, I'm good. And if you're ever in Berlin and you want to hang out, I'm more than willing to hang out. VICTORIA: Whoo, that's awesome. Yeah, Berlin is great. I was there a couple of years ago but no plans to go back anytime soon, but maybe I'll keep that in mind. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you could find me on Twitter @victori_ousg. And this podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Joe Ferris and Seif Lotfy.

CHAOSScast – Episode 71 In this episode, the CHAOSScast team is back! Georg Link, Dawn Foster, Sean Goggins, Matt Germonprez, and Elizabeth Barron discuss the relaunch of the podcast after taking a short break. They delve into the fascinating world of open source community health, focusing on metrics, metric models, and the CHAOSS Project's role in measuring the health of open source communities. They share insights on how they're working to make metrics more accessible and how they interpret these metrics within the context of specific projects. Additionally, they highlight the Data Science Initiative, the growth of CHAOSS community chapters worldwide, and their initiative to improve newcomer experience and promote diversity and inclusion in open source. Download this episode now to find out much more! [00:02:48] We hear more about where CHAOSS is with developing metrics and metric models and the Context Groups they've developed to bring together individuals interested in the health of specific projects or communities. [00:06:06] The Metric Development Process is brought up, which is the process of defining and releasing metrics has evolved. While some working groups still develop metrics, there's an effort to consolidate and organize metrics to make them more accessible to users, including categorizing and tagging them. [00:08:11] Dawn brings up Metrics Models which are collections of metrics that provide insights into specific aspects of open source community health. These models help users understand various phenomena in open source software health and use metrics effectively. [00:12:14] Georg brings up something new called the Data Science Initiative within CHAOSS, and Dawn talks about her role as Director of Data Science. The initiative aims to provide guidance to users of CHAOSS metrics and tools for interpreting data effectively and she tells us all the key areas that it's focused on. [00:16:14] Matt asks Dawn about the balance between maintain an agnostic stance on metrics and providing more guidance to users in interpreting metrics. Dawn discusses the importance of helping users interpret metrics in the context of their specific projects. [00:17:55] Georg and Dawn talk about using metrics as pointers to prompt users to investigate specific aspects of their communities and projects. [00:18:53] Elizabeth asks if CHAOSS should play a role in advising users on how to make changes in their communities based on metric insights without adversely affecting other metrics. Dawn shares her thoughts and Sean mentions the experience of CHAOSS members in evaluating different communities and interpreting metrics. [00:20:34] Georg expresses excitement about the future of CHAOSS and its journey. [00:21:54] Sean provides an overview of Augur and its evolution over time, including its ability to capture large volumes of data and the development of an API. [00:24:19] Georg discusses recent developments in Grimoire Lab, including multi tenancy support, scalability improvements, and optimization of data enrichment processes. He also talks about the migration of Grimoire Lab from Elasticsearch to OpenSearch for data storage and visualization, and Sorting Hat, a module within Grimoire Lab for managing identities. [00:27:40] Dawn asks about the future use of Kibiter, the Kibana fork used in Grimoire Lab, and Georg confirms a full migration to OpenSearch and Open Search Dashboards, indicating that Kibiter may be phased out. [00:28:52] Matt asks about recent challenges and achievements related to data management and data cleaning in Augur and Grimoire Lab. Sean mentions the importance of data in operationalizing metrics and making them tangible. Georg emphasizes two critical aspects of data quality. [00:33:32] Elizabeth shares insight into the growth of the CHAOSS community. She discusses the challenges of managing the growing community, and a group CHAOSS is partnering with called “All in” to develop badging for open source projects, addressing scalability challenges. [00:41:53] Elizabeth talks about the DEI Reflection Project which was crucial in identifying blind spots and improving the CHAOSS community. It led to valuable recommendations, including enhancing the newcomer experience and promoting diversity and inclusion. Value Adds (Picks) of the week: [00:44:30] Georg's pick is living in his new house that he loves. [00:45:11] Matt's pick is his cool morning bike rides to his office. [00:45:44] Dawn's pick is a warm, sunny vacation she took in Malta. [00:46:15] Elizabeth's pick is seeing her granddaughter getting excited to see flowers, birds, mushrooms, and be out in nature. [00:46:48] Sean's pick is his daughter, an English PHD student, who published her first academic paper, and has another up for a revise and resubmit. *Panelists: * Georg Link Dawn Foster Matt Germonprez Sean Goggins Elizabeth Barron Links: CHAOSS (https://chaoss.community/) CHAOSS Mastodon (https://fosstodon.org/@chaoss) CHAOSScast Podcast (https://podcast.chaoss.community/) podcast@chaoss.community (mailto:podcast@chaoss.community) Ford Foundation (https://www.fordfoundation.org/) Georg Link Website (https://georg.link/) Dawn Foster Twitter (https://twitter.com/geekygirldawn) Matt Germonprez Twitter (https://twitter.com/germ) Sean Goggins Twitter (https://twitter.com/sociallycompute) Elizabeth Barron Twitter (https://twitter.com/elizabethn) CHAOSS Data Science Working Group (https://github.com/chaoss/wg-data-science) Data Science Initiative-Raw data from the Understanding Challenges survey (https://github.com/chaoss/wg-data-science/commit/d86a02841f221308b913d08bc9ae644adced69fc) Augur repositories (https://ai.chaoss.io/) Project Aspen (https://github.com/oss-aspen#8knot-explorer) 8Knot-Metrix CHAOSS (https://metrix.chaoss.io/) Bitergia Analytics- GrimoireLab (https://chaoss.biterg.io) OpenSearch (https://opensearch.org/) Sorting Hat (https://github.com/chaoss/grimoirelab-sortinghat) Kibiter (https://github.com/chaoss/grimoirelab-kibiter) OpenSearch Dashboards (https://opensearch.org/docs/latest/dashboards/index/) All In (https://allinopensource.org/) GitHub All in (https://github.com/AllInOpenSource/All-In) CHAOSS Software (https://chaoss.community/software/) CHAOSScast Podcast-Episode 54: CHAOSS DEI Reflection Project (https://podcast.chaoss.community/54)

2023-06-27 Weekly News - Episode 199Watch the video version on YouTube at https://youtube.com/live/YhGqAVLYZk4?feature=shareHosts:  Gavin Pickin - Senior Developer at Ortus Solutions Brad Wood - Senior Developer at Ortus Solutions Thanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and all your favorite box-es out there. A few ways  to say thanks back to Ortus Solutions: Like and subscribe to our videos on YouTube.  Help ORTUS reach for the Stars - Star and Fork our Repos Star all of your Github Box Dependencies from CommandBox with https://www.forgebox.io/view/commandbox-github  Subscribe to our Podcast on your Podcast Apps and leave us a review Sign up for a free or paid account on CFCasts, which is releasing new content every week BOXLife store: https://www.ortussolutions.com/about-us/shop Buy Ortus's Books  102 ColdBox HMVC Quick Tips and Tricks on GumRoad (http://gum.co/coldbox-tips) Learn Modern ColdFusion (CFML) in 100+ Minutes - Free online https://modern-cfml.ortusbooks.com/ or buy an EBook or Paper copy https://www.ortussolutions.com/learn/books/coldfusion-in-100-minutes   Patreon Support ()We have 40 patreons: https://www.patreon.com/ortussolutions. News and AnnouncementsCFCamp was a blastBrad said: Back on US soil again, but still smiling from the wonderful experience at CFCamp.  It was so good to be back in Germany and see my EU friends again in person.  I'd say the first time back since Covid was a smashing success!Alex Well said: Back at home from my trip to 2023‘s #CFCamp

Sentry is an application monitoring tool that surfaces errors and performance problems. It minimizes the need to manually look at logs or dashboards by identifying common problems across applications and frameworks. David Cramer is the co-founder and CTO of Sentry. This episode originally aired on Software Engineering Radio. Topics covered: What's Sentry? Treating performance problems as errors Why you might no need logs Identifying common problems in applications and frameworks Issues with Open Telemetry data Why front-end applications are difficult to instrument The evolution of Sentry's architecture Switching from a permissive license to the Business Source License Related Links Sentry David's Blog Sentry 9.1 and Upcoming Changes Re-Licensing Sentry Transcript You can help edit this transcript on GitHub. [00:00:00] Jeremy: Today I'm talking to David Kramer. He's the founder and CTO of Sentry. David, welcome to Software Engineering Radio. [00:00:08] David: Thanks for having me. Excited for today's conversation. What's Sentry? [00:00:11] Jeremy: I think the first thing we could start with is defining what Sentry is. I know some people refer to it as an error tracker. Some people have referred to it as, an application performance monitoring tool. I wonder if you could kind of describe in, in your words what it is. [00:00:30] David: You know, as somebody who doesn't work in marketing, I just tell it how it is. So Sentry started out doing error monitoring, which. You know, dependent on who you talk to, you might just think of as logging, right? Like that's the honest truth. It is just logging just a different shape or form. these days it's hard to not classify us as just an APM tool that's like the industry that exists. It's like the tools people understand. So I would just say it's an APM tool, right? We do a bunch of things within that space, and maybe it's not, you know, item for item the same as say a product like New Relic. but a lot of the overlap's there, so it's like errors performance, which is like latency and sort of throughput. And then we have some stuff that just goes a little bit deeper within that. The, the one thing i would say that is different for us versus a lot of these tools is we actually only do application monitoring. So we don't do any since like systems or infrastructure monitoring. Meaning Sentry is not gonna tell you when you need to replace a hard drive or even that you need new hard, like more disk space or something like that because it's just, it's a domain that we don't think is relevant for sort of our customers and product. Application Performance Monitoring is about finding crashes and performance problems that users would associate with bugs [00:01:31] Jeremy: For people who aren't familiar with the term application performance monitoring, what is that compared to just error tracking? [00:01:41] David: The way I always reason about it, this is what I tell new hires and what I would tell, like my mother, if I had to explain what I do, is like, you load Uber and it crashes. We all know that's bad, right? That's error monitoring. We capture the crash report, we send it to developers. You load Uber and it's a 30 second spinner, like a loading indicator as a customer. Same outcome for me. I assume the app is broken, right? So we also know that's bad. Um, but that's different than a crash. Okay. Sentry captures that same thing and send it to developers. lastly the third example we use, which is a little bit more. I think, untraditional, but a non-traditional rather, uh, you load the Uber app and it's like a blank screen or there's no button to submit, like log in or something like this. So it's kind of like a, it's broken, but it maybe isn't erroring and it's not like a slow thing. Right. Same outcome. It's probably a bug of some sorts. Like it's what an end user would describe it as a bug. So for me, APM just translates to there are bugs, user perceived bugs in your application and we're able to monitor and, and help the software teams sort of prioritize and resolve those, those concerns. [00:02:42] Jeremy: Earlier you were talking about actual crashes, and then your second case is, may be more of if the app is running slowly, then that's not necessarily a crash, but it's still something that an APM would monitor. [00:02:57] David: Yeah. Yeah. And I, I think to be fair, APM, historically, it's not a very meaningful term. Like I as a, when I was more of just an individual contributor, I would associate APM to, like, there's a dashboard that will tell me what's slow in my application, which it does. And that is kind of core to APM, but it would also, none of the traditional tools, pre sentry would actually tell you why it's broken, like when there's an error, a crash. It was like most of those tools were kind of useless. And I don't know, I do actually know, but I'm gonna pretend I don't know about most people and just say for myself. But most of the time my problems are errors. They are not like it's fast or slow, you know? and so we just think of it as like it's a holistic thing to say, when I've changed the application and something's broken, or it's a bug, you know, what is that bug? How do we help people fix it? And that comes from a lot of different, like data signals and things like that. the end result is still the same. You either are gonna fix it or it's not important and you ignore it. I don't know. So it's a pretty straightforward, premise for us. But again, most companies in the space, like the traditional company is when you grow a big company, what happens is like you build one thing and then you build lots of check boxes to sell more things. And so I think a lot of the APM vendors, like they've created a lot of different products. Like RUM is a good example of another acronym that lives with an APM. And I would tell you RUM is completely meaningless. It, it stands for real user monitoring. And so I'm like, well, what's not real about monitoring the application? Well, nothing's not real, but like they created a new category because that's how marketing engines work. And that new category is more like analytics than it is like application telemetry. And it's only because they couldn't collect the app, the application telemetry at the time. And so there's just a lot of fluff, i would say. But at the end of the day too, like developers or engineering teams, it's like new version of the application. You broke something, let's tell you about it so you can fix it. You might not need logging or performance monitoring [00:04:40] Jeremy: And, and so earlier you were saying how this is a kind of logging, but there's also other companies, other products that are considered like logging infrastructure. Like I, I would think of companies like Paper Trail or Log Tail. So what space does Sentry fill that's that's different than that kind of logging? [00:05:03] David: Um, so the way I always think about it, and this is both personally true, and what I advise other folks is when you're building something new, when you start from zero, right, you can often take Sentry put it in, and that's good enough. You don't even need performance monitoring. You just need like errors, right? Like you're just causing bugs all the time. And you could do that with logging, but like the delta between air monitoring and logging is night and day. From a user experience, like error monitoring for us, or what we built at the very least, aggregates the errors. It, it helps you understand the frequency. It helps you when they're new versus old. it really gives you a lot of detail where logs don't, and so you don't need logging often. And I will tell you today at Sentry. Engineers do not use logs for the most part. Uh, I had a debate with one of our, our team members about it, like, why does he use logs recently? But you should not need them because logs serve a different purpose. Like if you have traces which tell you like, like fast and slow in a bunch of other network data and you have this sort of crash report collection or error monitoring thing, logs become like a compliance or an audit trail or like a security forensics, tool, and there's just not a lot of value that you would get out of them otherwise, like once in a while, maybe there's like some weird obscure use case, but generally speaking, you can just pretend that you don't need logs most days. Um, and to me that's like an evolution of the industry. And so when, when Sentry is getting started, most people were still logs. And if you go talk to SRE teams, they're like, oh, login is what we know. Some of that's changed a little bit, but. But at the end of the day, they should only be needed for more complicated audit trails because they're just not a good solution to the problem. It's just free form data. Structured or not, doesn't really matter. It's not aggregated. It's not something that you can really use. And it's why whenever you see logging tools, um, not even the papertrails of the world, but the bigger ones like Splunk or Cabana, it's like this weird, what we describe as choose your own adventure. Like go have fun, build your dashboards and try to make the logs useful kind of story. Whereas like something like Sentry, it's just like, why would you waste any time trying to build dashboards when we can just tell you when something new is broken? Like that's the ideal situation. [00:06:59] Jeremy: So it sounds like maybe the distinction is with a more general logging tool, like you mentioned Splunk and Kibana it's a collection of all this information. of things happening, even though nothing's necessarily wrong, whereas Sentry is more Sentry is it's going to log things, but it's only going to log things if Sentry believes something is wrong, either because of a crash or because of some kind of performance issue. People don't want to dig through logs or dashboards, they want to be told when something is wrong and whyMost software is built the same way, so we know common problems [00:07:28] David: Yeah. I, i would say it's about like actionability, right? Like, like nobody wants to spend their time digging through logs, digging through dashboards. Metrics are another good example of this. Like just charts with metrics on them. Yeah. They tell me something's happening. If there's lots of log statements, they tell me something's going on, but they're not, they're not optimized to like, help me solve a problem, right? And so our philosophy was always like, we haven't necessarily nailed this in all cases for what it's worth, but. It was like, the goal is we identify an actual problem, like close to like a root cause kind of problem, and we escalate that up and that's it. Uh, versus asking somebody to like go have to like build these dashboards, build these things, figure out what data matters and all this because most software looks exactly the same. Like if you have a web service, it doesn't matter what language it's written in, it doesn't matter how different you think your architecture is from somebody else's, they're all the same. It's like you've got a request, you've got a database, you've got some cache, you've got all these like known, known quantity things, and the slowness comes from the same places. Errors are structured while logs are not [00:08:25] David: The errors come from the same places. They're all exhibiting the same kinds of behavior. So logging is very unstructured. And what I mean by that is like there's no schema. Like you can hypothetically like make it JSON and everybody does that, but it's still unstructured. Whereas like errors, it's, it's a tight schema. It's like there's a type of error, there's a message for the error, there's a stack trace, there's all these things that you know. Right. And as soon as you know and you define those things, you can just build better products. And so distributed tracing is similar. Hypothetically, it's a little bit abstract to be fair, but hypothetically, distributed tracing is creating a schema out of basically network annotations. And somebody will yell at me for just simplifying it to that. I would tell 'em that's what it is. But, same goal in mind. If you know what the data is, you can take action on it. It's not quite entirely true. Um, because tracing is much more freeform. For example, it doesn't say if you have a SQL statement, it should be like this, it should be formatted this way, things like that. whereas like stack traces, there's a file name, there's there's a line number, there's like all these things, right? And so that's how I think about the delta between what is useful information and what isn't, I guess. And what allows you to actually build things like Sentry versus just build abstract exploration. Inferring problems rather than having user identify them [00:09:36] Jeremy: Kind of paint the picture of how someone would get started with a tool like Sentry. Do they need to tell Sentry anything about their application? Do they need to modify their source code at all? give us a picture of how that works. [00:09:50] David: Yeah, like one of our fundamentals, which I think applies for any real business these days is you've gotta like reduce user friction, right? Like you've gotta make it dead simple to use. Uh, and for us there were, there was like kind of a fundamental driving constraint behind that. So in many situations, um, APM vendors especially will require you to run an agent a basically like some kind of process that runs on your servers somewhere. Well, if you look at modern tech stacks, that doesn't really work because I don't run the servers half my stuff's in the browser, or it's a mobile app or a desktop app, and. Even if I do have those servers, it's like an entirely different team that controls them. So deploying like a sidecar, an agent is actually like much more complicated. And so we, we looked at that and also because like, it's much easier to have control if you just ship within the application. We're like, okay, let's build like an SDK and dependency that just injects into the, the application that runs, set an API key and then you're done. And so what that translates for Sentry is we spend a lot of time knowing what Django is or what Rails is or what expresses like all these frameworks. And just knowing how to plug into the right signals in those frameworks. And then at that point, like the user doesn't have to do anything. And so like the ideal outcome for Sentry is like you install the dependency in whatever language makes sense, right? You somehow configure the API key and maybe there's a couple other minor settings you add and that gives you the bare bones and that's it. Like it should just work from there. Now there's a lot you can do on top of that to enrich data and whatnot, but for the most part, especially for errors, like that's good enough. And that, that's always been a fundamental goal of ours. And I, I think we actually do it phenomenally well. [00:11:23] Jeremy: So it sounds like it infers things about the application without manual configuration. Can you give some examples of the kind of things that Sentry knows without the user having to tell it? [00:11:38] David: Yeah. So a good example. So on the errors side, we know literally everything because an error object in each language has all these attributes with it. It, it gives you the stack trace, it gives you a lot of these things. So that one's straightforward. On the performance side, we use a combination of leveraging some like open source, I guess implementations, like open telemetry where it's got all this instrumentation already and we can just soak that in, um, as well as we automatically instrument a bunch of stuff. So for example, say you've got like a Python application and you're using, let's say like SQL Alchemy or something. I don't actually know if this is how our SDK works right now, but, we will build something that's aware of that library and make sure it can automatically instrument the things it needs to get the right information out of it. And be fair. That's always been true for like APM vendors and stuff like that. The delta is, we've often gone a lot deeper. And so for Python for example, you plug it into an application, we'll capture things like the error, error object, which is like exception class name exception value, right? Stack trace, file, name, line number, all those normal things, function name. We'll also collect source code. So we'll, we'll give you sort of surrounding source code blocks for each line in the stack trace, which makes it infinitely easier to consume. And then in Python and, and php, and I forget if we do this anywhere else right now, we'll actually even allow you to collect what are called stack locals. So it'll, it'll give you basically the variables that are defined almost like a debugger. And that is actually, actually like game changing from a development point of view. Because if I can go look in production when there's an incident or a bug and I can actually see the state of the application. , I, I never need to know like, oh, what was going on here? Oh, what if like, do I need to go reproduce this somehow? I always have the right information. And so all of that for us is automatic and we only succeed like, it, it's, it's like by definition inside of Sentry, it has to be automatic. Like if we ask the user to do anything whatsoever, we're failing. And so whenever we design any product or anything, and to be fair, this is how every product company should operate. it's gotta be with as little user input as humanly possible. And so you can't always pull that off. Sometimes you have to have users configure stuff, but the goal should always be no input. Detecting errors through unhandled exceptions [00:13:42] Jeremy: So you, you're talking about getting a stack trace, getting, the state of variables, source code. That sounds like that's primarily gonna be through unhandled exceptions. Would you say that's, that's the primary way that you get error? [00:13:58] David: Yeah, you can integrate in other ways. So you can like trigger our API to capture an, uh, an exception. You can also, for better or worse, it's not always good. You can integrate through logging adapters. So if you're already using a logging framework and you log their errors there, we can often capture those. However, I will say in most cases, people use the logging APIs wrong and the data becomes junk. A good, a good example of this is like, uh, it varies per language. So I'm just gonna go to Python because Python is like sort of core to Sentry. Um, in Python you have the ability to log messages, you can log them as errors, you can log like actual error objects as errors. But what usually happens is somebody does a try-catch. They, they capture the error they rescue from it. They create a logging call, like log dot error or something, put the, the error message or value in there. And then they send that upstream. And what happens is the stack trace is gone because we don't know that it's an error object. And so for example, in Python, there's actually an an A flag. You pass the logging call to make sure that stack trace stays present. But if you don't know that the data becomes junk all of a sudden, and if we don't have a stack trace, we can't actually aggregate data because like there's just not enough information to like, to run hashing on it. And so, so there are a lot of ways, I guess, to capture the information, but there are like good ways and there are bad ways and I think it, it's in everybody's benefit when they design their, their apt to like build some of these abstractions. And so like as an example, when, whenever I would start a new project these days, I will add some kind of helper function for me to like log an exception when I like, try catch and then I can just plug in whatever I need later if I want to enrich the data or if I wanna send that to Sentry manually or send it to logs manually. And it just makes life a lot easier versus having to go back and like augment every single call in the code base. [00:15:37] Jeremy: So it, it sounds like. When you're using a tool like Sentry, there's gonna be the, the unhandled exceptions, which are ones that you weren't expecting. So those should I guess happen without you catching them. And then the ones that you perhaps do anticipate, but you still consider to be a problem, you would catch that and then you would add some kind of logging statement to your code that talks to Sentry directly. Finding issues like performance problems (N+1 queries) that are not explicit errorsz [00:16:05] David: Potentially. Yeah. It becomes a, a personal choice to be fair at that, at that point. but yeah, the, the way, one of the ways we've been thinking about this lately, because we've been changing our error monitoring product to not just be about errors, so we call it issues, and that's in the guise of like, it's like an issue tracker, a bug tracker. And so we started, we started putting what are effectively like, almost like static analysis concerns inside of this issue tracker. So for example, In our performance monitor, we'll do something called like detect n plus one queries, which is where you execute a, a duplicate query in a loop. It's not necessarily an error. It might not be causing a problem, but it could be causing a problem in the future. But it's like, you know, the, the, the qualities of it are not the same as an error. Like it's not necessarily causing the user to experience a bug. And so we've started thinking more about this, and, and this is the same as like logging errors that you handle. It's like, well, they're not really, they're not really bugs. It's like expected behavior, but maybe you still want to keep it like tracking somewhere. And I think about like, you know, Lins and things like that, where it's like, well, I've got some things that I definitely should be fixing. Then I've got a bunch of other stuff that's like informing me that maybe I should take action on or not. But only I, the human can really know at the end of the day, right, if I, if I should prioritize that or not. And so that's how I kind of think about like, if I'm gonna try catch and then log. Yeah, you should probably collect that data. It's probably less important than like the, these other concerns, like, like an actual unhandled exception. But you do, you do want to know that they're happening and whatnot. And so, I dunno, Sentry has not had a strong opinion on this historically. We're just like, send us whatever you want to capture in this regard, and you can pay for it, that's fine. It's like usage based, you know? we're starting to think a lot more about what should that look like if we, if we go back to like, what's the, what's the opinion we have for how you should use the product or how you should solve these kinds of software problems. [00:17:46] Jeremy: So you gave the example of detecting n plus one queries is, is that like being aware of the framework or the ORM the person is using and that's how you're determining this? Or is it at more of a lower level than that? [00:18:03] David: it is, yeah. It's at the framework level. So this is actually where Open Telemetry causes a lot of harm, uh, for us because we need to know what a database query is. Uh, we need to know like the structure of the query because we actually wanna parse it out in a lot of cases. Cause we actually need to identify if it's duplicate, right? And we need to know that it's a database query, not a random annotation that you've added. Um, and so what we do is within these traces, which is like if you, if you don't know what a trace is, it's basically just like, it's a tree, like a tree structure. So it's like A calls B, calls C, B also calls D and E and et cetera, right? And so you just, you know, it's a trace. Um, and so we actually just look at that trace data. We try to find these patterns, which is like, okay, B was a, a SQL query or something. And every single sibling of B is that same SQL query, but sort of removing certain parameters and stuff for the value. So we'll look at that data and we'll try to pull out anomalies. So m plus one is an example of like a fairly obvious anti pattern that everybody knows is bad and can be optimized. Uh, but there's a lot of other that are a little bit more subjective. I'll give you an example. If you execute three SQL statements back to back, one could argue that you could just batch those SQL statements together. I would argue most of the time it doesn't matter and I don't need to do that. And also it's not guaranteed that that is better. So it becomes much more like, well, in my particular situation this is valuable, but in this other situation it might not be. And that's where I go back to like, it's almost like a linter, you know? But we're trying to infer all of that from the data stream. So, so Sentry's kind of, we're kind of a backwards product company. So we build our product from a technology vision, not from customers want this, or we have this great product vision or anything like that. And so in our case, the technology vision is like, there's a lot of application data that comes in, a lot of telemetry, right? Errors, traces. We have a bunch of other streams now. within that telemetry there is like signal. And so one, it's all structured data so we know what it is so we can actually interpret it. And then we can identify that signal that might be a problem. And that signal in our case is often going to translate to like this issue concept. And then the goal is like, well, can we identify these problems for people and surface them versus the choose your own adventure model, which is like, we'll just capture everything and feed it to the user and they can figure out what matters. Because again, a web service is a web service. A database is a database. They're all the same problems for everybody. All you know, it's just, and so that's kind of the model we've built and are continuing to evolve on and, and so far works pretty well to, to curate a lot of these workflows. Want to infer everything, but there are challenges [00:20:26] Jeremy: You talked a little bit about how people will sometimes use tracing. And in cases like that, they may need some kind of session ID to track. Somebody making a call to a service and that talks to a database and that talks to other services. And you, inside of your application, you have to instrument some way of tracking. This all came from this one request. Is that something that Sentry can infer or is there something that the developer has to put into play so that you can track that sort of thing? [00:21:01] David: Yeah, so it's, it's like a bit of both. And i would say our goal is that we can infer everything. The reality is there is so much complexity and there's too much of a, like, too many technologies in the world. Like I was complaining about this the other day, like, the classic example on web service is if we have a middleware hook, We kind of know request response, usually that's how middleware would work, right? And so we can infer a lot from there. Like basically we can infer the boundaries, which is a really big deal. Okay. That's one thing is boundaries is a problem. What we, we describe that as a transaction. So like when the request starts. When the request ends, right? That's a very important boundary for everybody to understand because when I'm working on the api, I care about the API boundary. I actually don't care about what the database is doing at its low level or what the JavaScript application might be doing above it. I want my boundary. So that's one that we kind of can do. But it's hard in a lot of situations because of the way frameworks and technology has been designed, but at least traditional stuff like a, a traditional web stack, it works like a Rails app or a DDjango app or PHP app kind of thing, right? And then within that it becomes, well, how do you actually build a trace versus just have a bunch of arbitrary labels? And so we have a bunch of complicated tech within each language that tries to establish that tree. and then we annotate a lot of things along the way. And so we will either leverage Open Telemetry, which is an open format spec that ideally has very high quality data. Ideally, not realistically, but ideally it has high quality data. Every library author implements it great, everybody's happy. We don't have to do anything ever again. The reality is that data is like all over the map because there's not like strict requirements for what, how the data should be labeled and stuff. And not everything even has that data. Like not everything's instrumented with open telemetry. So we also have a bunch of stuff that, unrelated to using that we'll say, okay, we know what this library is, we're gonna try to infer some characteristics from this library, or we know what maybe like the DDjango template engine is. So we're gonna try to infer like when the template renders so you can capture that block of information. it is a very imperfect science and I would tell you like it's not, even though like Open Telemetry is a very fun topic for people. It is not necessarily good, like it's not in a good state. Could will it ever be good? I don't know in all honesty, but like the data quality is like all over the map and so that's honestly one of our biggest challenges to making this experience that, you know, tells you what's going on in your database so it tells you what's going on with the cash or things like this is like, I dunno, the cash might be called something completely random in one implementation and something totally different in another. And so it's a lot of like, like data normalization that you have to deal with. But for the most part, those libraries of things you don't control can and will be instrumented. Now the other interesting thing, which we'll see how this works out, so, so one thing Sentry tries to do there, we have all these layers of telemetry, so we have errors and traces, right? Those are pretty high level concepts. We also have profiling data, which is very, very, very, very low level. So it's usually only if you have like disc. I like. It's where is all the CPU time being spent in my application? Mostly not waiting. Like waiting's usually like a network call, right? But it's like, okay, I have a loop that's doing a lot of math, or I'm writing a bunch of stuff to disc and that's really slow. Like often those are not instrumented or it's like these black box areas of a performance. And so what we're trying to do with profiling data, instead of just showing you flame charts and stuff, is actually say, could we fill in these gaps in these traces? Like basically like, Hey, I've got a long period of time where the app's doing something. You know, here's an API call, here's the database stuff. But then there's this block, okay, what's that function or something? Can we pull that out of the profiling data? And so in that case, again, that's just automatic because the profile actually knows everything about the application and know it. It has full access to the function and the stack and everything, right? And so the dream is that you would just always have everything filled in the, the customer never has to do anything with one minor asterisk. And the asterisk is what I would call like business context. So a good example would be, You might wanna associate requests with a specific customer or something like that. Like you might wanna say, well it's uh, I don't know, Goldman Sachs or one of these big companies or something. So you can know like, well when Goldman Sachs is having performance issues or whatever it is, oh maybe I should focus on them cuz maybe they pay you a lot of money or something. Right. Sentry would never know that at the end of the day. So we also have these like kind of tagging contextual APIs that will say like, tell us some informations, maybe it's like customer, maybe it's something else that's relevant to your application. And we'll keep that data associated with the telemetry that's like present, you know, um, but the, at least the telemetry, like again, application's just worth the same, should be, there should be a day in the next few years that it's just all automatic. and again, the only challenge today is like, can it be high quality and automatic? And so that, that's like to be determined. [00:25:50] Jeremy: What you're kind of saying is the ideal is being able to look at this profiling information and be able to build a full picture of. a, a call from beginning to end, all the different things to talk to, but I guess what's the, what's the reality today? Like, what, what is Sentry able to determine, in the world we live in right now? [00:26:11] David: So we've done a lot of this like performance detection stuff already. So we actually can do a lot now. We put a lot of time into it and I, I will tell you, if you look at other tools trying to do tracing, their approach is much more abstract. It's like your traditional monitoring tool that's like, we're just gonna collect a lot of signals and maybe we'll find magic anomaly detection or something going on in it, which, you know, props, but that can figure that out. But, a lot of what we've done is like, okay, we kind of know what this data looks like. Let's go after this very like known quantity problem. Let's normalize the data. And let's make it happen like that's today. Um, the enrichment of profiles is new for us, but it, we actually can already do it. It's not perfect. Detection of blocking the UI thread in mobile apps [00:26:49] David: Um, and I think we're launching something in April or May, something around the, that timeframe where hopefully for the, the technologies we can instrument, we're actually able to surface that in a useful way. but as an example that, that concept that I was talking about, like with n plus one queries, the team built something using profiling data. and I think this, this might be for like a mobile app more so than anything where mobile apps have this problem of, it's, you've got a main thread and if you block that main thread, the app is basically frozen. You see this on desktop apps all the time. You, you very rarely see it on web apps anymore. But, but it's a really big problem when you have a web, uh, a mobile or desktop app because you don't want that like thing to be non-responsive. Right? And so one of the things they did was detect when you're doing like file io on the main thread, you know, right. When you're writing a disc, which is probably a slow thing or something like that, that's gonna block the whole thing. Because you should just do it on a separate thread. It's like an easy fix, potentially may not be a problem, but it could become a problem. Same thing as n plus one. But what's really interesting about it is what the team did is like they used the profiling data to detect it because we already know threads and everything in there, and then they actually recreated a stack trace out of that profiling data when it's surfaced. So it's actually like useful data with that. You could like that I or you as a developer might know how to take and actually be like, oh, this is where it happens at the source code. I can actually figure it out and go fix it myself. And to me, like as like I, I'm still very much in the weeds with software that is like one of the biggest gaps to most things. Is it just, it doesn't make it easy to consume or like take action on, right? Like if I've got a, a chart that says my error rate is high, what am I gonna do with that? I'm like, okay, what's breaking? That's immediately my next question. Right? Okay. This is the error. Where is that error happening at? Again, my next question, it, it's literally just root cause analysis, right? Um, and so that, that to me is very exciting. and I, I don't know that we're the first people to do that, I'm not sure. But like, if we can make that kind of data, that level of actionable and consumable, that's like a big deal for me because I will tell you is like I have 20 years of software experience. I still hate flame charts and like I struggle to use them. Like they're not a friendly visualization. They're almost like a, a hypothetically necessary evil. But I also think one where nobody said like, do we even need to use that? Do we need that to be like the way we operate? and so anyways, like I guess that's my long-winded way of saying like, I'm very excited for how we can leverage that data and change how it's used. [00:29:10] Jeremy: Yeah. So it sounds like in this example, both in the mobile app blocking the UI or the n plus one query is the Sentry, suppose, SDK or instrumentation that's hooked inside of your application. There are certain behaviors that it knows are, are not like ideal I guess, just based on. people's prior experience, like your own developers know that, hey, if you block the UI thread in this mobile application, then you're gonna have performance problems. And so that way, rather than just telling you, Hey, your app is slow, it can tell you your app is slow and it's because you're blocking the UI thread. Don't just aggregate metrics, the error tracker should have an opinion on what actual problems are [00:29:55] David: Exactly, and I, and I actually think, I don't know why so many people don't recognize this gap, because at the end of the day, like, I don't know, I don't need more people to tell me response times are bad or anything. I need you to have an opinion about what's good because. The only way it's like math education, right? Like, yeah, you learn the basics, but you're not expected to say, go to calc, but, and then like, do all the fundamentals. You're like, don't get a calculator and start simplifying the problem. Like, yeah, we're gonna teach you a few of these things so you understand it. We're gonna teach you how to use a calculator and then just use the calculator and then make it easier for everybody else. But we're also not teaching you how to build a calculator because who cares? Like, that's not the purpose of it. And so for me, this is like, we should be helping people sort of get to the finish line instead of making them run the entirety of the race over and over if they don't need to. I don't, I don't know if that's a good analogy, but that has been the biggest gap, I think, in so much of this software throughout the industry. And it's, it's, it's common everywhere. And there's no reason for that gap to exist these days. Like the technology's fine. And the technology's been fine for like 10 years. Like Sentry started in oh eight at this point. And I think there was only one other company I recall at the time that was doing anything that was even similar to like air monitoring and Sentry when we built it, we're just like, what if we just go deeper? What if we collect all this information that will help you debug the problem instead of just stopping it like a log aggregator or something kind of thing, so we can actually have an opinion about it. And I, I genuinely, it baffles me that more people do not think this way because it was not a hard problem at the time. It's certainly not hard these days, but there's still very, I mean, a lot more people do it now. They've seen Sentry successful and there's a lot of similar implementations, but it's, it's just amazes me. It's like, why don't you, why don't people try to make the data more actionable and more useful, the teams versus just collect more of it, you know? 40 people working on learning the common issues with languages and frameworks [00:31:41] Jeremy: it, it sounds like maybe the, the popularity of the stack the person is using or of the framework means that you're gonna have better insights, right? Like if somebody makes a, a Django application or a Rails application, there's all these lessons that your team has picked up in terms of, Hey, if you use the ORM this way, your application is gonna be slow. Whereas if somebody builds something totally homegrown, you won't know these patterns and you won't be able to like help as much basically. [00:32:18] David: Yeah. Yeah, that's exactly, and, and you might think that that is a challenge, but then you look at how many employees exist at like large tech companies and it's, it's not that big of a deal, like, , you might even think collecting all the information for each, like programming, runtime or framework is a challenge. We have like 40 people that work on that and it's totally fine. Like, and, and so I think actually all these scale just fine. Um, but you do have to understand like the domain, right? And so the counter version of this is if you look at say like browser applications, like very rich, uh, single page application type experiences. It's not really obvious like what the opinions are. Like, like if, if you, and this is like real, like if you go to Sentry, it's, it's kind of slow, like the app is kind of slow. Uh, we even make fun of ourselves for how slow it is cuz it's a lot of JavaScript and stuff. If you ask somebody internally, Hey, how would we make pick a page fast? They're gonna have no clue. Like, even if they have like infinite domain experience, they're gonna be like, I'm not entirely sure. Because there's a lot of like moving parts and it's not even clear what like, like good is right? Like we know n plus one is bad. So we can say not doing that is the better solution. And so if you have a JavaScript app, which is like where a lot of the slowness will come from is like the render times itself. Like how do you fix it? You, you can't actually build a product that tells you what to fix without knowing how to fix it, right? And so some of these newer and very fast moving targets are, are frankly very difficult for us. Um, and so that's one thing that I think is a challenge for the entire industry. And so, like, as an example, a lot of the browser folks have latched onto web vitals, which are just metrics that hopefully tell you something about the application, but they're not always actionable either. It'll be like, the idea with like web vitals is like, okay, time to interactive is an an important metric. It's like how long until the page loads that a user can do what they're probably there to do. Okay. Like abstractly, it makes sense to us, but like put into action. How do I optimize time to interactive? Don't block the page. That's one thing. I don't know. Defer assets, that's another thing. Okay. So you've gotta like, you've gotta build a technology that knows these assets could be deferred and aren't. Okay, which ones can be deferred? I don't know. Like, it, it, it's like such a deep rabbit hole. And then the problem is, six months from now, the tech will have completely changed, right? And it won't have like, necessarily solved some of these problems. It will just have changed and they're now a completely different shape of problem. But still the same fundamental like user experience is the same, you know? Um, and to me that's like the biggest challenge in the industry right now is that like dilemma of the browser at the end of the day. And so even from our end, we're like, okay, maybe we should step back, focus on servers again, focus on web services. Those are known quantities. We can do that really well. We can sort of change that to be better than it's been in the past and easier to consume with things like our n plus one detections. Um, and then take like a holistic, fresh look at browser and say, okay, now how would we solve this to make sure we can actually really latch onto the problems that like people have and, and we understand, right? And, you know, we'll see when we get there. I don't think any product does a great job these days for helping, uh, solve those problems. . But I think even without the, the products, like I said, like even our team would be like, fixing this is gonna take months because it's gonna take months just to figure out exactly where the, the common bottlenecks are and all these other things within an application. And so I, I guess what I mean to say with that is there's a lot of opportunity, I think with the moving landscape of technology, we can find a way to, whether it's standardized or Sentry, can find a way to make that data actionable want it something in between there. There are many ways to build things on the frontend with JavaScript which makes it harder to detect common problems compared to backend [00:35:52] Jeremy: So it sounds like what you're saying, With the, the back end, there's almost like a standard way of doing things or a way that a lot of people do it the same way. Whereas on the front end, even if you're looking at a React application, you could look at tenant react applications and they could all be doing state management a totally different way. They could be like the, the way that the application is structured could be totally different, and that makes it difficult for you to infer sort of these standard patterns on the front end side. [00:36:32] David: Yeah, that's definitely true. And it, it goes, it's even worse than that because well, one, there's just like the nature of JavaScript, which is asynchronous in the sense of like, it's a lot of callbacks and things like that. And so that already makes it hard to understand what's going on, uh, where things are happening. And then you have these abstractions like React, which are very good, but like they pull a lot of that away. And so, as an example of a common problem, you load the application, it has to do a lot of stuff to make the page render. You might call that hydration or whatever. Okay. And then there's a completely different state, which is going from, it's already hydrated. Page one, I, I've done an interaction or something. Or maybe I've navigated a page too, that's an entirely different, like, sort of performance problem. But that hydration time, that's like a known thing. That's kind of like time to interactive, right? But if the problem is in your framework, which a lot of it is like a lot of the problems today exist because of frameworks, not because of the technology's bad or the framework's bad, but just because it's abstracted and it's really hard to make it work in all these situations, it's complicated. And again, they have the same problem where it's like changing non sem. And so if the problem is the framework is somehow incorrectly re rendering the page as an example, and this came up recently, for some big technology stack, it's re rendering the page. That's a really bad problem for the, the customer because it's making the, it's probably actually causing a lot of CPU seconds. This is why like your Chrome browser tabs are using so much memory in cpu, right? How do you fix that? Can you even fix that? Do you just say, I don't know, blame the technology? Is that the solution? Maybe that is right, but how would we even blame the technology like that alone, just to identify why it's happening. and you need to know the why. Right? Like, that is such a hard problem these days. And, and personally, I think the only solution is if the industry sort of almost like standardizes on a way to like, on a belief of how this should be optimized and how it should be measured and monitored kind of thing. Because like how errors work is like a standardization effectively. It may not be like a formal like declaration of like, this is what an error is, but more or less they always have the same attributes because we've all kind of understood that. Like those are the valuable things, right? Okay. I've got a server rendered application that has client interaction, which is sort of the current generation of the technology. We need to standardize on what, like that web request, like response life cycle is, right? and what are the moving targets within there. And it just, to me, I, I honestly feel like a lot of what we use every day in technology is like beta. Right. And it's, I think it's one of the reasons why we're constantly always having to up, like upgrade and, and refactor and, and, and shift dependencies and things like that because it is not, it's very much a prototype, right? It's a moving target, which I personally do not think is great for the industry because like customers do not care. They do not care that you're using some technology that like needs a change every few months and things like that. now it has improved things to be fair. Like web applications are much more like interactive and responsive sometimes. Um, but it is a very hard problem I think for a lot of people in the world. [00:39:26] Jeremy: And, and when you refer to, to things feeling like beta, I suppose, are, are you referring to the frameworks people are using or the libraries they're using to support their front end development? I, I'm curious what you're, you're thinking there. [00:39:41] David: Um, I think it's everything. Even like the browser APIs are constantly shifting. It's, that's gotten a little bit better. But even the idea like type script and stuff, it's just like we're running like basically compilers to make all this code work. And, and so the, even that they're constantly adding features just because they can, which means behaviors are constantly changing. But like, if you look at a real world example, like React is like the, the most dominant technology. It's very well designed for managing the dom. It's basically just a rendering engine at the end of the day. It's like it's managed to process updates to the dom. Okay. Makes sense. But we've all learned that these massive single page applications where you build all your application logic and loaded into a bundle is a problem. Like, like, I don't know how big Sentry's bundle is, but it's multiple megs in size and it takes a little while for like a, even on fast fiber here in the Bay Area, it takes a, you know, several seconds for the UI to load. And that's not ideal. Like, it's like at some point half of us became okay with this. So we're like, okay, what we need to do is go back, literally just go back 10 years and we need to render it on the server. And then we need some stuff that makes interactions, you know, highly responsive in the UI or dynamic content in the ui, you know, bring, it's like bringing back jQuery or something. And so we're kind of going full circle, but that is actually like very complicated because the way people are trying to do is like, okay, we wanna, we wanna have the rendering engine operate the same on the server and is on as on the client, right? So it's like we just write one, path of code that basically it's like a template engine to some degree, right? And okay, that makes sense. Like we can all get behind that kind of model. But that is actually really hard to make work with a lot of people's software and, and I think the challenge and framers have adopted it, right? So they've taken this, so for example, it's like, uh, react server components, which is basically just like, can we render it on the server and then also keep that same interaction in the ui. But the problem is like frameworks take that, they abstract it and so it's another layer of complexity on something that is already enormously complex. And then they add their own flavor onto it, like their own opinions for maybe what the world way the world is going. And I will say like personally, I find those. Those flavors to be very hard to adapt to like things that are tried and true or importantly in this context, things that we know how to monitor and fix, right? And so I, I don't know what, what the be all end all is, but my thesis on this is you need to treat the UI like a template engine, and that's it. Remove all like complexity behind it. And so if you think about that, the term I've labeled it as, which I did not come up with, I saw this from somebody at some point, is like, it's like your front end as a service. Like you need to take that application that renders on the server and the front end, and it's just an entirely different application, which is annoying. and it just calls your APIs and that's how it gets the data it needs. So you're literally just treating it as if it's like a single page application that can't connect to your database. But the frameworks have not quite done that. And they're like, no, no, no. We'll connect to the database and we'll do all this stuff, but then it doesn't work because you've got, like, it works this way on the back end and this way on the front end anyways. Again, long winded way of saying like, it's very complicated. I don't think the technology can solve it today. I think the technology has to change before these problems can actually genuinely become solvable. And that's why I think the whole thing is like a beta, it's like, it's very much like a moving target that we're eventually we'll get there and it's definitely had value, but I don't know that, um, responsiveness for low latency connections is where the value has been created. You know, for like folks with bad internet and say remote Africa or something, like I'm sure the internet is not a very fun place for them to use these days. Some frontend code runs on the server and some in the browser which creates challenges [00:43:05] Jeremy: I guess one of the things you mentioned is there's this, almost like this split where you have the application running on the server. It has its own set of rules because it, like you said, has access to the database and it can do things that you can't do in the browser, and then you have to sort of run the same application in the browser, but it's not quite the same application because it doesn't have access to the same things in the browser. So you have this weird disconnect, I suppose. [00:43:35] David: Yeah. Yeah. And, and, and then the challenges is like a developer that's actually complicated for you from the experience point of view, cuz you have to know somehow, okay, these things are ta, these are actually running on the server and only on the server. And like, so I think the two biggest technologies that try to do this, um, or at least do it well enough, or the two that I've used, there might be some others, um, are NextJS and remix and they have very different takes on how to do this. But, remix is the one I use most recently. So I, I'll comment on that. But like, there's a, a way that you kind of say, well, this only runs on, I think the client as an example. And that helps you a little bit. You're like, okay, this is only gonna render on the client. I can, I actually can think about that and reason about that. But then there's this thing like, okay, sometimes this runs on the server, only this part runs on the server. And it's, it just becomes like the mental capacity to figure out what's going on and debug it is like so difficult. And that database problem is like the, the normal problem, right? Like of like, I can only query the database on the server because I need secure credentials or something. Okay. I understand that as a developer, but I don't understand how to make sure the application is doing what I expect it to do and how to fix it if something goes wrong. And that, that's why I think. , I'm a, I'm a believer in constraints. The only way you make progress is you simplify problems. Like you just give up on solving the complicated thing and you make the problem simpler. Right? And so for me, that's why I'm like, just take the database outta the equation. We can create APIs from the client, from the server, same security levels. Okay? Make it so it can only do that and it has to be run as almost like a UI only thing. Now that creates complexity cuz you have to run this other service, right? And, and like I personally do not wanna have to spin up a bunch of containers just to write like a simple like web application. but again, I, I think the problem has not been simplified yet for a lot of folks. Like React did this to be fair, um, it made it a lot easier to, to build UI that was responsive and, and just updated values when they changed, you know, which was a big deal for a long period of time. But I feel like everything after has not quite reached that that area, whereas it's simple and even react is hard to debug when it doesn't do what you want it to do. So I don't know, there, there's so gaps I guess is what i would say. And. Hopefully, hopefully, you know, in the next five years we'll kind of see this come to completion because it does feel like it's, it's getting closer to that compromise. You know, where like we used to have pure server rendered apps with some weird janky JavaScript on top. Now we've got this bridge of really complicated, you know, JavaScript on top, and the server apps are also complicated and it's just, it's a nightmare. And then this newer generation of these frameworks that work for some types of technology, but not all. And, and we're kind of almost coming full circle to like server rendered, you know, everything. But with like allowing the same level of interactions that we've been desiring, I guess, on the web. So, and I, fingers crossed this gets better, but right now I do not see like a clear like, oh, it's definitely there. I can see it coming. I'm like, well, we're kind of making progress. I don't love being the beta tester of the whole thing, but we're kind of getting there. And so, you know, we'll see. There are multiple ways to write mobile apps as well (flutter, react native, web views) [00:46:36] Jeremy: I guess you, you've been saying this whole shifting landscape of how Front End works has made it difficult for Sentry to provide like automatic instrumentation and things like that for, for mobile apps. Is that a different story? Like is it pretty standardized in terms of how do you instrument an Android app or an iOS app. [00:46:58] David: Sort of, but also, no, like, a good example here is like early days mobile, it's a native application. You ship a binary known quantity, right? Or maybe you embedded a web browser, but like, that was like a very different thing. Okay. And then they did things where like, okay, more of it's like embedded web browser type stuff, or dynamically render content. So that's now a moving target. the current version of that, which I'm not a mobile dev so like people have strong opinions on both sides of this fence, but it's like, okay, do you use like a, a hybrid framework which allows you to build. Say, uh, react native, which is like arou you to sort of write a JavaScript ish thing and it runs on both Android and mobile, but not really well on either. Um, or do you write a native, native app, which is like a known quantity, but then you may maintain like two code bases, have two degrees of expertise and stuff. Flutters the same thing. so there's still that version of complexity that goes on within it. And I, I think people care less about mobile cuz it impacts people less. Like, you know, there's that whole generation of like, oh, mobile's the future, everything's gonna be mobile, let's not become true. Uh, mobile's very important, but like we have desktops still. We use web software all the time, half the time on mobile. We're just using the web software at the end of the day, so at least we know that's a thing. And I think, so I think that investment in mobile has died down some. Um, but some companies like mobile is like their main experience or one of their driving experience is like a, like a company like DoorDash, mobile is as important as web, if not more, right? Because of like the types of customers. Spotify probably same thing, but I don't know, Sentry. We don't need a mobile app, who cares? It's irrelevant to the problem space, right? And so I, I think it's just not quite taken on. And so mobile is still like this secondary citizen at a lot of companies, and I think the evolution of it has been like complicated. And so I, I think a lot of the problems are known, but maybe people care less or there's just less customers. And so the weight doesn't, like, the weight is wildly different. Like JavaScript's probably like a hundred times the size from an investment point of view for everyone in the world than say mobile applications are, is how I would think about it. And so whether mobile is or isn't solved is almost irrelevant to the, the, the like general problem at hand. and I think at the very least, like mobile applications, there's like, there's like a tool chain where you can debug a lot of stuff that works fairly well and hasn't changed over the years, whereas like the web you have like browser tools, but that's about it. So. Mobile apps can have large binaries or pull in lots of dependencies at runtime [00:49:16] Jeremy: So I guess with mobile. Um, I was initially thinking of native apps, but you're, you're bringing up that there's actually people who would make a native app that's just a web view for a webpage, or there's React native or there's flutters, so there's actually, it really isn't standard how to make a mobile app. [00:49:36] David: Yeah. And even within those, it comes back to like, okay, is it now the same problem where we're loading in a bunch of JavaScript or downloading a bunch of JavaScript and content remotely and stuff? And like, you'll see this when you install a mobile app, and sometimes the binaries are huge, right? Sometimes they're really small, and then you load it up and it's downloading like several gigs of data and stuff, right? And those are completely different patterns. And even within those like subsets, I'm sure the implementations are wildly different, right? And so, you know, I, that may not be the same as like the runtime kind of changing, but I remember there was this, uh, this must be a decade ago. I, I used, I still am a gamer, but. Um, early in my career I worked a lot with like games like World of Warcraft and stuff, and I remember when games started launching progressive loading where it's like you could download a small chunk of the game and actually start playing and maybe the textures were lower, uh, like resolution and everything was lower fidelity and, and you could only go so far until the game fully installed. But like, imagine like if you're like focused on performance or something like that, measuring it there is completely different than measuring it once, say everything's installed, you know? And so I think those often become very complex use cases. And I think that used to be like an extreme edge case that was like such a, a hyper-specific optimization for like what The Warcraft, which is like one of the biggest games of all time that it made sense, you know, okay, whatever. They can build their own custom tooling and figure it out from there. And now we've taken that degree of complexity and tried to apply it to everything in the world. And it's like uhoh, like nobody has the teams or the, the, the talent or the, the experience to necessarily debug a lot of these complicated problems just like Sentry like. You know, we're not dealing with React internals. If something's wrong in the React internals, it's like somebody might be able to figure it out, but it's gonna take us so much time to figure out what's going on, versus, oh, we're rendering some html. Cool. We understand how it works. It's, it's a known, known problem. We can debug it. Like there's nothing to even debug most of the time. Right. And so, I, I don't know, I think the industry has to get to a place where you can reason about the software, where you have the calculator, right. And you don't have to figure out how the calculator works. You just can trust that it's gonna work for you. How Sentry's stack has become more complex over time [00:51:35] Jeremy: so kind of. Shifting over a little bit to Sentry's internals. You, you said that Sentry started in, was it 2008 you said? [00:51:47] David: Uh, the open source project was in 2008. Yeah. [00:51:50] Jeremy: The stack that's used in Sentry has evolved. Like I remembered that there was a period where I think you could run it with a pretty minimal stack, like I think it may have even supported SQLite. [00:52:02] David: Yeah. [00:52:03] Jeremy: And so it was something that people could run pretty easily on their own. But things have, have obviously changed a lot. And so I, I wonder if you could speak to sort of the evolution of that process. Like when do you decide like, Hey, this thing that I built in 2008, Is, you know, not gonna cut it. And I really need to re-architect what this system is. [00:52:25] David: Yeah, so I don't know if that's actually the reality of why things have changed, that it's like, oh, this doesn't work anymore. We've definitely introduced complexity in the sense of like, probably the biggest shift for Sentry was like, it used to be everything, and it was a SQL database, and everything was kind of optional. I think half that was maintainable because it was mostly built by. And so I could maintain like an architectural vision that kept it minimal. I had the experience to figure it out and duct tape the right things. Um, so that was one thing. And I think eventually, you know, that doesn't scale as you're trying to do more and build more into the product. So there's some complexity there. but for the most part you can, it can still

2023-06-13 Weekly News - Episode 198Watch the video version on YouTube at https://youtube.com/live/r1L8Aec5-mk?feature=share Hosts:  Gavin Pickin - Senior Developer at Ortus Solutions Grant Copley - Senior Developer at Ortus Solutions Thanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and all your favorite box-es out there. A few ways  to say thanks back to Ortus Solutions: Like and subscribe to our videos on YouTube.  Help ORTUS reach for the Stars - Star and Fork our ReposStar all of your Github Box Dependencies from CommandBox with https://www.forgebox.io/view/commandbox-github  Subscribe to our Podcast on your Podcast Apps and leave us a review Sign up for a free or paid account on CFCasts, which is releasing new content every week BOXLife store: https://www.ortussolutions.com/about-us/shop Buy Ortus's Books 102 ColdBox HMVC Quick Tips and Tricks on GumRoad (http://gum.co/coldbox-tips) Learn Modern ColdFusion (CFML) in 100+ Minutes - Free online https://modern-cfml.ortusbooks.com/ or buy an EBook or Paper copy https://www.ortussolutions.com/learn/books/coldfusion-in-100-minutes   Patreon Support ()We have 40 patreons: https://www.patreon.com/ortussolutions. News and AnnouncementsOrtus Training - ColdBox Zero to HeroOctober 4th and 5thVenue Confirmation in Progress - will be less than 2 miles from the Mirage.Registration will be open soon!CF Camp Pre Conference Workshop DiscountWe can offer a 30% discount by using the code "OrtusPre30".Thank you for your ongoing support!https://www.eventbrite.com/e/cfcamp-pre-conference-workshops-by-ortus-solutions-tickets-641489421127 New Releases and UpdatesColdBox 6.9.0 ReleasedWe are excited to announce the release of ColdBox 6.9.0 LTS, packed with new features, improvements, and bug fixes. In this version, we focused on enhancing the debugging capabilities, improving the ScheduledTasks module, and fixing an important issue related to RestHandler. Let's dive into the details of these updates.https://www.ortussolutions.com/blog/coldbox-690-released Lucee 6 Beta 2Following a long last few weeks of final development, testing and bug fixing, the Lucee team is really proud to present Lucee 6 BETA 2https://dev.lucee.org/t/lucee-6-0-451-beta-2/12673 Lucee 6.0 Launch at @cf_camp

Pour ce 4e épisode, je vais à la rencontre de Mathias Bouvant, manager d'une équipe de développeurs UBISOFT à Bordeaux. 1) Dans cet épisode, il parle de son parcours : - Ses débuts dans l'informatique avec un PC ZX80 - Les spécificités du secteur du développement de jeux vidéos dans une grosse entreprise - La mission de son équipe : la création de micro services à destination des jeux Ubisoft - Cette culture de l'agilité qui l'anime au quotidien et qui facilite la vie des projets - Son rôle de manager d'une équipe technique Donc si vous suivez le podcast, évidemment ça parle tech. Mais nous faisons des focus plus précis autour du management des équipes IT, du Scrum et du secteur du gaming. 2) Le Scrum, un sujet vaste et passionnant : - Comment la méthode Scrum peut-elle vraiment réussir (sans lasser les équipes) ? - Le point de vue Mathias : “Le Scrum doit être basé sur l'entraide. Si tu commences ton Sprint et qu'on se revoit dans 2 semaines et on regarde ce que tu as fait : ça risque de ne pas marcher.” - Il y voit un vrai gain de temps sur les projets grâce à des cycles plus courts et donc des process itératifs de plus en plus efficace. 3) Comment fonctionne son service ? - Les journées débutent par les Daily (max 15 minutes) - La revue de code : pour chaque tâche une revue de code - Coder à 2 voire à 3 (”Pair Programming”) : le travail en binôme avec un expert et l'autre qui l'est moins est le meilleur moyen pour faire monter en compétences (et améliorer la qualité du code au passage). 4) Et son métier de manager ? - Très humble, Mathias à une vision très humaine du management. - Il coconstruit et challenge les développements en place avec ses équipes. - Il intègre les nouveaux arrivants et s'inspire de leurs anciennes expériences pour nourrir les méthodologies en place dans son service (notamment l'esprit agile). - Les points en One & One : essentiels pour limiter la frustration et faire progresser. - Un souci avec un collaborateur ? Il faut poser des questions, détecter les points de frictions. Et surtout : apprendre à faire des feedback positifs pour ne pas casser le collaborateur ! Au contraire : il faut l'aider à s'améliorer. 5) Et le code dans tout ça ? - Clairement, ce n'est pas coder qui prend le plus de temps ! Le code représente environ 15 à 20% du job… - Et le reste ? Les tests, les tests et les tests ! C'est la revue de code qui est la tâche la plus longue. Donc le maître mot : Patience ! Merci encore Mathias pour ton temps. Allez c'est parti pour ce nouvel épisode ! Bonne écoute et à dans 15 jours ! P.S : pour en savoir encore plus sur l'agilité et Scrum, vous pouvez écouter l'épisode numéro 2 avec Jean Pierre Lambert, créateur de la chaîne YouTube “Scrum Life”. ▬▬▬▬▬▬▬▬▬▬ Soutenez ce super podcast dédié à la tech' : - Abonnez-vous - Laissez un avis et 5 ⭐ - Merci beaucoup ! - Inscrivez-vous sur On part en prod pour ne louper aucun épisode Les informations mentionnées dans cet épisode - PC ZX80 - UBISOFT - ALCATEL - Pair/Peer Programming - SHADOW (boitier de streaming de jeux vidéo) - Agile, Scrum - MIRO, RETROMAT, Google STADIA, Jira, Elasticsearch, Kibana, Grafana, Splunk, Voice Chat - Jeux vidéo cités : Assassin's Creed, Street Fighter 2, Rainbow Six, Just Dance - Livre "La règle ? Pas de règles !: Netflix et la culture de la réinvention” de Reed Hastings - Livre “Dream Team: Les meilleurs secrets des managers pour recruter et fidéliser votre équipe idéale” de Ludovic Girodon - Série “Drôle” de Fanny HERRERO : https://www.captainwatch.com/serie/157726/drole - DELUXE : groupe de musique originaire d'Aix en Provence - GHOST : groupe de musique Pour suivre l'actualité de Mathias LinkedIn de Mathias : https://www.linkedin.com/in/mathias-bouvant-8346a6132/ ▬▬▬▬▬▬▬▬▬▬ Postproduction Audio : Guillaume Lefebvre Music by MADiRFAN from Pixabay

About ThomasThomas Hazel is Founder, CTO, and Chief Scientist of ChaosSearch. He is a serial entrepreneur at the forefront of communication, virtualization, and database technology and the inventor of ChaosSearch's patented IP. Thomas has also patented several other technologies in the areas of distributed algorithms, virtualization and database science. He holds a Bachelor of Science in Computer Science from University of New Hampshire, Hall of Fame Alumni Inductee, and founded both student & professional chapters of the Association for Computing Machinery (ACM).Links Referenced: ChaosSearch: https://www.chaossearch.io/ Twitter: https://twitter.com/ChaosSearch Facebook: https://www.facebook.com/CHAOSSEARCH/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at AWS AppConfig. Engineers love to solve, and occasionally create, problems. But not when it's an on-call fire-drill at 4 in the morning. Software problems should drive innovation and collaboration, NOT stress, and sleeplessness, and threats of violence. That's why so many developers are realizing the value of AWS AppConfig Feature Flags. Feature Flags let developers push code to production, but hide that that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development. You can seamlessly incorporate AppConfig Feature Flags into your AWS or cloud environment and ship your Features with excitement, not trepidation and fear. To get started, go to snark.cloud/appconfig. That's snark.cloud/appconfig.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is brought to us by our returning sponsor and friend, ChaosSearch. And once again, the fine folks at ChaosSearch has seen fit to basically subject their CTO and Founder, Thomas Hazel, to my slings and arrows. Thomas, thank you for joining me. It feels like it's been a hot minute since we last caught up.Thomas: Yeah, Corey. Great to be on the program again, then. I think it's been almost a year. So, I look forward to these. They're fun, they're interesting, and you know, always a good time.Corey: It's always fun to just take a look at companies' web pages in the Wayback Machine, archive.org, where you can see snapshots of them at various points in time. Usually, it feels like this is either used for long-gone things and people want to remember the internet of yesteryear, or alternately to deliver sick burns with retorting a “This you,” when someone winds up making an unpopular statement. One of the approaches I like to use it for, which is significantly less nefarious—usually—is looking back in time at companies' websites, just to see how the positioning of the product evolves over time.And ChaosSearch has had an interesting evolution in that direction. But before we get into that, assuming that there might actually be people listening who do not know the intimate details of exactly what it is you folks do, what is ChaosSearch, and what might you folks do?Thomas: Yeah, well said, and I look forward to [laugh] doing the Wayback Time because some of our ideas, way back when, seemed crazy, but now they make a lot of sense. So, what ChaosSearch is all about is transforming customers' cloud object stores like Amazon S3 into an analytical database that supports search and SQL-type use cases. Now, where's that apply? In log analytics, observability, security, security data lakes, operational data, particularly at scale, where you just stream your data into your data lake, connect our service, our SaaS service, to that lake and automagically we index it and provide well-known APIs like Elasticsearch and integrate with Kibana or Grafana, and SQL APIs, something like, say, a Superset or Tableau or Looker into your data. So, you stream it in and you get analytics out. And the key thing is the time-cost complexity that we all know that operational data, particularly at scale, like terabytes and a day and up causes challenges, and we all know how much it costs.Corey: They certainly do. One of the things that I found interesting is that, as I've mentioned before, when I do consulting work at The Duckbill Group, we have absolutely no partners in the entire space. That includes AWS, incidentally. But it was easy in the beginning because I was well aware of what you folks were up to, and it was great when there was a use case that matched of you're spending an awful lot of money on Elasticsearch; consider perhaps migrating some of that—if it makes sense—to ChaosSearch. Ironically, when you started sponsoring some of my nonsense, that conversation got slightly trickier where I had to disclose, yeah our media arm is does have sponsorships going on with them, but that has no bearing on what I'm saying.And if they take their sponsorships away—please don't—then we would still be recommending them because it's the right answer, and it's what we would use if we were in your position. We receive no kickbacks or partner deal or any sort of reseller arrangement because it just clouds the whole conflict of interest perception. But you folks have been fantastic for a long time in a bunch of different ways.Thomas: Well, you know, I would say that what you thought made a lot of sense made a lot of sense to us as well. So, the ChaosSearch idea just makes sense. Now, you had to crack some code, solve some problems, invent some technology, and create some new architecture, but the idea that Elasticsearch is a useful solution with all the tooling, the visualization, the wonderful community around that, was a good place to start, but here's the problem: setting it up, scaling it out, keep it up, when things are happening, things go bump in the night. All those are real challenges, and one of them was just the storaging of the data. Well, what if you could make S3 the back-end store? One hundred percent; no SSDs or HDDs. Makes a lot of sense.And then support the APIs that your tooling uses. So, it just made a lot of sense on what we were trying to do, just no one thought of it. Now, if you think about the Northstar you were talking about, you know, five, six years ago, when I said, transforming cloud storage into an analytical database for search and SQL, people thought that was crazy and mad. Well, now everyone's using Cloud Storage, everyone's using S3 as a data lake. That's not in question anymore.But it was a question five, six, you know, years ago. So, when we met up, you're like, “Well, that makes sense.” It always made sense, but people either didn't think was possible, or were worried, you know, I'll just try to set up an Elastic cluster and deal with it. Because that's what happens when you particularly deal with large-scale implementations. So, you know, to us, we would love the Elastic API, the tooling around it, but what we all know is the cost, the time the complexity, to manage it, to scale it out, just almost want to pull your hair out. And so, that's where we come in is, don't change what you do, just change how you do it.Corey: Every once in a while, I'll talk to a client who's running an Amazon Elasticsearch cluster, and they have nothing but good things to say about it. Which, awesome. On the one hand, part of me wishes that I had some of their secrets, but often what's happened is that they have this down to a science, they have a data lifecycle that's clearly defined and implemented, the cluster is relatively static, so resizes aren't really a thing, and it just works for their use cases. And in those scenarios, like, “Do you care about the bill?” “Not overly. We don't have to think about it.”Great. Then why change? If there's no pain, you're not going to sell someone something, especially when we're talking, this tends to be relatively smaller-scale as well. It's okay, great, they're spending $5,000 a month on it. It doesn't necessarily justify the engineering effort to move off.Now, when you start looking at this, and, “Huh, that's a quarter million bucks a month we're spending on this nonsense, and it goes down all the time,” yeah, that's when it starts to be one of those logical areas to start picking apart and diving into. What's also muddied the waters since the last time we really went in-depth on any of this was it used to be we would be talking about it exactly like we are right now, about how it's Elasticsearch-compatible. Technically, these days, we probably shouldn't be saying it is OpenSearch compatible because of the trademark issues between Elastic and AWS and the Schism of the OpenSearch fork of the Elasticsearch project. And now it feels like when you start putting random words in front of the word search, ChaosSearch fits right in. It feels like your star is rising.Thomas: Yeah, no, well said. I appreciate that. You know, it's funny when Elastic changed our license, we all didn't know what was going to happen. We knew something was going to happen, but we didn't know what was going to happen. And Amazon, I say ironically, or, more importantly, decided they'll take up the open mantle of keeping an open, free solution.Now, obviously, they recommend running that in their cloud. Fair enough. But I would say we don't hear as much Elastic replacement, as much as OpenSearch replacement with our solution because of all the benefits that we talked about. Because the trigger points for when folks have an issue with the OpenSearch or Elastic stack is got too expensive, or it was changing so much and it was falling over, or the complexity of the schema changing, or all the above. The pipelines were complex, particularly at scale.That's both for Elasticsearch, as well as OpenSearch. And so, to us, we want either to win, but we want to be the replacement because, you know, at scale is where we shine. But we have seen a real trend where we see less Elasticsearch and more OpenSearch because the community is worried about the rules that were changed, right? You see it day in, day out, where you have a community that was built around open and fair and free, and because of business models not working or the big bad so-and-so is taking advantage of it better, there's a license change. And that's a trust change.And to us, we're following the OpenSearch path because it's still open. The 600-pound gorilla or 900-pound gorilla of Amazon. But they really held the mantle, saying, “We're going to stay open, we assume for as long as we know, and we'll follow that path. But again, at that scale, the time, the costs, we're here to help solve those problems.” Again, whether it's on Amazon or, you know, Google et cetera.Corey: I want to go back to what I mentioned at the start of this with the Wayback Machine and looking at how things wound up unfolding in the fullness of time. The first time that it snapshotted your site was way back in the year 2018, which—Thomas: Nice. [laugh].Corey: Some of us may remember, and at that point, like, I wasn't doing any work with you, and later in time I would make fun of you folks for this, but back then your brand name was in all caps, so I would periodically say things like this episode is sponsored by our friends at [loudly] CHAOSSEARCH.Thomas: [laugh].Corey: And once you stopped capitalizing it and that had faded from the common awareness, it just started to look like I had the inability to control the volume of my own voice. Which, fair, but generally not mid-sentence. So, I remember those early days, but the positioning of it was, “The future of log management and analytics,” back in 2018. Skipping forward a year later, you changed this because apparently in 2019, the future was already here. And you were talking about, “Log search analytics, purpose-built for Amazon S3. Store everything, ask anything all on your Amazon S3.”Which is awesome. You were still—unfortunately—going by the all caps thing, but by 2020, that wound up changing somewhat significantly. You were at that point, talking for it as, “The data platform for scalable log analytics.” Okay, it's clearly heading in a log direction, and that made a whole bunch of sense. And now today, you are, “The data lake platform for analytics at scale.” So, good for you, first off. You found a voice?Thomas: [laugh]. Well, you know, it's funny, as a product mining person—I'll take my marketing hat off—we've been building the same solution with the same value points and benefits as we mentioned earlier, but the market resonates with different terminology. When we said something like, “Transforming your Cloud Object Storage like S3 into an analytical database,” people were just were like, blown away. Is that even possible? Right? And so, that got some eyes.Corey: Oh, anything is a database if you hold that wrong. Absolutely.Thomas: [laugh]. Yeah, yeah. And then you're saying log analytics really resonated for a few years. Data platform, you know, is more broader because we do more broader things. And now we see over the last few years, observability, right? How do you fit in the observability viewpoint, the stack where log analytics is one aspect to it?Some of our customers use Grafana on us for that lens, and then for the analysis, alerting, dashboarding. You can say that Kibana in the hunting aspect, the log aspects. So, you know, to us, we're going to put a message out there that resonates with what we're hearing from our customers. For instance, we hear things like, “I need a security data lake. I need that. I need to stream all my data. I need to have all the data because what happens today that now, I need to know a week, two weeks, 90 days.”We constantly hear, “I need at least 90 days forensics on that data.” And it happens time and time again. We hear in the observability stack where, “Hey, I love Datadog, but I can't afford it more than a week or two.” Well, that's where we come in. And we either replace Datadog for the use cases that we support, or we're auxiliary to it.Sometimes we have an existing Grafana implementation, and then they store data in us for the long tail. That could be the scenario. So, to us, the message is around what resonates with our customers, but in the end, it's operational data, whether you want to call it observability, log analytics, security analytics, like the data lake, to us, it's just access to your data, all your data, all the time, and supporting the APIs and the tooling that you're using. And so, to me, it's the same product, but the market changes with messaging and requirements. And this is why we always felt that having a search and SQL platform is so key because what you'll see in Elastic or OpenSearch is, “Well, I only support the Elastic API. I can't do correlations. I can't do this. I can't do that. I'm going to move it over to say, maybe Athena but not so much. Maybe a Snowflake or something else.”Corey: “Well, Thomas, it's very simple. Once you learn our own purpose-built, domain-specific language, specifically for our product, well, why are you still sitting here, go learn that thing.” People aren't going to do that.Thomas: And that's what we hear. It was funny, I won't say what the company was, a big banking company that we're talking to, and we hear time and time again, “I only want to do it via the Elastic tooling,” or, “I only want to do it via the BI tooling.” I hear it time and time again. Both of these people are in the same company.Corey: And that's legitimate as well because there's a bunch of pre-existing processes pointing at things and we're not going to change 200 different applications in their data model just because you want to replace a back-end system. I also want to correct myself. I was one tab behind. This year's branding is slightly different: “Search and analyze unlimited log data in your cloud object storage.” Which is, I really like the evolution on this.Thomas: Yeah, yeah. And I love it. And what was interesting is the moving, the setting up, the doubling of your costs, let's say you have—I mean, we deal with some big customers that have petabytes of data; doubling your petabytes, that means, if your Elastic environment is costing you tens of millions and then you put into Snowflake, that's also going to be tens of millions. And with a solution like ours, you have really cost-effective storage, right? Your cloud storage, it's secure, it's reliable, it's Elastic, and you attach Chaos to get the well-known APIs that your well-known tooling can analyze.So, to us, our evolution has been really being the end viewpoint where we started early, where the search and SQL isn't here today—and you know, in the future, we'll be coming out with more ML type tooling—but we have two sides: we have the operational, security, observability. And a lot of the business side wants access to that data as well. Maybe it's app data that they need to do analysis on their shopping cart website, for instance.Corey: The thing that I find curious is, the entire space has been iterating forward on trying to define observability, generally, as whatever people are already trying to sell in many cases. And that has seemed to be a bit of a stumbling block for a lot of folks. I figured this out somewhat recently because I've built the—free for everyone to use—the lasttweetinaws.com, Twitter threading client.That's deployed to 20 different AWS regions because it's go—the idea is that should be snappy for people, no matter where they happen to be on the planet, and I use it for conferences when I travel, so great, let's get ahead of it. But that also means I've got 20 different sources of logs. And given that it's an omnibus Lambda function, it's very hard to correlate that to users, or user sessions, or even figure out where it's going. The problem I've had is, “Oh, well, this seems like something I could instrument to spray logs somewhere pretty easily, but I don't want to instrument it for 15 different observability vendors. Why don't I just use otel—or Open Telemetry—and then tell that to throw whatever I care about to various vendors and do a bit of a bake-off?” The problem, of course, is that open telemetry and Lambda seem to be in just the absolute wrong directions. A lot.Thomas: So, we see the same trend of otel coming out, and you know, this is another API that I'm sure we're going to go all-in on because it's getting more and more talked about. I won't say it's the standard that I think is trending to all your points about I need to normalize a process. But as you mentioned, we also need to correlate across the data. And this is where, you know, there are times where search and hunting and alerting is awesome and wonderful and solves all your needs, and sometimes correlation. Imagine trying to denormalize all those logs, set up a pipeline, put it into some database, or just do a SELECT *, you know, join this to that to that, and get your answers.And so, I think both OpenTelemetry and SQL and search all need to be played into one solution, or at least one capability because if you're not doing that, you're creating some hodgepodge pipeline to move it around and ultimately get your questions answered. And if it takes weeks—maybe even months, depending on the scale—you may sometimes not choose to do it.Corey: One other aspect that has always annoyed me about more or less every analytics company out there—and you folks are no exception to this—is the idea of charging per gigabyte ingested because that inherently sets up a weird dichotomy of, well, this is costing a lot, so I should strive to log less. And that is sort of the exact opposite, not just of the direction you folks want customers to go in, but also where customers themselves should be going in. Where you diverge from an awful lot of those other companies because of the nature of how you work, is that you don't charge them again for retention. And the idea that, yeah, the fact that anything stored in ChaosSearch lives in your own S3 buckets, you can set your own lifecycle policies and do whatever you want to do with that is a phenomenal benefit, just because I've always had a dim view of short-lived retention periods around logs, especially around things like audit logs. And these days, I would consider getting rid of audit logging data and application logging data—especially if there's a correlation story—any sooner than three years feels like borderline malpractice.Thomas: [laugh]. We—how many times—I mean, we've heard it time and time again is, “I don't have access to that data because it was too costly.” No one says they don't want the data. They just can't afford the data. And one of the key premises that if you don't have all the data, you're at risk, particularly in security—I mean, even audits. I mean, so many times our customers ask us, you know, “Hey, what was this going on? What was that go on?” And because we can so cost-effectively monitor our own service, we can provide that information for them. And we hear this time and time again.And retention is not a very sexy aspect, but it's so crucial. Anytime you look in problems with X solution or Y solution, it's the cost of the data. And this is something that we wanted to address, officially. And why do we make it so cost-effective and free after you ingest it was because we were using cloud storage. And it was just a great place to land the data cost-effective, securely.Now, with that said, there are two types of companies I've seen. Everybody needs at least 90 days. I see time and time again. Sure, maybe daily, in a weeks, they do a lot of their operation, but 90 days is where it lands. But there's also a bunch of companies that need it for years, for compliance, for audit reasons.And imagine trying to rehydrate, trying to rebuild—we have one customer—again I won't say who—has two petabytes of data that they rehydrate when they need it. And they say it's a nightmare. And it's growing. What if you just had it always alive, always accessible? Now, as we move from search to SQL, there are use cases where in the log world, they just want to pay upfront, fixed fee, this many dollars per terabyte, but as we get into the more ad hoc side of it, more and more folks are asking for, “Can I pay per query?”And so, you'll see coming out soon, about scenarios where we have a different pricing model. For logs, typically, you want to pay very consistent, you know, predetermined cost structure, but in the case of more security data lakes, where you want to go in the past and not really pay for something until you use it, that's going to be an option as well coming out soon. So, I would say you need both in the pricing models, but you need the data to have either side, right?Corey: This episode is sponsored in part by our friends at ChaosSearch. You could run Elasticsearch or Elastic Cloud—or OpenSearch as they're calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you've come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you're using Elasticsearch, consider not running Elasticsearch. They're also available now in the AWS marketplace if you'd prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.Corey: You'd like to hope. I mean, you could always theoretically wind up just pulling what Ubiquiti apparently did—where this came out in an indictment that was unsealed against an insider—but apparently one of their employees wound up attempting to extort them—which again, that's not their fault, to be clear—but what came out was that this person then wound up setting the CloudTrail audit log retention to one day, so there were no logs available. And then as a customer, I got an email from them saying there was no evidence that any customer data had been accessed. I mean, yeah, if you want, like, the world's most horrifyingly devilish best practice, go ahead and set your log retention to nothing, and then you too can confidently state that you have no evidence of anything untoward happening.Contrast this with what AWS did when there was a vulnerability reported in AWS Glue. Their analysis of it stated explicitly, “We have looked at our audit logs going back to the launch of the service and have conclusively proven that the only time this has ever happened was in the security researcher who reported the vulnerability to us, in their own account.” Yeah, one of those statements breeds an awful lot of confidence. The other one makes me think that you're basically being run by clowns.Thomas: You know what? CloudTrail is such a crucial—particularly Amazon, right—crucial service because of that, we see time and time again. And the challenge of CloudTrail is that storing a long period of time is costly and the messiness the JSON complexity, every company struggles with it. And this is how uniquely—how we represent information, we can model it in all its permutations—but the key thing is we can store it forever, or you can store forever. And time and time again, CloudTrail is a key aspect to correlate—to your question—correlate this happened to that. Or do an audit on two years ago, this happened.And I got to tell you, to all our listeners out there, please store your CloudTrail data—ideally in ChaosSearch—because you're going to need it. Everyone always needs that. And I know it's hard. CloudTrail data is messy, nested JSON data that can explode; I get it. You know, there's tricks to do it manually, although quite painful. But CloudTrail, every one of our customers is indexing with us in CloudTrail because of stories like that, as well as the correlation across what maybe their application log data is saying.Corey: I really have never regretted having extra logs lying around, especially with, to be very direct, the almost ridiculously inexpensive storage classes that S3 offers, especially since you can wind up having some of the offline retrieval stuff as part of a lifecycle policy now with intelligent tiering. I'm a big believer in just—again—the Glacier Deep Archive I've at the cost of $1,000 a month per petabyte, with admittedly up to 12 hours of calling that as a latency. But that's still, for audit logs and stuff like that, why would I ever want to delete things ever again?Thomas: You're exactly right. And we have a bunch of customers that do exactly that. And we automate the entire process with you. Obviously, it's your S3 account, but we can manage across those tiers. And it's just to a point where, why wouldn't you? It's so cost-effective.And the moments where you don't have that information, you're at risk, whether it's internal audits, or you're providing a service for somebody, it's critical data. With CloudTrail, it's critical data. And if you're not storing it and if you're not making it accessible through some tool like an Elastic API or Chaos, it's not worth it. I think, to your point about your story, it's epically not worth it.Corey: It's really not. It's one of those areas where that is not a place to overly cost optimize. This is—I mean we talked earlier about my business and perceptions of conflict of interest. There's a reason that I only ever charge fixed-fee and not percentage of savings or whatnot because, at some point, I'll be placed in a position of having to say nonsense, like, “Do you really need all of these backups?” That doesn't make sense at that point.I do point out things like you have hourly disk snapshots of your entire web fleet, which has no irreplaceable data on them dating back five years. Maybe cleaning some of that up might be the right answer. The happy answer is somewhere in between those two, and it's a business decision around exactly where that line lies. But I'm a believer in never regretting having kept logs almost into perpetuity. Until and unless I start getting more or less pillaged by some particularly rapacious vendor that's oh, yeah, we're going to charge you not just for ingest, but also for retention. And for how long you want to keep it, we're going to treat it like we're carving it into platinum tablets. No. Stop that.Thomas: [laugh]. Well, you know, it's funny, when we first came out, we were hearing stories that vendors were telling customers why they didn't need their data, to your point, like, “Oh, you don't need that,” or, “Don't worry about that.” And time and time again, they said, “Well, turns out we didn't need that.” You know, “Oh, don't index all your data because you just know what you know.” And the problem is that life doesn't work out that way business doesn't work out that way.And now what I see in the market is everyone's got tiering scenarios, but the accessibility of that data takes some time to get access to. And these are all workarounds and bandaids to what fundamentally is if you design an architecture and a solution is such a way, maybe it's just always hot; maybe it's just always available. Now, we talked about tiering off to something very, very cheap, then it's like virtually free. But you know, our solution was, whether it's ultra warm, or this tiering that takes hours to rehydrate—hours—no one wants to live in that world, right? They just want to say, “Hey, on this date on this year, what was happening? And let me go look, and I want to do it now.”And it has to be part of the exact same system that I was using already. I didn't have to call up IT to say, “Hey, can you rehydrate this?” Or, “Can I go back to the archive and look at it?” Although I guess we're talking about archiving with your website, viewing from days of old, I think that's kind of funny. I should do that more often myself.Corey: I really wish that more companies would put themselves in the customers' shoes. And for what it's worth, periodically, I've spoken to a number of very happy ChaosSearch customers. I haven't spoken to any angry ones yet, which tells me you're either terrific at crisis comms, or the product itself functions as intended. So, either way, excellent job. Now, which team of yours is doing that excellent job, of course, is going to depend on which one of those outcomes it is. But I'm pretty good at ferreting out stories on those things.Thomas: Well, you know, it's funny, being a company that's driven by customer ask, it's so easy build what the customer wants. And so, we really take every input of what the customer needs and wants—now, there are cases where we relace Splunk. They're the Cadillac, they have all the bells and whistles, and there's times where we'll say, “Listen, that's not what we're going to do. We're going to solve these problems in this vector.” But they always keep on asking, right? You know, “I want this, I want that.”But most of the feedback we get is exactly what we should be building. People need their answers and how they get it. It's really helped us grow as a company, grow as a product. And I will say ever since we went live now many, many years ago, all our roadmap—other than our Northstar of transforming cloud storage into a search SQL big data analytics database has been customer-driven, market customer-driven, like what our customer is asking for, whether it's observability and integrating with Grafana and Kibana or, you know, security data lakes. It's just a huge theme that we're going to make sure that we provide a solution that meets those needs.So, I love when customers ask for stuff because the product just gets better. I mean, yeah, sometimes you have to have a thick skin, like, “Why don't you have this?” Or, “Why don't you have that?” Or we have customers—and not to complain about customers; I love our customers—but they sometimes do crazy things that we have to help them on crazy-ify. [laugh]. I'll leave it at that. But customers do silly things and you have to help them out. I hope they remember that, so when they ask for a feature that maybe takes a month to make available, they're patient with us.Corey: We sure can hope. I really want to thank you for taking so much time to once again suffer all of my criticisms, slings and arrows, blithe market observations, et cetera, et cetera. If people want to learn more, where's the best place to find you?Thomas: Well, of course, chaossearch.io. There's tons of material about what we do, use cases, case studies; we just published a big case study with Equifax recently. We're in Gartner and a whole bunch of Hype Cycles that you can pull down to see how we fit in the market.Reach out to us. You can set up a trial, kick the tires, again, on your cloud storage like S3. And ChaosSearch on Twitter, we have a Facebook, we have all this classic social medias. But our website is really where all the good content and whether you want to learn about the architecture and how we've done it, and use cases; people who want to say, “Hey, I have a problem. How do you solve it? How do I learn more?”Corey: And we will, of course, put links to that in the show notes. For my own purposes, you could also just search for the term ChaosSearch in your email inbox and find one of their sponsored ads in my newsletter and click that link, but that's a little self-serving as we do it. I'm kidding. I'm kidding. There's no need to do that. That is not how we ever evaluate these things. But it is funny to tell that story. Thomas, thank you so much for your time. As always, it's appreciated.Thomas: Corey Quinn, I truly enjoyed this time. And I look forward to upcoming re:Invent. I'm assuming it's going to be live like last year, and this is where we have a lot of fun with the community.Corey: Oh, I have no doubt that we're about to go through that particular path very soon. Thank you. It's been an absolute pleasure.Thomas: Thank you.Corey: Thomas Hazel, CTO and Founder of ChaosSearch. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment that I will then set to have a retention period of one day, and then go on to claim that I have received no negative feedback.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Processing real-time event streams enables countless use cases big and small. With a day job designing and building highly available distributed data systems, Simon Aubury (Principal Data Engineer, Thoughtworks) believes stream-processing thinking can be applied to any stream of events. In this episode, Simon shares his Confluent Hackathon '22 winning project—a wildlife monitoring system to observe population trends over time using a Raspberry Pi, along with Apache Kafka®, Kafka Connect, ksqlDB, TensorFlow Lite, and Kibana. He used the system to count animals in his Australian backyard and perform trend analysis on the results. Simon also shares ideas on how you can use these same technologies to help with other real-world challenges.Open-source, object detection models for TensorFlow, which appropriately are collected into "model zoos," meant that Simon didn't have to provide his own object identification as part of the project, which would have made it untenable. Instead, he was able to utilize the open-source models, which are essentially neural nets pretrained on relevant data sets—in his case, backyard animals.Simon's system, which consists of around 200 lines of code, employs a Kafka producer running a while loop, which connects to a camera feed using a Python library. For each frame brought down, object masking is applied in order to crop and reduce pixel density, and then the frame is compared to the models mentioned above. A Python dictionary containing probable found objects is sent to a Kafka broker for processing; the images themselves aren't sent. (Note that Simon's system is also capable of alerting if a specific, rare animal is detected.) On the broker, Simon uses ksqlDB and windowing to smooth the data in case the frames were inconsistent for some reason (it may look back over thirty seconds, for example, and find the highest number of animals per type). Finally, the data is sent to a Kibana dashboard for analysis, through a Kafka Connect sink connector. Simon's system is an extremely low-cost system that can simulate the behaviors of more expensive, proprietary systems. And the concepts can easily be applied to many other use cases. For example, you could use it to estimate traffic at a shopping mall to gauge optimal opening hours, or you could use it to monitor the queue at a coffee shop, counting both queued patrons as well as impatient patrons who decide to leave because the queue is too long.EPISODE LINKSReal-Time Wildlife Monitoring with Apache KafkaWildlife Monitoring GithubksqlDB Fundamentals: How Apache Kafka, SQL, and ksqlDB Work TogetherEvent-Driven Architecture - Common Mistakes and Valuable LessonsWatch the video version of this podcastKris Jenkins' TwitterJoin the Confluent CommunityLearn more on Confluent DeveloperUse PODCAST100 to get $100 of free Confluent Cloud usage (details)   

Kim Doyal 0:01 Welcome to F the hustle. I'm your host, Kim Doyal. You want a life that is meaningful and exciting. In this podcast, we're going to talk about launching and growing an online business that fits your lifestyle. F the hustle is all about doing good work, building real relationships, and most importantly, creating a business that supports how you want to live your life. You don't have to sacrifice the quality of your life today to create something that sets your soul on fire. And yes, that includes making a lot of money. So we'll be talking about selling, charging, what you're worth, and how earning more means helping more people. My goal is to help you find freedom and create a business on your terms. Hey, what's going on everybody? Welcome back to another episode of EFF the hustle with Kim Doyal. I am your host, Kim Doyal. I'm really excited today because I swear to God, come on. I feel like my good friend come on. And we've known each other like two months or something. But this I feel like it's been a long time coming, but it hasn't we met a few months ago. My guest is C'mon Chung. Did I say your name correctly? Unknown Speaker 1:04 That's correct. Very good. Kim Doyal 1:06 Okay, I was like, you know, it's funny, I have a tent, I do this. And I'm like, Kim, you need to clarify this before you actually get on the interview. But anyway, Kibana and I connected through Twitter. And I just kind of fell in love with his content and what he was doing. I signed up for his free email course, which he's going to talk about everything he's doing. And one of the best things that I just love this is in his follow up sequence. He said, hit reply, and tell me, he said I reply to every email. And he did. And I just thought, this is friggin brilliant. I shared what he was doing. It was it was just a real fun engagement. And so come on. Thank you for being here today. Unknown Speaker 1:45 Yeah, thank you, Kim, for having me here. Seriously, I reply to 100% of my email. But sometimes like seven days, late 14 days late, like today, I was replying emails 14 days late. But late is better than never showing up. Right. So that's my, that's my way of doing things. Kim Doyal 2:04 Oh, absolutely. And you know, it's funny simply, I obviously love email. I do so much with email. I still it's kind of my almost a preferred choice of communication. But I like to get into conversations with people. I think it's, it's fantastic. So all right. We're gonna talk about everything. I love starting with the backstory. And you do this full time now you're a full time creator, and I should we should clarify for people. So our time zones are a little bit off. It's eight o'clock in Costa Rica. Where are you? And what time is it for you right now? Unknown Speaker 2:33 Well, I am based in Hong Kong is 10pm over here. But if you ask me, I am living in my computer right now. Because most of my friends are actually online, I just feel more connected to people like you, who were doing similar things where we're passionate about what we do, and it's hard to find it locally, honestly. Kim Doyal 2:56 Oh, you know, it's crazy. I was I'm from Northern California, San Francisco Bay Area, and I was out in the suburbs. So it was very, it felt very difficult for a long time. Like nobody gets what I do. Nobody understands. Unknown Speaker 3:09 I guess I feel the same way. Kim Doyal 3:12 Yeah, absolutely. And I'm a big believer online friends are friends. So how long? I'd love to hear your backstory, like I said, what got you into doing this? You know, a lot of people, you know, maybe it's just a desire or quit a job, whatever. But how did you start your online journey? What were you doing before? Unknown Speaker 3:30 So you know, the kind of life changing point for that is 20 months ago, I felt like a nobody. And I will tell you why. Because I have been in startups all my career for nine

Some products solve a huge issue for their users. But sometimes, it is this big innovation that stands in the way of users adopting newer features. The product falls victim to its own success.Philipp Krenn, EMEA Team Lead at Elastic, shares how they dealt with it, and talks with Elias about Elastic's experience.What's in it for you:1. Why innovative products can fall victim to their own success2. What changing licensing on Elastic and abandoning open source changed in Elastic's community3. What are the drivers behind adoption of cloud delivery for Elastic4. Philipp's thoughts on the benefits and trade-offs of observability players expanding into the security domainAbout Philipp:Philipp lives to demo interesting technology. Having worked as a web, infrastructure, and database engineer for over ten years, Philipp is now a developer advocate and EMEA team lead at Elastic — the company behind the Elastic Stack consisting of Elasticsearch, Kibana, Beats, and Logstash. Based in Vienna, Austria, he is constantly traveling Europe and beyond to speak and discuss open source software, search, databases, infrastructure, and security.Find Philipp on LinkedIn: https://www.linkedin.com/in/philippkrenn/ Find him on Twitter: @xeraaFind him on GitHub: https://github.com/xeraa _______About Elastic:From the early days of Elasticsearch to how the ELK Stack came to be, a period of awesome (but chaotic) development, the introduction of the Elastic Stack, and a new era of search-based solutions for enterprise search, observability, and security. There's a lot of goodness to unpack around Elastic.Website: https://www.elastic.co/ Industry: Analytics, Cloud Computing, Open Source, SaaS, Search Engine, SoftwareCompany size: 1001-5000Headquarters: San Francisco Bay Area, Silicon Valley, West CoastFounded: 2012_______ About the host Elias:Elias is Director of International and Indirect Business at tribe29. He comes from a strategy consulting background, but has been an entrepreneur for the better part of the last 10 years. In his spare time, he likes to do triathlon.Get in touch with Elias via LinkedIn or email elias.voelker@tribe29.com__________Podcast MusicMusic by Ströme, used by permission‚Panta Rhei‘ written by Mario Schoenhofer(c)+p 2022, Compost Medien GmbH & Co KGwww.stroeme.comhttps://compost-rec.com/ 

OpenSearch is a community-driven, open-source search and analytics suite derived from Apache 2.0 licensed Elasticsearch 7.10.2 & Kibana 7.10.2. The OpenSearch project started just over a year ago and is now the open-source alternative to ELK, which is no longer open source. The team has spent much of the last year getting the project going, but there was innovation as well. We will cover and discuss what OpenSearch has accomplished, but more importantly what's coming next, including a big 2.0 release. We are joined in this episode by Eli Fisher, who is the product lead at AWS, working on the OpenSearch project. He'll dive into recent launches, including several observability features, and innovations planned for 2.0 and beyond.    The podcast episodes are available for listening on your favorite podcast app and on this YouTube channel.   We live-stream the episodes, and you're welcome to join the stream here on YouTube Live or at https://www.twitch.tv/openobservability​.   

Isaac Levin from Elastic joins Scott Hanselman to discuss Elastic Cloud on Azure. Elastic Cloud is an Elasticsearch and Kibana managed service - with solutions for enterprise search, observability, and security. Running Elastic on Azure enables you to take data from any source - reliably and securely, in any format - then search, analyze, and visualize that data in real time. Elastic on Azure users experience frictionless integration directly within the Azure portal, allowing for faster time to market. With deployment models to meet your unique use case, you'll gain the speed, scale, and relevance you need to react quickly to support your rapidly evolving business needs. Chapters 00:00 - Introduction 01:04 - Getting started with Elasticsearch 04:05 - Enterprise search 05:10 - App Search: Engines 06:06 - App Search: Analytics 06:58 - App Search: Web crawler 08:16 - App Search: Search UI 10:17 - App Search: Relevance tuning 12:13 - App Search: Synonyms 14:56 - App Search: Curations 17:15 - Wrap-up Recommended resources Elastic on Azure Elastic Enterprise Search Elastic Search UI Create a free account Connect Scott Hanselman | Twitter: @shanselman Isaac Levin | Twitter: @isaacrlevin Elastic | Twitter: @elastic Azure Friday | Twitter: @azurefriday

Isaac Levin from Elastic joins Scott Hanselman to discuss Elastic Cloud on Azure. Elastic Cloud is an Elasticsearch and Kibana managed service - with solutions for enterprise search, observability, and security. Running Elastic on Azure enables you to take data from any source - reliably and securely, in any format - then search, analyze, and visualize that data in real time. Elastic on Azure users experience frictionless integration directly within the Azure portal, allowing for faster time to market. With deployment models to meet your unique use case, you'll gain the speed, scale, and relevance you need to react quickly to support your rapidly evolving business needs. Chapters 00:00 - Introduction 01:04 - Getting started with Elasticsearch 04:05 - Enterprise search 05:10 - App Search: Engines 06:06 - App Search: Analytics 06:58 - App Search: Web crawler 08:16 - App Search: Search UI 10:17 - App Search: Relevance tuning 12:13 - App Search: Synonyms 14:56 - App Search: Curations 17:15 - Wrap-up Recommended resources Elastic on Azure Elastic Enterprise Search Elastic Search UI Create a free account Connect Scott Hanselman | Twitter: @shanselman Isaac Levin | Twitter: @isaacrlevin Elastic | Twitter: @elastic Azure Friday | Twitter: @azurefriday

On The Cloud Pod this week, Jonathan is still AWOL. Also Amazon is on GuardDuty with credential exfiltration, Google Cloud Deploy is generally available, and Azure is suffering from more serious DDoS attacks.  A big thanks to this week's sponsors: Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. This week's highlights

Xin Shi, an Azure PM focused on the Developer Experience, tells us about the Service Connector service in Azure which makes is easy for developers to ensure apps have all the right connectivity and security in place to access their Azure resources.   Media file: https://azpodcast.blob.core.windows.net/episodes/Episode409.mp3 YouTube: https://youtu.be/odJubQN6SJ8 Resources: https://aka.ms/service-connector   Other updates: http://azure.microsoft.com/en-us/updates/public-preview-azure-static-web-apps-enterprisegrade-edge/   General availability: Ultra disks support on AKS | Azure updates | Microsoft Azure   Public Preview: Managed Certificate support for Azure API Management | Azure updates | Microsoft Azure   Azure DDoS Protection—2021 Q3 and Q4 DDoS attack trends https://azure.microsoft.com/en-us/blog/azure-ddos-protection-2021-q3-and-q4-ddos-attack-trends/   Rightsize to maximize your cloud investment with Microsoft Azure https://azure.microsoft.com/en-us/blog/rightsize-to-maximize-your-cloud-investment-with-microsoft-azure/   7 reasons to attend Azure Open Source Day https://azure.microsoft.com/en-us/blog/7-reasons-to-attend-azure-open-source-day/     Generally available: Kibana dashboards and visualizations on top of Azure Data Explorer | Azure updates | Microsoft Azure     Public preview: Support for managed identity in Azure Cache for Redis | Azure updates | Microsoft Azure

About ThomasThomas Hazel is Founder, CTO, and Chief Scientist of ChaosSearch. He is a serial entrepreneur at the forefront of communication, virtualization, and database technology and the inventor of ChaosSearch's patented IP. Thomas has also patented several other technologies in the areas of distributed algorithms, virtualization and database science. He holds a Bachelor of Science in Computer Science from University of New Hampshire, Hall of Fame Alumni Inductee, and founded both student & professional chapters of the Association for Computing Machinery (ACM).Links:ChaosSearch: https://www.chaossearch.io TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by my friends at ThinkstCanary. Most companies find out way too late that they've been breached. ThinksCanary changes this and I love how they do it. Deploy canaries and canary tokens in minutes and then forget about them. What's great is the attackers tip their hand by touching them, giving you one alert, when it matters. I use it myself and I only remember this when I get the weekly update with a “we're still here, so you're aware” from them. It's glorious! There is zero admin overhead  to this, there are effectively no false positives unless I do something foolish. Canaries are deployed and loved on all seven continents. You can check out what people are saying at canary.love. And, their Kub config canary token is new and completely free as well. You can do an awful lot without paying them a dime, which is one of the things I love about them. It is useful stuff and not an, “ohh, I wish I had money.” It is speculator! Take a look; that's canary.love because it's genuinely rare to find a security product that people talk about in terms of love. It really is a unique thing to see. Canary.love. Thank you to ThinkstCanary for their support of my ridiculous, ridiculous non-sense.   Corey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is brought to us by our friends at ChaosSearch.We've been working with them for a long time; they've sponsored a bunch of our nonsense, and it turns out that we've been talking about them to our clients since long before they were a sponsor because it actually does what it says on the tin. Here to talk to us about that in a few minutes is Thomas Hazel, ChaosSearch's CTO and founder. First, Thomas, nice to talk to you again, and as always, thanks for humoring me.Thomas: [laugh]. Hi, Corey. Always great to talk to you. And I enjoy these conversations that sometimes go up and down, left and right, but I look forward to all the fun we're going to have.Corey: So, my understanding of ChaosSearch is probably a few years old because it turns out, I don't spend a whole lot of time meticulously studying your company's roadmap in the same way that you presumably do. When last we checked in with what the service did-slash-does, you are effectively solving the problem of data movement and querying that data. The idea behind data warehouses is generally something that's shoved onto us by cloud providers where, “Hey, this data is going to be valuable to you someday.” Data science teams are big proponents of this because when you're storing that much data, their salaries look relatively reasonable by comparison. And the ChaosSearch vision was, instead of copying all this data out of an object store and storing it on expensive disks, and replicating it, et cetera, what if we queried it in place in a somewhat intelligent manner?So, you take the data and you store it, in this case, in S3 or equivalent, and then just query it there, rather than having to move it around all over the place, which of course, then incurs data transfer fees, you're storing it multiple times, and it's never in quite the format that you want it. That was the breakthrough revelation, you were Elasticsearch—now OpenSearch—API compatible, which was great. And that was, sort of, a state of the art a year or two ago. Is that generally correct?Thomas: No, you nailed our mission statement. No, you're exactly right. You know, the value of cloud object stores, S3, the elasticity, the durability, all these wonderful things, the problem was you couldn't get any value out of it, and you had to move it out to these siloed solutions, as you indicated. So, you know, our mission was exactly that, transformed customers' cloud storage into an analytical database, a multi-model analytical database, where our first use case was search and log analytics, replacing the ELK stack and also replacing the data pipeline, the schema management, et cetera. We automate the entire step, raw data to insights.Corey: It's funny we're having this conversation today. Earlier, today, I was trying to get rid of a relatively paltry 200 gigs or so of small files on an EFS volume—you know, Amazon's version of NFS; it's like an NFS volume except you're paying Amazon for the privilege—great. And it turns out that it's a whole bunch of operations across a network on a whole bunch of tiny files, so I had to spin up other instances that were not getting backed by spot terminations, and just firing up a whole bunch of threads. So, now the load average on that box is approaching 300, but it's plowing through, getting rid of that data finally.And I'm looking at this saying this is a quarter of a terabyte. Data warehouses are in the petabyte range. Oh, I begin to see aspects of the problem. Even searching that kind of data using traditional tooling starts to break down, which is sort of the revelation that Google had 20-some-odd years ago, and other folks have since solved for, but this is the first time I've had significant data that wasn't just easily searched with a grep. For those of you in the Unix world who understand what that means, condolences. We're having a support group meeting at the bar.Thomas: Yeah. And you know, I always thought, what if you could make cloud object storage like S3 high performance and really transform it into a database? And so that warehouse capability, that's great. We like that. However to manage it, to scale it, to configure it, to get the data into that, was the problem.That was the promise of a data lake, right? This simple in, and then this arbitrary schema on read generic out. The problem next came, it became swampy, it was really hard, and that promise was not delivered. And so what we're trying to do is get all the benefits of the data lake: simple in, so many services naturally stream to cloud storage. Shoot, I would say every one of our customers are putting their data in cloud storage because their data pipeline to their warehousing solution or Elasticsearch may go down and they're worried they'll lose the data.So, what we say is what if you just said activate that data lake and get that ELK use case, get that BI use case without that data movement, as you indicated, without that ETL-ing, without that data pipeline that you're worried is going to fall over. So, that vision has been Chaos. Now, we haven't talked in, you know, a few years, but this idea that we're growing beyond what we are just going after logs, we're going into new use cases, new opportunities, and I'm looking forward to discussing with you.Corey: It's a great answer that—though I have to call out that I am right there with you as far as inappropriately using things as databases. I know that someone is going to come back and say, “Oh, S3 is a database. You're dancing around it. Isn't that what Athena is?” Which is named, of course, after the Greek Goddess of spending money on AWS? And that is a fair question, but to my understanding, there's a schema story behind that does not apply to what you're doing.Thomas: Yeah, and that is so crucial is that we like the relational access. The time-cost complexity to get it into that, as you mentioned, scaled access, I mean, it could take weeks, months to test it, to configure it, to provision it, and imagine if you got it wrong; you got to redo it again. And so our unique service removes all that data pipeline schema management. And because of our innovation because of our service, you do all schema definition, on the fly, virtually, what we call views on your index data, that you can publish an elastic index pattern for that consumption, or a relational table for that consumption. And that's kind of leading the witness into things that we're coming out with this quarter into 2022.Corey: I have to deal with a little bit of, I guess, a shame here because yeah, I'm doing exactly what you just described. I'm using Athena to wind up querying our customers' Cost and Usage Reports, and we spend a couple hundred bucks a month on AWS Glue to wind up massaging those into the way that they expect it to be. And it's great. Ish. We hook it up to Tableau and can make those queries from it, and all right, it's great.It just, burrr goes the money printer, and we somehow get access and insight to a lot of valuable data. But even that is knowing exactly what the format is going to look like. Ish. I mean, Cost and Usage Reports from Amazon are sort of aspirational when it comes to schema sometimes, but here we are. And that's been all well and good.But now the idea of log files, even looking at the base case of sending logs from an application, great. Nginx, or Apache, or [unintelligible 00:07:24], or any of the various web servers out there all tend to use different logging formats just to describe the same exact things, start spreading that across custom in-house applications and getting signal from that is almost impossible. “Oh,” people say, “So, we'll use a structured data format.” Now, you're putting log and structuring requirements on application developers who don't care in the first place, and now you have a mess on your hands.Thomas: And it really is a mess. And that challenge is, it's so problematic. And schemas changing. You know, we have customers and one reasons why they go with us is their log data is changing; they didn't expect it. Well, in your data pipeline, and your Athena database, that breaks. That brings the system down.And so our system uniquely detects that and manages that for you and then you can pick and choose how you want to export in these views dynamically. So, you know, it's really not rocket science, but the problem is, a lot of the technology that we're using is designed for static, fixed thinking. And then to scale it is problematic and time-consuming. So, you know, Glue is a great idea, but it has a lot of sharp [pebbles 00:08:26]. Athena is a great idea but also has a lot of problems.And so that data pipeline, you know, it's not for digitally native, active, new use cases, new workloads coming up hourly, daily. You think about this long-term; so a lot of that data prep pipelining is something we address so uniquely, but really where the customer cares is the value of that data, right? And so if you're spending toils trying to get the data into a database, you're not answering the questions, whether it's for security, for performance, for your business needs. That's the problem. And you know, that agility, that time-to-value is where we're very uniquely coming in because we start where your data is raw and we automate the process all the way through.Corey: So, when I look at the things that I have stuffed into S3, they generally fall into a couple of categories. There are a bunch of logs for things I never asked for nor particularly wanted, but AWS is aggressive about that, first routing through CloudTrail so you can get charged 50-cent per gigabyte ingested. Awesome. And of course, large static assets, images I have done something to enter colloquially now known as shitposts, which is great. Other than logs, what could you possibly be storing in S3 that lends itself to, effectively, the type of analysis that you built around this?Thomas: Well, our first use case was the classic log use cases, app logs, web service logs. I mean, CloudTrail, it's famous; we had customers that gave up on elastic, and definitely gave up on relational where you can do a couple changes and your permutation of attributes for CloudTrail is going to put you to your knees. And people just say, “I give up.” Same thing with Kubernetes logs. And so it's the classic—whether it's CSV, where it's JSON, where it's log types, we auto-discover all that.We also allow you, if you want to override that and change the parsing capabilities through a UI wizard, we do discover what's in your buckets. That term data swamp, and not knowing what's in your bucket, we do a facility that will index that data, actually create a report for you for knowing what's in. Now, if you have text data, if you have log data, if you have BI data, we can bring it all together, but the real pain is at the scale. So classically, app logs, system logs, many devices sending IoT-type streams is where we really come in—Kubernetes—where they're dealing with terabytes of data per day, and managing an ELK cluster at that scale. Particularly on a Black Friday.Shoot, some of our customers like—Klarna is one of them; credit card payment—they're ramping up for Black Friday, and one of the reasons why they chose us is our ability to scale when maybe you're doing a terabyte or two a day and then it goes up to twenty, twenty-five. How do you test that scale? How do you manage that scale? And so for us, the data streams are, traditionally with our customers, the well-known log types, at least in the log use cases. And the challenge is scaling it, is getting access to it, and that's where we come in.Corey: I will say the last time you were on the show a couple of years ago, you were talking about the initial logging use case and you were speaking, in many cases aspirationally, about where things were going. What a difference a couple years is made. Instead of talking about what hypothetical customers might want, or what—might be able to do, you're just able to name-drop them off the top of your head, you have scaled to approximately ten times the number of employees you had back then. You've—Thomas: Yep. Yep.Corey: —raised, I think, a total of—what, 50 million?—since then.Thomas: Uh, 60 now. Yeah.Corey: Oh, 60? Fantastic.Thomas: Yeah, yeah.Corey: Congrats. And of course, how do you do it? By sponsoring Last Week in AWS, as everyone should. I'm taking clear credit for that every time someone announces around, that's the game. But no, there is validity to it because telling fun stories and sponsoring exciting things like this only carry you so far. At some point, customers have to say, yeah, this is solving a pain that I have; I'm willing to pay you money to solve it.And you've clearly gotten to a point where you are addressing the needs of those customers at a pretty fascinating clip. It's bittersweet from my perspective because it seems like the majority of your customers have not come from my nonsense anymore. They're finding you through word of mouth, they're finding through more traditional—read as boring—ad campaigns, et cetera, et cetera. But you've built a brand that extends beyond just me. I'm no longer viewed as the de facto ombudsperson for any issue someone might have with ChaosSearch on Twitters. It's kind of, “Aww, the company grew up. What happened there?”Thomas: No, [laugh] listen, this you were great. We reached out to you to tell our story, and I got to be honest. A lot of people came by, said, “I heard something on Corey Quinn's podcasts,” or et cetera. And it came a long way now. Now, we have, you know, companies like Equifax, multi-cloud—Amazon and Google.They love the data lake philosophy, the centralized, where use cases are now available within days, not weeks and months. Whether it's logs and BI. Correlating across all those data streams, it's huge. We mentioned Klarna, [APM Performance 00:13:19], and, you know, we have Armor for SIEM, and Blackboard for [Observers 00:13:24].So, it's funny—yeah, it's funny, when I first was talking to you, I was like, “What if? What if we had this customer, that customer?” And we were building the capabilities, but now that we have it, now that we have customers, yeah, I guess, maybe we've grown up a little bit. But hey, listen to you're always near and dear to our heart because we remember, you know, when you stop[ed by our booth at re:Invent several times. And we're coming to re:Invent this year, and I believe you are as well.Corey: Oh, yeah. But people listening to this, it's if they're listening the day it's released, this will be during re:Invent. So, by all means, come by the ChaosSearch booth, and see what they have to say. For once they have people who aren't me who are going to be telling stories about these things. And it's fun. Like, I joke, it's nothing but positive here.It's interesting from where I sit seeing the parallels here. For example, we have both had—how we say—adult supervision come in. You have a CEO, Ed, who came over from IBM Storage. I have Mike Julian, whose first love language is of course spreadsheets. And it's great, on some level, realizing that, wow, this company has eclipsed my ability to manage these things myself and put my hands-on everything. And eventually, you have to start letting go. It's a weird growth stage, and it's a heck of a transition. But—Thomas: No, I love it. You know, I mean, I think when we were talking, we were maybe 15 employees. Now, we're pushing 100. We brought on Ed Walsh, who's an amazing CEO. It's funny, I told him about this idea, I invented this technology roughly eight years ago, and he's like, “I love it. Let's do it.” And I wasn't ready to do it.So, you know, five, six years ago, I started the company always knowing that, you know, I'd give him a call once we got the plane up in the air. And it's been great to have him here because the next level up, right, of execution and growth and business development and sales and marketing. So, you're exactly right. I mean, we were a young pup several years ago, when we were talking to you and, you know, we're a little bit older, a little bit wiser. But no, it's great to have Ed here. And just the leadership in general; we've grown immensely.Corey: Now, we are recording this in advance of re:Invent, so there's always the question of, “Wow, are we going to look really silly based upon what is being announced when this airs?” Because it's very hard to predict some things that AWS does. And let's be clear, I always stay away from predictions, just because first, I have a bit of a knack for being right. But also, when I'm right, people will think, “Oh, Corey must have known about that and is leaking,” whereas if I get it wrong, I just look like a fool. There's no win for me if I start doing the predictive dance on stuff like that.But I have to level with you, I have been somewhat surprised that, at least as of this recording, AWS has not moved more in your direction because storing data in S3 is kind of their whole thing, and querying that data through something that isn't Athena has been a bit of a reach for them that they're slowly starting to wrap their heads around. But their UltraWarm nonsense—which is just, okay, great naming there—what is the point of continually having a model where oh, yeah, we're going to just age it out, the stuff that isn't actively being used into S3, rather than coming up with a way to query it there. Because you've done exactly that, and please don't take this as anything other than a statement of fact, they have better access to what S3 is doing than you do. You're forced to deal with this thing entirely from a public API standpoint, which is fine. They can theoretically change the behavior of aspects of S3 to unlock these use cases if they chose to do so. And they haven't. Why is it that you're the only folks that are doing this?Thomas: No, it's a great question, and I'll give them props for continuing to push the data lake [unintelligible 00:17:09] to the cloud providers' S3 because it was really where I saw the world. Lakes, I believe in. I love them. They love them. However, they promote the move the data out to get access, and it seems so counterintuitive on why wouldn't you leave it in and put these services, make them more intelligent? So, it's funny, I've trademark ‘Smart Object Storage,' I actually trademarked—I think you [laugh] were a part of this—‘UltraHot,' right? Because why would you want UltraWarm when you can have UltraHot?And the reason, I feel, is that if you're using Parquet for Athena [unintelligible 00:17:40] store, or Lucene for Elasticsearch, these two index technologies were not designed for cloud storage, for real-time streaming off of cloud storage. So, the trick is, you have to build UltraWarm, get it off of what they consider cold S3 into a more warmer memory or SSD type access. What we did, what the invention I created was, that first read is hot. That first read is fast.Snowflake is a good example. They give you a ten terabyte demo example, and if you have a big instance and you do that first query, maybe several orders or groups, it could take an hour to warm up. The second query is fast. Well, what if the first query is in seconds as well? And that's where we really spent the last five, six years building out the tech and the vision behind this because I like to say you go to a doctor and say, “Hey, Doc, every single time I move my arm, it hurts.” And the doctor says, “Well, don't move your arm.”It's things like that, to your point, it's like, why wouldn't they? I would argue, one, you have to believe it's possible—we're proving that it is—and two, you have to have the technology to do it. Not just the index, but the architecture. So, I believe they will go this direction. You know, little birdies always say that all these companies understand this need.Shoot, Snowflake is trying to be lake-y; Databricks is trying to really bring this warehouse lake concept. But you still do all the pipelining; you still have to do all the data management the way that you don't want to do. It's not a lake. And so my argument is that it's innovation on why. Now, they have money; they have time, but, you know, we have a big head start.Corey: I remembered last year at re:Invent they released a, shall we say, significant change to S3 that it enabled read after write consistency, which is awesome, for again, those of us in the business of misusing things as databases. But for some folks, the majority of folks I would say, it was a, “I don't know what that means and therefore I don't care.” And that's fine. I have no issue with that. There are other folks, some of my customers for example, who are suddenly, “Wait a minute. This means I can sunset this entire janky sidecar metadata system that is designed to make sure that we are consistent in our use of S3 because it now does it automatically under the hood?” And that's awesome. Does that change mean anything for ChaosSearch?Thomas: It doesn't because of our architecture. We're append-only, write-once scenario, so a lot of update-in-place viewpoints. My viewpoint is that if you're seeing S3 as the database and you need that type of consistency, it make sense of why you'd want it, but because of our distributive fabric, our stateless architecture, our append-only nature, it really doesn't affect us.Now, I talked to the S3 team, I said, “Please if you're coming up with this feature, it better not be slower.” I want S3 to be fast, right? And they said, “No, no. It won't affect performance.” I'm like, “Okay. Let's keep that up.”And so to us, any type of S3 capability, we'll take advantage of it if benefits us, whether it's consistency as you indicated, performance, functionality. But we really keep the constructs of S3 access to really limited features: list, put, get. [roll-on 00:20:49] policies to give us read-only access to your data, and a location to write our indices into your account, and then are distributed fabric, our service, acts as those indices and query them or searches them to resolve whatever analytics you need. So, we made it pretty simple, and that is allowed us to make it high performance.Corey: I'll take it a step further because you want to talk about changes since the last time we spoke, it used to be that this was on top of S3, you can store your data anywhere you want, as long as it's S3 in the customer's account. Now, you're also supporting one-click integration with Google Cloud's object storage, which, great. That does mean though, that you're not dependent upon provider-specific implementations of things like a consistency model for how you've built things. It really does use the lowest common denominator—to my understanding—of object stores. Is that something that you're seeing broad adoption of, or is this one of those areas where, well, you have one customer on a different provider, but almost everything lives on the primary? I'm curious what you're seeing for adoption models across multiple providers?Thomas: It's a great question. We built an architecture purposely to be cloud-agnostic. I mean, we use compute in a containerized way, we use object storage in a very simple construct—put, get, list—and we went over to Google because that made sense, right? We have customers on both sides. I would say Amazon is the gorilla, but Google's trying to get there and growing.We had a big customer, Equifax, that's on both Amazon and Google, but we offer the same service. To be frank, it looks like the exact same product. And it should, right? Whether it's Amazon Cloud, or Google Cloud, multi-select and I want to choose either one and get the other one. I would say that different business types are using each one, but our bulk of the business isn't Amazon, but we just this summer released our SaaS offerings, so it's growing.And you know, it's funny, you never know where it comes from. So, we have one customer—actually DigitalRiver—as one of our customers on Amazon for logs, but we're growing in working together to do a BI on GCP or on Google. And so it's kind of funny; they have two departments on two different clouds with two different use cases. And so do they want unification? I'm not sure, but they definitely have their BI on Google and their operations in Amazon. It's interesting.Corey: You know its important to me that people learn how to use the cloud effectively. Thats why I'm so glad that Cloud Academy is sponsoring my ridiculous non-sense. They're a great way to build in demand tech skills the way that, well personally, I learn best which I learn by doing not by reading. They have live cloud labs that you can run in real environments that aren't going to blow up your own bill—I can't stress how important that is. Visit cloudacademy.com/corey. Thats C-O-R-E-Y, don't drop the “E.” Use Corey as a promo-code as well. You're going to get a bunch of discounts on it with a lifetime deal—the price will not go up. It is limited time, they assured me this is not one of those things that is going to wind up being a rug pull scenario, oh no no. Talk to them, tell me what you think. Visit: cloudacademy.com/corey,  C-O-R-E-Y and tell them that I sent you!Corey: I know that I'm going to get letters for this. So, let me just call it out right now. Because I've been a big advocate of pick a provider—I care not which one—and go all-in on it. And I'm sitting here congratulating you on extending to another provider, and people are going to say, “Ah, you're being inconsistent.”No. I'm suggesting that you as a provider have to meet your customers where they are because if someone is sitting in GCP and your entire approach is, “Step one, migrate those four petabytes of data right on over here to AWS,” they're going to call you that jackhole that you would be by making that suggestion and go immediately for option B, which is literally anything that is not ChaosSearch, just based upon that core misunderstanding of their business constraints. That is the way to think about these things. For a vendor position that you are in as an ISV—Independent Software Vendor for those not up on the lingo of this ridiculous industry—you have to meet customers where they are. And it's the right move.Thomas: Well, you just said it. Imagine moving terabytes and petabytes of data.Corey: It sounds terrific if I'm a salesperson for one of these companies working on commission, but for the rest of us, it sounds awful.Thomas: We really are a data fabric across clouds, within clouds. We're going to go where the data is and we're going to provide access to where that data lives. Our whole philosophy is the no-movement movement, right? Don't move your data. Leave it where it is and provide access at scale.And so you may have services in Google that naturally stream to GCS; let's do it there. Imagine moving that amount of data over to Amazon to analyze it, and vice versa. 2020, we're going to be in Azure. They're a totally different type of business, users, and personas, but you're getting asked, “Can you support Azure?” And the answer is, “Yes,” and, “We will in 2022.”So, to us, if you have cloud storage, if you have compute, and it's a big enough business opportunity in the market, we're there. We're going there. When we first started, we were talking to MinIO—remember that open-source, object storage platform?—We've run on our laptops, we run—this [unintelligible 00:25:04] Dr. Seuss thing—“We run over here; we run over there; we run everywhere.”But the honest truth is, you're going to go with the big cloud providers where the business opportunity is, and offer the same solution because the same solution is valued everywhere: simple in; value out; cost-effective; long retention; flexibility. That sounds so basic, but you mentioned this all the time with our Rube Goldberg, Amazon diagrams we see time and time again. It's like, if you looked at that and you were from an alien planet, you'd be like, “These people don't know what they're doing. Why is it so complicated?” And the simple answer is, I don't know why people think it's complicated.To your point about Amazon, why won't they do it? I don't know, but if they did, things would be different. And being honest, I think people are catching on. We do talk to Amazon and others. They see the need, but they also have to build it; they have to invent technology to address it. And using Parquet and Lucene are not the answer.Corey: Yeah, it's too much of a demand on the producers of that data rather than the consumer. And yeah, I would love to be able to go upstream to application developers and demand they do things in certain ways. It turns out as a consultant, you have zero authority to do that. As a DevOps team member, you have limited ability to influence it, but it turns out that being the ‘department of no' quickly turns into being the ‘department of unemployment insurance' because no one wants to work with you. And collaboration—contrary to what people wish to believe—is a key part of working in a modern workplace.Thomas: Absolutely. And it's funny, the demands of IT are getting harder; the actual getting the employees to build out the solutions are getting harder. And so a lot of that time is in the pipeline, is the prep, is the schema, the sharding, and et cetera, et cetera, et cetera. My viewpoint is that should be automated away. More and more databases are being autotune, right?This whole knobs and this and that, to me, Glue is a means to an end. I mean, let's get rid of it. Why can't Athena know what to do? Why can't object storage be Athena and vice versa? I mean, to me, it seems like all this moving through all these services, the classic Amazon viewpoint, even their diagrams of having this centralized repository of S3, move it all out to your services, get results, put it back in, then take it back out again, move it around, it just doesn't make much sense. And so to us, I love S3, love the service. I think it's brilliant—Amazon's first service, right?—but from there get a little smarter. That's where ChaosSearch comes in.Corey: I would argue that S3 is in fact, a modern miracle. And one of those companies saying, “Oh, we have an object store; it's S3 compatible.” It's like, “Yeah. We have S3 at home.” Look at S3 at home, and it's just basically a series of failing Raspberry Pis.But you have this whole ecosystem of things that have built up and sprung up around S3. It is wildly understated just how scalable and massive it is. There was an academic paper recently that won an award on how they use automated reasoning to validate what is going on in the S3 environment, and they talked about hundreds of petabytes in some cases. And folks are saying, ah, S3 is hundreds of petabytes. Yeah, I have clients storing hundreds of petabytes.There are larger companies out there. Steve Schmidt, Amazon's CISO, was recently at a Splunk keynote where he mentioned that in security info alone, AWS itself generates 500 petabytes a day that then gets reduced down to a bunch of stuff, and some of it gets loaded into Splunk. I think. I couldn't really hear the second half of that sentence because of the sound of all of the Splunk salespeople in that room becoming excited so quickly you could hear it.Thomas: [laugh]. I love it. If I could be so bold, those S3 team, they're gods. They are amazing. They created such an amazing service, and when I started playing with S3 now, I guess, 2006 or 7, I mean, we were using for a repository, URL access to get images, I was doing a virtualization [unintelligible 00:29:05] at the time—Corey: Oh, the first time I played with it, “This seems ridiculous and kind of dumb. Why would anyone use this?” Yeah, yeah. It turns out I'm really bad at predicting the future. Another reason I don't do the prediction thing.Thomas: Yeah. And when I started this company officially, five, six years ago, I was thinking about S3 and I was thinking about HDFS not being a good answer. And I said, “I think S3 will actually achieve the goals and performance we need.” It's a distributed file system. You can run parallel puts and parallel gets. And the performance that I was seeing when the data was a certain way, certain size, “Wait, you can get high performance.”And you know, when I first turned on the engine, now four or five years ago, I was like, “Wow. This is going to work. We're off to the races.” And now obviously, we're more than just an idea when we first talked to you. We're a service.We deliver benefits to our customers both in logs. And shoot, this quarter alone we're coming out with new features not just in the logs, which I'll talk about second, but in a direct SQL access. But you know, one thing that you hear time and time again, we talked about it—JSON, CloudTrail, and Kubernetes; this is a real nightmare, and so one thing that we've come out with this quarter is the ability to virtually flatten. Now, you heard time and time again, where, “Okay. I'm going to pick and choose my data because my database can't handle whether it's elastic, or say, relational.” And all of a sudden, “Shoot, I don't have that. I got to reindex that.”And so what we've done is we've created a index technology that we're always planning to come out with that indexes the JSON raw blob, but in the data refinery have, post-index you can select how to unflatten it. Why is that important? Because all that tooling, whether it's elastic or SQL, is now available. You don't have to change anything. Why is Snowflake and BigQuery has these proprietary JSON APIs that none of these tools know how to use to get access to the data?Or you pick and choose. And so when you have a CloudTrail, and you need to know what's going on, if you picked wrong, you're in trouble. So, this new feature we're calling ‘Virtual Flattening'—or I don't know what we're—we have to work with the marketing team on it. And we're also bringing—this is where I get kind of excited where the elastic world, the ELK world, we're bringing correlations into Elasticsearch. And like, how do you do that? They don't have the APIs?Well, our data refinery, again, has the ability to correlate index patterns into one view. A view is an index pattern, so all those same constructs that you had in Kibana, or Grafana, or Elastic API still work. And so, no more denormalizing, no more trying to hodgepodge query over here, query over there. You're actually going to have correlations in Elastic, natively. And we're excited about that.And one more push on the future, Q4 into 2022; we have been given early access to S3 SQL access. And, you know, as I mentioned, correlations in Elastic, but we're going full in on publishing our [TPCH 00:31:56] report, we're excited about publishing those numbers, as well as not just giving early access, but going GA in the first of the year, next year.Corey: I look forward to it. This is also, I guess, it's impossible to have a conversation with you, even now, where you're not still forward-looking about what comes next. Which is natural; that is how we get excited about the things that we're building. But so much less of what you're doing now in our conversations have focused around what's coming, as opposed to the neat stuff you're already doing. I had to double-check when we were talking just now about oh, yeah, is that Google cloud object store support still something that is roadmapped, or is that out in the real world?No, it's very much here in the real world, available today. You can use it. Go click the button, have fun. It's neat to see at least some evidence that not all roadmaps are wishes and pixie dust. The things that you were talking to me about years ago are established parts of ChaosSearch now. It hasn't been just, sort of, frozen in amber for years, or months, or these giant periods of time. Because, again, there's—yeah, don't sell me vaporware; I know how this works. The things you have promised have come to fruition. It's nice to see that.Thomas: No, I appreciate it. We talked a little while ago, now a few years ago, and it was a bit of aspirational, right? We had a lot to do, we had more to do. But now when we have big customers using our product, solving their problems, whether it's security, performance, operation, again—at scale, right? The real pain is, sure you have a small ELK cluster or small Athena use case, but when you're dealing with terabytes to petabytes, trillions of rows, right—billions—when you were dealing trillions, billions are now small. Millions don't even exist, right?And you're graduating from computer science in college and you say the word, “Trillion,” they're like, “Nah. No one does that.” And like you were saying, people do petabytes and exabytes. That's the world we're living in, and that's something that we really went hard at because these are challenging data problems and this is where we feel we uniquely sit. And again, we don't have to break the bank while doing it.Corey: Oh, yeah. Or at least as of this recording, there's a meme going around, again, from an old internal Google Video, of, “I just want to serve five terabytes of traffic,” and it's an internal Google discussion of, “I don't know how to count that low.” And, yeah.Thomas: [laugh].Corey: But there's also value in being able to address things at much larger volume. I would love to see better responsiveness options around things like Deep Archive because the idea of being able to query that—even if you can wait a day or two—becomes really interesting just from the perspective of, at that point, current cost for one petabyte of data in Glacier Deep Archive is 1000 bucks a month. That is ‘why would I ever delete data again?' Pricing.Thomas: Yeah. You said it. And what's interesting about our technology is unlike, let's say Lucene, when you index it, it could be 3, 4, or 5x the raw size, our representation is smaller than gzip. So, it is a full representation, so why don't you store it efficiently long-term in S3? Oh, by the way, with the Glacier; we support Glacier too.And so, I mean, it's amazing the cost of data with cloud storage is dramatic, and if you can make it hot and activated, that's the real promise of a data lake. And, you know, it's funny, we use our own service to run our SaaS—we log our own data, we monitor, we alert, have dashboards—and I can't tell you how cheap our service is to ourselves, right? Because it's so cost-effective for long-tail, not just, oh, a few weeks; we store a whole year's worth of our operational data so we can go back in time to debug something or figure something out. And a lot of that's savings. Actually, huge savings is cloud storage with a distributed elastic compute fabric that is serverless. These are things that seem so obvious now, but if you have SSDs, and you're moving things around, you know, a team of IT professionals trying to manage it, it's not cheap.Corey: Oh, yeah, that's the story. It's like, “Step one, start paying for using things in cloud.” “Okay, great. When do I stop paying?” “That's the neat part. You don't.” And it continues to grow and build.And again, this is the thing I learned running a business that focuses on this, the people working on this, in almost every case, are more expensive than the infrastructure they're working on. And that's fine. I'd rather pay people than technologies. And it does help reaffirm, on some level, that—people don't like this reminder—but you have to generate more value than you cost. So, when you're sitting there spending all your time trying to avoid saving money on, “Oh, I've listened to ChaosSearch talk about what they do a few times. I can probably build my own and roll it at home.”It's, I've seen the kind of work that you folks have put into this—again, you have something like 100 employees now; it is not just you building this—my belief has always been that if you can buy something that gets you 90, 95% of where you are, great. Buy it, and then yell at whoever selling it to you for the rest of it, and that'll get you a lot further than, “We're going to do this ourselves from first principles.” Which is great for a weekend project for just something that you have a passion for, but in production mistakes show. I've always been a big proponent of buying wherever you can. It's cheaper, which sounds weird, but it's true.Thomas: And we do the same thing. We have single-sign-on support; we didn't build that ourselves, we use a service now. Auth0 is one of our providers now that owns that [crosstalk 00:37:12]—Corey: Oh, you didn't roll your own authentication layer? Why ever not? Next, you're going to tell me that you didn't roll your own payment gateway when you wound up charging people on your website to sign up?Thomas: You got it. And so, I mean, do what you do well. Focus on what you do well. If you're repeating what everyone seems to do over and over again, time, costs, complexity, and… service, it makes sense. You know, I'm not trying to build storage; I'm using storage. I'm using a great, wonderful service, cloud object storage.Use whats works, whats works well, and do what you do well. And what we do well is make cloud object storage analytical and fast. So, call us up and we'll take away that 2 a.m. call you have when your cluster falls down, or you have a new workload that you are going to go to the—I don't know, the beach house, and now the weekend shot, right? Spin it up, stream it in. We'll take over.Corey: Yeah. So, if you're listening to this and you happen to be at re:Invent, which is sort of an open question: why would you be at re:Invent while listening to a podcast? And then I remember how long the shuttle lines are likely to be, and yeah. So, if you're at re:Invent, make it on down to the show floor, visit the ChaosSearch booth, tell them I sent you, watch for the wince, that's always worth doing. Thomas, if people have better decision-making capability than the two of us do, where can they find you if they're not in Las Vegas this week?Thomas: So, you find us online chaossearch.io. We have so much material, videos, use cases, testimonials. You can reach out to us, get a free trial. We have a self-service experience where connect to your S3 bucket and you're up and running within five minutes.So, definitely chaossearch.io. Reach out if you want a hand-held, white-glove experience POV. If you have those type of needs, we can do that with you as well. But we booth on re:Invent and I don't know the booth number, but I'm sure either we've assigned it or we'll find it out.Corey: Don't worry. This year, it is a low enough attendance rate that I'm projecting that you will not be as hard to find in recent years. For example, there's only one expo hall this year. What a concept. If only it hadn't taken a deadly pandemic to get us here.Thomas: Yeah. But you know, we'll have the ability to demonstrate Chaos at the booth, and really, within a few minutes, you'll say, “Wow. How come I never heard of doing it this way?” Because it just makes so much sense on why you do it this way versus the merry-go-round of data movement, and transformation, and schema management, let alone all the sharding that I know is a nightmare, more often than not.Corey: And we'll, of course, put links to that in the [show notes 00:39:40]. Thomas, thank you so much for taking the time to speak with me today. As always, it's appreciated.Thomas: Corey, thank you. Let's do this again.Corey: We absolutely will. Thomas Hazel, CTO and Founder of ChaosSearch. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast episode, please leave a five-star review on your podcast platform of choice, whereas if you've hated this episode, please leave a five-star review on your podcast platform of choice along with an angry comment because I have dared to besmirch the honor of your homebrewed object store, running on top of some trusty and reliable Raspberries Pie.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

About JordanJordan is a self proclaimed “hacker.” Links:Twitter: https://twitter.com/jordansissel TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by “you”—gabyte. Distributed technologies like Kubernetes are great, citation very much needed, because they make it easier to have resilient, scalable, systems. SQL databases haven't kept pace though, certainly not like no SQL databases have like Route 53, the world's greatest database. We're still, other than that, using legacy monolithic databases that require ever growing instances of compute. Sometimes we'll try and bolt them together to make them more resilient and scalable, but let's be honest it never works out well. Consider Yugabyte DB, its a distributed SQL database that solves basically all of this. It is 100% open source, and there's not asterisk next to the “open” on that one. And its designed to be resilient and scalable out of the box so you don't have to charge yourself to death. It's compatible with PostgreSQL, or “postgresqueal” as I insist on pronouncing it, so you can use it right away without having to learn a new language and refactor everything. And you can distribute it wherever your applications take you, from across availability zones to other regions or even other cloud providers should one of those happen to exist. Go to yugabyte.com, thats Y-U-G-A-B-Y-T-E dot com and try their free beta of Yugabyte Cloud, where they host and manage it for you. Or see what the open source project looks like—its effortless distributed SQL for global apps. My thanks to Yu—gabyte for sponsoring this episode.Corey: This episode is sponsored in part by our friends at VMware. Let's be honest—the past year has been far from easy. Due to, well, everything. It caused us to rush cloud migrations and digital transformation, which of course means long hours refactoring your apps, surprises on your cloud bill, misconfigurations and headache for everyone trying manage disparate and fractured cloud environments. VMware has an answer for this. With VMware multi-cloud solutions, organizations have the choice, speed, and control to migrate and optimize applications seamlessly without recoding, take the fastest path to modern infrastructure, and operate consistently across the data center, the edge, and any cloud. I urge to take a look at vmware.com/go/multicloud. You know my opinions on multi cloud by now, but there's a lot of stuff in here that works on any cloud. But don't take it from me thats: VMware.com/go/multicloud and my thanks to them again for sponsoring my ridiculous nonsense.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I've been to a lot of conference talks in my life. I've seen good ones, I've seen terrible ones, and then I've seen the ones that are way worse than that. But we don't tend to think in terms of impact very often, about how conference talks can move the audience.In fact, that's the only purpose of giving a talk ever—to my mind—is you're trying to spark some form of alchemy or shift in the audience and convince them to do something. Maybe in the banal sense, it's to sign up for something that you're selling, or to go look at your website, or to contribute to a project, or maybe it's to change the way they view things. One of the more transformative talks I've ever seen that shifted my outlook on a lot of things was at [SCALE 00:01:11] in 2012. Person who gave that talk is my guest today, Jordan Sissel, who, among many other things in his career, was the original creator behind logstash, which is the L in ELK Stack. Jordan, thank you for joining me.Jordan: Thanks for having me, Corey.Corey: I don't know how well you remember those days in 2012. It was the dark times; we thought oh, the world is going to end; that wouldn't happen until 2020. But it was an interesting conference full of a bunch of open-source folks, it was my local conference because I lived in Los Angeles. And it was the thing I looked forward to every year because I would always go and learn something new. I was in the trenches in those days, and I had a bunch of problems that looked an awful lot like other people's problems, and having a hallway track where, “Hey, how are you solving this problem?” Was a big deal. I missed those days in some ways.Jordan: Yeah, SCALE was a particularly good conference. I think I made it twice. Traveling down to LA was infrequent for me, but I always enjoyed how it was a very communal setting. They had dedicated hallway tracks. They had kids tracks, which I thought was great because folks couldn't usually come to conferences if they couldn't bring their kids or they had to take care of that stuff. But having a kids track was great, they had kids presenting. It felt more organic than a lot of other conferences did, and that's kind of what drew me to it initially.Corey: Yeah, it was my local network. It turns out that the Southern California tech community is relatively small, and we all go different lives. And it's LA, let's face it, I lived there for over a decade. Flaking as a way of life. So yeah, well, “Oh, we'll go out and catch dinner. Ooh, have to flake at the last minute.” If you're one of the good people, you tell people you're flaking instead of just no-showing, but it happens.But this was the thing that we would gather and catch up every year. And, “Oh, what have you been doing?” “Wow, you work in that company now? Congratulations, slash, what's wrong with you?” It was fun, just sort of a central sync point. It started off as hanging out with friends.And in those days, I was approaching the idea of, “You know what? I should learn to give a conference talk someday. But let's be clear. People don't give conference talks; legends give conference talks. And one day, I'll be good enough to get on stage and give a talk to my peers at a conference.”Now, the easy, cynical interpretation would be, “Well, but I saw your talk and I figured, hey, any jackhole can get up there. If he can do it, anyone can.” But that's not at all how it wound up impacting me. You were talking about logstash, which let's start there because that's a good entry point. Logstash was transformative for me.Before that, I'd spent a lot of time playing around with syslog, usually rsyslog, but there are other stories here of when a system does something and it spits out logs—ideally—how do you make sure you capture those logs in a reliable way so if you restart a computer, you don't wind up with a gap in your logs? If it's the right computer, it could be a gap in everything's logs while that thing is coming back up. And let's avoid single points of failure and the rest. And I had done all kinds of horrible monstrosities, and someone asked me at one point—Jordan: [laugh]. Guilty.Corey: Yeah. Someone said, “Well, there are a couple of options. Why don't you use Splunk?” And the answer is that I don't have a spare princess lying around that I can ransom back to her kingdom, so I can't afford it. “Okay, what about logstash?” And my answer was, “What's a logstash?” And thus that sound was Pandora's Box creaking open.So, I started playing with it and realized, “Okay, this is interesting.” And I lost track of it because we have demands on our time. Then I was dragged into a session that you gave and you explained what logstash was. I'm not going to do nearly as good of a job as you can on this. What the hell was logstash, for folks who are not screaming at syslog while they first hear of it.Jordan: All right. So, you mentioned rsyslog, and there's—old is often a pejorative of more established projects because I don't think these projects are bad. But rsyslog, syslog-ng, things like that were common to see for me as a sysadmin. But to talk about logstash, we need to go back a little further than 2012. So, the logstash project started—Corey: I disagree because I wasn't aware of it until 2012. Until I become aware of something it doesn't really exist. That's right, I have the object permanence of an infant.Jordan: [laugh].That's fair. And I've always felt like perception is reality, so if someone—this gets into something I like to say, but if someone is having a bad time or someone doesn't know about something, then it might as well not exist. So, logstash as a project started in 2008, 2009. I don't remember when the first commits landed, but it was, gosh, it's more than ten years ago now.But even before that in college, I was fortunate to, through a network of friends, get a job as a sysadmin. And as a sysadmin, you stare at logs a lot to figure out what's going on. And I wanted a more interesting way to process the logs. I had taught myself regular expressions and it wasn't finding joy in it… at all, like pretty much most people, probably. Either they look at regular expressions and just… evacuate with disgust, which is absolutely an appropriate response, or they dive into it and they have to use it for their job.But it wasn't enjoyable, and I found myself repeating stuff a lot. Matching IP addresses, matching strings, URLs, just trying to pull out useful information about what is going on?Corey: Oh, and the timestamp problem, too. One of the things that I think people don't understand who have not played in this space, is that all systems do have logs unless you've really pooched something somewhere—Jordan: Yeah.Corey: —and it shows that at this point in time, this thing happened. As we start talking about multiple computers and distributed systems—but even on the same computer—great, so at this time there was something that showed up in the system log because there was a disk event or something, and at the same time you have application logs that are talking about what the application running is talking about. And that is ideally using a somewhat similar system to do this, but often not. And the way that timestamps are expressed in these are radically different and the way that the log files themselves are structured. One might be timestamp followed by hostname followed by error code.The other one might be hostname followed by a timestamp—in a different format—followed by a copyright notice because a big company got to it followed by the actual event notice, and trying to disambiguate all of these into a standardized form was first obnoxious, and secondly, very important because you want to see the exact chain of events. This also leads to a separate sidebar on making sure that all the clocks are synchronized, but that's a separate story for another time. And that's where you enter the story in many respects.Jordan: Right. So, my thought around what led to logstash is you can take a sysadmin or software IT developer—whatever—expert, and you can sit them in front of a bunch of logs and they can read them and say, “That's the time it happened. That's the user who caused this action. This is the action.” But if you try and abstract and step away, and so you ask how many times did this action happen? When did this user appear? What time did this happen?You start losing the ability to ask those questions without being an expert yourself, or sitting next to an expert and having them be your keyboard. Kind of a phenomenon I call the human keyboard problem where you're speaking to a computer, but someone has to translate for you. And so in around 2004, I was super into Perl. No shocker that I enjoyed—ish. I sort of enjoyed regular expressions, but I was super into Perl, and there was a Perl module called Regexp::Common which is a library of regular expressions to match known things: IP addresses, certain kinds of timestamps, quoted strings, and whatnot.Corey: And this stuff is always challenging because it sounds like oh, an IP address. One of the interview questions I hated the most someone asked me was write a regular expression to detect an IP address. It turns out that to do this correctly, even if you bound it to ipv4 only, the answer takes up multiple lines on a screen.Jordan: Oh, for sure.Corey: It's enormous.Jordan: It's like a full page of—Corey: It is.Jordan: —of code you can't read. And that's one of the things that, it was sort of like standing on the shoulders of the person who came before; it was kind of an epiphany to me.Corey: Yeah. So, I can copy and paste that into my code, but someone who has to maintain that thing after I get fired is going to be, “What the hell is this and what does it do?” It's like it's the blessed artifact that the ancients built it and left it there like it's a Stargate sitting in your code. And it's, “We don't know how it works; we're scared to break it, so we don't even look at that thing directly. We just know that we put nonsense in, an IP address comes out, and let's not touch it, ever again.”Jordan: Exactly. And even to your example, even before you get fired and someone replaces you and looks at your regular expression, the problem I was having was, I would have this library of copy and pasteable things, and then I would find a bug, and edge case. And I would fix that edge case but the other 15 scripts that were using the same way regular expression, I can't even read them anymore because I don't carry that kind of context in my head for all of that syntax. So, you either have to go back and copy and paste and fix all those old regular expressions. Or you just say, “You know what? We're not going to fix the old code. We have a new version of it that works here, but everywhere else this edge case fails.”So, that's one of the things that drew me to the Regexp::Common library in Perl was that it was reusable and things had names. It was, “I want to match an IP address.” You didn't have to memorize that long piece of text to precisely and accurately accept only regular expressions and rejects things that are not. You just said, “Give me the regular expression that matches an IP.” And from that library gave me the idea to write grok.Well, if we could name things, then maybe we could turn that into some kind of data structure, sort of the combination of, “I have a piece of log data, and I as an expert, I know that's an IP address, that's the username, and that's the timestamp.” Well, now I can apply this library of regular expressions that I didn't have to write and hopefully has a unit test suite, and say, now we can pull out instead of that plain piece of text that is hard to read as a non-expert, now I can have a data structure we can format however we want, that non-experts can see. And even experts can just relax and not have to be full experts all the time, using that part of your brain. So, now you can start getting towards answering search-oriented questions. “How many login attempts happened yesterday from this IP address?”Corey: Right. And back then, the way that people would do these things was Elasticsearch. So, that's the thing you shove all your data into in a bunch of different ways and you can run full-text queries on it. And that's great, but now we want to have that stuff actually structured, and that is sort of the magic of logstash—which was used in conjunction with Elasticsearch a lot—and it turns out that typing random SQL queries in the command line is not generally how most business users like to interact with this stuff, seems to be something dashboard-y-like, and the project that folks use for that was Kibana. And ELK Stack became a thing because Elasticsearch in isolation can do a lot but it doesn't get you all the way there for what people were using to look at logs.Jordan: You're right.Corey: And Kibana is also one of the projects that Elastic owned, and at some point, someone looks around, like, “Oh, logstash. People are using that with us an awful lot. How big is the company that built that? Oh, it's an open-source project run by some guy? Can we hire that guy?” And the answer is, “Apparently,” because you wound up working as an Elastic employee for a while.Jordan: Yeah. It was kind of an interesting journey. So, in the beginning of logstash in 2009, I kind of had this picture of how I wanted to solve log processing search challenges. And I broke it down into a couple of parts of visualization—to be clear, I broke it down in my head, not into code, but visualization, kind of exploration, there's the processing and transmission, and then there's storage and search. And I only felt confident really attending to a solution for one of those parts. And I picked log processing partly because I already had a jumpstart from a couple of years prior, working on grok and feeling really comfortable with regular expressions. I don't want to say good because that's—Corey: You heard it here first—Jordan: [laugh].Corey: —we found the person that knows regular expressions. [laugh].Jordan: [laugh]. And logstash was being worked on to solve this problem of taking your data, processing it, and getting it somewhere. That's why logstash has so many outputs, has so many inputs, and lots of filters. And about I think a year into building logstash, I had experimented with storage and search backends, and I never found something that really clicked with me. And I was experimenting with Leucine, and knowing that I could not complete this journey because that the problem space is so large, it would be foolish of me to try to do distributed log stores or anything like that, plus visualization.I just didn't have the skills or the time in the day. I ended up writing a frontend for logstash called logstash-web—naming things is hard—and I wasn't particularly skilled or attentive to that project, and it was more of a very lightweight frontend to solve the visualization, the exploration aspect. And about a year into logstash being alive, I found Elasticsearch. And what clicked with me from being a sysadmin and having worked at large data center companies in the past is I know the logs on a single system are going to quickly outgrow it. So, whatever storage system will accept these logs, it's got to be easy to add new storage.And Elasticsearch first-day promise was it's distributed; you can add more nodes and go about your day. And it fulfilled that promise and I think it still fulfills that promise that if you're going to be processing terabytes of data, yeah, just keep dumping it in there. That's one of the reasons I didn't try and even use MySQL, or Postgres, or other data systems because it didn't seem obvious how to have multiple storage servers collecting this data with those solutions, for me at the time.Corey: It turns out that solving problems like this that are global and universal lead to massive adoption very quickly. I want to get this back a bit before you wound up joining Elastic because you get up on stage and you talked through what this is. And I mentioned at the start of this recording, that it was one of those transformative talks. But let's be clear here, I don't remember 95% of how logstash works. Like, the technology you talked about ten years ago is largely outmoded slash replaced slash outdated today. I assure you, I did not take anything of note whatsoever from your talk regarding regular expressions, I promise. And—Jordan: [laugh]. Good.Corey: But that's not the stuff that was transformative to me. What was, was the way that you talked about these things. And there was the first time I'd ever heard the phrase that if a new user has a bad time, it's a bug. This was 2012. The idea of empathy hadn't really penetrated into the ops and engineering spaces in any meaningful way yet. It was about gatekeeping, it was about, “Read the manual fool”—Jordan: Yes.Corey: —if people had questions. And it was actively user-hostile. And it was something that I found transformative of, forget the technology piece for a second; this is a story about how it could be different. Because logstash was the vehicle to deliver a message that transcended far beyond the boundaries of how to structure your logs, or maybe the other boundaries of regular expressions, I'm never quite sure where those things start and stop. But it was something that was actively transformative where you're on stage as someone who is a recognized authority in the space, and you're getting up there and you're sending an implicit message—both explicitly and by example—of be nice to people; demonstrate empathy. And that left a hell of an impact. And—Jordan: Thank you.Corey: I wound up doing a spot check just now, and I wound up looking at this and sure enough, early in 2013, I wound up committing—it's still in the history of the changelog for logstash because it's open-source—I committed two pull requests and minutes apart, two submissions—I don't know if pull requests were even a thing back then—but it wound up in the log. Because another project you were renowned for was fpm: Effing Package Manager if I'm—is that what the acronym stands for, or am I misremembering?Jordan: [laugh]. We'll go with that. I'm sure, vulgar viewers will know what the F stands for, but you don't have to say it. It's just Effing Package Management.Corey: Yeah.Jordan: But yeah, I think I really do believe that if a user, especially if a new user has a bad time, it's a bug, and that came from many years of participating at various levels in open-source, where if you came at it with a tinkerer's or a hacker's mindset and you think, “This project is great. I would like it to do one additional thing, and I would like to talk to someone about how to make it do that one additional thing.” And you go find the owners or the maintainers of that project, and you come in with gusto and energy, and you describe what you want to do and, first, they say, “What you want to do is not possible.” They don't even say they don't want to do it; they frame the whole universe against you. “It's not possible. Why would you want to do that? If you want to make that, do it yourself.”You know, none of these things are an extended hand, a lowered ladder, an open door, none of those. It's always, “You're bothering me. Go away. Please read the documentation and see where we clearly”—which they don't—“Document that this is not a thing we're interested in.” And I came to the conclusion that any future open-source or collaborative work that I worked on, it's got to be from a place where, “You're welcome, and whatever contributions or participation levels you choose, are okay. And if you have an idea, let's talk about it. If you're having a bad time, let's figure out how to solve it.”Maybe the solution is we point you in the right direction to the documentation, if documentation exists; maybe we find a bug that we need to fix. The idea that the way to build communities is through kindness and collaboration, not through walls or gatekeeping or just being rude. And I really do think that's one of the reasons logstash became so successful. I mean, any particular technology could have succeeded in the space that logstash did, but I believe that it did so because of that one piece of framework where if a new user has a bad time, it's a bug. Because to me, that opens the door to say, “Yeah, you know what? Some of the code I write is not going to be good. Or, the thing you want to do is undocumented. Or the documentation is out of date. It told you a lie and you followed the documentation and it misled you because it's incorrect.”We can fix that. Maybe we don't have time to fix it right now. Maybe there's no one around to fix it, but we can at least say, “You know what? That information is incorrect, and I'm sorry you were misled. Come on into the community and we'll figure it out.” And one of the patterns I know is, on the IRC channel, which is where the logstash real-time community chat… I don't know how to describe that.Corey: No, it was on freenode. That's part of the reason I felt okay, talking to you. At that point. I was volunteer network staff. This is before freenode turned into basically a haven for Nazis this past year.Jordan: Yeah. It was still called lilo… lilonet [crosstalk 00:20:20]—Corey: No, the open freenode network, that predates me. This was—yeah, lilo—Jordan: Okay.Corey: —died about six years prior. But—Jordan: Oh, all right.Corey: Freenode's been around a long time. What make this thing work was that I was network staff, and that means that I had a bit of perceived authority—it's a chat room; not really—but it was one of those things where it was at least, “Okay, this is not just some sketchy drive-by rando,” which I very much was, but I didn't present that way, so I could strike up conversations. But with you talking about this stuff, I never needed to be that person. It was just if someone wants to pitch in on this, great; more hands make lighter work. Sure.Jordan: Yeah, for sure.Corey: And for me, the interesting part is not even around the logstash aspects so much; it's your other project, fbm. Well, one of your other projects. Back in 2012, that was an interesting year for me. Another area that got very near and dear to my heart in open-source world was the SaltStack project; I was contributor number 15. And I didn't know how Python worked. Not that I do now, but I can fake it better now.And Tom Hatch, the guy that ran the project before it was a company was famous for this where I could send in horrifying levels of code, and every time he would merge it in and then ten minutes later, there would be another patch that comes in that fixes all bugs I just introduced and it was just such a warm onboarding. I'm not suggesting that approach and I'm not saying it's scalable, but I started contributing. And I became the first Debian and Ubuntu packager for SaltStack, which was great. And I did a terrible job at it because—let me explain. I don't know if it's any better now, but back in those days, there were multiple documentation sources on the proper way to package software.They were all contradictory with each other, there was no guidance as to when to follow each one, there was never a, “You know nothing about packaging; here's what you need to know, step-by-step,” and when you get it wrong, they yell at you. And it turns out that the best practice then to get it formally accepted upstream—which is what I did—is do a crap-ass job, and then you'll wind up with a grownup coming in, like, “This is awful. Move.” And then they'll fix it and yell at you, and gatekeep like hell, and then you have a package that works and gets accepted upstream because the magic incantation has been said somewhere. And what I loved about fpm was that I could take any random repo or any source tarball or anything I wanted, run it through with a single command, and it would wind up building out a RPM and a Deb file—and I don't know what else it's supported; those are the ones I cared about—that I could then install on a system. I put in a repo and add that to a sources list on systems, and get to automatically install so I could use configuration management—like SaltStack—to wind up installing custom local packages. And oh, my God, did the packaging communities for multiple different distros hate you—Jordan: Yep.Corey: —and specifically what you had built because this was not the proper way to package. How dare you solve an actual business problem someone has instead of forcing them to go to packaging school where the address is secret, and you have to learn that. It was awful. It was the clearest example that I can come up with of gatekeeping, and then you're coming up with fbm which gets rid of user pain, and I realized that in that fight between the church of orthodoxy of, “This is how it should be done,” and the, “You're having a problem; here's a tool that makes it simple,” I know exactly what side of that line I wanted to be on. And I hadn't always been previously, and that is what clarified it for me.Jordan: Yeah, fbm was a really delightful enjoyment for me to build. The origins of that was I worked at a company and they were all… I think, at that time, we were RPM-based, and then as folks tend to do, I bounced around between jobs almost every year, so I went from one place that—Corey: Hey, it's me.Jordan: [laugh]. Right? And there's absolutely nothing wrong with leaving every year or staying longer. It's just whatever progresses your career in the way that you want and keeps you safe and your family safe. But we were using RPM and we were building packages already not following the orthodoxy.A lot of times if you ask someone how to build a package for Fedora, they'll point you at the Maximum RPM book, and that's… a lot of pages, and honestly, I'm not going to sit down and read it. I just want to take a bunch of files, name it, and install it on 30 machines with Puppet. And that's what we were doing. Cue one year later, I moved to a new company, and we were using Debian packages. And they're the same thing.What struck me is they are identical. It's a bunch of files—and don't pedant me about this—it's a bunch of files with a name, with some other sometimes useful metadata, like other names that you might depend on. And I really didn't find it enjoyable to transfer my knowledge of how to build RPMs, and the tooling and the structures and the syntaxes, to building Debian packages. And this was not for greater publication; this was I have a bunch of internal applications I needed to package and deploy with, at the time it was Puppet. And it wasn't fun.So, I did what we did with grok which was codify that knowledge to reduce the burden. And after a few, probably a year or so of that, it really dawned on me that a generality is all packaging formats are largely solving the same problem and I wanted to build something that was solving problems for folks like you and me: sysadmins, who were handed a pile of code and they needed to get it into production. And I wasn't interested in formalities or appeasing any priesthoods or orthodoxies about what really—you know, “You should really shine your package with this special wax,” kind of thing. Because all of the documentation for Debian packages, Fedora packages are often dedicated to those projects. You're going to submit a package to Fedora so that the rest of the world can use it on Fedora. That wasn't my use case.Corey: Right. I built a thing and a thing that I built is awesome and I want the world to use it, so now I have to go to packaging school? Not just once but twice—Jordan: Right.Corey: —and possibly more. That's awful.Jordan: Or more. Yeah. And it's tough.Corey: This episode is sponsored in part by our friends at Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part.Corey: And this gets back to what I found of—it was rare that I could find a way to contribute to something meaningfully, and I was using logstash after your talk, I'd started using it and rolling it out somewhere, and I discovered that there wasn't a Debian package for it—the environment I was in at that time—or Ubuntu package, and, “Hey Jordan, are you the guy that wrote fpm and there isn't a package here?” And the thing is is that you would never frame it this way, but the answer was, of course, “Pull requests welcome,” which is often an invitation to do free volunteer work for companies, but this was an open-source project that was not backed by a publicly-traded company; it was some guy. And of course, I'll pitch in on that. And I checked the commit log on this for what it is that I see, and sure enough, I have two commits. The first one was on Sunday night in February of 2013, and my commit message was, “Initial packaging work for Deb building.” And sure enough, there's a bunch of files I put up there and that's great. And my second and last commit was 12 minutes later saying, “Remove large binary because I'm foolish.” Yeah.Jordan: Was that you? [laugh].Corey: Yeah. Oh, yeah, I'm sure—yeah, it was great. I didn't know how Git worked back then. I'm sure it's still in the history there. I wonder how big that binary is, and exactly how much I have screwed people over in the last decade since.Jordan: I've noticed this over time. And every now and then you'd be—I would be or someone would be on a slow internet connection—which again, is something that we need to optimize for, or at least be aware of and help where we can—someone would be cloning logstash on an airplane or something like that, or rural setting, and they would say, “It gets stuck at 76% for, like, ten minutes.” And you would go back and dust off your tome of how to use Git because it's very difficult piece of software to use, and you would find this one blob and I never even looked at it who committed it or whatever, but it was like I think it was 80 Megs of a JAR file or a Debian package that was [unintelligible 00:28:31] logstash release. And… [laugh] it's such a small world that you're like, yep, that was me.Corey: Oh, yeah. Oh, yeah. Let's check this just for fun here. To be clear, the entire repository right now is 167 Megs, so that file that I had up there for all of 13 minutes lives indelibly in Git history, and it is fully half of the size—Jordan: Yep.Corey: —of the entirety of the logstash project. All right, then. I didn't realize this was one of those confess your sins episodes, but here we are.Jordan: Look, sometimes we put flags on the moon, sometimes we put big files in git. You could just for posterity, we could go back and edit the history and remove that, but it never became important to do it, it wasn't loud, people weren't upset enough by it, or it didn't come up enough to say, “You know what? This is a big file.” So, it's there. You left your mark.Corey: You know, we take what we can get. It's an odd time. I'll have to do some digging around; I'm sure I'll tweet about this as soon as I get a bit more data on it, but I wonder how often people have had frustration caused by that. There's no ill intent here, to be very clear, but it was instead, I didn't know how Git worked very well. I didn't know what I was doing in a lot of respects, and sure enough in the fullness of time, some condescending package people came in and actually made this right.And there is a reasonable, responsible package now because, surprise, of course there is. But I wonder how much inadvertent pain I caused people by that ridiculous commit. And it's the idea of impact and how this stuff works. I'm not happy that people are on a plane with a slow connection had a wait an extra minute or two to download that nonsense. It's one of those things that is, oops. I feel like a bit of a heel for that, not for not knowing something, but for causing harm to folks. Intent doesn't outweigh impact. There is a lesson in there for it.Jordan: Agreed. On that example, I think one of the things… code is not the most important thing I can contribute to a project, even though I feel very confident in my skills in programming in a variety of environments. I think the number one thing I can do is listen and look for sources of pain. And people would come in and say, “I can't get this to work.” And we would work together and figure out how to make it work for their use case, and that could result in a new feature, a bug fix, or some documentation improvements, or a blog post, or something like that.And I think in this case, I don't really recall any amount of noise for someone saying, “Cloning the Git repository is just a pain in the butt.” And I think a lot of that is because either the people who would be negatively impacted by that weren't doing that use case, they were downloading the releases, which were as small as we can possibly get them, or they were editing files using the GitHub online edit the file thing, which is a totally acceptable, it's perfectly fine way to do things in Git. So, I don't remember anyone complaining about that particular file size issue. The Elasticsearch repository is massive and I don't think it even has binaries. It just has so much more—Corey: Someone accidentally committed their entire production test data set at one point and oops-a-doozy. Yeah, it's not the most egregious harm I've ever caused—Jordan: Yeah.Corey: —but it's there. The thing that, I guess, resonates with me and still does is the lessons I learned from you, I could sum them up as being not just empathy-driven—because that's the easy answer—but the other layers were that you didn't need to be the world's greatest expert in a thing in order to credibly give a conference talk. To be clear, you were miles ahead of me and still are in a lot of different areas—Jordan: Thanks.Corey: —and that's fine. But you don't need to be the—like, you are not the world's greatest expert on empathy, but that's what I took from the talk and that's what it was about. It also taught me that things you can pick up from talks—and other means—there are things you can talk about in terms of technology and there are things you can talk about in terms of people, and the things about people do not have expiration dates in the same way that technology does. And if I'm going to be remembered for impact on people versus impact on technology, for me, there's no contest. And you forced me to really think about a lot of those things that it started my path to, I guess, becoming a public speaker and then later all the rest that followed, like this podcast, the nonsense on Twitter, and all the rest. So, it is, I guess, we can lay the responsibility for all that at your feet. Enjoy the hate mail.Jordan: Uhh, my email address is now closed. I'm sorry.Corey: Exactly.Jordan: Well, I appreciate the kind words.Corey: We'll get letters on this one.Jordan: [laugh].Corey: It's the impact that people have, and someti—I don't think you knew at the time that that's the impact you were having. It matters.Jordan: I agree. I think a lot of it came from how do I want to experience this? And it was much later that it became something that was really outside of me, in the sense that it was building communities. One of the things I learned shortly after—or even just before—joining Elastic was how many folks were looking to solve a problem, found logstash, became a participant in the community, and that participation could just be anything, just hanging out on IRC, on the mailing list, whatever, and the next step for them was to get a better paying job in an environment they enjoyed that helped them take the next step in their career. Some of those people came to work with me at Elastic; some of them started to work on the logstash team at some point they decided because a lot of logstash users were sysadmins.And on the logstash team, we were all developers; we weren't sysadmins, there was nothing to operate. And a lot of folks would come on board and they were like, “You know what? I'm not enjoying writing Ruby for my job.” And they could take the next step to transition to the support team or the sales engineer team, or cloud operations team at Elastic. So, it was really, like you mentioned, it has nothing to do with the technology of—to me—why these projects are important.They became an amplifier and a hand to pull people up to go the next step they need to go. And on the way maybe they can make a positive impact in the communities they participate in. If those happen to be fpm or logstash, that's great, but I think I want folks to see that technology doesn't have to be a grind of getting through gatekeepers, meeting artificial barriers, and things like that.Corey: The thing that I took, too, is that I gave a talk in 2015 or'16, which is strangely appropriate now: “Terrible ideas in Git.” And yes, checking large binaries in is one of the terrible ideas I talk about. It's Git through counter-example. And around that time, I also gave a talk for a while on how to handle a job interview and advance your career. Only one of those talks has resulted in people approaching me even years later saying that what I did had changed aspects of their life. It wasn't the Git one. And that's the impact it comes down to. That is the change that I wanted to start having because I saw someone else do it and realized, you know, maybe I could possibly be that good someday. Well, I'd like to think I made it, on some level.Jordan: [laugh]. I'm proud of the impact you've made. And I agree with you, it is about people. Even with fpm where I was very selfishly tickling my own itch, I don't want to remember all of this stuff and I also enjoy operating outside of the boundaries of a church or whatever the priesthoods that say, “This is how you must do a thing,” I knew there was a lot of folks who worked at jobs and they didn't have authority, and they had to deploy something, and they knew if they could just package it into a Debian format, or an RPM format, or whatever they needed to do, they could get it deployed and it would make their lives easier. Well, they didn't have the time or the energy or the support in order to learn how to do that and fpm brought them that success where you can say, “Here's a bunch of files; here's a name, poof, you have a package for whatever format you want.”Where I found fpm really take off is when Gem and Python and Node.js support were added. The sysadmins were kind of sandwiched in between—in two impossible worlds where they are only authorized to deploy a certain package format, but all of their internal application developer teams were using Node.js and newer technologies, and all of those package formats were not permitted by whoever had the authority to permit those things at their job. But now they had a tool that said, “You know what? We can just take that thing, we'll take Django and Python, and we'll make it an RPM and we won't have to think a lot about it.”And that really, I think—to me, my hope was that it de-stresses that sort of work environment where you're not having to do three weeks of brand new work every time someone releases something internally in your company; you can just run a script that you wrote a month ago and maintain it as you go.Corey: Wouldn't that be something?Jordan: [laugh]. Ideally, ideally.Corey: Jordan, I want to thank you for not only the stuff you did ten years ago, but also the stuff you just said now. If people want to learn more about you, how you view the world, see what you're up to these days, where can they find you?Jordan: I'm mostly active on Twitter, at @jordansissel, all one word. Mostly these days, I post repair stuff I do on the house. I'm a stay-at-home full0 time dad these days, and… I'm still doing maintenance on the projects that need maintenance, like fpm or xdotool, so if you're one of those users, I hope you're happy. If you're not happy, please reach out and we'll figure out what the next steps can be. But yeah. If you like bugs, especially spiders—or if you don't like spiders and you want to like spiders, check me out on Twitter. I'm often posting macro photos, close-up photos of butterflies, bees, spiders, and the like.Corey: And we will, of course, throw links to that in the [show notes 00:38:10]. Jordan, thank you so much for your time today. It's appreciated.Jordan: Thank you, Corey. It's good talking to you.Corey: Jordan Sissel, founder of logstash and currently, blissfully, not working on a particular corporate job. I envy him, some days. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment in which you have also embedded a large binary.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

O volume dois da série de players de observabilidade apresenta Ricardo Ferreira, developer advocate da Elastic, empresa que tem sua solução de observabilidade integrada e Open Source, baseada no Elasticsearch e Kibana.Numa conversa profunda sobre a prática de avaliar o comportamento de sistemas distribuídos cada vez mais complexos, falamos sobre o conceito de observabilidade x monitoração, prós e contras das instrumentações Black box e White box, suporte para OpenTelemetry e as principais features do produto da Elastic. Siga com o play para conferir na íntegra o novo episódio da Saga de Observabilidade:CONTATO - Para falar com o Ricardo, envie sua mensagem para: Telegram: https://t.me/riferreiTwitter: https://twitter.com/riferreiEmail: riferrei@riferrei.comYouTube: https://videos.riferrei.comBlog: https://riferrei.comOs LINKS comentados nesse Kubicast são:OpenTelemetry com JAVAOpenTelemetry com GolangAs RECOMENDAÇÕES do programa seguem aqui:Ricardo:Restaurante Bolão em Belo Horizonte - MGPão na chapa Mind Hunter (Tem na Netflix)João:Esquadrão dos Confeiteiros (Tem na Netflix)AVISO! O CFP do #kcdbrasil está aberto e vai até 29/10. Apresente sua ideia para espalhar a palavra no maior evento de Kubernetes do Brasil. O Kubicast é uma produção da Getup, especialista em Kubernetes e apoiadora do projeto UnDistro, uma distribuição para gerenciar múltiplos clusters Kubernetes. #o11y #Observability #DevOps #Kubernetes #Containers #docker 

Elasticsearch, Logstash and Kibana is what makes up ELK in ELK-stack. Listen to Morten Vestergaard and Asger Mikkelsen when they deep dive in the technology that makes it possible to handle large data sets gathered from multiple servers, security issues and why it is great to take the tool into consideration already when designing the architecture for your system.

This week on the podcast, Dan talk about email authenticity and his experience with the auto-applying PRPs in FS Image 40, and Kyle shares ways to find hidden errors with Kibana. Show Notes Email Authenticity @ 2:45 https://www.alexblackie.com/articles/email-authenticity-dkim-spf-dmarc/ https://simonandrews.ca/articles/how-to-set-up-spf-dkim-dmarc Kibana and researching errors @ 13:00 Auto-Apply PRPs @ 21:15

Antonio, Guillaume et Emmanuel discutent de pleins de choses dont des analyses de l'écosystème de la JVM, de la generation de code via intelligence Artificielle avec CoPilot, mais pas que. Enregistré le 16 juillet 2021 Téléchargement de l'épisode LesCastCodeurs-Episode–999.mp3 News Langages Les prédictions d'Adam Bien pour la seconde moitié de 2021 Kube a gagné la guerre. Les cloud providers fournissent des solutions dérivées plus simplifiées. La compatibilité kubernetes devient moins cruciale FaaS est utilise pour son usage listener et point d'intégration et plus en général purpose tool Prix du cloud et repatriation. Bouger une app existante dans le cloud n'amène pas d'avantage. Le monolith devient une best pratice Coût du cloud pousse a merger des microsercices dans un cadre de cloud cost driven development Cloud deviennent intéressant pour les services unique (text to speech, image recognition, etc). En parallèle la sécurité des cloud providers est reconnu. Donc boring load on prem, projects innovants dans le cloud. Serverless va être le trend de 2021 (fonction mais aussi db, workflow, event streams etc) idée est scale down to zero La montée des frameworks next gen Micronaut et Quarkus est indisputable. Build time deployment. La popularité de quarkus a explosé, difficile de trouver un développeur Java qui n'a pas expérimenté. Le cocktail GraalVM api familières Jakarta ee et micro profile, sa do so mémoire et temps de démarrage lui donne un avantage. Mais la compétition ne dors pas (Helidon et micronaut) Moins de langages alternatifs parce que l'innovation dans Java a accéléré Lombok moins populaire parce que Java Records. Kafka sera plus un data store immuable et source de vérité que un remplacement pour JMS Kafka et réactive en combo va rendre la programmation réactive populaire Le projet Loom eliminera la programmation reactive pour les resources non-reactives ARM sur le serveur GraalVM pour remplacer OpenJDK car rapide et multi langage. Et competitor a GraalVM qui arrive Visual studio code et ses features pour Java pas forcément connu et donc va croître encore. Payara cloud serverless server ou l'app server est un opérateur Kube et on déploie un thin jar. GraalVM offre des plugins Gradle et Maven pour la compilation native Tester les libraires en natif avec les tests junit 5 qui tournent en natif Après tourne les tests en JVM, ils sont loggués et ajoutés en réflection et complication native. Et un binaire de test est créé plugin Gradle License Oracle Universal Permissive probablement un dérivé de Universal Permissive License Le rapport sur l'écosystème JVM par Snyk Sondage effectué durant six semaines (entre février et mars 2021) au prêt de 2000 developeurs et comparé à GitHub et Google Trends Mon (Emmanuel) intuition c'est qu'il y un biais dans les gens mesurés 44% des Dev Java utilisent adoptopenjdk en prod. Oracle openjdk 28 et Oracle JDG 23 60% utilisent Java 11 en prod. Et 12 la dernière mais encore 60% de 8 en prod Java 91% kotlin 18% groovy 13 et scala 10 IntelliJ 70% eclipse 25 et vscode 23. 50% sont bi IDE Maven 76% gradle 38% ant 12W yah Spring Boot 58% Spring MVC 29% Jakarta ee 13% Quarkus 11% JDK 17 en ramp down phase 2 Schedule 2021/07/15 Rampdown Phase Two 2021/08/05 Initial Release Candidate 2021/08/19 Final Release Candidate 2021/09/14 General Availability Features integrated in JDK 17: JEP 306: Restore Always-Strict Floating-Point Semantics JEP 356: Enhanced Pseudo-Random Number Generators JEP 382: New macOS Rendering Pipeline JEP 391: macOS/AArch64 Port */ JEP 398: Deprecate the Applet API for Removal JEP 403: Strongly Encapsulate JDK Internals (sauf pour sun.misc.Unsafe) JEP 406: Pattern Matching for switch (Preview) JEP 407: Remove RMI Activation JEP 409: Sealed Classes JEP 410: Remove the Experimental AOT and JIT Compiler JEP 411: Deprecate the Security Manager for Removal JEP 412: Foreign Function & Memory API (Incubator) JEP 414: Vector API (Second Incubator) JEP 415: Context-Specific Deserialization Filters Librairies Spring Native 0.10.0 Utilise Native testing de GraalVM Passe au plugin Gradle de l'équipe GraalVM Ahead of time proxies pour les classes Quarkus 2.0 est sorti Guide de migration mais les applis devraient essentiellement fonctionner (extensions ont plus de taf) JDK 11+ GraalVM 21.1 Vert.x 4 Microprofile 4 Continuous testing : les tests impactes tournent automatiquement en Dev mode. Les tests qui cassent sur un changement sont visible tout de suite et en continu. Comme infinitest mais sans plugin IDE. Quarkus a une CLI pour simplifier l'interaction vs les plugins maven ou gradle. Notamment création de projetas. JDK 11+ GraalVM 21.1 Vert.x 4 Microprofile 4 GraphQL client (smallrye), CDI decorators supportés, transaction pour MongoDB avec Panache, Support kotlin grandement amélioré : resteasy rezctive, rest client, reactive messaging extensions supportent tous les coroutines Support d'Amazon services system manager Crafting rolling releases for a Quarkus CLI application Y'a encore du chemin pour faire simplement des CLI avec graalVM en comparaison de go JReleaser outils permettant de livrer automatiquement des projets Java vers différentes plateforme (Homebrew, Snapcraft, Scoop) Inspiré de GoReleaser et jbang Le blog package l'outil kcctl créé par Gunnar avec JReleaser Pas mal de conf (Windows vs Linux/MacOS) mais à la fin il y arrive Infrastructure Amazon sort son OpenSearch 1.0 et OpenSearch Dashboard, leur fork d'Elastic Search et Kibana 1.0 sortie de OpenSearch (GitHub) Suppression du code propriétaire Upgrading: mise a jour d'ElasticSearch et Kibana vers OpenSearch et OpenSearch Dashboard aussi simple qu'une mise a jour de version Compatibility: travaux de reflexion autour de la compatibilité avec les outils existants Testing: infrastructure de test moderne et flexible Supporte les architecture for Linux ARM64 Minimal artifacts for embedding of OpenSearch and OpenSearch Dashboards into existing products and services, Data stream support for OpenSearch Dashboards, Span attribute visibility and filtering in the Trace Analytics plugin, Scheduling and tenant support in the Reporting plugin. Aussi mentionne la roadmap Kubernetes 1.22 enlève le support des vieilles versions de ressource Faites le ménage en continu pas des grosses migrations tous les 3 ans Release prévue en aout Il vont supprimer des APIs qui étaient en beta Cloud Un tweet lance un faux service AWS InfiniDash qui a été repris par des devs et des boîtes La théorie est que la plupart des devs n'entendront parler de technologie que via les tweets et les articles. Aussi le métier de devrel c'est de surfer la vague du social media. Les dev rels AWS ont continué la farce (je crois) Werner Vogels, oui pour sur. gros effet boulle de neige Outillage GitHub copilot itellisense boosté par les projets visible et hostés dans GitHub et autre données publiques via l'intelligence artificelle, essaie de comprendre l'intention via le contexte uniquement le fichier édité en contxte pour l'instant VSCode extension donc tourne partout où les plugins VSCode tournent 0,1% de copie exacte le code nous appartient en tant qu'utilisateur le code contexte est transmis a GitHub qui l'utilise pour ses telemetries et améliorer les modèles ML pas toujours du code de qualité des secrets valides sont générés (du corpus originali e.g. SendGrid) propose du code GPL (derivation?) attaque de sécurité vont venir :) Audacity 3 spyware ou pas après le rachat la communauté “niveau 2” s'est emballée, a crée une dizaine de forks. C'était déjà annoncé et discuté avec la communauté Audacity. OS, pays, cpu, erreurs, reports de crash Protection légale « law enforcement ». Les 13 ans, juste pour éviter des restrictions légales us 3.0.2 n'a pas le code des collections de données Avec feedback initial passe de Google analytics à un hébergement propre. Quand compile le project c'est off par défaut (donc seuls les binaires distribués l'ont par défaut) donc pas dans les distros linux Sécurité LinkedIn la brèche qui donne des infos de 92% de ses utilisateurs y compris les salaires inférés API LinkedIn abusée. Email, noms, telephone, adresse physique, de 700M d'utilisateurs Presque interessé de fouiller pour voir mon salaire théorique :) Dispo sur le dark web Loi, société et organisation Lettre à ceux qui veulent faire tourner la France sur l'ordinateur de quelqu'un d'autre par Tariq Krim Télécharger l'ebook au format PDF. Très documenté et référencé Coulisses et manoeuvres pour installer les GAFAM au coeur de l'État 17 mai 2021, Bercy présente la nouvelle stratégie Cloud du Gouvernement GAM (Googla Amazon Microsoft) À part OVH Cloud, aucun des acteurs français n'a été mentionné par les Ministres Les lois américaines dites FISA et Cloud Act permettent d'obliger les grandes sociétés US à fournir à la justice américaine les données situées sur leurs serveurs européens Si l'on met de côté les questions de souveraineté, les services de sociétés comme Amazon, Microsoft et Google sont très ergonomiques Les Américains offrent des services clé en main, les services “made in France” demandent de combiner plusieurs produits issus de sociétés différentes Apple, Google, Facebook, Amazon ont embauché des dizaines de milliers d'ingénieurs, dont de très talentueux Français Les clouds GAM pourraient décrocher le label SecNum Cloud (le plus haut niveau de sécurisation de l'État) Après avoir délocalisé notre industrie (le fameux “Fabless” de Serge Tchuruk ancien patron d'Alcatel), l'État et les grandes entreprises ont délocalisé leur informatique vers les grandes SSII qui se sont mises à produire des projets à la chaîne Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/

Antonio, Guillaume et Emmanuel discutent de pleins de choses dont des analyses de l'écosystème de la JVM, de la generation de code via intelligence Artificielle avec CoPilot, mais pas que. Enregistré le 16 juillet 2021 Téléchargement de l'épisode [LesCastCodeurs-Episode-999.mp3](https://traffic.libsyn.com/lescastcodeurs/LesCastCodeurs-Episode-999.mp3) ## News ### Langages [Les prédictions d'Adam Bien pour la seconde moitié de 2021](https://adambien.blog/roller/abien/entry/mid_year_2021_observations_and) * Kube a gagné la guerre. Les cloud providers fournissent des solutions dérivées plus simplifiées. La compatibilité kubernetes devient moins cruciale * FaaS est utilise pour son usage listener et point d'intégration et plus en général purpose tool * Prix du cloud et repatriation. Bouger une app existante dans le cloud n'amène pas d'avantage. Le monolith devient une best pratice * Coût du cloud pousse a merger des microsercices dans un cadre de cloud cost driven development * Cloud deviennent intéressant pour les services unique (text to speech, image recognition, etc). En parallèle la sécurité des cloud providers est reconnu. Donc boring load on prem, projects innovants dans le cloud. * Serverless va être le trend de 2021 (fonction mais aussi db, workflow, event streams etc) idée est scale down to zero * La montée des frameworks next gen Micronaut et Quarkus est indisputable. Build time deployment. * La popularité de quarkus a explosé, difficile de trouver un développeur Java qui n'a pas expérimenté. Le cocktail GraalVM api familières Jakarta ee et micro profile, sa do so mémoire et temps de démarrage lui donne un avantage. Mais la compétition ne dors pas (Helidon et micronaut) * Moins de langages alternatifs parce que l'innovation dans Java a accéléré * Lombok moins populaire parce que Java Records. * Kafka sera plus un data store immuable et source de vérité que un remplacement pour JMS * Kafka et réactive en combo va rendre la programmation réactive populaire * Le projet Loom eliminera la programmation reactive pour les resources non-reactives * ARM sur le serveur * GraalVM pour remplacer OpenJDK car rapide et multi langage. Et competitor a GraalVM qui arrive * Visual studio code et ses features pour Java pas forcément connu et donc va croître encore. * Payara cloud serverless server ou l'app server est un opérateur Kube et on déploie un thin jar. [GraalVM offre des plugins Gradle et Maven pour la compilation native](https://medium.com/graalvm/gradle-and-maven-plugins-for-native-image-with-initial-junit-testing-support-dde00a8caf0b) * Tester les libraires en natif avec les tests junit 5 qui tournent en natif * Après tourne les tests en JVM, ils sont loggués et ajoutés en réflection et complication native. * Et un binaire de test est créé * plugin Gradle * License Oracle Universal Permissive * probablement un dérivé de [Universal Permissive License](https://opensource.org/licenses/UPL) [Le rapport sur l'écosystème JVM](https://snyk.io/jvm-ecosystem-report-2021) par Snyk * Sondage effectué durant six semaines (entre février et mars 2021) au prêt de 2000 developeurs et comparé à GitHub et Google Trends * Mon (Emmanuel) intuition c'est qu'il y un biais dans les gens mesurés * 44% des Dev Java utilisent adoptopenjdk en prod. Oracle openjdk 28 et Oracle JDG 23 * 60% utilisent Java 11 en prod. Et 12 la dernière mais encore 60% de 8 en prod * Java 91% kotlin 18% groovy 13 et scala 10 * IntelliJ 70% eclipse 25 et vscode 23. 50% sont bi IDE * Maven 76% gradle 38% ant 12W yah * Spring Boot 58% Spring MVC 29% Jakarta ee 13% Quarkus 11% [JDK 17 en ramp down phase 2](https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005266.html) Schedule * 2021/07/15 Rampdown Phase Two * 2021/08/05 Initial Release Candidate * 2021/08/19 Final Release Candidate * 2021/09/14 General Availability Features integrated in JDK 17: * [JEP 306: Restore Always-Strict Floating-Point Semantics](https://openjdk.java.net/jeps/306) * [JEP 356: Enhanced Pseudo-Random Number Generators](https://openjdk.java.net/jeps/356) * [JEP 382: New macOS Rendering Pipeline](https://openjdk.java.net/jeps/382) * [JEP 391: macOS/AArch64 Port ](https:/*openjdk.java.net/jeps/391)*/ * [JEP 398: Deprecate the Applet API for Removal](https://openjdk.java.net/jeps/398) * [JEP 403: Strongly Encapsulate JDK Internals](https://openjdk.java.net/jeps/403) (sauf pour `sun.misc.Unsafe`) * [JEP 406: Pattern Matching for switch (Preview)](https://openjdk.java.net/jeps/406) * [JEP 407: Remove RMI Activation ](https://openjdk.java.net/jeps/407) * [JEP 409: Sealed Classes ](https://openjdk.java.net/jeps/409) * [JEP 410: Remove the Experimental AOT and JIT Compiler](https://openjdk.java.net/jeps/410) * [JEP 411: Deprecate the Security Manager for Removal](https://openjdk.java.net/jeps/411) * [JEP 412: Foreign Function & Memory API (Incubator)](https://openjdk.java.net/jeps/412) * [JEP 414: Vector API (Second Incubator)](https://openjdk.java.net/jeps/414) * [JEP 415: Context-Specific Deserialization Filters](https://openjdk.java.net/jeps/415) ### Librairies [Spring Native 0.10.0](https://spring.io/blog/2021/06/14/spring-native-0-10-0-available-now) * Utilise Native testing de GraalVM * Passe au plugin Gradle de l'équipe GraalVM * Ahead of time proxies pour les classes [Quarkus 2.0 est sorti](https://quarkus.io/blog/quarkus-2-0-0-final-released/) * Guide de migration mais les applis devraient essentiellement fonctionner (extensions ont plus de taf) * JDK 11+ GraalVM 21.1 * Vert.x 4 * Microprofile 4 * Continuous testing : les tests impactes tournent automatiquement en Dev mode. Les tests qui cassent sur un changement sont visible tout de suite et en continu. Comme infinitest mais sans plugin IDE. * Quarkus a une CLI pour simplifier l'interaction vs les plugins maven ou gradle. Notamment création de projetas. * JDK 11+ GraalVM 21.1 * Vert.x 4 * Microprofile 4 * GraphQL client (smallrye), CDI decorators supportés, transaction pour MongoDB avec Panache, * Support kotlin grandement amélioré : resteasy rezctive, rest client, reactive messaging extensions supportent tous les coroutines * Support d'Amazon services system manager [Crafting rolling releases for a Quarkus CLI application](https://andresalmiray.com/crafting-rolling-releases-for-a-quarkus-cli-application/) * Y'a encore du chemin pour faire simplement des CLI avec graalVM en comparaison de go * [JReleaser](https://jreleaser.org) outils permettant de livrer automatiquement des projets Java vers différentes plateforme (Homebrew, Snapcraft, Scoop) * Inspiré de GoReleaser et jbang * Le blog package l'outil `kcctl` créé par Gunnar avec JReleaser * Pas mal de conf (Windows vs Linux/MacOS) mais à la fin il y arrive ### Infrastructure [Amazon sort son OpenSearch 1.0 et OpenSearch Dashboard, leur fork d'Elastic Search et Kibana](https://opensearch.org/blog/updates/2021/07/opensearch-general-availability-announcement/) * 1.0 sortie de [OpenSearch](https://opensearch.org) ([GitHub](https://github.com/opensearch-project)) * Suppression du code propriétaire * Upgrading: mise a jour d'ElasticSearch et Kibana vers OpenSearch et OpenSearch Dashboard aussi simple qu'une mise a jour de version * Compatibility: travaux de reflexion autour de la compatibilité avec les outils existants * Testing: infrastructure de test moderne et flexible * Supporte les architecture for Linux ARM64 * Minimal artifacts for embedding of OpenSearch and OpenSearch Dashboards into existing products and services, * Data stream support for OpenSearch Dashboards, * Span attribute visibility and filtering in the Trace Analytics plugin, * Scheduling and tenant support in the Reporting plugin. * Aussi mentionne la roadmap [Kubernetes 1.22 enlève le support des vieilles versions de ressource](https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/#api-changes) * Faites le ménage en continu pas des grosses migrations tous les 3 ans * Release prévue en aout * Il vont supprimer des APIs qui étaient en beta ### Cloud [Un tweet lance un faux service AWS InfiniDash qui a été repris par des devs et des boîtes](https://siliconangle.com/2021/07/05/fake-amazon-cloud-service-aws-infinidash-quickly-goes-viral/) * La théorie est que la plupart des devs n'entendront parler de technologie que via les tweets et les articles. * Aussi le métier de devrel c'est de surfer la vague du social media. Les dev rels AWS ont continué la farce (je crois) * Werner Vogels, oui pour sur. * gros effet boulle de neige ### Outillage [GitHub copilot](https://copilot.github.com/) * itellisense boosté par les projets visible et hostés dans GitHub et autre données publiques * via l'intelligence artificelle, essaie de comprendre l'intention via le contexte * uniquement le fichier édité en contxte pour l'instant * VSCode extension donc tourne partout où les plugins VSCode tournent * 0,1% de copie exacte * le code nous appartient en tant qu'utilisateur * le code contexte est transmis a GitHub qui l'utilise pour ses telemetries et améliorer les modèles ML * pas toujours du code de qualité * [des secrets valides sont générés](https://twitter.com/alexjc/status/1411966249437995010) (du corpus originali e.g. SendGrid) * [propose du code GPL (derivation?)](https://drewdevault.com/2021/07/04/Is-GitHub-a-derivative-work.html) * attaque de sécurité vont venir :) [Audacity 3 spyware ou pas après le rachat](https://arstechnica.com/gadgets/2021/07/no-open-source-audacity-audio-editor-is-not-spyware/) * la communauté "niveau 2" s'est emballée, a crée une dizaine de forks. * C'était déjà annoncé et discuté avec la communauté Audacity. * OS, pays, cpu, erreurs, reports de crash * Protection légale « law enforcement ». Les 13 ans, juste pour éviter des restrictions légales us * 3.0.2 n'a pas le code des collections de données * Avec feedback initial passe de Google analytics à un hébergement propre. * Quand compile le project c'est off par défaut (donc seuls les binaires distribués l'ont par défaut) donc pas dans les distros linux ### Sécurité [LinkedIn la brèche qui donne des infos de 92% de ses utilisateurs y compris les salaires inférés](https://9to5mac.com/2021/06/29/linkedin-breach/amp/?__twitter_impression=true) * API LinkedIn abusée. * Email, noms, telephone, adresse physique, de 700M d'utilisateurs * Presque interessé de fouiller pour voir mon salaire théorique :) * Dispo sur le dark web ### Loi, société et organisation [Lettre à ceux qui veulent faire tourner la France sur l'ordinateur de quelqu'un d'autre](https://www.codeforfrance.fr/publications) par [Tariq Krim](https://twitter.com/tariqkrim) * [Télécharger l'ebook au format PDF](https://www.codeforfrance.fr/assets/ebook/cloud_14Juillet2021.pdf). Très documenté et référencé * Coulisses et manoeuvres pour installer les GAFAM au coeur de l'État * 17 mai 2021, Bercy présente la nouvelle stratégie Cloud du Gouvernement * GAM (Googla Amazon Microsoft) * À part OVH Cloud, aucun des acteurs français n'a été mentionné par les Ministres * Les lois américaines dites FISA et Cloud Act permettent d'obliger les grandes sociétés US à fournir à la justice américaine les données situées sur leurs serveurs européens * Si l'on met de côté les questions de souveraineté, les services de sociétés comme Amazon, Microsoft et Google sont très ergonomiques * Les Américains offrent des services clé en main, les services “made in France” demandent de combiner plusieurs produits issus de sociétés différentes * Apple, Google, Facebook, Amazon ont embauché des dizaines de milliers d'ingénieurs, dont de très talentueux Français * Les clouds GAM pourraient décrocher le label SecNum Cloud (le plus haut niveau de sécurisation de l'État) * Après avoir délocalisé notre industrie (le fameux “Fabless” de Serge Tchuruk ancien patron d'Alcatel), l'État et les grandes entreprises ont délocalisé leur informatique vers les grandes SSII qui se sont mises à produire des projets à la chaîne ## Nous contacter Soutenez Les Cast Codeurs sur Patreon [Faire un crowdcast ou une crowdquestion](https://lescastcodeurs.com/crowdcasting/) Contactez-nous via twitter sur le groupe Google ou sur le site web

Steam Deck looks impressive; we cover the details you care about and one aspect that concerns us. Plus, how Microsoft just gave a boost to the Linux Desktop and more.

Steam Deck looks impressive; we cover the details you care about and one aspect that concerns us. Plus, how Microsoft just gave a boost to the Linux Desktop and more.

Steam Deck looks impressive; we cover the details you care about and one aspect that concerns us. Plus, how Microsoft just gave a boost to the Linux Desktop and more.

Elasticsearch: Easy, fast, and reliableElasticsearch is a highly scalable open source full-text search and analytics engine; it allows you to store, search, and analyze big volumes of data quickly and near real-time. As one of our guests, Jay Miller says, Elasticsearch is “the original idea of making search easy, fast, reliable.” Today with Jay Miller and Ricardo Ferreira, we'll discuss the success cases, tips, why you should use a search engine in your project, and where the project is headed in the future. Ingesting data into ElasticsearchThere's no one right way to ingest data into Elasticsearch; our guests say it depends on your architecture. Jay Miller asks us to consider these questions.What does the data look like?Does the data need to be worked on prior to ingesting it into Elasticsearch?Are you using it in some type of programming language?Jay Miller adds, “Decide what's going to be the easiest for you to maintain, whether you're controlling your ingestion from within your project, or if you're going to add a layer on to it to keep it separated from the rest of the project.”Elasticsearch supports database aggregationDatabase aggregation support in Elasticsearch is powerful because, as Ricardo says, “it allows us different contexts to request and execute aggregations.” He names different programming languages you can use, such as Java, Go, Python, C++, C Sharp, .Net, REST, and Kibana. Ricardo adds, “There's also built-in support for custom aggregations.”When not to use Elasticsearch“Just because Elasticsearch is scalable,” explains Ricardo Ferreira, “it doesn't mean that it will play well with every single use case.” Elasticsearch may not be the best choice when handling transactions, “If you're looking for a highly transactional system that relies on ACID (atomicity, consistency, isolation, durability) you probably will miss one of those letters there. You will have atomicity, isolation, and durability, but not consistency.”Use Elasticsearch on Platform.shPlatform.shLearn more about us.Get started with a free trial.Have a question? Get in touch!Platform.sh on social mediaTwitter @platformshTwitter (France): @platformsh_frLinkedIn: Platform.shLinkedIn (France): Platform.shFacebook: Platform.shWatch, listen, subscribe to the Platform.sh Deploy Friday podcast:YouTubeApple PodcastsBuzzsproutPlatform.sh is a robust, reliable hosting platform that gives development teams the tools to build and scale applications efficiently. Whether you run one or one thousand websites, you can focus on creating features and functionality with your favorite tech stack.

Elastic Stack ist eine verteilte RESTful-Suchmaschine und -Analytics-Engine, die eine wachsende Zahl von Anwendungsfällen abdecken kann. Egal, ob es darum geht, die Top-N-Ereignisse in einem Gewirr textbasierter Dokumente zu finden, Sicherheitsereignisse zu analysieren oder Metriken ohne Beschränkungen zu analysieren. Selbst Milliarden Logzeilen sollen kein Problem darstellen und Trends erkennbar machen. Aber wie funktioniert die Anwendung des Elastic Stacks in der Praxis?Kai berichtet aus der Praxis und teilt seine Erfahrungen.Link zum Fundstück der WocheElasticsearch und Kibana mal ausprobierenOPITZ CONSULTING ■■■ Digitale Service Manufaktur

OpenSearch project was born out of the passion for Elasticsearch and Kibana and the desire to keep them open source in the face of Elastic's decision to close-source them. After a couple of months of hard work led by AWS, the Beta release was announced earlier this month under Apache2 license. On this episode of OpenObservability Talks I hosted Kyle Davis, Senior Developer Advocate for OpenSearch at AWS. We talked about how OpenSearch came to be, what it took to fork Elasticsearch and Kibana, what the engineers discovered when they dug into the code, what's planned ahead, and much more. About Kyle Davis: While being a relative newcomer to Amazon, Kyle has a long history with software development and databases. When not working, Kyle enjoys 3D printing, and getting his hand dirty in his Edmonton, Alberta-based home garden. The episode was live-streamed on 27 May 2021 and the video is available at https://youtube.com/live/UDvWdTeH5V4 Resources: https://github.com/opensearch-project Beta announcement Roadmap available Put the OPEN in Observability: Elasticsearch and Kibana relicensing and community chat - OpenObservability Talks S1E08 Socials: Twitter:⁠ https://twitter.com/OpenObserv⁠ YouTube: ⁠https://www.youtube.com/@openobservabilitytalks⁠

The eighth of our OpenObservability Talks has Tomer Levy, CEO & Founder of Logz.io. The community is in turmoil around Elastic's announced plan to take Elasticsearch and Kibana off open source. In this episode, both Dotan and Mike have the pleasure of hosting Tomer where we discuss the recent news of Elastic moving Elasticsearch and Kibana to a dual non-OSS license - SSPL and Elastic License - and the implications that have on the open source community around it, including plans to fork Elasticsearch and Kibana, AWS announcement and more. We also talk about what Logz.io hopes to do, and how it wants the OSS to be better than ever. Tomer Levy is co-founder and CEO of Logz.io. Before founding Logz.io, Tomer was the co-founder and CTO of Intigua, and prior to that he managed the Intrusion Prevention System at CheckPoint. Tomer has an M.B.A. from Tel Aviv University and a B.S. in computer science and is an enthusiastic kitesurfer. The live streaming of the OpenObservability Talks is on the last Thursday of each month, and you can join us on Twitch or YouTube Live. Socials: Website: https://openobservability.io/ Twitter: https://twitter.com/OpenObserv Twitch: https://www.twitch.tv/openobservability YouTube: https://www.youtube.com/channel/UCLKOtaBdQAJVRJqhJDuOlPg

Why we don't think Red Hat's expanded developer program is enough, our reaction to Ubuntu sticking with an older Gnome release, and a tiny delightful surprise.

In this week's podcast we have a conversation with Kasper Nissen, Site Reliability Engineer at Lunar, about his experience with the new Humio Operator for Kubernetes.  Lunar is a Nordic bank with more than 200,000 users in Denmark, Sweden, and Norway. Lunar seeks to change banking for the better so that its users can control their spending, save smarter and make their money grow. Born in the cloud, Lunar uses technology to react swiftly to user needs and expectations. Previously on The Hoot, Kasper introduced us to Lunar's cloud-native environment, and what it took to make the environment at this innovative fintech startup reliable and secure. The platform is built entirely as a cloud-native app hosted in AWS. Lunar uses Humio to achieve observability into what is happening in all parts of the environment, so they log everything they can from the cloud.  Currently, Kasper is in the process of centralizing log management on a cluster in Lunar's Kubernetes environment. He's using the new Humio Operator to simplify the process of creating and running Humio in Kubernetes.  “Running Humio with the Operator is so much easier because it minimizes the operational overhead of running Humio in Kubernetes. The Operator also provides us with a distributed set up out of the box, which is awesome, especially now that we can push the burden of managing Kafka and Zookeeper, which are notoriously difficult systems to run, to the cloud provider.”  Kasper Nissen, SRE at Lunar Listen to our conversation with Kasper to learn:  How Humio addresses the challenge of volumes being tied to Availability Zones in AWS How the Humio Operator simplifies the deployment and management of Humio in Kubernetes How Lunar uses Humio and Git as a single source of truth for all of its environments How Humio helps Lunar optimize their cloud storage Show notes:  Listen to episode 32, when Kasper introduced us to Lunar's cloud-native environment. Read about Lunar's log management journey, which took them from an Elasticsearch and Kibana setup to Humio.  Learn more about the Humio Operator for running Humio on Kubernetes.  Watch an on-demand webinar to learn more about the Humio Operator from one of the engineers who helped build it!

Apple Security Updates Details Released https://support.apple.com/en-us/HT201222 Untitled Goose Deserialization https://pulsesecurity.co.nz/advisories/untitled-goose-game-deserialization Insecure Pagers Leak Medical Data https://techcrunch.com/2019/10/30/nhs-pagers-medical-health-data/ Kibana Vulnerablity https://research.securitum.com/prototype-pollution-rce-kibana-cve-2019-7609/

Christian Saide and Devin Bernosky of NS1 join Aaron and Mike to talk about what NS1 does and how they leverage the Elastic stack to provide data-driven DNS. The latest news regarding Elastic going public and changes to Kibana are mentioned and we answer the question: 'What is an availability zone in the context of Elastic Cloud?'

Rashid Khan joins Mike and Aaron to discuss the Canvas project in Kibana--a composable, extendable, creative space for live data. Aaron and Mike answer "What is the difference between Beats and Logstash".

This week on the podcast, Kyle talks about Push Notifications he built for Phire and how you could extend Phire. Dan explains the pt_password DPK Puppet Type, and Kyle discusses a leak of 2 billion passwords. Show Notes 2 Billion Passwords @ 1:00 pt_password Puppet Type @ 5:30 Kibana and PeopleSoft @ 12:15 Push Notifications and Phire @ 24:30 Andy Dorfman's Push Notifications Write-up Writing Push Notifications

Mark Rittman is joined by Elastic's Mark Walkom to talk about Elasticsearch, Kibana, Logstash and the Elastic Stack; business models built-around an open-source software core; and their move into cloud services with Elastic Cloud

This week on the podcast, Dan and Kyle talk about using web traffic data to analyze user activity, new information on Jolt Failover, and how we generate and distribute compare reports. Then, they discuss Critical Patch Updates and how they affect PeopleSoft Administrators. Show Notes Building a Billion User Load Balancer @ 1:30 X-Forwarded-For and Kibana @ 6:00 Alliance 2017 Presentation Collaborate 2017 Presentation Windows Command Line Tip and Windows 10 @ 14:45 start . Jolt Failover Update @ 20:45 Response Compression and Servlet Filters @ 27:45 LLE Warnings in Tuxedo Logs @ 30:30 How Do You Do it? Compare Reports @ 31:30 Define Compare Location in Config Manager CPU Patching and Testing @ 40:00 Comparing Download Hashes Recommended Patch Advisor Java MOS Homepage CPU Patching with the DPK? Not yet.

This week on the show, we have an interview with Jamie This episode was brought to you by Headlines BSDCan 2016 List of Talks (http://www.bsdcan.org/2016/list-of-talks.txt) We are all looking forward to BSDCan Make sure you arrive in time for the Goat BoF, the evening of Tuesday June 7th at the Royal Oak, just up the street from the university residence There will also be a ZFS BoF during lunch of one of the conference days, be sure to grab your lunch and bring it to the BoF room Also, don't forget to get signed up for the various DevSummits taking place at BSDCan. *** What does Load Average really mean (https://utcc.utoronto.ca/~cks/space/blog/unix/ManyLoadAveragesOfUnix) Chris Siebenmann, a sysadmin at the University of Toronto, does some comparison of what “Load Average” means on different unix systems, including Solaris/IllumOS, FreeBSD, NetBSD, OpenBSD, and Linux It seems that no two OSes use the same definition, so comparing load averages is impossible On FreeBSD, where I/O does not affect load average, you can divide the load average by the number of CPU cores to be able to compare across machines with different core counts *** GPL violations related to combining ZFS and Linux (http://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/) As we mentioned in last week's episode, Ubuntu was preparing to release their next version with native ZFS support. + As expected, the Software Freedom Conservancy has issued a statement detailing the legal argument why they believe this is a violation of the GPL license for the Linux kernel. It's a pretty long and complete article, but we wanted to bring you the summary of the whole, and encourage you to read the rest, since it's good to be knowledgeable about the various open-source projects and their license conditions. “We are sympathetic to Canonical's frustration in this desire to easily support more features for their users. However, as set out below, we have concluded that their distribution of zfs.ko violates the GPL. We have written this statement to answer, from the point of view of many key Linux copyright holders, the community questions that we've seen on this matter. Specifically, we provide our detailed analysis of the incompatibility between CDDLv1 and GPLv2 — and its potential impact on the trajectory of free software development — below. However, our conclusion is simple: Conservancy and the Linux copyright holders in the GPL Compliance Project for Linux Developers believe that distribution of ZFS binaries is a GPL violation and infringes Linux's copyright. We are also concerned that it may infringe Oracle's copyrights in ZFS. As such, we again ask Oracle to respect community norms against license proliferation and simply relicense its copyrights in ZFS under a GPLv2-compatible license.” The Software Freedom Law Center's take on the issue (https://softwarefreedom.org/resources/2016/linux-kernel-cddl.html) Linux SCSI subsystem Maintainer, James Bottomley, asks “where is the harm” (http://blog.hansenpartnership.com/are-gplv2-and-cddl-incompatible/) FreeBSD and ZFS (http://freebsdfoundation.blogspot.ca/2016/02/freebsd-and-zfs.html) *** DragonFly i915 reaches Linux 4.2 (https://www.phoronix.com/scan.php?page=news_item&px=DragonFlyBSD-i915-4.2) The port of the Intel i915 DRM/KMS Linux driver to DragonFlyBSD has been updated to match Linux kernel 4.2 Various improvements and better support for new hardware are included One big difference, is that DragonFlyBSD will not require the binary firmware blob that Linux does François Tigeot explains: "starting from Linux 4.2, a separate firmware blob is required to save and restore the state of display engines in some low-power modes. These low-power modes have been forcibly disabled in the DragonFly version of this driver in order to keep it blob-free." Obviously this will have some disadvantage, but as those modes were never available on DragonFlyBSD before, users are not likely to miss them *** Interview - Jamie McParland - mcparlandj@newberg.k12.or.us (mailto:mcparlandj@newberg.k12.or.us) / @nsdjamie (https://twitter.com/nsdjamie) FreeBSD behind the chalkboard *** iXsystems My New IXSystems Mail Server (https://www.reddit.com/r/LinuxActionShow/comments/48c9nt/my_new_ixsystems_mail_server/) News Roundup Installing ELK on FreeBSD, Tutorial Part 1 (https://blog.gufi.org/2016/02/15/elk-first-part/) Are you an ELK user, or interested in becoming one? If so, Gruppo Utenti has a nice blog post / tutorial on how to get started with it on FreeBSD. Maybe you haven't heard of ELK, but its not the ELK in ports, specifically in this case he is referring to “ElasticSearch/Logstash/Kibana” as a stack. Getting started is relatively simply, first we install a few ports/packages: textproc/elasticsearch sysutils/logstash textproc/kibana43 www/nginx After enabling the various services for those (hint: sysrc may be easier), he then takes us through the configuration of ElasticSearch and LogStash. For the most part they are fairly straightforward, but you can always copy and paste his example config files as a template. Follow up to Installing ELK on FreeBSD (https://blog.gufi.org/2016/02/23/elk-second-part/) Jumping directly into the next blog entry, he then takes us through the “K” part of ELK, specifically setting up Kibana, and exposing it via nginx publically. At this point most of the CLI work is finished, and we have a great walkthrough of doing the Kibana configuration via their UI. We are still awaiting the final entry to the series, where the setup of ElastAlert will be detailed, and we will bring that to your attention when it lands. *** From 1989: An Empirical Study of the Reliablity of Unix Utilities (http://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf) A paper from 1989 on the results of fuzz testing various unix utilities across a range of available unix operating systems Very interesting results, it is interesting to look back at before the start of the modern BSD projects New problems are still being found in utilities using similar testing methodologies, like afl (American Fuzzy lop) *** Google Summer of Code Both FreeBSD (https://summerofcode.withgoogle.com/organizations/4892834293350400/) and NetBSD (https://summerofcode.withgoogle.com/organizations/6246531984261120/) Are running 2016 Google Summer of Code projects. Students can start submitting proposals on March 14th. In the meantime, if you have any ideas, please post them to the Summer Of Code Ideas Page (https://wiki.freebsd.org/SummerOfCodeIdeas) on the FreeBSD wiki Students can start looking at the list now and try to find mentors to get a jump start on their project. *** High Availablity Sync for ipfw3 in Dragonfly (http://lists.dragonflybsd.org/pipermail/commits/2016-February/459424.html) Similar to pfsync, this new protocol allows firewall dynamic rules (state) to be synchronized between two firewalls that are working together in HA with CARP Does not yet sync NAT state, it seems libalias will need some modernization first Apparently it will be relatively easy to port to FreeBSD This is one of the only features ipfw lacks when compared to pf *** Beastie Bits FreeBSD 10.3-BETA3 Now Available (https://lists.freebsd.org/pipermail/freebsd-stable/2016-February/084238.html) LibreSSL isnt affected by the OpenSSL DROWN attack (http://undeadly.org/cgi?action=article&sid=20160301141941&mode=expanded) NetBSD machines at the Open Source Conference 2016 in Toyko (http://mail-index.netbsd.org/netbsd-advocacy/2016/02/29/msg000703.html) OpenBSD removes Linux Emulation (https://marc.info/?l=openbsd-ports-cvs&m=145650279825695&w=2) Time is an illusion - George Neville-Neil (https://queue.acm.org/detail.cfm?id=2878574) OpenSSH 7.2 Released (http://www.openssh.com/txt/release-7.2) Feedback/Questions Shane - IPSEC (http://slexy.org/view/s2qCKWWKv0) Darrall - 14TB Zpool (http://slexy.org/view/s20CP3ty5P) Pedja - ZFS setup (http://slexy.org/view/s2qp7K9KBG) ***

This week on the show we'll be talking with Hiroki Sato about the status of BSD in Japan. We also get to hear about how he got on the core team, and we just might find out why NetBSD is so popular over there! Answers to all your emails, the latest news, and even a brand new segment, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines BSD talks at XDC 2014 (https://www.youtube.com/channel/UCXlH5v1PkEhjzLFTUTm_U7g/videos) This year's Xorg conference featured a few BSD-related talks Matthieu Herrb, Status of the OpenBSD graphics stack (https://www.youtube.com/watch?v=KopgD4nTtnA) Matthieu's talk details what's been done recently in Xenocara the OpenBSD kernel for graphics (slides here (http://www.openbsd.org/papers/xdc2014-xenocara.pdf)) Jean-Sébastien Pédron, The status of the graphics stack on FreeBSD (https://www.youtube.com/watch?v=POmxFleN3Bc) His presentation gives a history of major changes and outlines the current overall status of graphics in FreeBSD (slides here (http://www.x.org/wiki/Events/XDC2014/XDC2014PedronFreeBSD/XDC-2014_FreeBSD.pdf)) Francois Tigeot, Porting DRM/KMS drivers to DragonFlyBSD (https://www.youtube.com/watch?v=NdM7_yPGFDk) Francois' talk tells the story of how he ported some of the DRM and KMS kernel drivers to DragonFly (slides here (http://www.x.org/wiki/Events/XDC2014/XDC2014TigeotDragonFlyBSD/XDC-2014_Porting_kms_drivers_to_DragonFly.pdf)) *** FreeBSD Quarterly Status Report (https://www.freebsd.org/news/status/report-2014-07-2014-09.html) The FreeBSD project has a report of their activities between July and September of this year Lots of ARM work has been done, and a goal for 11.0 is tier one support for the platform The release includes reports from the cluster admin team, release team, ports team, core team and much more, but we've already covered most of the items on the show If you're interested in seeing what the FreeBSD community has been up to lately, check the full report - it's huge *** Monitoring pfSense logs using ELK (http://elijahpaul.co.uk/monitoring-pfsense-2-1-logs-using-elk-logstash-kibana-elasticsearch/) If you're one of those people who loves the cool graphs and charts that pfSense can produce, this is the post for you ELK (ElasticSearch, Logstash, Kibana) is a group of tools that let you collect, store, search and (most importantly) visualize logs It works with lots of different things that output logs and can be sent to one central server for displaying This post shows you how to set up pfSense to do remote logging to ELK and get some pretty awesome graphs *** Some updates to IPFW (https://svnweb.freebsd.org/base?view=revision&revision=272840) Even though PF gets a lot of attention, a lot of FreeBSD people still love IPFW While mostly a dormant section of the source tree, some updates were recently committed to -CURRENT The commit lists the user-visible changes, performance changes, ABI changes and internal changes It should be merged back to -STABLE after a month or so of testing, and will probably end up in 10.2-RELEASE Also check this blog post (http://blog.cochard.me/2014/10/ipfw-improvement-on-freebsd-current.html) for some more information and fancy graphs *** Interview - Hiroki Sato (佐藤広生) - hrs@freebsd.org (mailto:hrs@freebsd.org) / @hiroki_sato (https://twitter.com/hiroki_sato) BSD in Japan, technology conferences, various topics News Roundup pfSense on Hyper-V (https://virtual-ops.de/?p=600) In case you didn't know, the latest pfSense snapshots support running on Hyper-V Unfortunately, the current stable release is based on an old, unsupported FreeBSD 8.x base, so you have to use the snapshots for now The author of the post tells about his experience running pfSense and gives lots of links to read if you're interested in doing the same He also praises pfSense above other Linux-based solutions for its IPv6 support and high quality code *** OpenBSD as a daily driver (https://www.reddit.com/r/openbsd/comments/2isz24/openbsd_as_a_daily_driver/) A curious Reddit user posts to ask the community about using OpenBSD as an everyday desktop OS The overall consensus is that it works great for that, stays out of your way and is quite reliable Caveats would include there being no Adobe Flash support (though others consider this a blessing..) and it requiring a more hands-on approach to updating If you're considering running OpenBSD as a "daily driver," check all the comments for more information and tips *** Getting PF log statistics (https://secure.ciscodude.net/2014/10/09/firewall-log-stats/) The author of this post runs an OpenBSD box in front of all his VMs at his colocation, and details his experiences with firewall logs He usually investigates any IPs of interest with whois, nslookup, etc. - but this gets repetitive quickly, so.. He sets out to find the best way to gather firewall log statistics After coming across a perl script (http://www.pantz.org/software/pf/pantzpfblockstats.html) to do this, he edited it a bit and is now a happy, lazy admin once again You can try out his updated PF script here (https://github.com/tbaschak/Pantz-PFlog-Stats) *** FlashRD 1.7 released (http://www.nmedia.net/flashrd/) In case anyone's not familiar, flashrd is a tool to create OpenBSD images for embedded hardware devices, executing from a virtualized environment This new version is based on (the currently unreleased) OpenBSD 5.6, and automatically adapts to the number of CPUs you have for building It also includes fixes for 4k drives and lots of various other improvements If you're interested in learning more, take a look at some of the slides and audio from the main developer on the website *** Feedback/Questions Antonio writes in (http://slexy.org/view/s20XvSa4h0) Don writes in (http://slexy.org/view/s20lGUXW3d) Andriy writes in (http://slexy.org/view/s2al5DFIO7) Richard writes in (http://slexy.org/view/s203QoFuWs) Robert writes in (http://slexy.org/view/s29WIplL6k) *** Mailing List Gold Subtle trolling (https://marc.info/?l=openbsd-cvs&m=141271076115386&w=2) Old bugs with old fixes (https://marc.info/?l=openbsd-cvs&m=141275713329601&w=2) A pig reinstall (https://lists.freebsd.org/pipermail/freebsd-ports/2014-October/095906.html) Strange DOS-like environment (https://lists.freebsd.org/pipermail/freebsd-doc/2014-October/024408.html) ***